From nobody Wed Oct 1 06:27:39 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB191A039A for ; Wed, 1 Oct 2014 06:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.9 X-Spam-Level: * X-Spam-Status: No, score=1.9 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_16=0.6, J_CHICKENPOX_92=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQ3dn7F0jpXd for ; Wed, 1 Oct 2014 06:27:35 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F1A11A038E for ; Wed, 1 Oct 2014 06:27:35 -0700 (PDT) Received: by mail-pa0-f49.google.com with SMTP id hz1so275379pad.8 for ; Wed, 01 Oct 2014 06:27:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=e+wTPUL6ygOvB8Xiw40LHwhDywKrVpIOIs/sa2nh+bw=; b=YwZhD9yZ/qFIMdTA1vFrvzaF4a1n59HWMCmoqIo2w6FPqxy3PzfhPQtlF/pqdcCcrF 3sONU6YtjbchzA/gAIYMlo2p/DU/JRTwT/FaydvWNM/lNlieqHbO+laGOOHr/YeE95lF B547tyQv9fhfkudlZg0tvTZBIdruB7xNs58rTZX0VF3wMKO9aNUt2nUvrs+5tdft7GrZ 7VEx3TWDoTFCXpDc5zy2MljiuncCuThPSnHc6rmhpwS4XAKGcqeiO/pmYtCCjstanU1F 9paIbcNl2ik7im2M5DDuCHfRNq7XUrVh89cZpJzUGcwd0QRlpAxoYkm0VlXuA6yKy5QO +Jbg== X-Received: by 10.70.96.237 with SMTP id dv13mr15623494pdb.66.1412170054913; Wed, 01 Oct 2014 06:27:34 -0700 (PDT) Received: from ?IPv6:2601:9:7680:f38:34f1:bb5:6bef:3a9b? ([2601:9:7680:f38:34f1:bb5:6bef:3a9b]) by mx.google.com with ESMTPSA id c3sm1103791pbu.15.2014.10.01.06.27.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 01 Oct 2014 06:27:34 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Douglas Otis In-Reply-To: <87oatwuvgf.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Wed, 1 Oct 2014 06:27:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <24B9D0D2-5797-45F1-A44F-0EB1F20CEE72@gmail.com> References: <20140922211530.53023.qmail@joyce.lan> <1561541.nWppMeomLX@scott-latitude-e6320> <6CE8A547-291D-4D07-9A66-0CC95F8F61BC@gmail.com> <877g0lwq58.fsf@uwakimon.sk.tsukuba.ac.jp> <9EEFB48E-A456-433B-B435-2ADE90FDB95B@gmail.com> <87oatwuvgf.fsf@uwakimon.sk.tsukuba.ac.jp> To: "Stephen J. Turnbull" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/jAYVb80WIMI7A7J_aZwAPTzgjYI Cc: dmarc@ietf.org, Douglas Otis Subject: Re: [dmarc-ietf] yet more From rewriting, X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 13:27:37 -0000 On Sep 30, 2014, at 11:59 PM, Stephen J. Turnbull = wrote: > Douglas Otis writes: >=20 >> Thank you for your response, but it seems to overlook a few >> important issues. >=20 > Indeed I overlooked them, but that's because in the context of this > working group I consider them unimportant. As follows: >=20 >> The view of DMARC being a private agreement between MX servers >> assumes services to the general public are normally categorized as >> common carriers to ensure against discrimination and franchise >> abuse. >=20 > [...] >=20 >> To overcome misuse of DMARC policies, email reliant services are >> then FORCED to alter the content of their =46rom header fields into >> non-compliant forms as their only means to ensure the integrity of >> their own service. Such behavior clearly moves DMARC well beyond >> the realm of private agreements. >=20 > [...] >=20 >> SPF is being used by the Kelihos peer-to-peer botnet variant as a >> means to create DMARC valid messages [...]. DMARC is also not >> effective against look-alike attacks [...]. >=20 > Abuse of common carrier status is not IETF business, is it? Again thank you for your thoughtful response. If only it was abuse of a = common carrier status. Be careful not to take a naive view about what = to expect from a large ISP that has had a prolonged series of massive = account compromises. That said, when their proposed solution has a high = propensity to impact legitimate email services, such as forums like this = one, it is time to find a better alternative. People should find it = disturbing being forced to look into spam folders for messages from = officers of a company attempting to make exchanges in similar forums. = It seems they all do it initially and many persist expecting some kind = of 'special' treatment. Talk about dangerous and spurious correlations = being given to the common folk. > As for > private decisions and agreements having external effects, what else is > new? The important content of "private agreement" is that outsiders > can make all the "standards" they like, but the parties need not adopt > them and can continue their behavior. Whether DMARC is effective or > not is also outside of the scope of this WG. When DMARC's reject or quarantine policy is applied against normal email = accounts held by many millions of typical users, an option whether to = mitigate damage to reliant email services, such as that of this forum, = can not be considered some kind of adoption option. In fact, the = charter for this WG states: ,--- ...DMARC is problematic for mail that does not flow from operators = having a relationship with the domain owner, directly to receivers = operating the destination mailbox (for example, mailing lists, = publish-to-friend functionality, mailbox forwarding via ".forward", and = third-party services that send on behalf of clients). The working group = will explore possible updates and extensions to the specifications in = order to address limitations and/or add capabilities. It will also = provide technical implementation guidance and review possible = enhancements elsewhere in the mail handling sequence that could improve = DMARC compatibility. Finding methods to better mitigate against the = disruption affecting legitimate services is very much within the scope = of this WG. '--- > Bottom line: DMARC is a non-IETF standard prevalent on the Internet, > and the WG charter takes that as given as far as I can see. I grant > that discussion of these issues provides context, but if I choose not > to discuss them, I don't see a problem for conducting WG business. Some ISPs seem content taking inadequate measures to address their = growing account compromise problems. Originally, DMARC only ensured = customers receiving high-value transactional messages would not see high = levels of spoofing the service attracted. DMARC was never intended to = address massive compromises of contacts and credentials, nor is its = current form suitable for use with general email. As such, it seems it = is unlikely to be considered suitable as a proposed standard, no matter = how prevalent its mis-application becomes. Haphazard mitigation = strategies caused by a laissez-faire approach is likely to incur greater = harm and disruption, at the crux of the matter to be handled by this WG, = unless I am woefully mistaken. >> At least adopting a standard DMARC Group exception should give >> potential victims a clue something is different about the message. >=20 > "Should", yes, I agree in some sense. Unfortunately, at least one HCI > paper I read (I am not a specialist) says many potential victims are > clueless, and most lack some important clues for protecting their own > security. >=20 > What worries me is that users will pick up on a spurious correlation > (the same research provides evidence for that) and interpret the > visible artifacts (such as a DMARC-noncompliant tag) incorrectly. > Specifically, they'll interpret as just another example of computer > breakage, and ignore it in favor of their trust relationship with the > apparent author. Perhaps the group name might use something more plain, like U+2620 skull = and crossbones =E2=98=A0 or perhaps DMARC-UNKNOWN > Remember, *we* know that a great majority of all messages getting that > tag are spam, but *the users* never notice them -- many are discarded > automatically and those in the spam bucket get discarded without > thought -- unless the message is actually from a trusted party, which > validates the "computer is broken" hypothesis from that point of view. Again, DMARC is not comprehensive since it still permits various = look-alike attacks. Not allowing exceptions results in users checking = their spam folders, a far worse practice. >> In the era of botnets, spammers are able to create DMARC valid >> messages without much difficulty. >=20 > Who needs a botnet? Anybody with access to any domain's DNS can do > that. I suppose your point is that somebody with a botnet is able to > send From-aligned messages from a Yahoo! address. I don't see how > anything authentication-based can deal with such malicious mail, by > definition -- the bot must be able to authenticate to send it. To > combat such abuse, you need to examine content of outgoing messages as > well as incoming messages. "Defense in depth" is the watchword here. >=20 > But that doesn't make DMARC "D for dangerous"or useless. The point of > Yahoo!'s and AOL's use case (thanks to Alessandro Veseley here for > making me aware of this) is that the "acquaintance recommendation" > spam or phish is based on the ability to spoof a *particular* user to > another user, and this is based on an *external* (stolen) contact > list. A bot can't do that arbitrarily: because of the way message > submission works, it needs to authenticate to pass DMARC p=3Dreject. I find less threats reading messages in mailing-lists than in my inbox. = You must be horrified anyone reading these messages can spoof you as me, = Alessandro, and others. How do you cope without DMARC protection? I = too have seen spoofs of friends purporting to be stuck in an airport in = Turkey claiming to have lost their wallet and cell phone.=20 > I suppose if you have both that list and the list of bots, you could > match them up and use the "right" bot for this contact list (although > the number of matches would be a smallish fraction of all contacts, I > suppose). (Not to mention that if you have such a 'bot, it seems more > sensible to just use its contact list if you're going to try > "acquaintance recommendation spam".) So apparently that isn't what is > happening, as p=3Dreject was effective to combat the April attacks. DMARC represents a poorly considered reaction that disrupts normal email = use. Basic security issues must still be addressed such as sloppy use = of SPF for example. It took TW forever to implement TLS. Disruptions = can be mitigated by DMARC domains' use of TPA-Labels where no other = change would be needed, or by adoption of a group label rewrite strategy = where users would require some education. It seems the alternatives are = much worse. Regards, Douglas Otis= From nobody Wed Oct 1 20:41:12 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A5C1A0048 for ; Wed, 1 Oct 2014 20:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.309 X-Spam-Level: *** X-Spam-Status: No, score=3.309 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CiooVOa4vzIb for ; Wed, 1 Oct 2014 20:41:08 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 9EEEF1A0056 for ; Wed, 1 Oct 2014 20:41:08 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id EDD271C39FF; Thu, 2 Oct 2014 12:41:06 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id E21E41A2697; Thu, 2 Oct 2014 12:41:06 +0900 (JST) From: "Stephen J. Turnbull" To: Douglas Otis In-Reply-To: <24B9D0D2-5797-45F1-A44F-0EB1F20CEE72@gmail.com> References: <20140922211530.53023.qmail@joyce.lan> <1561541.nWppMeomLX@scott-latitude-e6320> <6CE8A547-291D-4D07-9A66-0CC95F8F61BC@gmail.com> <877g0lwq58.fsf@uwakimon.sk.tsukuba.ac.jp> <9EEFB48E-A456-433B-B435-2ADE90FDB95B@gmail.com> <87oatwuvgf.fsf@uwakimon.sk.tsukuba.ac.jp> <24B9D0D2-5797-45F1-A44F-0EB1F20CEE72@gmail.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Thu, 02 Oct 2014 12:41:06 +0900 Message-ID: <877g0juoj1.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/UxQHcNJEQRtQ3Oee7dLXIHiYMh0 Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] yet more From rewriting, X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 03:41:10 -0000 I think this is going around in circles so I've replied at length off-list. This one opinion I wish to respond to on-list, though. Douglas Otis writes: > DMARC represents a poorly considered reaction Even though I'm a mailing list user, owner, and developer, I cannot agree. I *wish* that they had put MLs at the top of the list of issues when discussing whether to impose "p=reject" or not, but get serious. That's really not that big a deal for their users compared to network disruption and a flood of spam, not to mention falling victim to fraud.[1] My conversations with Yahoo! techs indicate that they are competent, hard-working, and ethical. I conclude that when they say "p=reject" was the best option, they mean it and it was chosen carefully. True, I don't recall an explicit apology from a Yahoo! tech[2], even in non-public channels, but I suppose "Yahoo! has something to be sorry for" is covered by their NDA. :-) So I give them credit for *feeling* sorry even if they don't say it. :-) Footnotes: [1] Please don't respond that they shouldn't have leaked contact lists in the first place. That's true, but irrelevant -- these things happen (I know from experience :-( ), and we should assume they're going to continue to happen even with state-of-the-art security. [2] My memory is fallible, though. From nobody Thu Oct 2 16:17:03 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEEB61ACF18 for ; Thu, 2 Oct 2014 16:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.099 X-Spam-Level: * X-Spam-Status: No, score=1.099 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_110=0.6, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBUKFRdFHY6Q for ; Thu, 2 Oct 2014 16:17:00 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F3541ACF16 for ; Thu, 2 Oct 2014 16:17:00 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id lf10so225917pab.2 for ; Thu, 02 Oct 2014 16:16:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NoeBSkfXgs8xSIp3mtpKWLLhfozNgjX0rPq4ukHhVnk=; b=nxRj0JG7CfmB17FvD7GRkEAy7eax0jioHwHLArIiKz7ecpDgiI91jL1SHHS2eQJ0S8 2+pGlsCb7fCcImv4us81GCcNc1zNTDHG/vlvgPzo+Rogl5SsPqE5tgIXvGO6o+KI5AJR xu6jr945GPgM7Ct9GjUdgVusXg1hOEb8ChTXN68Myk4LAS95Lvbp5YaYxWYXYZMaB+Z8 I2FLC1OWprY7foLibB5X3dJZ1BQITuJ91ILrNol8BWAu5q7nFuBTPhOMY9r9SnEX71yj YlqgPUHH6VnL8Uflyooh79WC2NlMr1Cw/fF8XFPzvF4n7g8hBDi8x/OuczJ4wqwSCX0d DNfA== X-Received: by 10.66.118.136 with SMTP id km8mr2877636pab.54.1412291819047; Thu, 02 Oct 2014 16:16:59 -0700 (PDT) Received: from [192.168.2.226] (c-67-188-1-12.hsd1.ca.comcast.net. [67.188.1.12]) by mx.google.com with ESMTPSA id uj7sm5016083pac.4.2014.10.02.16.16.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Oct 2014 16:16:55 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=utf-8 From: Douglas Otis In-Reply-To: <877g0juoj1.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Thu, 2 Oct 2014 16:11:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140922211530.53023.qmail@joyce.lan> <1561541.nWppMeomLX@scott-latitude-e6320> <6CE8A547-291D-4D07-9A66-0CC95F8F61BC@gmail.com> <877g0lwq58.fsf@uwakimon.sk.tsukuba.ac.jp> <9EEFB48E-A456-433B-B435-2ADE90FDB95B@gmail.com> <87oatwuvgf.fsf@uwakimon.sk.tsukuba.ac.jp> <24B9D0D2-5797-45F1-A44F-0EB1F20CEE72@gmail.com> <877g0juoj1.fsf@uwakimon.sk.tsukuba.ac.jp> To: "Stephen J. Turnbull" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/16wOdRB4YqD2KZXLU4pvlmibKtg Cc: dmarc@ietf.org, Douglas Otis Subject: Re: [dmarc-ietf] yet more From rewriting, X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 23:17:01 -0000 On Oct 1, 2014, at 8:41 PM, Stephen J. Turnbull = wrote: > I think this is going around in circles so I've replied at length > off-list. This one opinion I wish to respond to on-list, though. >=20 > Douglas Otis writes: >=20 >> DMARC represents a poorly considered reaction >=20 > Even though I'm a mailing list user, owner, and developer, I cannot > agree. I *wish* that they had put MLs at the top of the list of > issues when discussing whether to impose "p=3Dreject" or not, but get > serious. That's really not that big a deal for their users compared > to network disruption and a flood of spam, not to mention falling > victim to fraud.[1] My conversations with Yahoo! techs indicate that > they are competent, hard-working, and ethical. I conclude that when > they say "p=3Dreject" was the best option, they mean it and it was > chosen carefully. Dear Stephen,=20 =46rom your response, I can more clearly understand where our views = differ, and for that, thank you. p=3Dreject should NOT be seen as having been their best policy solution = applied against general purpose or public user accounts! The typical = reaction to the disruption they created was to translate their p=3Dreject = into p=3Dquarantine. This reaction also represents a similarly = expedient solution. Not expecting such a reaction would be naive in my = opinion. Also note, those who created DMARC did not expect their = protocol to be abused in this manner. As such, the reaction to the = resulting disruption showed a reject policy was not well considered. = Since this also injured competing mailing-lists, some may even view = p=3Dquarantine as not ethical especially when applied over an extended = duration. This is why the role of a common carrier was mentioned. = Taking on the role of common carrier would impact ISPs in several = interesting ways. :^) My suggestions were all aimed at extending or tweaking DMARC to be even = more effective while not disrupting legitimate services, such as those = offered by Intuit as an example. One was to craft a specific exception = list to excuse responsible third-party services employed by their user = base. The other was to have the protocol adopt a highly visible =46rom = scheme that permits specific group syntax such as =E2=98=A0: or = DMARC-UNKNOWN: where DMARC would not be applied. Those promoting DMARC = are euphoric for the most part DMARC published policies are being = applied. As these policies become abused with an excuse it offers no = means to make exceptions, this success seems destine to fade. The next = stage of abuse seems likely to attack its relatively weak SPF = authorization scheme. If so, we might find ourselves once again looking = for a policy assertions effective against a new flood of abuse. Now = that would be a true circle.=20 Regards, Douglas Otis From nobody Thu Oct 2 16:46:05 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 119641ACF16 for ; Thu, 2 Oct 2014 16:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.178 X-Spam-Level: X-Spam-Status: No, score=-0.178 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_110=0.6, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOru5u4Odu-9 for ; Thu, 2 Oct 2014 16:46:04 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 095D61A87DE for ; Thu, 2 Oct 2014 16:46:03 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id a1so175423wgh.23 for ; Thu, 02 Oct 2014 16:46:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=twitter.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=aid80qubi7LNUu8q78BvaunjAlNPKXDdEwW495I50n8=; b=lNgmZH+70mK7/QSPyWrW1o+N5ATdzrYsZvqIfmyCl72X5litW/ZWx5+kSVYMHwSLcn pErO/16uZl0zx9+MzBAuWXmATt9FJZR8kQqgKClhVgGK/Tau7/WCmwOLRwv5Llb/UOYu ynkvr5r2V6rcD5I5HcpdC52FoCCYO2w3TPIg4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=aid80qubi7LNUu8q78BvaunjAlNPKXDdEwW495I50n8=; b=SevKgrrFmYgFHVZ68RbW+BUuvC6g79rBOQiCEqeBLP+dWyeOGo4rroA0zuHAja9l44 5UOk891mB5d7TZN2JW7lESmwLqiIcAcUFVVjcNClOOOF7Gybzfc9O1+lIbfQa3hJQK6c f+xLT/JavjoLy0B7d82nbOu31Qe8Dr36o1h6eGCGLtOh3w3TbXm2CcL/ZZWP7tdNozvF i8XrL8NAhrz2zYdkzTafFUbGoK+0Z1KLk3T/oKcUCpKmSwqIIoVEIF9hzYqwEGDmbd5i ci4oVfLfA8iMPgZTJpF4F0ZZMXAtu/jHX8GOWQbXzsn+uf8l4oxYVhIhYMUxdcDUSrvy b5wQ== X-Gm-Message-State: ALoCoQlnIPm6rDNkpVfLaCkLIYR5ljb8z042uiDIAoW/B0F8yEe647ZmSBb25++Ylh8d11uG4mnJ X-Received: by 10.194.222.232 with SMTP id qp8mr2646989wjc.94.1412293562332; Thu, 02 Oct 2014 16:46:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.103.227 with HTTP; Thu, 2 Oct 2014 16:45:42 -0700 (PDT) In-Reply-To: References: <20140922211530.53023.qmail@joyce.lan> <1561541.nWppMeomLX@scott-latitude-e6320> <6CE8A547-291D-4D07-9A66-0CC95F8F61BC@gmail.com> <877g0lwq58.fsf@uwakimon.sk.tsukuba.ac.jp> <9EEFB48E-A456-433B-B435-2ADE90FDB95B@gmail.com> <87oatwuvgf.fsf@uwakimon.sk.tsukuba.ac.jp> <24B9D0D2-5797-45F1-A44F-0EB1F20CEE72@gmail.com> <877g0juoj1.fsf@uwakimon.sk.tsukuba.ac.jp> From: Josh Aberant Date: Thu, 2 Oct 2014 16:45:42 -0700 Message-ID: To: dmarc@ietf.org Content-Type: multipart/alternative; boundary=001a11c3baa01a12530504793804 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/6mCyzSyLWAxusbsM8TOWb0WyfoQ Subject: Re: [dmarc-ietf] yet more From rewriting, X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 23:46:05 -0000 --001a11c3baa01a12530504793804 Content-Type: text/plain; charset=UTF-8 > The typical reaction to the disruption they created was to translate their > p=reject into p=quarantine. > Would you provide some proof of this assertion? Josh --001a11c3baa01a12530504793804 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

=
The typical reaction to the disruption they created was to translate their = p=3Dreject into p=3Dquarantine.
=C2=A0
Would= you provide some proof of this assertion?

Josh
--001a11c3baa01a12530504793804-- From nobody Thu Oct 2 19:24:04 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F96F1ACFEA for ; Thu, 2 Oct 2014 19:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.863 X-Spam-Level: ** X-Spam-Status: No, score=2.863 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_110=0.6, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLS97Ft5wkNq for ; Thu, 2 Oct 2014 19:24:02 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1536C1A0275 for ; Thu, 2 Oct 2014 19:24:01 -0700 (PDT) Received: (qmail 33904 invoked from network); 3 Oct 2014 02:24:00 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 3 Oct 2014 02:24:00 -0000 Date: 3 Oct 2014 02:23:38 -0000 Message-ID: <20141003022338.3339.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/65wAym2Sb8Bcai3xb7SpojDUMEU Cc: jaberant@twitter.com Subject: Re: [dmarc-ietf] yet more From rewriting, X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 02:24:03 -0000 >> The typical reaction to the disruption they created was to translate their >> p=reject into p=quarantine. > >Would you provide some proof of this assertion? I'm not Doug, but Google unquestionably did that when AOL and Yahoo started publishing p=reject. R's, John From nobody Thu Oct 2 20:15:57 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCE9C1A010C for ; Thu, 2 Oct 2014 20:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.588 X-Spam-Level: X-Spam-Status: No, score=-1.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_110=0.6, J_CHICKENPOX_16=0.6, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8NYw84NPW88 for ; Thu, 2 Oct 2014 20:15:53 -0700 (PDT) Received: from articuno.alameth.org (articuno.alameth.org [IPv6:2600:3c01::f03c:91ff:fe70:755c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 015341A000F for ; Thu, 2 Oct 2014 20:15:52 -0700 (PDT) Received: from [192.168.147.8] (76-191-206-73.dsl.dynamic.sonic.net [76.191.206.73]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by articuno.alameth.org (Postfix) with ESMTPS id 7C0588342; Fri, 3 Oct 2014 03:21:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alameth.org; s=n01; t=1412306483; bh=uopNvrQlJc1FGINefNuzzR8vSyTgPiYMA/g3Ce0A3nE=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=KCloTw3V54agmDMVmuJrqeGAVSuF8PoTHKRwQsS0RHlsmkJqZ8gWCmXgHuvslDWXk zbcF62WLJblxOXOE9RpfzFwzxQ7sbcikcMI2MmwxSr2VCyRUloINcHNjziwz2ltrI5 M0Va61z6+y1PanPh74uGrGY0TlDLHz9pjIvsFZSk= Message-ID: <542E14E6.1010808@alameth.org> Date: Thu, 02 Oct 2014 20:15:50 -0700 From: "Carl S. Gutekunst" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: John Levine , dmarc@ietf.org References: <20141003022338.3339.qmail@ary.lan> In-Reply-To: <20141003022338.3339.qmail@ary.lan> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/fpIXNUkCVJDiYkfCTaMrTCyR00E Cc: jaberant@twitter.com Subject: Re: [dmarc-ietf] yet more From rewriting, X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 03:15:54 -0000 On 10/02/2014 07:23 PM, John Levine wrote: >>> The typical reaction to the disruption they created was to translate their >>> p=reject into p=quarantine. >> Would you provide some proof of this assertion? > I'm not Doug, but Google unquestionably did that when AOL and Yahoo started > publishing p=reject. My day job's product (SonicWall) handles p=reject as quarantine by default. The administrator has the option of changing that if they want, but it's both the default and the recommend setting in the UI. This was based on the broad observation that false positive rate was way too high. Yahoo and AOL weren't the sole reasons (bad DKIM and SPF records as well as skittishness over our own bugs were factors, too), although they were part of the discussion. From nobody Fri Oct 3 06:53:27 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15EE71A1B53 for ; Fri, 3 Oct 2014 06:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.698 X-Spam-Level: * X-Spam-Status: No, score=1.698 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_110=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOcHiEnD4Haq for ; Fri, 3 Oct 2014 06:53:25 -0700 (PDT) Received: from mail1.altn.com (mail1.altn.com [65.99.242.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FA091A1AFF for ; Fri, 3 Oct 2014 06:53:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/relaxed; d=altn.com; s=mail1; t=1412344404; x=1412949204; q=dns/txt; h=Received: VBR-Info:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version: To:Subject:References:In-Reply-To:Content-Type: Content-Transfer-Encoding; bh=7agEbSWg07UcQXtz1g56rEuGYU6R1Ie+PJ xMnduOiFA=; b=nIaFyUVYGglk24C5uZ7OGvAFFPIeYI0fa4x1QE80jp41lLThOi cZ84OlM7vbl2BsFAHy9AxO2X5b0dL136lrUO2Y5geZrFQEaxNvqPeYJJ9CtP5UKr +MsBS0vKmGT6UmQ3HZnXtSQlSpBISA1HtRihdDkvakyeUkXt8nl7+qG3U= X-MDAV-Processed: mail1.altn.com, Fri, 03 Oct 2014 08:53:24 -0500 Received: from [x.x.x.x] by altn.com (Cipher TLSv1:AES-SHA:256) (MDaemon PRO v14.5.0rc4) with ESMTPSA id md50000315133.msg for ; Fri, 03 Oct 2014 08:53:23 -0500 VBR-Info: md=altn.com; mc=all; mv=vbr.emailcertification.org; X-Spam-Processed: mail1.altn.com, Fri, 03 Oct 2014 08:53:23 -0500 (not processed: message from trusted or authenticated source) X-MDArrival-Date: Fri, 03 Oct 2014 08:53:23 -0500 X-Authenticated-Sender: arvel@altn.com X-Return-Path: prvs=1353951b4c=arvel.hathcock@altn.com X-Envelope-From: arvel.hathcock@altn.com X-MDaemon-Deliver-To: dmarc@ietf.org Message-ID: <542EAA15.7000407@altn.com> Date: Fri, 03 Oct 2014 08:52:21 -0500 From: Arvel Hathcock User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <20141003022338.3339.qmail@ary.lan> <542E14E6.1010808@alameth.org> In-Reply-To: <542E14E6.1010808@alameth.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/zr5DEey6GsbL_44yHaxjjZWUbHs Subject: Re: [dmarc-ietf] yet more From rewriting, X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: arvel.hathcock@altn.com List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 13:53:26 -0000 > My day job's product (SonicWall) handles p=reject as quarantine by > default. The administrator has the option of changing that if they > want, but it's both the default and the recommend setting in the UI. > This was based on the broad observation that false positive rate was > way too high. Yahoo and AOL weren't the sole reasons (bad DKIM and SPF > records as well as skittishness over our own bugs were factors, too), > although they were part of the discussion. More or less the same for mine (MDaemon). I do not honor p=reject by default. What I did was insert a header in the message for the filtering modules down-stream to treat it like p=quarantine (or p=none for that matter if that's what the admin/user wants to do). Arvel From nobody Fri Oct 3 09:05:37 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0F61A0673 for ; Fri, 3 Oct 2014 09:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbA_fJTtIHqP for ; Fri, 3 Oct 2014 09:05:33 -0700 (PDT) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id C27201A03E3 for ; Fri, 3 Oct 2014 09:05:33 -0700 (PDT) Received: from [192.168.82.48] (unknown [72.250.228.105]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id AB1BCCB46 for ; Fri, 3 Oct 2014 12:05:33 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Tim Draegen In-Reply-To: <541D67F0.5070800@tana.it> Date: Fri, 3 Oct 2014 12:05:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140918134416.2051.qmail@joyce.lan> <541BABD0.10506@rolandturner.com> <87zjdvzzt1.fsf@uwakimon.sk.tsukuba.ac.jp> <541D67F0.5070800@tana.it> To: dmarc@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/n49N5vqY0_clNSnvu02SCYmA_sM Subject: [dmarc-ietf] Modeling MLM behavior X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 16:05:36 -0000 On Sep 20, 2014, at 7:41 AM, Alessandro Vesely wrote: > IMHO, we should specify a credible MLM model, even if that can be > slightly off topic for the WG, in order to maximize its probability of > being adopted. The rest of this message has some notes to this end. The discussion of interoperability between DMARC and MLMs has become = opaque enough to warrant taking the time to document the learning. To = make comparing and contrasting between MLMs possible, I think the WG = needs a model -- just like Alessandro proposed -- so that we can all = talk about this space with a common understanding. AND, so that others = can quickly get up to speed and make appropriate contributions. To this end, I've created: http://trac.tools.ietf.org/wg/dmarc/trac/wiki/MailingListModel ..and have asked Alessandro to put his proposal into Wiki form. = Alessandro's proposal can be found here: http://www.ietf.org/mail-archive/web/dmarc/current/msg01670.html Everyone is free to help out by working on the page. 1/2 of the WG Chair, =3D- Tim From nobody Fri Oct 3 09:28:23 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D21B71A03A4 for ; Fri, 3 Oct 2014 09:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBnh2rO7mRc4 for ; Fri, 3 Oct 2014 09:28:11 -0700 (PDT) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 757DF1A19F1 for ; Fri, 3 Oct 2014 09:28:11 -0700 (PDT) Received: from [192.168.82.48] (unknown [72.250.228.105]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id 5FD40CB46 for ; Fri, 3 Oct 2014 12:28:11 -0400 (EDT) From: Tim Draegen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Fri, 3 Oct 2014 12:28:17 -0400 To: dmarc@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/h3hFTSNlIHflYDMn7IzP56XDg40 Subject: [dmarc-ietf] documenting x-original-from usage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 16:28:17 -0000 Although a bit forward looking, I've created this page: http://trac.tools.ietf.org/wg/dmarc/trac/wiki/XOriginalFrom ..for people to add their smarts of how X-Original-=46rom is being used = today. I haven't fleshed it out with content, please feel free to do = so! This page is being linked from the next milestone's wiki page, fwiw: http://trac.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneTwoWiki 1/2 of WG Chair, =3D- Tim From nobody Fri Oct 3 09:36:07 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97D2C1A1A26 for ; Fri, 3 Oct 2014 09:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rECjqOL-lkKn for ; Fri, 3 Oct 2014 09:36:01 -0700 (PDT) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 6847C1A19F4 for ; Fri, 3 Oct 2014 09:36:01 -0700 (PDT) Received: from [192.168.82.48] (unknown [72.250.228.105]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id 7FBCFCB46 for ; Fri, 3 Oct 2014 12:36:01 -0400 (EDT) From: Tim Draegen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <434F8A28-4A5C-4814-A3F5-A1B381CC36C1@eudaemon.net> Date: Fri, 3 Oct 2014 12:36:07 -0400 To: dmarc@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Ur1YtAyNR8z9Ftl_a7uT7DrqeJ4 Subject: [dmarc-ietf] email orphans - embedded devices X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 16:36:05 -0000 I've created a wiki page to expand upon an often overlooked source of = email -- embedded devices. http://trac.tools.ietf.org/wg/dmarc/trac/wiki/EmbeddedDevices These sources of email are often incredibly problematic. Thanks to John = Levine for quietly inserting this into the WG's wiki. I'll be trying to find.. volunteers... from various embedded communities = to contribute to this page. Feel free to note your own experiences. 1/2 of the WG Chair, =3D- Tim From nobody Fri Oct 3 09:39:05 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A86C71A1A30 for ; Fri, 3 Oct 2014 09:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ucxf-nP0yjXz for ; Fri, 3 Oct 2014 09:39:01 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E8361A1A26 for ; Fri, 3 Oct 2014 09:39:01 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s93GctVr007774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 3 Oct 2014 09:38:59 -0700 Message-ID: <542ED11B.5040405@dcrocker.net> Date: Fri, 03 Oct 2014 09:38:51 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Tim Draegen , dmarc@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Fri, 03 Oct 2014 09:38:59 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/-ZA4TRB-AH8igUqR4aR_hcE5t7g Subject: Re: [dmarc-ietf] documenting x-original-from usage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 16:39:04 -0000 The X-* construct has been deprecated. It was a worthy experiment, and had an entirely reasonable value proposition, but it has a significant downside: If the header field becomes popular and standardized, the field name has to be changed. That's a /very/ serious barrier to adoption of the 'standard' form. So the rule now is: choose a name that works as a long-term standard, even when it's initial used privately. I realize there is already some installed base for x-original-from, but let's make the change now rather than later. Along an entirely different line of analysis, note that Original-From is merely adding complexity to the 'who was the author of this message' assessment, very possibly creating yet-another security hole. d/ On 10/3/2014 9:28 AM, Tim Draegen wrote: > Although a bit forward looking, I've created this page: > > http://trac.tools.ietf.org/wg/dmarc/trac/wiki/XOriginalFrom > > ..for people to add their smarts of how X-Original-From is being used today. I haven't fleshed it out with content, please feel free to do so! > > This page is being linked from the next milestone's wiki page, fwiw: > > http://trac.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneTwoWiki > > 1/2 of WG Chair, > =- Tim > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Oct 3 09:43:30 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64BD21A00AD for ; Fri, 3 Oct 2014 09:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTxQUDx7tst1 for ; Fri, 3 Oct 2014 09:43:27 -0700 (PDT) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 35B201A19F6 for ; Fri, 3 Oct 2014 09:43:24 -0700 (PDT) Received: from [192.168.82.48] (unknown [72.250.228.105]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id 46935CB46; Fri, 3 Oct 2014 12:43:24 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Tim Draegen In-Reply-To: <542ED11B.5040405@dcrocker.net> Date: Fri, 3 Oct 2014 12:43:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <63F10064-B2A5-40F7-8E23-C4500AD75B11@eudaemon.net> References: <542ED11B.5040405@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/dk-RVA2f7-cKN-nv3JP1R2-Fj-A Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] documenting x-original-from usage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 16:43:28 -0000 On Oct 3, 2014, at 12:38 PM, Dave Crocker wrote: > The X-* construct has been deprecated. Yes. Let's collect everything around what people have been using = "X-Original-From:" for as a starting point. The application of this = header in different contexts brushes up against what the WG is trying to = address. =3D- Tim From nobody Fri Oct 3 10:15:17 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 985E11A1A7F for ; Fri, 3 Oct 2014 10:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9JysbYRt1N0W for ; Fri, 3 Oct 2014 10:15:10 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F1BC1A1A66 for ; Fri, 3 Oct 2014 10:15:09 -0700 (PDT) Received: (qmail 44455 invoked from network); 3 Oct 2014 17:15:07 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 3 Oct 2014 17:15:07 -0000 Date: 3 Oct 2014 17:14:45 -0000 Message-ID: <20141003171445.1122.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/p8f5jL9mRjKnOIoTmsazqcB9ze0 Cc: tim@eudaemon.net Subject: Re: [dmarc-ietf] Modeling MLM behavior X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 17:15:11 -0000 >The discussion of interoperability between DMARC and MLMs has become opaque enough to >warrant taking the time to document the learning. To make comparing and contrasting between >MLMs possible, I think the WG needs a model -- Take a look at RFC 6377. It's not really a BCP, but it lays out most of the ways MLMs interact with DKIM keys. From nobody Fri Oct 3 13:02:36 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCE491A6EE6 for ; Fri, 3 Oct 2014 13:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.037 X-Spam-Level: X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fsypb4jtBpN for ; Fri, 3 Oct 2014 13:02:33 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 191B11A1B20 for ; Fri, 3 Oct 2014 13:02:32 -0700 (PDT) Received: (qmail 62771 invoked from network); 3 Oct 2014 20:02:31 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 3 Oct 2014 20:02:31 -0000 Date: 3 Oct 2014 20:02:09 -0000 Message-ID: <20141003200209.1503.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <434F8A28-4A5C-4814-A3F5-A1B381CC36C1@eudaemon.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/IsN5l7EU5GCjN-mPEzTsn9nD_hc Cc: tim@eudaemon.net Subject: Re: [dmarc-ietf] email orphans - embedded devices X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 20:02:35 -0000 In article <434F8A28-4A5C-4814-A3F5-A1B381CC36C1@eudaemon.net> you write: >I've created a wiki page to expand upon an often overlooked source of email -- embedded devices. > > http://trac.tools.ietf.org/wg/dmarc/trac/wiki/EmbeddedDevices > >These sources of email are often incredibly problematic. Thanks to John Levine for quietly >inserting this into the WG's wiki. > >I'll be trying to find.. volunteers... from various embedded communities to contribute to >this page. Feel free to note your own experiences. I stuck in a few things about the problems I've noted with the limited number of embedded devices I use. From nobody Fri Oct 3 15:41:39 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B0131A1A3A for ; Fri, 3 Oct 2014 15:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.964 X-Spam-Level: X-Spam-Status: No, score=-0.964 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_110=0.6, J_CHICKENPOX_16=0.6, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8ompCnI91TU for ; Fri, 3 Oct 2014 15:41:37 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 334491A19E6 for ; Fri, 3 Oct 2014 15:41:37 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id tr6so580796ieb.30 for ; Fri, 03 Oct 2014 15:41:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rLQ2C+lft4TL0hiB/pATN0PCtOl/Hi5xybEWmVqMr4U=; b=hv9WWKXkSl6vrBkSlL78EBQabQduGRQvG24LTFab5AKeYGAbLC7SJ9Pq4dTbGGdjvU xNIht0EES3+MluWJixS9xQojK3VvG3IfGHx5QFwdTIOQkF2/9DKasS/Z1QoRQS/p0l7q F/amm4R5eyC11XxifxORzvMVu5JV+5H4AmxVmDdqZP7Jr0Vsdfy1XX85x0AtfJWEVcia rObAOIi6mIYSaEu4DsteeSd7zKD23NyuXOKQV52mm/3sd1+Ps/djPSxZcpNkKkMXyaEP jGEmCGmx/o8ggb0prKrrr9wON0bN4PQcf+1m9YnI0EWkA1sLUlbChz1c7w68OdqN/n+i 5zJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rLQ2C+lft4TL0hiB/pATN0PCtOl/Hi5xybEWmVqMr4U=; b=dUAKU3EjHiXEupmoOSe1lnw8PA/Ft+Ot30vMayVzf0PghXAINTrNOZ1Oh2A0+jHBU/ +lkkTOI2tyqGQq5P940V3w1jDrkAn9sFhKt0Pg7AMGX6bhiUAq0hDb0BnPLO4AmMG2iy WrAltZogb7XevmCE8xPEkqghaGDMDI4TGZrvCN85o93kUTKZ+76r8CetgEW3SE2BWd25 tkw4V9mf3nbp2tfX5nrVPHW+Ohpf3OybPErvZ1TmoGOj9LIvw2NXFVjPpveb7bKQPPcV CeUX5I4Y4J9cCTTf2w/ehFmBLRbzcwUNV8sVV4ctom1egE/NMivhjgqNe9OJ4hhKuYeC rCOQ== X-Gm-Message-State: ALoCoQnwSc0IXr7wysXW/E8/kn1iXW1KLMrEsiLnnHkuNRZzdSBSRriCxDHx7ysQ0rGmBd3hNUuk MIME-Version: 1.0 X-Received: by 10.42.237.197 with SMTP id kp5mr16723796icb.49.1412376096344; Fri, 03 Oct 2014 15:41:36 -0700 (PDT) Received: by 10.64.62.78 with HTTP; Fri, 3 Oct 2014 15:41:36 -0700 (PDT) In-Reply-To: <20141003022338.3339.qmail@ary.lan> References: <20141003022338.3339.qmail@ary.lan> Date: Fri, 3 Oct 2014 15:41:36 -0700 Message-ID: From: Brandon Long To: John Levine Content-Type: multipart/alternative; boundary=047d7b6d8694834b5505048c6f5b Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/LtWJ_RdMtrysRKpVCydZ0zWpkAI Cc: jaberant@twitter.com, "dmarc@ietf.org" Subject: Re: [dmarc-ietf] yet more From rewriting, X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 22:41:38 -0000 --047d7b6d8694834b5505048c6f5b Content-Type: text/plain; charset=UTF-8 On Thu, Oct 2, 2014 at 7:23 PM, John Levine wrote: > >> The typical reaction to the disruption they created was to translate > their > >> p=reject into p=quarantine. > > > >Would you provide some proof of this assertion? > > I'm not Doug, but Google unquestionably did that when AOL and Yahoo started > publishing p=reject. > We didn't change anything at that point. We already had code for treating some specific cases as p=quarantine where we expected the messages were unable to pass SPF or DKIM. Its not a blanket thing, and we expect it will be tightened up over time ... especially if phishers figure out how to spoof it. Brandon --047d7b6d8694834b5505048c6f5b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Oct 2, 2014 at 7:23 PM, John Levine <johnl@taugh.com> wrote:
>> The = typical reaction to the disruption they created was to translate their
>> p=3Dreject into p=3Dquarantine.
>
>Would you provide some proof of this assertion?

I'm not Doug, but Google unquestionably did that when AOL and Yahoo sta= rted
publishing p=3Dreject.

We didn't ch= ange anything at that point.=C2=A0 We already had code for treating some sp= ecific cases as p=3Dquarantine where we expected the messages were unable t= o pass SPF or DKIM.=C2=A0 Its not a blanket thing, and we expect it will be= tightened up over time ... especially if phishers figure out how to spoof = it.

Brandon
--047d7b6d8694834b5505048c6f5b-- From nobody Fri Oct 3 20:42:00 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1B21A8A6B for ; Fri, 3 Oct 2014 20:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4Z1udL5fgjb for ; Fri, 3 Oct 2014 20:41:56 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 38D901A8A6A for ; Fri, 3 Oct 2014 20:41:55 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id 570661C3A2D; Sat, 4 Oct 2014 12:41:53 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 4B1271A2760; Sat, 4 Oct 2014 12:41:53 +0900 (JST) From: "Stephen J. Turnbull" To: dcrocker@bbiw.net In-Reply-To: <542ED11B.5040405@dcrocker.net> References: <542ED11B.5040405@dcrocker.net> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Sat, 04 Oct 2014 12:41:53 +0900 Message-ID: <87k34gtsam.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/h3B671CHDSgUiXZpp4-Nnlrrivo Cc: dmarc@ietf.org, Tim Draegen Subject: Re: [dmarc-ietf] documenting x-original-from usage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 03:41:58 -0000 Dave Crocker writes: > Along an entirely different line of analysis, note that Original-From is > merely adding complexity to the 'who was the author of this message' > assessment, very possibly creating yet-another security hole. Messrs Chairguys, Inquiring Minds Question a Point of Order: doesn't this kind of comment belong on the wiki page, now that it's been created? Feeling-guilty-about-own-too-long-threads-so-really-wanna-know-ly y'rs, Steve From nobody Fri Oct 3 22:09:30 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF03F1A1B08 for ; Fri, 3 Oct 2014 22:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.809 X-Spam-Level: * X-Spam-Status: No, score=1.809 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_110=0.6, J_CHICKENPOX_16=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-yj-hrVIsXK for ; Fri, 3 Oct 2014 22:09:23 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF391A6FF2 for ; Fri, 3 Oct 2014 22:09:22 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id 455F31C3A74; Sat, 4 Oct 2014 14:09:21 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 3908A1A2760; Sat, 4 Oct 2014 14:09:21 +0900 (JST) From: "Stephen J. Turnbull" To: Brandon Long In-Reply-To: References: <20141003022338.3339.qmail@ary.lan> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Sat, 04 Oct 2014 14:09:21 +0900 Message-ID: <87h9zkto8u.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/90wpDOnaN1h2SWwn1L4a-HvhzUc Cc: jaberant@twitter.com, "dmarc@ietf.org" , John Levine Subject: Re: [dmarc-ietf] yet more From rewriting, X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 05:09:26 -0000 Brandon Long writes: > On Thu, Oct 2, 2014 at 7:23 PM, John Levine wrote: > > I'm not Doug, but Google unquestionably [started translating > > p=reject into p=quarantine] when AOL and Yahoo started publishing > > p=reject. > We didn't change anything at that point. We already had code for treating > some specific cases as p=quarantine If you can answer, I'd like to know: would Google have introduced that code if DMARC were a standards track RFC? If Google would likely not conform even to a standard, given the testimony from several other vendors as well, I consider the current protocol irretrievably broken (ie, it's almost a no-op) in this one respect. Where I would go with this: I have long thought that the current "p" definition, which tells the receiver "what to do", is inappropriate because it is uninformative about the nature of the email (by definition the From Domain doesn't know, because that domain didn't handle the email in current form!), and often conformance is *very* much against the receiver's interests (who *does* know exactly what they're looking at). I would prefer an informative definition that describes the Domain Owner's *sender* policy.[1] Regards, Footnotes: [1] Here's what I have in mind. Note that this text MUST NOT be construed as a proposal by me to amend the DMARC protocol at this time. Of course I'd be thrilled if the editors of the draft informative RFC chose to adopt it, but at the present point of time I consider it equivalent to "asking for a pony". p: Domain Owner origination policy (plain-text; REQUIRED for policy records). Indicates the policy published to mailbox users by the Domain Owner. Policy applies to the domain queried and to sub-domains unless sub-domain policy is explicitly described using the "sp" tag. This tag is mandatory for policy records only, but not for third-party reporting records (see Section 7.1). Possible values are as follows: none: The Domain Owner imposes no sending policy on mailbox users, and failure of the DMARC mechanism check MUST be considered equivalent to absence of DMARC mechanisms. suspicious: The Domain Owner does not prohibit indirect email, but warns Mail Receivers that email that fails the DMARC mechanism check is likely to be mischievous or malicious. prohibited: The Domain Owner prohibits indirect email. Mail Receivers are authorized by the Domain Owner to reject all email that fails the DMARC mechanism check. Rejection SHOULD occur during the SMTP transaction. See Section 15.4 for some discussion of SMTP rejection methods and their implications. Third parties SHOULD NOT transmit email with this From Domain. [Mediators which perform transformations of email known to cause failure of the DMARC mechanism check MAY proactively reject email received for redistribution, even though as received it passes the DMARC mechanism check.] quarantine: (Obsolete) MUST be treated as equivalent to suspicious. reject: (Obsolete) MUST be treated as equivalent to prohibited. Rationale: "quarantine" and "reject" were defined with somewhat different semantics in a previous version of this standard, but the non-conformant practice of giving them the semantics defined here was observed to be widespread among Mail Receivers. I probably have some of the technical terms wrong. The part in brackets is probably wishful thinking on my part, although in practice I expect some Mediators to behave that way even if the MAY amended to MUST NOT. Note that because it requires a DNS check etc, and the third parties are typically *not* party to agreements not to send with the Domain owner, I don't think the prohibition on third party email should be strengthened to MUST NOT. "Reasonable effort" is really all you can ask of third parties in general. From nobody Sat Oct 4 10:40:14 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD661A0111 for ; Sat, 4 Oct 2014 10:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_110=0.6, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyVN9w3jVSxj for ; Sat, 4 Oct 2014 10:40:11 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2D5E1A00FA for ; Sat, 4 Oct 2014 10:40:10 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id eu11so3136519pac.0 for ; Sat, 04 Oct 2014 10:40:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=agari.com; s=s1024; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=AsBA7d5Y0PO0EaYE2vkFL/wJzlYN2yPqVgXb0XQLT5k=; b=Rb57aP0ROB1sDA0ciN/+UmQtLYoGfwTfYbJa52Tx7OAp3QSPewY52RjQqXnaOR3w21 oyCguVjsC5Lnas8ecBAQDw4NzFDwyK+/16LlRmLH2BIzpHjYrjHXqYg3wUwAlQYzedbV 16aQAyvIHLqO7mcRFLUX1Jb8iPLF+rNXsIJaE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=AsBA7d5Y0PO0EaYE2vkFL/wJzlYN2yPqVgXb0XQLT5k=; b=WlaPTpYHWFTACZ8Si73+EoweKlV86PMZgiq87i0c/h3Q2YI+mJMm1Qb/aGUfNeUxK7 /9yZ6G3UZt0s8yp3s5DFWsd6WoqqPLdC9jdizrO+ZyYwPpPop91Ko+ySbdSlxy3MYR9n anq5N22QVp5JeqHSYLcFpoqunbNIYAa/8crSzWmoYRN98oF4d3VYH2uzYxDfy1Kuzrs6 e334WBaOt99qL02GTzlKas3d7E4w7qC/QforuOAOhKbQZ9UMhRXrbNiVt2CNKpupAsnu TJRevI4L3VKlnWFy/tdad+Zsp3zxwTkj80cWTwrE93SpmtEKl30tlBuqhf9eiYX2h9vD dpcQ== X-Gm-Message-State: ALoCoQmkw4Cge9KWeMdQ3d/Zw8APHfBf5s/hLZaWpdCrlSB9sPKLUDTt0nujnlJp97OFvGNUo0KS X-Received: by 10.70.44.73 with SMTP id c9mr8081149pdm.11.1412444410589; Sat, 04 Oct 2014 10:40:10 -0700 (PDT) Received: from [192.168.1.3] (191.sub-70-197-4.myvzw.com. [70.197.4.191]) by mx.google.com with ESMTPSA id df1sm9325610pbb.2.2014.10.04.10.40.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 04 Oct 2014 10:40:09 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_4EB5D8D2-A70C-410C-B830-3F20EF700C46"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Patrick Peterson In-Reply-To: <87h9zkto8u.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Sat, 4 Oct 2014 10:40:04 -0700 Message-Id: References: <20141003022338.3339.qmail@ary.lan> <87h9zkto8u.fsf@uwakimon.sk.tsukuba.ac.jp> To: "Stephen J. Turnbull" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/LslDa48feAOFdVmEePvs32N58Iw Cc: Brandon Long , Josh Aberant , "dmarc@ietf.org" , John Levine Subject: Re: [dmarc-ietf] yet more From rewriting, X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 17:40:12 -0000 --Apple-Mail=_4EB5D8D2-A70C-410C-B830-3F20EF700C46 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 3, 2014, at 10:09 PM, Stephen J. Turnbull = wrote: > Brandon Long writes: >> On Thu, Oct 2, 2014 at 7:23 PM, John Levine wrote: >=20 >>> I'm not Doug, but Google unquestionably [started translating >>> p=3Dreject into p=3Dquarantine] when AOL and Yahoo started = publishing >>> p=3Dreject. >=20 >> We didn't change anything at that point. We already had code for = treating >> some specific cases as p=3Dquarantine >=20 > If you can answer, I'd like to know: would Google have introduced that > code if DMARC were a standards track RFC? >=20 > If Google would likely not conform even to a standard, given the > testimony from several other vendors as well, I consider the current > protocol irretrievably broken (ie, it's almost a no-op) in this one > respect. Just a point of clarification. The current DMARC spec [B.3.1] states =93...the Mail Receiver applies the DMARC-record-specified policy. However, before this action is taken, the Mail Receiver can consult external information to override the Domain Owner's policy. =93 So it is my understanding that a receiver can both conform to the spec = and not honor the sender policy. I believe that was the intent as = receivers will not honor a policy of they believe it is the wrong thing = to do for their users. Additional note: one nice feature is that the aggregate DMARC data = indicates when the policy has been overridden enabling the domain-owner = to see what mail sources and percentage of email has a different = disposition that intended. This is powerful as the domain owner can = determine the magnitude of the issue and determine whether the = overridden mail is likely malicious or an issue of authentication = issues. pat --Apple-Mail=_4EB5D8D2-A70C-410C-B830-3F20EF700C46 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJUMDD1AAoJEK1XNLV61MH0p/oIAIN1itqdPR72DMKZWjwDoZ8J 1aKd8i8lwarQcWQI3jlgj/plfhESekRH6it8zhh3jrD6M11h0sDQDzV6dzsEhP4O PcyIBoKJXk9tPBo4io8rXiRt1FO0ERSREKsqbXi2ExD2QzlhtFKDU5n0yu20adDM 33SWsQKMWfOkScI+MPnfo9Jres5tvYuqbZgQawJ5JPavkPmbz8ODLNw7MnWNGmCk OeSrrSW0NWQcYZ1uK3Ig9Valh6dD9m2ndu4nbzfza2XFchfKPK6pNASB1PhxLDcE xiEwOcPNtJxlYbVgK0MDrJF8LuSVMdh56uSnDNUlcvZPfyvucMhJ3FjTOBCi6oY= =uH9y -----END PGP SIGNATURE----- --Apple-Mail=_4EB5D8D2-A70C-410C-B830-3F20EF700C46-- From nobody Sat Oct 4 13:31:52 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27EC11A0258 for ; Sat, 4 Oct 2014 13:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-v82ZVeqMQO for ; Sat, 4 Oct 2014 13:31:50 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D98DC1A0242 for ; Sat, 4 Oct 2014 13:31:49 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id l18so3854756wgh.29 for ; Sat, 04 Oct 2014 13:31:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=twitter.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=tEB/pVVbKa2TJ1MLqICjnz8o/WH9xLCfdf/jmRDyGaM=; b=Xc3dqPNLMDhYudXR/0xRinKUN1qiHl06scuQT6RONISsrve2MMFZQcX0Q2Zqvo69sc YWvdztKB+ERUCwntNX6X01qyaf/Z//uGWJ0VKSHTUExJgsBEzmQ8DtGqtj2rur7X5RG4 b0XKbj1zTN2zVh1y28jWL3486CiMm8GDmum38= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=tEB/pVVbKa2TJ1MLqICjnz8o/WH9xLCfdf/jmRDyGaM=; b=O3noQZkxcyTaOtGkzhSVyUEVelLYgdB4aJGquah7KFfEUiwtbXxGke5GpC0VDP2XFt U/+1PP8fEwtVmnq72xgcEo81vndzJuVCAIbFcaOCUbibAAzUAQymJtErIxg9bk6htLO6 E9JU9PiodSSf3jOzYnYK/K7A2bgHLYLj+zmoAOyWRMJtZXBFAgURYEoOst1xFgLtfAdr M7e8Q372kvOjNqOzFSi0xeDs/xUvPYz8hs+kRFJ3t2xrjp0QLTjTTW7XNeC7aKWDUBI5 YnAF5rlVsnmyCbdngdJfTWULhHqWw0yflk+J8Zng1asMuBF3cxjtDo2XmGnhbT17AoaO n6IA== X-Gm-Message-State: ALoCoQkqdBInQciGS/fRHiUWRmUoDgvvjMO241DHBMGM/6dTxxQFMKMzRO8gnG5RPBYuOmXZLIaI X-Received: by 10.180.19.193 with SMTP id h1mr7790345wie.14.1412454708511; Sat, 04 Oct 2014 13:31:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.103.227 with HTTP; Sat, 4 Oct 2014 13:31:28 -0700 (PDT) In-Reply-To: <20141003022338.3339.qmail@ary.lan> References: <20141003022338.3339.qmail@ary.lan> From: Josh Aberant Date: Sat, 4 Oct 2014 13:31:28 -0700 Message-ID: To: dmarc@ietf.org Content-Type: multipart/alternative; boundary=bcaec53d526f299bf405049ebdae Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/E0C9Ij_1IvYcIAYlgO_Mu0h0OLI Subject: Re: [dmarc-ietf] yet more From rewriting, X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 20:31:51 -0000 --bcaec53d526f299bf405049ebdae Content-Type: text/plain; charset=UTF-8 > I'm not Doug, but Google unquestionably did that when AOL and Yahoo started > publishing p=reject Again, this is an assertion and where is the evidence for this? The reason I ask for evidence is that this doesn't match what we've seen at Twitter. Google's already replied on this list that they didn't change anything because of Yahoo & AOL. We observed Google's transitive trust stuff long before those ISPs made their moves to protect their users. More importantly, there continues to be very real and significant differences between reject & quarantine. #RejectPolicies result in a whole lot of bounces which are both better user protection and also probably very discouraging for the bad guys. Thanks to SonicWall and MDaemon for their replies on their approach. While I very much appreciate the goal of reducing false positives, I would also like to reply that enabling a #RejectPolicy tends to be a very considered move. The senders I know with a current #RejectPolicy all had spent many months inventorying their mailstreams prior - they knew what would be "false positive" long before they turned it on. Josh --bcaec53d526f299bf405049ebdae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

=
I'm not Doug, but Google unquestionably did that when AOL and Ya= hoo started
publishing p=3Dreject

Again, this is an ass= ertion and where is the evidence for this?

The reason I ask for evi= dence is that this doesn't match what we've seen at Twitter.=C2=A0 = Google's already replied on this list that they didn't change anyth= ing because of Yahoo & AOL. We observed Google's transitive trust s= tuff long before those ISPs made their moves to protect their users.
More importantly, there continues to be very real and significa= nt differences between reject & quarantine. #RejectPolicies result in a= whole lot of bounces which are both better user protection and also probab= ly very discouraging for the bad guys.

Thanks to SonicWal= l and MDaemon for their replies on their approach. While I very much apprec= iate the goal of reducing false positives, I would also like to reply that = enabling a #RejectPolicy tends to be a very considered move. The senders I = know with a current #RejectPolicy all had spent many months inventorying th= eir mailstreams prior - they knew what would be "false positive" = long before they turned it on.

Josh
=
--bcaec53d526f299bf405049ebdae-- From nobody Sat Oct 4 14:35:02 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 355671A02A5 for ; Sat, 4 Oct 2014 14:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.263 X-Spam-Level: ** X-Spam-Status: No, score=2.263 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47TnvQrSe_kD for ; Sat, 4 Oct 2014 14:34:59 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 031BD1A01D8 for ; Sat, 4 Oct 2014 14:34:58 -0700 (PDT) Received: (qmail 51493 invoked from network); 4 Oct 2014 21:34:57 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 4 Oct 2014 21:34:57 -0000 Date: 4 Oct 2014 21:34:35 -0000 Message-ID: <20141004213435.4738.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/yNHeggplVarQe1T3su5FEqarEQ4 Cc: jaberant@twitter.com Subject: Re: [dmarc-ietf] yet more From rewriting, X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 21:35:00 -0000 In article you write: >-=-=-=-=-=- >-=-=-=-=-=- > >> I'm not Doug, but Google unquestionably did that when AOL and Yahoo started >> publishing p=reject > >Again, this is an assertion and where is the evidence for this? Tech people at Google told me that's what they did. R's, John From nobody Sun Oct 5 02:03:38 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 167D71A1A82 for ; Sun, 5 Oct 2014 02:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.508 X-Spam-Level: ** X-Spam-Status: No, score=2.508 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAI6llKqXpWJ for ; Sun, 5 Oct 2014 02:03:35 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4E01A1A4B for ; Sun, 5 Oct 2014 02:03:34 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id BF11B1C391E; Sun, 5 Oct 2014 18:03:33 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id B11DA1A2760; Sun, 5 Oct 2014 18:03:33 +0900 (JST) From: "Stephen J. Turnbull" To: Patrick Peterson In-Reply-To: References: <20141003022338.3339.qmail@ary.lan> <87h9zkto8u.fsf@uwakimon.sk.tsukuba.ac.jp> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Sun, 05 Oct 2014 18:03:33 +0900 Message-ID: <87a95aubve.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/U7wuRLp4LTVXnADQSa8I16lUkj0 Cc: Brandon Long , Josh Aberant , "dmarc@ietf.org" , John Levine Subject: Re: [dmarc-ietf] yet more From rewriting, X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2014 09:03:37 -0000 Patrick Peterson writes: > On Oct 3, 2014, at 10:09 PM, Stephen J. Turnbull wrote: > > If you can answer, I'd like to know: would Google have introduced that > > code if DMARC were a standards track RFC? > > > > If Google would likely not conform even to a standard, given the > > testimony from several other vendors as well, I consider the current > > protocol irretrievably broken (ie, it's almost a no-op) in this one > > respect. > Just a point of clarification. The current DMARC spec [B.3.1] > states Thank you for pointing this out. You are quite correct, as Section 6 (Policy Enforcement Considerations), paragraph 2 says clearly: Mail Receivers MAY choose to accept email that fails the DMARC mechanism check even if the Domain Owner has published a "reject" policy. As well as other language specifying that final disposition of a message received is, as it always has been, at the discretion of the receiving system. Nor has this changed in the current version of the next draft that Murray is working on. I should be more careful to read the document. However, AFAIK it is inappropriate to cite an Examples Appendix as though it were normative. > So it is my understanding that a receiver can both conform to the > spec and not honor the sender policy. I believe that was the intent > as receivers will not honor a policy of they believe it is the > wrong thing to do for their users. Indeed. I still think the choice of describing the protocol in terms that give the Domain Owner, who has no idea what's in the mail, the power to decide disposition was a bad idea, especially since the actual language shows definitively that that is not the case! From nobody Sun Oct 5 02:16:27 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 241041A19E7 for ; Sun, 5 Oct 2014 02:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.309 X-Spam-Level: *** X-Spam-Status: No, score=3.309 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYq5tHLj8y_W for ; Sun, 5 Oct 2014 02:16:25 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9E41A0164 for ; Sun, 5 Oct 2014 02:16:25 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id E088D1C3920; Sun, 5 Oct 2014 18:16:24 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id D4B8A1A2760; Sun, 5 Oct 2014 18:16:24 +0900 (JST) From: "Stephen J. Turnbull" To: Josh Aberant In-Reply-To: References: <20141003022338.3339.qmail@ary.lan> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Sun, 05 Oct 2014 18:16:24 +0900 Message-ID: <878ukuub9z.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/tOzfvyfmjIzbAcn2_SRp_7Zvs0A Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] yet more From rewriting, X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2014 09:16:26 -0000 Josh Aberant writes: > The senders I know with a current #RejectPolicy all had spent many > months inventorying their mailstreams prior - they knew what would > be "false positive" long before they turned it on. This certainly wasn't true for Yahoo! and AOL. And it's certainly of no consolation to the thousands of other users, completely unknown to Yahoo! and AOL, whose list service was interrupted or terminated because of those "false positives". Finally, while transactional mail streams probably had rather predictable lack of visible effect on their authentic messages, authentic Yahoo! and AOL messages were rejected en masse from some mailing lists because the operators had no other way to protect their lists from the bounces. AFAIK nobody anticipated that side effect. I have to wonder if Yahoo! (and AOL) anticipated the havoc they would create with business mail streams (such as billing services). AFAIK DMARC reports don't provide that kind of information. From nobody Sun Oct 5 07:51:32 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2D9E1A02ED for ; Sun, 5 Oct 2014 07:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.501 X-Spam-Level: X-Spam-Status: No, score=-97.501 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_41=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1P3zs6BCNBJ5 for ; Sun, 5 Oct 2014 07:51:27 -0700 (PDT) Received: from secure.winserver.com (dkim.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC991A02E4 for ; Sun, 5 Oct 2014 07:51:25 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=105135; t=1412520683; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=R/IZRUSzy3eQ+IsouCBKe6tgis4=; b=CvohMiN1pXZnmE/zRf5K 3QHX9gb1p8GFzpMcOv1sMktjM8YQ/JZ71iJM7yBjyxYOMSFJz8aBX8HImbkOZv1k dATbDpsNKFHyRLPf71WLvkoAzNzNQ6qtQy/N4KQGo7i4yn/lU1coM8xMkEhZmfyx swxP3YWC6vnqgFbPIhJOUuo= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sun, 05 Oct 2014 10:51:23 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3410756395.11276.3176; Sun, 05 Oct 2014 10:51:23 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=105135; t=1412520304; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=nsovIOJ Ty1JIIIMd3ckMnDagGANuIFntCe7umPP1/Dg=; b=Bn4WLjjSwgXWraTKW4ssksf 8c0vnWd4a0nTqPjGJLN7jCX7bL/PCRN8frgWm6CimXElzIx+llYNk5gMl6xqy1ak yUjegoOZxiQLhfGH8/H+JAgJp/AUIOPEBRpb7I76MHJmH7qBbMO/I5CBL7szM3Vu r7+kx6/uJ4T771VVE7lk= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sun, 05 Oct 2014 10:45:04 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2003183141.9.3908; Sun, 05 Oct 2014 10:45:02 -0400 Message-ID: <54315AE3.90008@isdg.net> Date: Sun, 05 Oct 2014 10:51:15 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Josh Aberant , dmarc@ietf.org References: <20141003022338.3339.qmail@ary.lan> In-Reply-To: Content-Type: multipart/mixed; boundary="------------060305030101060601020906" Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/77JcBKYI7fJ4VIOgFK3IhlOYuQY Subject: Re: [dmarc-ietf] yet more From rewriting, X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2014 14:51:30 -0000 This is a multi-part message in MIME format. --------------060305030101060601020906 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 10/4/2014 4:31 PM, Josh Aberant wrote: >> I'm not Doug, but Google unquestionably did that when AOL and Yahoo started >> publishing p=reject > > > Again, this is an assertion and where is the evidence for this? Hi Josh. I'm Hector. I own http://www.santronics.com. To explore what will happen with several of our domains, I created DMARC "p=reject" records for them. I used my wizard and simulator to create records at: http://www.winserver.com/public/wcdmarc I added logic to our current system that already support DKIM+ADSP+ATPS but only from a recording standpoint -- no action is taken on ADSP/ATPS policy results. I have a similar wizard for http://www.winserver.com/public/wcADSP. I did a plug and play for wcDMARC and just recording stuff. But the proof of concept (and issues) has long been known. Anyway, Google was indeed moving my isdg.net posted mail for the IETF LIST into a spam box. My domain mail is signed my our edged outbound server (see attached image) as a 1st party signature. The mail sent for the ietf-list was processed by the IETF receiver and list processor. It was now no longer a valid 1st party signature (1PS) for the distribution but a valid 3rd aprty signature (3PS). That means all DMARC compliant downlinks could either REJECT or QUARANTINE mail. The EASY SOLUTION is to support 3rd party signer (3PS) protocol solutions as envisioned since day uno! The idsg.net DMARC record when I had it as a "p=reject" would be: "v=DMARC1; p=reject; atps=y; rua=mailto:dmarc-rua@isdg.net; ruf=mailto:dmarc-ruf@isdg.net;" The atps=y is the ADSP EXTENSION used for DMARC now that would tell the receiver to support RFC6541 http://tools.ietf.org/html/rfc6541 It was one extra lookup. You can use the above wizard to generate a hash record for the IETF.ORG domain and the supportive DMARC receivers would just a hash lookup for the 3rd party IETF.ORG Domain. Done, simple! I have ATPS records for a few others: e4qssg6j6f6vggflfwk56n6ppxlbglmu._atps TXT ( "v=atps01; d=megabytecoffee.com;" ) jchjykxmwknbyfge2bg4td6add264olh._atps TXT ( "v=atps01; d=winserver.com;" ) kjshf2duqstols65zbhuytbbyr3zdecf._atps TXT ( "v=atps01; d=gmail.com;" ) n3lsehml2wgbfxov7hsak2qzsubsefhb._atps TXT ( "v=atps01; d=mipassoc.org;" ) pq6xadozsi47rluiq5yohg2hy3mvjyoo._atps TXT ( "v=atps01; d=ietf.org;" ) q42vdaxs6p26zflt3hcvqey3zp5aivxj._atps TXT ( "v=atps01; d=isdg.net;" ) rni5mcktu7c46wfgxg4mhhnv4t62bi3y._atps TXT ( "v=atps01; d=mapurdy.com.au;" ) tudfisabn5dz3vjm2kxcehc5attdbqh6._atps TXT ( "v=atps01; d=santronics.com;" ) All of those domains are authorized 3rd party signers (3PS). So as you can see, the other side of the coin here -- scalability and management of large list of authorized domains. I don't see it as a problem. But thats me. Yahoo should be having a WIZARD that allows them to AUTHORIZED 3PS domains that wish support end users with those domains. If they don't want to do that, thats a different issue all together that the LIST people don't really like. Their push to REWRITE isn't going to work and when the bad guys begin to explore it, well... I hate to see that happen if not already too late. > The reason I ask for evidence is that this doesn't match what we've seen at > Twitter. Google's already replied on this list that they didn't change > anything because of Yahoo & AOL. We observed Google's transitive trust > stuff long before those ISPs made their moves to protect their users. I saw Brandon's post. I scratched my head. They were indeed separating it when my record was p=reject. I changed it to p=none because I don't want any negative potential "learning" and R&D going on out there. > More importantly, there continues to be very real and significant > differences between reject & quarantine. #RejectPolicies result in a whole > lot of bounces which are both better user protection and also probably very > discouraging for the bad guys. You appear are a strong advocate for rejection. We could of used you back in the SSP/ADSP days. ADSP was IETF standard track, you know and it was made historic just last year or so so that should tell us that there is going to be HIGH resistance for DMARC by the list or 3rd party mail distribution market. FOLKS -- SUPPORT 3PS solutions and everyone can have their cake and eat it! It is the LEAST COST and ULTIMATE SOLUTION as oppose to the kludgy, complex way people what to fit a LIST system into the untold variant forms of mail networks! > Thanks to SonicWall and MDaemon for their replies on their approach. While > I very much appreciate the goal of reducing false positives, I would also > like to reply that enabling a #RejectPolicy tends to be a very considered > move. The senders I know with a current #RejectPolicy all had spent many > months inventorying their mailstreams prior - they knew what would be > "false positive" long before they turned it on. This solution for all this was long known but only by the strong policy advocates. I explored it all. SSP/ADSP/DSAP and stopped short with DMARC because it didn't solve this exact problem and it was going to have the same problem until some key IETF people begin to change their tune about DKIM POLICY frameworks,. The original DKIM had 3rd party options. It was split as DKIM+SSP. I recall Avrel and I believe that was not a good idea. But it went that way. SSP got too bit complex too much and lost, again among the the swamp of indirect and MAIL LIST usages that is going on now, again, repeated. I attempted to simplified it with DSAP http://tools.ietf.org/html/draft-santos-dkim-dsap-00 and was ready to an IETF meeting to begin to champion it, even made the PPS slides for it: http://www.winserver.com/public/sap/DSAP.pdf which removed all the subjective OPERATIONAL stuff and just provided the technical protocol framework based off its boundary conditions for all the potential combination of results. All usages had to fall in one of the sets of process parameter values for 1SP and 3PS values: 1SP (_) MUST (_) OPTIONAL (_) NEVER 3SP (_) MUST (_) OPTIONAL (_) NEVER etc. Levine created ADSP, a reduced version of SSP that in short tried to IGNORE LIST considerations. 1st party wishes MUST NOT IMPUGN on the needs of the 3rd party operations. It was flawed. Unfortunately, ADSP became was standard track but never supported by its author, levein. I created ASL "Allowed Signer List" to fix it which was a extension of ASDP, a tag that listed the authorized list of 3rd party signers. Doug Otis created TPA (Third Party Authorization) which piggybacked off ADSP as well and Murray created ATPS (Authorized Third Party Signer) (rfc6541). We didn't have the politic power to push this the DKIM PLUS POLICY framework. The push was for a DKIM + TRUST network using the DKIM signer domain (SDID). I added support DKIM+ADSP+ASL+ATPS into Wildcat! I think Murray added DKIM+ADSP+ATPS into Sendmail. I don't know what Arvel did with ADSP but he provided a open source DKIM C++ API with a ADSP optional functional hook. We used for our package. I vastly extended it for ADSP, ASL, ATPS and VBR, adding p-code language import hooks into our server-side scripting code where operators can create their own scripting rules. In fact, all the early DKIM APIs always had POLICY support. Domainkeys had it built-in. Its clone called DKIM with an expanded policy set. To push DKIM as a standard, the policy part was separated as SSP. It became standard track when Levine did ADSP. ADSP was hampered by a lack of desire to champion it by its authors who preferred the TRUST framework instead. DKIM became a STD, the same folks killed ADSP and then reintroduce the POLICY idea via DMARC. But it only did 1PS. It didn't do the 3PS part. So that is where we are at. Try this. Add support for the DKIM+DMARC+ATPS as I explored it with the WIZARD. Create a few domains to authorized and it will WORK. That problem is the scale of all this. I don't see that as a problem. Its doable. -- HLS --------------060305030101060601020906 Content-Type: image/png; name="WCDKIM-Drawing4.png" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="WCDKIM-Drawing4.png" iVBORw0KGgoAAAANSUhEUgAAA6cAAALKCAIAAABBY7AXAAAAAXNSR0IArs4c6QAAAARnQU1B AACxjwv8YQUAAAAgY0hSTQAAeiYAAICEAAD6AAAAgOgAAHUwAADqYAAAOpgAABdwnLpRPAAA /45JREFUeF7s/QuUHWWZ9g/3N++MZNSBjA7Yoxx6OLbDqZWDARNsRDEqkUZFI4o0IjEgaH+S kWRwaOSQRgVaMBqijM2YIRFlEhPUJsp/GkTIi2RWI4PTZCmrFT5oZuS1X8mfNy/jzMp3xSve PKmqXV177zo8VXXtVatX7drP8Xqeqv7te9/P/fx/duzY0dHS63/+z//5f//v//3l718tFdB0 pr/4i7/o7Ox89NFHmfP5559/2cte1nQpyiAFpICXCsyePbunpwdNmzNnzqxZs7xsoxolBaSA FJACZVYA1JvwNT09vXbt2nedceafvGQP9Pg1Bx2136HHHnTMOw964zn5HDf+/fonn/4163r1 kfNftucrBvWSAlKgKgoMDAz0/v5F5AX7Dg8PT05OJnxAKZkUkAJSQApIgXgFOpIIND4+Dtj9 05fteWDPW49619+95ZJNp146lv+xZNX4yjt/znqP/cDwn/9FZ5LGK40UkAJlVGDz5s3g4K6u ru7ubnzfLmMX1GYpIAWkgBTwSoEZqBeGFvBu5/7dgN38MTemRlGvV9NIjZEC2SkwMTGxcOFC OD+Mjo5mV4tKlgJSQApIgcorEEe9X7zpy6/Y+zW+8a5svZWflOqgFAgrgF+c5s+fD/zdvn27 9JECUkAKSAEp0IICDan3Q+d8tPuEd3tl3139w8lnfrNd1NvCMCuLFKiGAnB1gL/v1NRUNbqj XkgBKSAFpECeCkRQL1atHfuGua877RKvkBeNkV9vnjNDdUkBPxWA0RfeDvjrZ/PUKikgBaSA FPBWgSD14tfDE+ad8vozP+cb8gbaI79eb6eUGiYFslYAtl6Ar8I7ZK2zypcCUkAKVEyBIPXC scFDK28YwctLvU8//fQ111xzxhlnzP39a8mSJatXr67YrErSnbGxMeiA14oVK5KkTz0NG8BR wAvnuJJKLRhQji/+othUylQhAQWwxA2uDvhhSspIASkgBaSAFEiowG7Ue+3nr3/t3Pd7a+Wt gF/veeedd8ghh4TjO+NibuwL7EYztmzZknCKZJQMOEgdQIcZVdGo2K1bt6LSyCjbuN6mMiBd t2SMrDWDNJxzZytcHUI6YH1bhTuorkkBKSAFpEC6CrxIvfCTQ4Qyb5G3An69YM34/UxyAF+w JrG7TbZrfxYWSL2NkJejA32Axa11EBltiFEOrcgoClZkVpo/4rfWkbLkQkBf7GRRltaqnVJA CkgBKVCsAi9S71vnn9bz7qt8pl63baXzcHB5iKZWvgz+yFuZzgZUZ0xWOPUW5eEAhwoTAeLb QLjfSVq2yKJThs7btm2z0TTOFvWmO8Pp4KuQDumqqtKkgBSQAlVVYBf1Yhsk7DBcFuQt495s RrdhtHXBN1MY9Yp6i7qjDECBuYE2mHNCy18/Go2yqDe74YatFxbf7MpXyVJACkgBKVAZBXZR 75FHH/uGs7/sOfWW2q/X5SHXCoiZBDMw13XhFfgIhkkAEyCML5yD1eCY684/XOEv6SiHPruW 3l1KxWRm5mQWriRjLSwcZGw1btiwwSoKlIw04XVa9JdlOcgIhw0rCkAZWCvmVhq4nZAS6d1e h30/kMbtKRIji9vgRreoiRA26CK7DUQ4O5e+WasCA8G+u07bNijudQ4iqjatAs2w0XQX+UF8 loaXzRC01lWJCgREtkWTqA7rJtl4t8ZAIeHZ5f+TDmFnsGuxzL3+j5RaKAWkgBQoXIGd1IsA QNiDzXPkLbtfr/32TU8GIMiMZt3AuijXYdR1PDWMAyeFl8oZ4rjI6/7Ejwnguti6JRhr4qTR Ijy3F2ZLJviGnZhdJmvk19vI+9k1zaI9jTykIWz8TYUELvpDtBm9eNGvGdcgunZ0t22R12lL Zpn4636NsYqgoXXEvDLsovv7QEAK9xuClebOJSskUmpkSfLlofAnl9uAxYsXr1y50qsmqTFS QApIASngoQI7qRf/MA46vs9/6i21Xy90DnMnDW9gmoD5loZSoxnQCYOduVdsMlmxtOQhMa16 lpisSbugi854S3ttAKHMnMkqwEDhFVpWlAttAcKjPTiStwKobX1xW4Ls6IgrmlmXrXYqg5cL cPEUC6nDCEvdIlcTuulpqQ3YdMmIJOOwwmFiZjKOCIU1s27gq1F4iJnSbRKDo7mxQVg4X4Ge smoz8NuwshB3IoUnpIcPL2sSdOvt7fW5hWqbFJACUkAK+KDATurFTmxYHCbqzWE8Ig2uZv11 G0DgMzDlR2andA2BLqyY5dUFI4PFRn69Adbkb+hml7Xy3Z/XXZgzK6xbvmuaNSR1gSzS1uvi rKlh2dlr16LsKoZkpLeWbbcciED8YLfxJi8kcmUJU7vbU3wamdi+2Jg93rVDozFWHWWxLxjg bM6NgK+CLaSLpF4yPSYGx9ekDrjBsJAZTeY53CzJq4CTQ2dnp2L3JldMKaWAFJAC9VRgJ/X+ yUv2eMslm/yn3lL79dr0Mm/X8G/0LstGTsd46g14iBppNUW9AWR0QTbgM2rYaoTnJnbLcSMb hAHRem3ZXfsx0oPSUJchoBsNg+bkGX1FIsVExrDRN8x8kXTIbwUBazouhjVh1ZHUa+hpAjJZ oEarKH56GENH2noDc8OV2hWn0XX/H459fX3r16/3v51qoRSQAlJAChSoQEdZnHrL7tcbGGOY 3IAp7g/TRKjAj+xMZnZf1yHVCgzTbYC0klNvwEIZg3H4yKVPcmdTLBW29TZCxvDt0chXpIWA x+gFjLth9w/+xN+I49mkMBA3S73WEX6jYIHWGGKuGZvDm9jZ9nIBzwpTrBGyu+2kiwhf9rUq PBMKfEglqVqBe5OopDRSQApIgZor0FG6mGW0SZcuXm/MPMMP1kYnrj0vwMR0yiT4Rno4uD9V o7oWbL0x1BtpaLT25Ey96F2jpX5oZxKf1Mg0rqcHxYy3fYYVbpZ6bZkaN6a2bz7sHeSFnTvg 3sCJFDBUu3Mj0tYbmBtuT8O/OfDKjI4iXj06h4aGli5d6lWT1BgpIAWkgBTwTYGOtWvXHtjz Vv/dGwItLB31kkvwirRHhn8Bd91JgUS0BUb6wtbQ1su7iNG4AmvLaCttdJshiw1EJPgGjKNZ 23rN/Rr1csRxQgM/0dOw2GXZwEpHvEWWSEBv1tbr2n0DQfR8e3IF2jMyMtLf3+95I9U8KSAF pIAUKFaBDsR4P3jO+0pBvaX2640009rYh6nX0rthpNqkXlQXsM6a4TC8EIofxWBf2JG0TQ+H Rn69RENIBMY1FMPFgOuwu6qv0U3lLvILL9gywyrUMOOoKRZwMHCLMo/nRrbeSIdsNtJ8ec2m i4suDYddja2nbheaot7y+u82GlmFcSj2H4lqlwJSQAqUQoGOwcHBg954Timod8mq8ZV3/ryk Hg7ub8qBvQDcqFuELddl1l1DZj/rt+bh0AL1ulmSx3AIeEpEMlYkwRtixoSA4I/7fLn3WORy rvBN6LpGuL/7cyeI8AI1S4/qWo7hENlZts3dIRm1W8dNirC/gX3kUm8kcDey9brD6opgG3/E 2Mv9fK6Jev0cF7VKCkgBKeCVAmWi3rLH63U5xrgtcNEmh12nUwS3KzMmc4EvuYeDyzq0npJ4 Glkow1jGXK5TAX+RZ8o2bb1uS/hbP+uyXrO1rpEVn4IaUa/r5xrwYQ3cb27sBdZiL6vIZT46 RZgtPNB9XI80xgeI3P3OwxKsVe43HJRmDjDud6FAaS6Io2R0P5DYRiSGegNfw/DWLSS8cs6r x1a4MaJezwdIzZMCUkAK+KCAqDe/UQhvWOAuJHJNiWETIFPa6v6WqTewCIzGwnjqZYKA6dEo 0I0a1j71oq6Ee7NFtgetilx1FxjjRlvNsVPhEtzlhoEhC3hpN1IyjNpuk1yqtutuloAzhgvi 1h73q4j9PhBDvQmlzu/2aK8mUW97+im3FJACUqAWCpSJekvt12uzCVY0Aoq9zOYamHG2GQGt ngQsQCGNhUY2diW8vQJTutcBTERnvohTbBJeMb9rw3xoP38zb9ikisIjy4m8bpW6zgxUwEIa syLru6tPuD2BnsbfvsjOHewCAxET+wz9dQcu4KbC6mKUdB0zUI67lo4l4xWQAsPB6+FwCoFx NJs909vQWAmNbLdJpC7Fg1DUW4phUiOlgBSQAsUqUCbqLbVfb7HDrNqlQLUVEPVWe3zVOykg BaRAKgqUiXrL7tebyoCpECkgBcIKiHo1K6SAFJACUmBGBUS9M0qkBFJACviugKjX9xFS+6SA FJACHihQJuqthl+vB4OuJkiBqikg6q3aiKo/UkAKSIEMFCgT9cqvN4MJoCKlQBUUEPVWYRTV BykgBaRAxgqUiXrl15vxZFDxUqCsCoh6yzpyarcUkAJSIEcFRL05iq2qpIAUyEYBUW82uqpU KSAFpEClFCgT9cqvt1JTT52RAukpIOpNT0uVJAWkgBSorAJlol759VZ2GqpjUqA9BUS97emn 3FJACkiBWihQJuqVX28tpqQ6KQWaV0DU27xmyiEFpIAUqJ0CJabel7xkjzfpJQXyVWDevHnn n3/+oF6eKXDOOecce+yxtXt+q8NSQApIASnQjAJlol7Xr/eQkz7a2dnp2X9eNaf6CvT19e27 777V72fZegjqPeKII5p59CmtFJACUkAK1E6BMlGv69d72Ckff93rXle74VKHi1ZgZGREdFX0 IETULw8HDwdFTZICUkAK+KZAmajX9esV9fo2k2rSHlGvnwMt6vVzXNQqKSAFpIBXCoh6vRoO NcZ3BUS9fo6QqNfPcVGrpIAUkAJeKVAm6nX9emXr9Woa1acxol4/x1rU6+e4qFVSQApIAa8U KBP1yq/Xq6lTz8aIev0cd1Gvn+OiVkkBKSAFvFKgTNQrv16vpk49GyPq9XPcRb1+jotaJQWk gBTwSgFRr1fDocb4roCo188REvX6OS5qlRSQAlLAKwXKRL3y6/Vq6tSzMaJeP8dd1OvnuKhV UkAKSAGvFCgT9cqv16upU8/GiHr9HHdRr5/jolZJASkgBbxSoEzUK79er6ZOPRsj6vVz3EW9 fo6LWiUFpIAU8EoBUW/0cGzZsuWQ3V9z58695ppr3NRn/P7lXmEuu4hzy4KLeHveeeeF62M9 yBv+KFxFo9mzevXq3CbW008/vWHDBlbn9jG3BqRbEaRDLxKWmRH1QlLOELww00xetMr9KHL+ IA3yBiYnKBDlsMDAR4GexpSPOWmFLFmyJEaimPZbrq1btzaa5wnFj0km6m1fQ5UgBaSAFKi8 AmWi3jz9evH/vqOjA//pQQx8AThIJDYncO6+JfK6V1zgwHUUGKarFStW4CI+iqTeQBWNpiOa l5zb2p/TAZpHF9ovs6gSgGtEw4QNyIh6OdCYA3hhNDEfDHztI1xxv1NZgzEzkd5FW3YK11Ea RifwaaCnjconpLIQMnTgO55bTkz73ful0TxPKL6ot32hVIIUkAJSoM4KlIl68/TrJfUGSBT/ +12AcJE0jLyYVQHqJV2hkAAukFpKSr1lv3kIc8VSL43NQNXwFyp+tG3bNn7EGQgetbe0xQa4 FjPK/fYV86Uopnx+zbMmkaQDs5efxrTfsuMLJHWOnOftzyLZetvXUCVIASkgBSqvQJmotym/ XoAC/vHbP2mAgvuWtivCBExo4d+CI6kXiV1CMuqNRN4w9RKw3B+pSRJoQBLqRUbY7UgwtPmR fsxajPLN7EpkwcvttdtZXAesuIUgC9CEWZAShdtv7gHjLo3WtPzhr1UKPSPrRQJcN51RvvsL fgv3GKVwnUbc1uI6CRJ/A93nNDC+hJi0sBZLvdAtYC+3qRXg1/CkQgJkdwcokAZvG01mfBRT PtoQcKgI1GIDF9N+o3PklYdDC1NdWaSAFJACUiBFBTqGhoYOPvGDLlCW4jzJjsTuv23wHFjN /ovjLdmOxAn6ARnQZEX/xUagQOgkNtmvuuTL8Ki4lMDEARdSsA6pKwn1Es35i7P7YzeYg7SK 6+R41gWyxxViKPmYlkKWwJZYvewXctGdg+TElPabO12HyYiokUa7cB+tXhTObx1WOD9iR9qZ xCyBzqyQwv1Bn+VzcCmFi24u5LEjUKZw6g1Iwe5wFNy+WI/MmcFswPHUy2FK+GMC5wCrDrg0 2Dei+LFz229tJtY3akY7k4F5ZettX0OVIAWkgBSovAIda9euPbDnraUg3Wb9et0fdkkPBls4 4b/hABUhC//TNyJR9zoL5MsIz50xYSLkP36zQJODm6JeK9/tnXse/rnZlsThxHAQ5bg2ZvqS 2k/naFKYeAy23H7ZOU3O7s/0Vl248Db9OwPcHPgtnrZPji9bZaLZdQ490/hGvQFqdx12IzmY k8pNFobLQAITxBjXvcJJwkllrIx5hVFz50+jh2OA1DE69sUjO+rFc2zhwoWVf16rg1JACkgB KdCOAjutcfsdemwpqLdZv14wnJEc/t3SPgos4y+t5DOcREY/aESiXBtEFMB/d5pO6U0RBoJI 6jUnB5rEYgg7gDiBKlxWc6mXdl+abPkyr4ww+hiFuCXYfEILUQu6TEt5PPUGkNqwyT1x6TNs eqRdOfIVmOIBKQjBbpfx1obDhhhT3QgYo2ZY7w/12kSyrx/oRSB4QuB7GpUJU2/AAddEcOXl BIspn8JSbXtxxtrLHZpw+wN+w9lR7/Dw8MDAQDuPQuWVAlJACkiByivQMTk5+Yq9X1MK6m3K r9doANBmfgX832/2PxoFI3/5bUS9ZEoW7rKXLXh3Z0wk9Vpj6JmaOvVGkgoraop63UBaRtJh xrIyw9xvJB1G6kjZcbHRK556mSsAZ2ZfNMA1mze/DuE6Qdl6lyQYRUYxHDgNXFgPz7FIwG1E va7pl9+vyKmuwoE5HFkUXcnthxEisluI3T6R7UdKOqLwhbeMi5L6g3Xp0qVw1kq9WBUoBaSA FJACVVKgY/v27X/ykj2qSr1cOW6/sfLctW/h37DLOuAD/ktuRL38Lx5JJMgIlnJLi6ReQgOX 05mnbEK/Xtec3MjWG0ZM8zpAveG1dKSWQC6+db8PuH2JPA+4GbhlJqTe5PdV2NYb8MdwHS1o 4uXXElpAuabNffG3+8Dircj2ZES9HM1wA8wB3RqDZOFfJwLfZwIWXCrgamKlxZSP74RmcjYg bhQWulH7+QuAvahzYLCSj3tMSrg3wMkhlaJUiBSQAlJAClRVgQ507Mijj33D2V/2H3yb9etF 1/j/3nCHdlYyEEfU7H98a6udIqkXn7r+u2HrJu2jBouNqJeV4lNW2oiw8ZFbRaC6RtTLJWsu nRhnBFiW3YmkXrd5lHFGDwf6fbo/rAfqdW+hAFI3e3cFpAj0K7yait9VTPBAdYV7ONhqvLAO VN5UDTtPG4+6BlQKYmvdwoEarKKY8lmXFRLpA8NyYtof6FGb4x4zT7q6uvCzVbMTSemlgBSQ AlKgVgrspN6rr1l+2NwP+U+9zfr1GhAY7oS3JKAJkD/C0lrJoFokUbNRkZUDZrYw9bJ8s8g2 ol4CoutX2qatl+yCemlpJs7yF3w6PLh+omwhX0YhAabhQjeWQAcAvMwSyYxhrwkKyJ+wmYb2 xaxtvfx6YFW7Q8A5QL/kRruLFU69HK+A+dn10GDXAt7VgW8RAbcBlmazOjLOLkuwUQuXTyVZ SOCrlFt7fPsD7Yx0KGrzmTs+Pt7T09NmIcouBaSAFJAClVdgJ/VOTEzs/eq/8p96W/DrRe8A gq7XgTkp2tDSqwH/3fHP2+gQJi5zRuRJ+LfdQMksEHiBxCwHJ66VLtCMQF1mVHPnnFtFoDq2 0BLT/9KqQ2tp4cPFwE/b+IjdMXdPa7ZbNcCXJbDZeGvVoeXUJNBHvLV63c5SE7dwvI3sb8L7 LVJ5+knjFXbP5RBH/sSPGgNKxrchCw8Hjl3g5fYC5zScN4pz7A69tZ/eC+6sbtS1RuVDMSsk hptnbL/V2+a4N2r/4O9fCSePkkkBKSAFpEBtFdhJvXjt/1eHvPGj/1Ai8E0Sr7e2g9qo4wAg 195pQS0kVHIFsqDe5LUrZaQC3d3d+OoucaSAFJACUkAKxCuwi3rXr1//V0f2ek69Lfj1avhd BehZAXsbfmWm12YW64qqrbmo17fxxbOrr6/Pt1apPVJACkgBKeChAruoFy07pPuIE879ms/g 25pfr4eiF9gkgK/5jwa8DgpsVYmqFvV6NVgIQTNnzhz49XrVKjVGCkgBKSAF/FTgReothbnX oFweDn7Op8q3StTr1RBrcwqvhkONkQJSQAp4rsCL1IuGnnb6e19/xuU+m3tFvZ7Pp8o3T9Tr zxAjVBlCN0xPT/vTJLVECkgBKSAFfFZgN+rFz4WvO+6N3sbulV+vzzOpJm0T9Xoy0HhYAXm1 iM2T4VAzpIAUkAKlUGA36kWLp6amDvnr181bvNZDi6/8eksxpardSFGvJ+OLFWxwyvKkMWqG FJACUkAKlEKBIPWi0Vgasv9Bf+35yjb59ZZielWvkaLewscULg1AXgxE4S1RA6SAFJACUqBc CkRQLy2+f33UMT77+Ip6yzXPKtNaUW+xQwmXBgRtkJW32FFQ7VJACkiBkioQTb3oDNzmsLjt oGPe6Y+3g/x6SzrJqtRsUW9Ro4kn0tDQEJBXvrxFDYHqlQJSQAqUXYGG1MuO4X/8vgccfOiJ 73/TRf9UuKev/HrLPtsq0H5RbyGDuHLlyq6urqVLlypiQyH6q1IpIAWkQDUUmIF6afS97vob /vyV+2Dzttee+v/1AX/B3/JwqMb8K10vRL15Dhk8Gfr7+zs7OxcvXgy3qzyrVl1SQApIASlQ PQVmpl7rM/4DnXveIuDvaw46ar9Djz34xA8e9MZzijpeeeDxnZ1/OaiXFMhXAayj2nffffOt s3a1zZ8/v7e3d9asWVy1Jt6t3j8e9UgKSAEpUIgCTVCvtW/z5s1jY2PwsSvwv/HAwMDhhx/+ Jr2kQL4KvOENb3jb295W4MyvQ9Wjo6N4wuBXpkKeiapUCkgBKSAFqqpAK9RbVS3ULykgBaSA FJACUkAKSIGqKiDqrerIql9SQApIASkgBaSAFJACLyog6tVskAJSQApIASkgBaSAFKi+AqLe 6o+xeigFpIAUkAJSQApIASkg6tUckAJSQApIASkgBaSAFKi+AqLe6o+xeigFpIAUkAJSQApI ASkg6tUckAJSQApIASkgBaSAFKi+AqLe6o+xeigFpIAUkAJSQApIASkg6tUckAJSQApIASkg BaSAFKi+AqLe6o+xeigFpIAUkAJSQApIASkg6tUckAJSQApIgSorgN2tscd1o9fExESVO6++ SQEp4Cgg6tV0kAJSQApIgeooAIpduXLl4OBgX19fb29vR7JXZ2cnEiMLMm7evLk6cqgnUkAK iHo1B6SAFJACUqAyCkxNTa1du7a/v7+rqysZ5c6QatasWfPnzx8aGhofH6+MSuqIFJACsvVq DkgBKSAFpEBbCkxPT9N/YHh4GLbS8Gv9+vVZOBLAdQFm3e7u7lRIt1Ehs2fPXrx4cRbtb0t0 ZZYCUqB5BUS9zWumHFJACkiB2isAChwZGQEOJodOGFDhRTAwMICMbUIkjLtga/Boct49ce5J 4SN5dqRE42FRrv3ISwApUGIFRL0lHjw1XQpIASmQswKTk5PAzVQcCYDLsA2DX5vqAhoATwYA dAyw7rXXXm8+5dQll15244qvrtu4aevkM8/8Znuj41dT00gzsvpbSH/OuecffMhh8SiMvoPa m2qzEksBKeCJAqJeTwZCzZACUkAKeK0AUC/54rCmbKjwoE1oQ4WjbSPe3WOPWSDdyy6/6u57 H4xh3CQfPfLYL2++5RvvP+vs/fY/oFFHenp64LbR7IBhnRx6iq8NMHhDzPBr4cKF+BRuG3AX afb7QLONUXopUEMFRL01HHR1WQpIASnQhAKjo6NJ3BjAiHQhAC/Cboq/5lEQg4+GlXPmzIkJ noCPAJqRDArYhaU2Cc62kOahhx+7eGDJPvu8KrJqQCp8muOlBLziCwNSNuWPwerQZfAx9IcH cxMDpqRSQAo0UEDUq6khBaSAFJAC0QrA+zbGvgsW7Hv3mVde84Xv/eDeGYESbgZwJIAtFlka QSQ4D47CARsngG/p0qVh6IRxF2D94wcfnrHqVBLA+gu8DjcD3wcaxXkA7ALlmzJ7xySGX4cC SuhGlQJtKiDqbVNAZZcCUkAKVFMB/BYf6U4Ar1ngZhLSjcHNNd/egEJArmHOg03UHB5gSY00 8cL+Cj+EVHC2qUIA7scce3ygzVAJPgk2CeB5DExHAOC0eNctB19CWvCsqOYEVa+kQPMKiHqb 10w5pIAUkAJVVwDepWFow0ovmDyx/KspUoxfSYYFZ0cceVS4Lix0i0ReQGdu9t1GLYcIQP9A m6FYI7O0mxJ2bjh+vP2dC+AEAjM5MNoOGMJxERZlJIj8PmDl4JuAttKo+i2o/mWigKg3E1lV qBSQAlKgvArACTWAdIA8IFpasBsu53PX3xTmyIC5FCAILsyuDU2VDEtz2OjbyL4Lt2YYtsH3 8BJOXguW5aG/4VpsaODzMKNXcXknoVouBbJQQNSbhaoqUwpIASlQVgWwfCqAvIjnFR/8KznJ xaREFaiokVcAwLFwE2+48XC0iHdjgBMzfDna1AfKAH8jnaHhVQyHirJONbVbCuSugKg3d8lV oRSQAlLAVwXgMxrAuExNvGEcBN6FORLI25SVtE3KbCo7LLiRK+0AxKm3OdIbBG7QWuXm6/2k dnmngKjXuyFRg6SAFJAChSiAiA1udC14FLRvp2yKIJk4wJE+I29kg7P2PMb3kIA3CEatzb3u CplvqlQK5K+AqDd/zVWjFJACUsBHBfr6+lyzZc5WXpePAb4EOyx0S91i2gKIz5gF69vggYDV fmj5jInbTwCv4sASQOwYp10tfLyp1CbPFBD1ejYgao4UkAJSIAMFsNcXoiJgmRr3AyPdIpos 3yL+QCBOGRxS24ezdkpApIj2d1lrpwGe54U+gfjB2OIO4IuBRpxgDGjghfHFR4r8kMG9pSLL pICot0yjpbZKASkgBZIrgEBaYB2QbqNdfButxIJvQw7L1zzHSv+bB/CNifAQs8wO33awGwjg WH4Rye8mpayGAqLeaoyjeiEFpIAUeFEBBLSCqa+FLXCJSosuuMh/5lMLoQC+nMRsdJdkmwxE gcCPAPKO0OOjJgqIemsy0OqmFJACdVEANryWeZecJNeCEiE1XIqT0O2MaeDVrVgQdXlG1Lif ot4aD766LgWkQLUUgEsDdi5oxDfY8QtGXOz+NbL6W7YfGJascT8wMxnmsx6rRFjpf1MxrO6g w+0BYx04IjfAC08VsW+1HgnqTVABUa/mhBSQAlKgCgoAeeGvGeYYEC1AVn66/sNrOy1EpAt8 k5lxlOEKjGQIiozVijGuEUuXLsV0qsJdoT5Igd0VEPVqRkgBKSAFqqBAeBvht79zgXwV2kHJ yueF1R9bJWPxYvjLEvx9tdatCs8F9UHUqzkgBaSAFKiYAitXrnTBBRwDd8/KQ5s6mIoCMADD 0SVs+kXoj9HR0YrdKepOzRWQrbfmE0DdlwJSoPQK4Mfozs5Oo14gr0y8qeBgrQoB+8LzIWD3 FfiW/umgDsjWqzkgBaSAFKiSAgjK6xp68bN16XDtB//8wIEHHYxj2Wc+21Tjm03fVOHJEz/+ 5K89aUnyNkem/PGDD2OHOXc6AXyxvUWV7hf1pc4KyNZb59Evvu94mH5y4JPzeufZcebCMxF3 CdFGi2+cWiAFSqKA69GL9fttck8h2UG9JK3k7IhVWW+YcyJAuZAGu5WizWgGGlN4S1JpAIy+ cPZ1wRfbHZfkVlAzpcAMCoh6NUWKUeArK7+yT+c+x/ce/6nhT60aW2XH8rXLT+8/fc/Ze35i 4BMKnF7M2KjWsinQ09NjjFLSuGMtUC9YE732gXrBu2hJZaiX6BwAX5l7y/ZUUHujFRD1ambk rcDk5OSRPUe+b/H7Nk1t2rJjS6NjyfCSg7sPXrd+Xd7tU31SoGwKuBsOf+8H96Zi8Mu5kDD1 4goOeA6gJStu/joYF8f9Dz3ChuHkwosGSL1MaQ3GR0yM46cTk25HrEzYifHp0OeHWRSus2Re x4GTgAKNikVeo14rJ2f1MqrODfGLHYzLdluovVIgQgFRr6ZFrgrAYHB4z+FrxtfE8K59NDY9 dkrfKVcPXZ1rE1WZFCibAggyZbbeMjr1AtrC1AucRaeAtmRKe4GAkT5w0Sy+RGF74TrT82CZ Z32onyd4gWWNWXHdzYu3ljGmWCuKeatk8cXiNhMEc6xst4XaKwVEvZoDhSqwefPmnjk9YNkk yGtpzh44W+Bb6Lipct8VmD9/vtEJtunKyPKXabGNqJf+sjC+GncScF1yRYJ3nPYumoSpA94i i1GsGW6NUFksCdUAGhdRC510aUWmqTi+WNRl6VGUy8qZKpZD4fgGZfNKrr2+PwXUvmQKyNab TCelalsBOOkeM+eYjZMbm0JeJp43f973R7/fdhNUgBSopgKDg4NGJ4g8hW26ckCidKuIoV46 OeAAXxJG+Tbs1xv2r+UVMrHZeg1nedGo1+AYng/Uk44TMxZbSb9edHzNtzeIeqv5yKhxr0S9 NR78fLt+dv/ZV4xc0QLyIgs8gPfr2k87ZOY7YqqtNArgK6Xr2ovIUzPuTJsus7ZfWiPqdR0G Apgbpl5zYKD/Lg6aew2UmSDghEBmdVfFWWNIvTMWW1XqXXLpZUa9vb29pbkf1FAp0FgBUa9m Rx4KjI+Pv7bnta0hL3MtHlz8d4N/l0dbVYcUKKECAwMDrk8q1iGVy+LbPvVaCa4OPG+HepMU W0nqRfwyd7c2TLAS3hZqshQIKiDq1ZzIQ4EP9394cGQwknrXbV138hkn73/I/vgbg8Uw9yLS WR5tVR1SoIQKIMS1u6YNqLfXXnuVKIpZ+9QbaZQ1o6/r4QDnXdc43YKtN1BsJanXXcqG6aTI ZSV8KqjJEQqIejUt8lAAwNooThlgt2duzw0bbpgRfBHcV0/ePEZLdZRTAcQEdPclppkTRl+w r/8ODylSb8ApAo4QFteMvgqBjTASUm9MsdWjXrg4u1sTIyB0Oe8JtVoKyNarOZC7AhMTEwd1 H9TIjrt6y2qYe/Ep2Dfe3Hvu0nOHhoZyb74qlAKlUQDgG7D42s/9fe8+85HHftm+A25GJbRM veggbLc039LTFy+486JAW5RmcRVao94ZizVuZqzfjCTKrViEbsAPBa6jyOjoaGnuATVUCsQq IFuvJkjmCsBACzNtvFMvkBe2XhBwTDLs4obtizNvriqQAqVVAN8wAw6+LrtglVtu5NRsRS1Q L+yR1jvz3GWcB/fl2mhbo14LH9GoWMPi8FK5ZnUoNj18ed0VbOyvPHpL+zxQw+XhoDlQhAIj IyPYZDgGZ3+07UdXrr4S4IsjJhk8g+EfXEQPVKcU8FoBhDdZuXKluy9xeEUXr3jr6oDwZIFN 0fiW26fxsI3T7Mo/3PZtYC4D+tpFhNeFcZdBfN0tKmgMDu+7hioCNlprjAVNQ96YYvEpCmGN boOLRdhma4cnjLt8jROmr6/P66mvxkmBJhWQrbdJwZS8eQXw6xgC7jbCWbg3gHrx6YXXXIiH LL0dIo9lK5ctWryo+fqVQwpUWYH169djB4FGmOteh5NDsySk9JVX4McPPoydTcK8i5mzcOFC xYus8rOjln0T9dZy2PPtdHzYMjg2nH7e6fBtwF+cx9h6Fw0uQjT+fNuu2qSAvwogbgNMcTG8 C5eGE+eeBKbBz9Yl3am48tBZbAdh33VXrblzaXh42N+pr5ZJgVYVEPW2qpzyJVYA1oI9Z+/5 wPYHIokWvg2AXTxt8RfnMdR7St8pMGslrlYJpUCVFcD+3pEmXhjtzjn3fDgDeOvMUCznqXZX gUgTLxZEYnZV+eZR32qsgKi3xoOfY9cX9C24bv11MUR719N3xS93AzQDnfVzW46Dpqr8VQC/ n7ibsdFEhyBlN9/yDVGdFEiuwDHHHh/5W8HixYux4Z+/N4BaJgVaVUDU26pyyteMArDRwlLb zt5s2M0Yexo3U6fSSoFqKoDwZLNnz3ZhBXGmPnf9TclZRymlABWAUy/cYCLBF3Ns7dq11byF 1KsaKyDqrfHg59v14+YcN7J5pDXwhaF33659ZXvId8RUm6cKBGI1wFzncyBe8aX/CnzvB/e+ /6yzAzF6icIKke7pU0DNalUBUW+ryilfkwrgN9nXzXldI+/eeBo+b+l5Vw9d3WSFSi4FKqgA 4gC6lrk3n3IqYqz6z1Vqof8KYCJdec0Xwuzb399fwRtJXaqrAqLeuo58Ef3++sjX3/retzZr 7r1+/fVwCy6ivapTCvilAPza3T2H8du0kNd/mixXC7EIEqshAz4Piufg14NArWlDAVFvG+Ip a5MKIHBvzzE9p5x+ytj0WEL2XTK85C3z36JFbE0qreTVVADbHLo4Up9gZNxFotHh7iWRImLa phgsP7yPRop1+VYUjL7uTMPSSUV1qOYzpX69EvXWb8wL6jGQF7FFwa/r1q87vOfw5WuXx4Pv mvE12Nvi4oGLC2qvqpUC3imAeNXGIj5vL5w6w3En4UYv7Gaceo0o0PYZZvnhPZOzqNSfMvGd yhUcYfJkffDuiaAGNa+AqLd5zZSjeQUMeZkVi9DPXHjmQd0HfWzwY6BbF383TW3CzsMI+HBk z5HI1XxVyiEFKqvA/PnzDUSw94Q/hJR1S4x6setv+Lj/oUeyaAA3GcbB8utGvegyNjdxwVfh 0iv7ZKlTx0S9dRrtgvoaQF5rxcTExOWDl4Nu3QfrPp37fLj/w3q8FjRWqtZrBXp7e+1mAZFk gXp+lknqxd8Cm1dD6oXaCAJtU27OnDle3x5qnBRIoICoN4FIStKGAo2Qt40ilVUK1FSBhQsX inobgS9Ns2d9qB+m2Xec9i4gMg6cIP0/3PZtfMQrSOCWgLe87qZnAtl6IULAzwE/09X03lO3 q6KAqLcqI+llP4S8Xg6LGlVWBbBjllEvwvQWaPjMuWqz9cLgGjjMvYFuuC7CUivwrl3nlQsv GmD7wcS8wlw8JyjLr9eGeI89Ztmsk9dZWZ8davcfFBD1ai5kpYCQNytlVW5dFYDnj+sOdPe9 D+ZMn0VVF7OaDVAbgFRacxFywXIFrjDLTycmCbuw6bIEJHP9KGq+ms3G2t28beXKlXW9+dTv iigg6q3IQPrWDSGvbyOi9lRAgdrG6zV+dU25AZ8Eg1Sz/pqVF4BLhrMrYXxHGtiARb1hZU6c e5J910IUkQrcR+pCnRUQ9dZ59LPqu5A3K2VVbu0VGBjYSWb2wkayRdlf86w3yWo283CwhoUZ N3xlxc1fNydg83aQh4M7uPvs8yqbb1pnXPsnUOkFEPWWfgh964CQ17cRUXuqpADMvd3d3S74 9r37zMrv0JYR9RoE4wSGXnk4hL/JPPLYL93JhsA7Vbqb1JcaKiDqreGgZ9hlIW+G4qpoKfB7 BbBLFvbKclkEnpff+8G9eRpfc64rC+qFOy/9GWyTi4C1WH69GGX8mGAzbfbs2boFpUDZFRD1 ln0EPWq/kNejwVBTKq0AfmgOgC/QBEbfHz/4cM48mk91MTEcwKzcMbhZDwdLb16/DOlgUYFF vfgq5X65gndNpe8qda4WCoh6azHMOXRSyJuDyKpCCpgCY2NjsL25UMJzRDS78povVCy8Q/yO xMDTFqgXHr3myGtRe3mF1t+aUy98G/bb/wCbYPiWNTU1pRtQCpRdAVFv2UfQi/YLeb0YBjWi ZgqMj4/39PSEwZdXEGYVq+/xCzV2cfvc9Tc99PBj+dhls6glHLrBvWLUy4vWAFum1ugKfHnN igzX3nUbN7mxzFAs3xKC8ZdvWV21j62Tz7i7smE6LV26tGa3l7pbTQVEvdUc1zx7JeTNU23V JQUCCgwNDUUafcM0DBtwtVmttd4BZ83JobUSKpYLjg1u3AZMJOxFjGWUuvWkQAUUEPVWYBCL 7IKQt0j1VbcU+L0C+OkZ7NvV1dXI7svr+MG6Ynym7qSrALwaFl1wUWAWYV5NT0/rVpMC1VBA 1FuNcSymF0LeYnRXrVKggQK4Jfv7+wOhzQxi9tprr3QhSaVVRgE4wIB33c2HOW2AvJOTk7rh pEBlFBD1VmYo8+6IkDdvxVWfFEisAKy/a9euxU5a8+fPN+rFQrfKUJo6kooCcGaA30vAhdcm TF9fn6y8ie85JSyHAqLecoyTb60U8vo2ImqPFIhUAOBrEIPFbamgkgrxVoEbV3yV9lquZTzn 3POxlhEHrmOt3s23fINvcR1fgWL8YRCxYeXKlbqnpED1FBD1Vm9MM++RkDdziVWBFEhJAVGv t4SaesPWfHtDvGN3wk8Rl1dBylK6/1SMdwqIer0bEs8bJOT1fIDUPCngKgCLnbGOVrOlDpr+ FAjHXPhtJ+TayGSdnZ2LFy+WF68eINVWQNRb7fFNuXdC3pQFVXFSIGMFENPXRZxSR+31BzF9 awnC62JX6taQFyGfAbvY9CTjmajipYAXCoh6vRiGUjRCyFuKYVIjpUBAATea78UDS3wjNrWn fQXe/s4FLvIuXLgQFDs8PAyc7Q29sEYNfi/4VKSrZ0UNFRD11nDQW+mykLcV1ZRHCnigANDH kAi7D8Au2D5mqQRPFMBoBpBXO0p4cM+pCf4qIOr1d2z8aZmQ15+xUEukQLMKBJwc+t59pifE pma0qcCPH3w44NiA8LpaiNbsDaL0tVJA1Fur4W6ls0LeVlRTHingkwL4Udv9Bfxz19/UJm8p e+EKIGJDYPkaXFnwDceneae2SAHvFBD1ejckXjVIyOvVcKgxUqA1BbAwHxFYXfAFMxXObWpA awo02jdYyNva3aFctVJA1Fur4W6us0Le5vRSaingsQIjIyMu9WIXg/wtvnff+yD2R7js8qvk W9wa70I37DER3jcYK9a0iZrHN5+a5pECol6PBsOrpgh5vRoONUYKtK+Au2MFCfj9Z52dD4D+ amoa4SMMu/HTfP7M3RpoepILAmLr4MiIvNhUov25oRKkQE0UEPXWZKCb66aQtzm9lFoKlESB /v7+QFRXRHXARrWZst33fnBvZDTZI448Ch9lWnUFCqeBHMMUDscLr5W1a9eWZOqpmVLACwVE vV4Mg1eNEPJ6NRxqjBRIV4GwxRc4BQC9ccVXYVBMFxPB0yfOPSl+9wTYm+Gomm69mZY2svpb cDOArTrTLT9QOGqJ2XsCAekUriHdW0Ol1UEBUW8dRrmJPgp5mxBLSaVAORVYv369u3WFG80X fggwLrZJjYioBeddbICccLcw/HCPn+9TZ+42exHIjuaBdAOdApVCMXBwKgQM+idS40tIjHSI yKF9g8t556nVxSsg6i1+DPxpgZDXn7FQS6RApgoAm+bPn98IrYChCOvblDkTxAZrMQy3kb/F syIsupqYmNi8eTN2wQ1XjUrxUz6IOV1abb80dA1oG+lTG1ggCMP2ogsugg7rNm6a8csD0vAA 5r75lFNjdLNaIKACNWR6X6jwyisg6i1siPHon9fb68/x+mOPfeVf/MUbTzrJnyZ9ZeXKwoZH FUuBGigAo293d/eMFllYNMlz4DP3AAvierxhkoV3dnYiiISrKHbEjbQ3I/Exxx6fhbtFC/gL cgXHz6hPkgQwEkOr5PZvt0zsPYEla/jCUIMpqS5KgWwVEPVmq29M6fgfMHf+/FVjY/4cKzZt 8qcx/UuXfri/v7DhUcVSoDYKjI2NLVy4MAm6tZAGG+QGeNd0RbAtd7fkQOE0/cIUmrPnA4Ja wB0ZsBtDqPiqABJtQY2msuBbAVYfYnRqMxPVUSmQuQKi3swlblQB/hOc3t+/ZccOHZEKDI6M iHoLm52quH4KYGnU0qVL04I5GHdBbPhFa0Yh8ZM9UgY20QjQIay/sDTD5zW7OGuIJgHTNSqK B1P41BqGwvg6NDQERxF0timcjUkM0kWBWHEIf7MZpVMCKSAFmlVA1NusYqmlF/XG476oN7Wp poKkQDMKwOUXTyeQaLMEDHIFscF1oQXfU9h9V65cmdDdAjZgrH6jU2wLfgvIAtcFOtSiKDge hPd9CIApugazdMwaMrQfNAxahdU80mu5EenCVRcvfN+At4nWqDUzT5VWCrSigKi3FdVSySPq FfWmMpFUiBTIVIGxf/qn0T//88GOjgEsRzviCFIaXyBjcB5CxgL40tobDObhGU2/YYKk5zFW 4AU8j8NeyM161sKOC4Nua73bvn07lIl8ZTpkKlwKSIFGCoh6C5sbol5Rb2GTTxVLgeQKYOuv jo6dR29v8kxtpqTpFz7BaXkONFsOjNaA3RaM1m12XNmlgBTIVAFRb6byxhUu6hX1Fjb5VLEU SKjA+PiOWbN2US/Oi3jRcwCm5Xjf3yRc+z9e+pKYZPCvQKgEeBrARltER1WnFJACmSsg6s1c 4kYViHpFvYVNPlUsBRIq0Ne3C3kXL06YI9Nk8H+ACRZLygDBSTDXTfNHf/I/upf24S8vwmsZ hQBzuXRMPrWZDpwKlwKeKCDqLWwgRL2i3sImnyqWAkkUWL9+F/LC3Ds1lSRH/mkQSAHGYBho Aa94EYjxYiQE93XB8qXHrFr0N9/+ovwW8h8m1SgFPFFA1FvYQIh6Rb2FTT5VLAWSKNDTs4t6 h4eTJPc8zbK7vwbqxbHlqa2eN1XNkwJSICMFRL0ZCTtzsaJeUe/Ms0QppEBRCoB0uYitq2tH +f1cX/iv/zzhlo+TehesWYa3RemqeqWAFChQAVFvYeKLekW9hU0+VSwF4hWYnt7R2bmLeuHn UP7Xpl/8hMjL44p7bi1/n9QDKSAFmlZA1Nu0ZGllEPWKetOaSypHCqSsQBHRylLuwu7FmXuD ge/9TzyaaY0qXApIAQ8VEPUWNiiiXlFvYZNPFUuBGAUmJgqPVpbu+LjuDUa9p65e8uzzv023 IpUmBaSA5wqIegsbIFGvqLewyaeKpUCMAp5FK2t/rALuDQa+MAC3X7hKkAJSoEQKiHoLGyxR r6i3sMmniqVAIwVGR/2PVtbs6F38/Rtdp173HEDcbGlKLwWkQHkVEPUWNnaiXlFvYZNPFUuB RgpUK1oZevncC89b9IYw+/aODMjPQXeDFKiPAqLewsZa1CvqLWzyqWIpEKnAypVVilbGLm58 7P5Ghl5ehyVY00EKSIGaKCDqLWygRb2i3sImnyqWAmEFEJS3WtHK2MVI94Z33HbpojuvX7Vl 422P3I1NKxS+VzeEFKiJAqLewgZa1CvqLWzyqWIpEFagctHK0EXgLKgXq9YAuDD6fnfrZtp3 P3DHVZoCUkAK1FABUW9hgy7qFfUWNvlUsRQIKDA1VbFoZY1GGBuzEXzlzqubQArUUAFRb2GD LuoV9RY2+VSxFAgoYIZehC2r9Gv5fbeRemH6rXRH1TkpIAUiFBD1FjYtRL2i3sImnyqWAq4C tTH0otNjk+OkXgXr1U0gBWqogKi3sEEX9Yp6C5t8qlgKuArUxtCLTts+bYhZplkgBaRA3RQQ 9RY24qJeUW9hk08VSwFToE6GXnYa0Rto7kX0Bk0EKSAFaqWAqLew4Y6n3guvuebTK1aQC3GC tz/atg3n+IvzdVu34vyup5/GOY5VY2NMiU9Xb9kSoEk3AVIyC0uwt7zoVnrl6tV8i1qsXkvG j9gYawOr5kVrEq7csGED2+9md+uKxN/BkZEP9/cXNjyqWArURAEz9OKkHi9EKyP1funBdfXo sXopBaTALgVEvYVNhXjq7Zk7d/9DDiEO4qSjo4MQjL84B7OCSnGdB66cft55+BQoifMA+CIB ruNTpMGnLBknhFErgScnn3EGUjIN/+IA+KJMZLEamTJwkYWzwTyx9uNtZAmRvHvXc89efM+t 87568eu/dN5b/uFTX/uX7xU2SKpYClRbgfHxXaEbZs3aAaNvPV6T01OKX1aPoVYvpUBQAVFv YXNiRlsvqReAC5rEizwKciWG4i9JF8fZS5bwYjz1Ig1S0hwLDGWBOMijJGN7CybmOaE5kCYy Iwonc1sjrf1g9MgSwtS75qmt80YGAnspXaTNkwqbp6q40gogYkNHx86jNoZeDqfFL3vquWcr PcDqnBSQArspIOotbELEUy8ZEX4CMO6SVgnBNLICIsM23RltvbTdoigUS3+JSHglUiMxYddN g7y4wiOMywa7JHUap63l7FGghAD1/s//+s933n555Pah3936QGFDpYqlQCUVgKGXyFsnQy9H UvHLKjmj1SkpMKMCot4ZJcoqwYyr2WhkpVEWnErMxUW6+bZAvYBRFEX3BvwFOkdSLy7C0GuO EDhBxrB/Atk34PZgBmNzcjCvicgSAtR76xOPRiIvLr71G0uwu9IdP7sHC1B4PPLM41mNjcqV AnVQoK6GXoytxS+7ZNNX6jDU6qMUkAJUQNRb2EyYkXqBm0RPGk2Jj3TqpXevGWJhuOXqtHgP B6bBAYZ2/YbDvgcsGUZfeg+bC69BbcAADEo2unWdLnCdFuuwYTjs24Ar1/5hlUkU+36sERDz ev93rsXSbB4w5GDBynMvPF/Y6KpiKeC5AjU29GJk3PhlOPd8rNQ8KSAF0lJA1JuWkk2XMyP1 0k2WmAsiBKfSsEoedf16CbtIFkO9RFuLC0FvhEhbL5e4GVLTajujXy8Bl37D1kKufmtkUQ6D 7y1/CCAfD7gJPwX7zjgq8OpDMhwwJG/6xU9gQtY+pTOKpgRVUKDGhl4On8Uvg923CgOqPkgB KZBAAVFvApGySTIj9dKrwaiRRGtL0MjEtAfjxI3hwIs8gML0lDButixGqAGiJVITdukOAaI1 /wQrGTUGMjJGhMUscxtmtl4Wy8NW4xn+/vPzv33DLR+PhNo3fO2CwPVTV//NeRs//4E7rmoE wTD3zjh0V9xza2T299x+OW3GouEZNVSC8ilQb0MvxwvfchXJoXxTVy2WAu0pIOptT782cs9I vfRYMOssQzS4cXBxDnIFO5qHbjj+biB6LkpDeuSyLKglHGGXdYGwrcbIaLvhjEgfaIy5VSSM 1xvp5HDSyCehNDwW7n/iUXgyGKeeunoJrriDYF6/W599IsngbHzs/oSWYyYL03CSWpRGCvil QG9vPUM3uKMAxwY8QHhfy9zr1/xUa6RAZgqIejOTdqaCk1BvpPNr5S9ePT7qBi9bsOZvn972 rCvnyPjoCY5JGPbadlx44eQAVkaZMOte/P0bYeJ1C5+RiZF+pqHW51LAJwXWr9+FvJ2dO6an fWpZ3m2x7Sq0pi1v6VWfFChIAVFvQcLv2CHqjcF3hDC76O9vfNvHPvDov/8ycoQQZz5g9E1o 3E0+3ogREaDhSAIGIidZDcPS2qHz5C1XSikQp0BPzy7qHR6uuVCuuTf1B0jNtVX3pYCfCoh6 CxsXUW+80TrJjsSu0Rc/VuazEI1OFDAM44CJCN6BM84hIK8RM8LjIxfyauXcjLopQfoKmEcv DL3bt6dfftlKvP6B23lvytxbtqFTe6VAKwqIeltRLZU8ot72qRcDAaOvbbME628Ss2sqw9dU IRYcNGwtBqzDrQIQDAflfKi9qZYrcdUUsNANg4NV61pL/cFNZx5NugFbklCZpECZFBD1FjZa ot5UqBfjh58m7f/Wsru/VtiIxlaMZXNoGxbDxTsK944MwFEYEAxQ1l6pfg5liVul0A1Rg2fm XpyUeHDVdCkgBRIoIOpNIFI2SUS9aVEvxsc1pnq+HBvWaLoLYxFeTNg1wjFoHhD8pQfXwaSd zTRUqXVSYPFihW4IjzduLrvdZO6t0/2gvtZRAVFvYaMu6k2RejGK4Ej+68KuxYUNaksVA4Kx lhwQ7K7PC5iEE66Za6l+ZaqHAlNTO2bN2kW9ONfLUQBOvbzj8DOLhJECUqDCCoh6CxtcUW+6 1EuLL5DXT9fe5PMMS9/QC2yQYXtH4Z8x3H8V/yG5hkoZocDAwC7khWuvXrsrAC8pUi9utLI/ QDS2UkAKxCgg6i1seoh6U6fewsYyy4rx/xjG4IQeDow6DG5u1KItW7YcEnpl2fwZyl69evXW rVsLbEBdqka4htmzd1EvvHv1CilgXzKT7Oko/aSAFCipAqLewgZO1CvqTXfyWch9OgTjR1tc CeDytm3brvn9i+jL83Sbkby0FStWYAtrgHjyLErZogIIzdvRsfOQobeBgrY2AObeFkVWNikg BbxXQNRb2BCJekW96U4+mIQjd5XDf3E4DSOIhLtSB8g7d+5cNgDWVpwvWbIEf3G+YcMGnOB1 xhln4C0/hVGWF/Eps+BT98p5f3jhopG0JcOHrIupkBd/kRLUy0rTlUKl7aYADL2IzkvqxcZs ejVQwFaX4maRSFJAClRSAVFvYcMq6hX1pj75YNmFfRcBgBvFR1vx4C7ocakX1lbSJ8AXxmB8 BCQF3fLEPgX40kKMZgNbcYKPCK/IRYSl8ZgnTz/9NNIgJc7Jx8jIZKgIhl58xHNkT10KFfii AiMju5AXu7Lp1VgBM/cigKCCOWimSIFKKiDqLWxYRb2i3kwnH7a9QMizQHC0K8ZuZaVh6h0b G+NHYFCc0wsCkErq5ae8SOolKJNuibNmPOa5JcanyE5nBjcZ+VgeDplOg52F2xbERRt6R0dH Fy1eNK933pE9R+4xaw+c4BgeHp6YmMhchGQVmHevtmpLJphSSYGSKSDqLWzARL2i3nwmH4I/ YNtkODlgE7sY6iV9moEWtlgSKqmXn7ogywS0/iJXPPVaIaLefAb9xVpAuvRtgJNDca+1a9fu 07nPvPnzlq1ctmps1ZrxNQ9sfwAnOD448MGDug966/y3+sC++LXE3ISSbDZenKKqWQpIgVYU EPW2oloqeUS9ot5UJlJThfz6+f/N9GFbL7mWeAr3Bro6NKJe2HrhmYD0SGlGXKSHTZdhIuD5 QPsu4BjJ8JZGYpd6uZoNjhNNdUGJm1Ogt3cX9WJBWxGvqamp4+Yc9/aFb980tWkL5leD46bR m8C+fzf4d0W0cbc6LfK3wgUWPhZqgBRIXQFRb+qSJi1Q1CvqTTpXMkhHj1sWTE41TwNacPGX 69XcT83Waz6+BFziLHO5PG3BInCRy+BQptWLRWw0FcvJIYMR/n2RtgUxDL1Y05b7a3x8/PCe w0c2j8TwrvvR4sHFC/oWbC+iqaYN4vWaXxB+IcldM1UoBaRAhgqIejMUN75oUa+ot7DJl0HF rhE3g+JVZEsKIE4Z3RsGB1vK31amycnJ1895/cbJjQmRl8muGLnizIVntlVx25lt0wqsCoV/ fNvlqQApIAV8UUDUW9hIiHrzoV7808K/rvfcfrkWZWc610W9mcrbSuG2BTE2Is59C2LYa+f2 zk1u5XXJ+OyBs68fvr6VLqeXBytBGQgF3vDarS09XVWSFChYAVFvYQMg6s2HerFXGf97Xf/A 7YUNdg0qZmTfGnS0PF0cGtpl6O3vz7/R1wxd85GlH2nKymuJsdBt36594RCcf7OtRpAuvirr 0VHgEKhqKZCFAqLeLFRNVKaoNx/qtR8rsTQ74b6+icZPiaSA5wp0de2i3s2bc24pgBXYCnht jXqR67r118HBN+dmB6rDti8W9zpml+9iG6napYAUaEoBUW9TcqWZWNSbD/VizJbd/TX+91p+ 321pDqHKkgLeKjA6WuDOFAjBi3hkMch75eor9z9k/3gm3nP2ntPT08UKjCcGHx1Y31YfPwfI fsqp80+Y16tDCrSmwEcXLS72zo2pXdRb2NCIenOjXnj08l8XzL31+dfV8szmvmsWtgzlWCgG lmkBHBjeIfCyi/T0tb2IW26PMraigK1jKyJgGfaeQCDeRlBL5J2Rek/vPx0PyVb6nl4exLpG /DI+PeArlV7BXpeEZYiv2LvzklVjOqRACwp8dPna1+zf5e0UF/UWNjSi3tyoF2Nsm/RufOz+ woa8DBUTecG1RFtut8ZN1GyvCgbf5VtuQUzw5Tkj/nIjYsT0xbnAN++Rd9exFWEu3Tk3GsTl vfCaC8G7PXN7ZqRe7GeBjdzyli5Un21TjO/McJcqvD05NADU27lvF7616JACLSiwfOOkqDeH +7R8VYh686RebLNEgw12HC3fXMmxxQy4y02GuS+x2XrxEXemYKxfdzNhN0YvqZcZ8VJshxxH 7w9VFbqODU69e3fu3Yh6121dd9fTd5F94z0csG8FNmwrQL1QleYi1f+da+vwY5GotwXUUxZT QNTrw1PLxzaIevOkXvyvsl8qtaYt5n7AXhLmsQAbLfGX1lwgLxCWWxZzWzXbXSJMvUhMSzDt vj7egRVuU3f3LqfesbFAL3t6emi2z/Q1+y9mxxNtEuqFjwQ8JXwYJbhI9Y4M1GdtgKhXCNuO AqJeH55aPrZB1Jsn9WIGIHIZ/28hEqePE8KbNoFrQas0+uJl1EsgBu9yN7V46jV0FvLmPbAg Xe5MAfYt4hVv6yUNJ6Fef2y9UNF+LMID5LZH7i5C1/zqTEi9f7t6y5Xrthoe4S2ORm8/f9fT H/j0ir4Lr4GfaICoUEjkRyzwph9tC5TJSvGXCdyDHwUutgBwKAFNxeH2KFyyNQ+NDDfVxAk0 FVK4TQr3wroc+CiQMSCLJQ73Fw2I7A5TxgxNYIgTKinqze9eLVdNa9eu3buz8/jeXo+OU072 pzEHdncvWpzmOlALYQajb7mmSp6thX0XXMsagbnmvAuK3bZtG2263KY4oYdDno1XXTsVWLhw F/UWsY6NQxDj15ucegdHBj/c/2F/xtT2raj8hm0JqXef/Q/BQRL6yJWr+euBYSI+OrhnLj89 9ewleGs/L9h1fsTrTICPyHYoh9dfd/IZgSqYHX/Dv1fwI7culozmJSQ2JEONzMVyrAHWJLde 0CSy4K+bkm2wbgaaio/Qa7YnpszwR8j4xtPPC3ckvr+B2vHW/a6CAt3sOL/whg1u29zBSqih qNefp5Z3LYHfpD+vv/n2F79052p/2oOWpB63COGHaO7VLqONbgaaeMG74FqubKPpl0ZffIqH uy1Zi/FwML9e7+66ajeo0P3YTNrj5hwXvytbElvvmYvPXLlypVfDdcmmr1g0mAqvbEtIveAh QBIhFfBEFiQFktjIdrDjEmdpjGRK0hvykg7JYe5HxnwG1sZn5DAzoBJPWTjLYZm8Qh61Qmbk NuI76kLbcBAZCc3WKdcES7ssa8ELnWUVAeq1FqIoUibhMqbMwEdIz4wus7p1RfaXBI/uuJ8a yLLZeAsDPBKwbTambICo16tHkBqTmgJcp1z53cvu+Nk9/KeF/16paVetggCy5tvAYA7on1Ev vHXp3sDwZC71micDPxL1FjMvYN+lewMsvsW9Lh+8/GODH2t5iwpmxD4XwK/iOhFRM5YHYEGb 7VRc1U3OE1IvmYkeC4Q8Q73ARwZSpDRAGDkSAOfad4mPLg4SOmk/RiFgOJcmjfkCUBtIw4bN yLtMQEY3kyp9A8xxwrA+UJpRLyoiB4ep17JAMaNJkiW/KgSO8EeuGm7iRv2lvIG+86uFjVpg aNh9fl0R9Xr18FFj0lQARgsE5WEk9jTL9a8sRN9kT/G3qv+x0lKd69jyf2E2YuUQNoNFjLk6 rJdPWeHG69hSrii2uGrszRbZRTw3FqxZRvCtakiHhNRLegMhka6AbqRSAJMLmmFOdYnN3AmQ hUXxUyIX7bvkTlbRLPWa/TIh9RJYCYtoEijQvGnZJF63gw0m9bq26hjqZRUUKqZMfgR96JLL vkfiu1uX21/arc2bwsV6lGaGdlcZ+x4i6s3zgam6clUAIGgPcTzHn3ru2Vyrz70yC0JU+SUp uUubToXYC8C2gQX+4veHys/JdIRDKbaODXsRF/36xMAnlgwvadnc+9qe146Pjxfdiej6EQTG QjrgeeJnI9tpVULqNYsmDYSgNJ6Aho3DktgLjefoJOC6ExjmWhUJqZd4Sn61Ml284/ozHgEg Bg663q4oxLX1slg7mJ3Ui3OaY10FAt8BAvZpo95wme5H7AUIOOze4GJ6oL9sVcCQbCbkRkPT 1NhFfpeQX287d5/yZq4A4tcaZOCk8ps4wKPXthjNXFxV0LwCYFwYet05SY8UuWLPrGV//y73 BsTrLfoFp/wjeo7YOLmxBfAFLl88cHHRPYir3x4jmJwj46M+N7WFtiWnXtp0zcRLS6Fr8nTt mkZILmiaJZWRBOwXeYMzAqgZjxNSLy3EPCJJ0fVJCKCbG3uBfeGCthhvBKNe2r+JsO5qtoCN NmDrjfdwIIVT2EjKZGnh/rIxgVwuCoeNxy4KJ/nGIupt4f5SliIVsGBeBhlX3HNrkQ3KpW6z bT/yzOO5VKhKmlYAVGHb6dnkxMDBMxu/TjRdXB0ybN++Y/bsXdSLNW0evCYmJv6656/Hpsea Al8ELPMkTG+8hLZIAPMTcc080Du1JiSnXovAYIEOzMJqYRPM/GmuC0aEwFzimsFTGActOgSr SEi9M67BAhEaJoY9Liy8musGkIR6UZRp0oh64bichKQD1VHGSD4Oa8IesfE43JBnLIdkz3ML 2oArxGuuyRP1pnZHqSBPFHAjULpg4UnzsmuG/Ya+/L7bsqtFJbevAOy++GJmvyZzluItBk5b jQTlNfeG3t72lU+rhO+Pfv91c153x8QdCcH3spWXze2dm3rwlrS6EyjHrAZYJ1Clr9DJqZfW ROMkwyaXtMz8CRykx4K5HBDL8JYfRRpWLQ1RLC3qjTRS4iKR1EynLmuGHW3RZrbKbL3mwIBC AtRLyKbpOuA14TrvWpkB6gWnhhHWqmtE+URwZKTC7I5Zf62zuEK3bLfZ5mJhXw9w4oZPbqSh PBwyeuCo2LYUsBVsgZ+S6+DaC5YyfmpLRGXORQGsaYNdLez2AGMwYo/k0oQyVILg1ozeUFyY 3kiZYPGFqwNCOjyw/YEY9gUZz5s/7/zF52+H0bo8L4tlhijglXFAT069Zk00rwCupgpAGOiK LgoGlAZMYGL3Izc4rpmBmcCiklmagI+sazAOpGnEZ5HXaYEmzZMXXSs10dMOVkSaN88NRhmz NtADxM1itmRkCRRoGfmRa9xlLeGuRV60rrlu0253mCAwNG7hkW0Lu0GHNRT1lucBVpuWusuQ w9RbeddejLN5M295amtthr30HcVg2WJE99cJOFbK7WFHZ+cu6vUs2hemHUAWscwQiez0/tOv W3+d6+yLsL7LVi4D7x7SfcjoaPkcZPGVzKKA46QaUUeSU29TNAlEjnSx5W/xSXCqqeraTMx4 wG0W4k/2GPGN6dNqrai39P9rK9YBPJcDK9gC4FsH115wEntdvZUoFZuu4e7AooZdsmBac+ct fmLGvK2v24O5N8yZ4+0EQDgzbMO+oG/B/l3705CGF/azWLR4URl513TGhLSlAvj9oQLgmxH1 pgVVKsdzBUS93j6Ea9owrBOyQOthQy+u4AleeWnwj4reoopfVtKxBlvgRwkzs9lMrti6oqSj Y+4NHkRvSNrmCqVzHcYqAL6iXs+x0vPmiXor9GyrVlfwezEsnW/8+4tq6NqLkYRdsEoLUDKd m3DN9G1vWOsvBhFW3loFIYkYawTopVOvf+4Nmc5MfwqHizl3wMFRdvAV9XqOlZ43T9Trz3NJ LQkqYOu6+tZ+Bk9tBDeA8wOe3XVw7dVsSK4AfpjuRyxYj19wVYfZHhO4MiuKmhB78+ZdyNvT 00QuJU1bAfyMZuCLXyHK62su6vUcKz1vnqg37UeLyktPAZAujRMBX97yPq/T00YlvaiA/9Rb 69FaunQX9Q4O1loHDzpfDfAV9XqOlZ43T9TrwaNITWiggMWbRGQoiSQFGikg6vV6bph7w8SE 1+2sR+PgOWYRpmHxxa8Qpeu3qNdzrPS8eaLe0t3yNWqwLWvDaowadVtdbVIBUW+TguWYfHx8 l6G3uzvHWlVVnAJ4nBr4YnFw6bxuRL2eY6XnzRP16vnoqQJYBU8vNDygPW2imuWHAlWiXi59 gxGuIjtcwKuB69jk3uDHzcJWlBp8Rb2eY6XnzRP1+vQoUlscBbD4nU69WMEmYaRAjAJVol53 j7cqsC9MvKRerGnTyycFECXG4vgivHSJfk8T9XqOlZ43T9Tr03NIbXEUwJp3Ui9WvksYKVAT 6gV8GItw/sPPp6xb9CFOGZEXrr16+aeAu4EFflIrC/iKej3HSs+bJ+r171GkFv1eAdtBviI/ 9WpYM1OgSrZeioTYfAH2xS8e5WPfkZFd1Ot3XLnMJmYJCg6AbylihIt6PcdKz5sn6i3Bg6me TbT/+opTVs8JkLzX1aNe9h2hSwI7G5eMfQG7tPUCf/XyVQGEcbBNBLGUAtHNfG3prnaJej3H Ss+bJ+r1/AavafNsfwq4OdZUAnU7sQJVpV4IgDWdcPUpK/tiWwptyZZ4GheYEJaFEoGvqNdz rPS8eaLeAh81qrqhAo32p6inZFADmzMDgOrZ/Rl7XWHqZd8bsa/Xv0dPT8upd8ap60+CAPj6 HCJd1Os5VnrePFGvP48dteRFBbQ/hWmB3x+5qulLD67TFIlUoPLUG8O+cH/3dBHS+vVy6i3X DYsvVxd//0Y+bXAsv+82P79pi3o9x0rPmyfqLddzqS6t1f4UYerFT5B1Gf4m+1kT6qUqsMkh qontMkBA8ZF9Bwbk1NvkRC4+OTDXlhEzbrSHe1iIej3HSs+bJ+ot/kGjFgQU0P4UAUG0sC/+ HqkV9cawLzyAPXqYmFMvtmfTq1QK4GuVWXzx/cq34CGiXs+x0vPmiXpL9TSqR2PxkNX+FO5Q m/XFt38/nszHGlJvJPt6tJ+LOfXOnu3JJFEzmlIAkRzc3xO8+kIl6vUcKz1vnqi3qUeBEueh gPanCKgsQWTrjVGAPg9+BTUbHd3l3tDXl8cjQ3VkoAB8GyywA71oPAkiKer1HCs9b56oN4On hYpsTwEzbfofObK9jibNbcZvKJM0T53S1dbW6+8gDw7uot7hYX8bqZbNpACczZbd/TXzdkAc SexjPFOmzD8X9XqOlZ43T9Sb+S2qCppVwKKTemJaaLb9qaeXo7NsvalPqmwL7O3dRb1y6s1W 6DxKt9+agL9weyh8s0xRr+dY6XnzRL15PDVUR3IFbH8KhSxwRbOfGj1cUp18cDNKKVtvRsK2 WOz27TtmzdpJvXLqbVFB77Lh5yZ3q5RioyiKej3HSs+bJ+r17vlS8wZt+sVP+IPaFffcWnMp 3O5bAOONj90vWQIKiHr9mhKw73JLtvnz/WqYWtOGAggcbgEl8XyGH3lRv8WJej3HSs+bJ+pt 4zGgrBkoILyLFBWwyy8D0CcD1ctdpKg3yfiBUeCXySmULa/Y/hSLFydpmNKURQG4WmHrCnPz RUTFQnZIEfV6jpWeN0/UW5YHTl3aaT/lF/I89VZlOX7EDI2oN8m8xfbFxiv4tTrDHw2GhrSU LcmIlDQNNis+4ZaPcy7hJMOJ1EAgUa/nWOl580S9JX3yVLPZWrYVM64WPtPPbUILnJGi3oTi u4Y6IAt+sM7ku2V//y7qhdFXryoqgG9QrptvznsXi3o9x0rPmyfqreIzqbR9shBd2A6+tJ3I quHaq6KRsqLe5HMOvOIGYc3E4WHOnF3UOzGRvGFKWS4F4CQD1143qBmmVj5d8J96v7Bp6ui5 bzv8uDfpgAKH9ZxwaM8b/UFhUW8+96lqSaSAtmOI+x1/fJT/Y7zaJynRuGacSNTbrMCYQu7O Wyk7PHR27qLeZpul9GVTwJZh8NGE2A45/BLlP/UuWDT44XPPX7dxkw4o8P4PfOhVf/maS1aN eQK+ot6yPWYq3V7tTxEzvNqrQrbeFO9+LMlHmBSz1aXm8GB7EXd3p9haFeWtAthLyPV2wIrJ rI2+nlPvige2d77mgEce++Uzv9mu41dT0/vtf8AXV3z1uDefLupNchd3JEmkNJVRQPtTxAwl flIko0Clyox4Kh2RrbdlGQEobjiqFBweNm9W2LKWh6OkGfFoCnyDytTo6zn1vv+S4Y987GLx LhW48povLLrgIpwcdvjRn1kz7gP4ytZb0udMBZutMAUzDqr2qoiUSNQ748yJT4BV+ak5PKxd u4t6BwbabJWyl0uB3Iy+nlPvvgd2//jBh0W9VODgQw6jGp+7/qY3v3exqHfGm1q23hklqk6C h56aWHTndThuffiu6vQq1Z7YGnzs5ZFqweUuTNTb/vjBXJdOhIelSxW2rP3hKGkJ+Rh9fabe C65b/5b57xLyUoGR1d96+zsX8ByuDn+57wFY51c4+MrWW9LHi5pdRwW0V4VsvZnO+2YdHuAc vMP2pMBmbL29O/bZZxf1HnXUzrc4wMErV2babBXulQJho2+6AfJ8pl6ELMD6LVEvFThx7kmu Gpd8+jKs8xP1xt+tsvV69TSLa8wZZ5xx3nnnuSmuueaaQw45pFEefOp+tGXLFiTGCye4/vTT T/NtIBmzMDH+2klpZGqvofjnQddeuDq0V1KlcsvWm+5w4suVuz4J51hJGa4CF3fNw66uXaTL jYjDhwL3pjtC3pcWMPpiM4uR8dG0Wu0t9cKQ+cq9O4W8VADr+fbZ51WuGnB1gPuHqFfUm9aj oOBygKFz5851GzE2NhbJrEgDRA4AMfi14/cvZlm9erX7NtC3bdu2IRn+MhdBuSYv+l9iL9Ca 9DdJN0W9SVRqKg2oxQ1KFY6fjQBVmISYivAJ3jE8HEe9PT1NVa3ElVEgYPTFusnJ6an2e+ct 9Z4zOPLehWeLeqnAjSu++v6zgmp0HXTYZ++YKBZ85eHQ/j2oEnYqEKbeFStWgG7x0datW3EC JsZrw4YNeIvEoFV+yhf5lcnwFmZjnJitF4zL7DQnowSc428NqRd2ONDGTtTQ6w8KiHozmgv4 bYERHsK7zpoTMCzBL/y/z+2wGL1hQ+9oaka+jLqpYrNTIAujr7fU2zP3bWu+vUHUSwXefMqp YTV8cHIQ9WZ3v9er5DD1mocDLbsgVLIsbLRh7wXyK7MwwZIlS0i9sBnjBAyNF9LADGywW0Pq rdesStZbUW8ynVJLZaGj6W8Dq/COwcFoc29fX2q1qqDSKpCu0ddP6kWY3pfvORtrtkS9XLu2 1157hdW4+94HD+w+WrbemFtZfr2lec7FUy9oFbwLhIXDLrpEO67bN/IrARdci788p8MDcuEi OJhkLOotzbTIpaGi3lxk3lWJ+TbYDhfw2nxi6093zJoVAb7j43m2TXV5q0CKRl8/qfejy9ee 1vc+IS8VuPmWb/S9+8xINRDJAdbWAsFXtl5vnxIla1gM9aInMNOSdPECwjaiXuAsPRnIxKRe OEXgBHZi0rCot2QzI/vminqz1/jFGrABgbujG8+xq+IOBOgNuDf09+fZMNXlvwLh8A640myz /aTeee/qhyerqJcKwKO3kRofXXzx+z41LOptNO1l6232gVBYelIv4yrgBadb18MBZlq0DPzK xWfm82DNNfMtDbr07iXjmtsDrL+y9RY2wB5XLOrNbXAQ2iyMvLyy5YFNu1EvTL9TKSxdyq1r qigfBcIxfbFWsqlVbn5SL364x8/3ol4qcMSRRzVSA2bgE+YvFPWKevN54GRYC+249gLXGvXS RssXl6PB9Mu3LvXiLdjXdWwg9fIKXlzrBiyubeSyDMevzEWLevMZPfg2vOf2yxtR784oZvDi NXOv9mbLZ1TKWcvY5DhjgNgB73AAcZLeeEi9cOp9yR6zhLy2IcUejdUo3LVXHg5J7jKlkQJS wF8FRL35jE2kb4MLLt//1qpd1IuQDtPT+bRKtZRUAXyJQhDfwFbYSaLTeEi9n1kzftjhR4t6 qQC4FrbeRmpgiRuW/eF7QlHmXlFvSZ8YarYUkAK7FBD15jAVYnwbDHwRxew/583dCb6I4KuX FEigALb3C2yFjR8NIndFscI8pF5F6nUZNzJSr5sA3xDwPUHUG3l/yK83wWNDSaRAvRUQ9eYz /mARHLDPrdqyEcvXFt15vbuFG9l3w7VLdsbu3b49nyaplmooEN4KGxPsqeeejeydh9T71rMG rrzmC7L1UoFFF1wUrwb28sD3BFGvqLcajy/1QgrkrYBv1Iv/ym+c13tCbY7jTpzbM+eEI44/ /tBjXnfIMa/7UM/r69P3QE8/c/lg3rO/QvVt+sVP3O9RiIiH71dwhAh00UPq1f4ULvFH7k/h JgAT43uCqFfUW/qnFxaZYYOJ5N1oKn1TiZO3QSkroIBv1Iv1lwe+tueSVWM6aqUA4jEBgitw QxXYBTAuSBe867rNgIbdJnlIvTkEcBj6/LALjitu/vqyz3zWLj7+5K/xdt3GTW4aXMF1pMGJ eyCZXcT5D/75gXSt1DEBHFgRXCAQ6E3UK+ot8FGTTtUMuZC8rKbSN5U4eRuUsgIKeEi9Rx7f W9QzXfUWpQAQX9SbyvMEzr7wcHAXSmJnbHhBIMgDmPjD377m9Td+pO+bNw6M3lPUWAfqfdVr uh56+LF02TFQ2jtOe5ddecOcE8/6UD9A9sKLBg486OCfTkyCXBHW000DLMYVXCfgMiXZF6SL EpCYb3GCtyk2fr/9D4hXY2T1t4578+lFjZ1Ws6Vyk6qQnQo0C6Yw33KrtiSvphInKbDUaWgR ifz5r9T9aq3xot6i/n+oXlcBUW9r92+jXHAix8o2l31P+vonAoHz3vetr/kwCRGUYOvkMymC Y7gowCtAFtcBsi6kAmfxES+Cay0jWBZvzY6LE/dTJAbvuhidosUXexHHqwHsPvy4NxU1cKLe dO/TapZmu6kxaC46abF4cY4rvMiNKty4vAysixi9vGiBexm11yiZm1YwO7a3YJmBK5aY+7dZ gdYYqwV7YUSWUKWx2frsk4vuvA7Hvb98uEr9aqEvExMTl1566fz58+FX0EL2LLKgJbL1FvUv rcB6Rb1Z3E2IZRZeNOmy77K7C4sGYJMNVtVMkReFw6AL+y5rodX2/ocesUpJvUhAMsaBtzgK od4Z1fjeD+499Og3FHWrinqzuE+rViYZFzwK4sQmEe6+a+gq9xA26gUiYxMKzHswLndcQxb4 +5JT8Sne4sSol2mQGGnwEZg1fMVFZJI30rAWEAaahxO8ReFE58gSqjYq9e4P7LtnLjxzj1l7 HNR9UM+JPUccf8TxvcdjGhzZc+TQ0NBUobuCNaLev129BYc96wNvr1y31f0UyT5y5eq+C6/B 38C/h8/f9bR9hPNAgSgncIXF3vSjbawxcOAjVm2HW2ZT/5kCJbstsXKAhujUBz69wmoJdxyJ URSzB9oWkMiKDfQusupI0cINC+SNbF6kLKLejJ5JcGz4/I+/2Wh7lHfcdm1TszT1xLltUWEO DCRgsC8OojCpFzZUpgH7wgAcT73ISzLmkRa1IxxvzBYVrAX+D/AJSX0gEhYo6s3oPq1UsSBR s7zSc9e19brUa369NM3aPsPGxG5epiGqmoUYb8NXAoiMYqkvSwg3JrIEr4bEumwn1qn82wlK o4G8FK/NmzcDbU/vP3352uUPbH9gyw7MhhePNeNrzl167sHdB18+ePn2guJnNaLeg3vm7rP/ IaQ9/MU5MB0IyIc1P+U5+Iyf8oVzo70Lb9jAj+wvrjCXXeFbq4LFoiIr0C2ZVbsfIf2pZy9J +C/ETea2mQWiZBfB3YqQmEAPAkZKt0Zcx5U3nn5euG3seBhqw7173clnWNVhPU12Enag5aza xgWVNqJtt/ui3uweIPB2aES9J95SWDQAjj4o6i/3PSAtaowpB4Dr2nfNAIzr5vZANwaybzz1 wjUCuXAEymyzIyBa+PXGFyLqjblTFK83u8dIcyXTggsjK62qjagXxlqXR5NQL9LDygtbL10U 6CwRvuJitP2W3Yh6I0torsMZpzZYty40Ff4ixdbBco8xbWoZYoq1N1vU9cPX98zpAdoGYDfw dmx67GODH5vbO3e6iB3CGlEvyYyoR7BzuRDgRUYE0uEcB3AWsMVcho+EY5IuedE+MnQjFLIK FoW3Zg0leuJTMzazTL41QIw0l8ajMLtgFl9WhEa6+Ii3Vgu/A5DOjfiRGMCKjIBI+zJgZYJH 8ZFLtCzctEVKZHSrxlvqwC7bp2ZEt68frIVVGPiyKFFvs7dquum3PvtEI+qd+/VWvqG18KWu UZYvbJp65d6dbcJikuyMvYDDXB3MymvUC5blArUZqdf1601Se8I0jzz2y332eZWot+X5L+pt Wbo0M5JHYQ6k0RfUS+8COzEPB3xKfsWn9IjACa2Y9D0I23rp7Iui6AQM6g1fMbMuTmhaRkvY KuB4GMEjS0hTkZTKooOyFYa+42sDLkINdJA9xUXzdUZP8RYXCam4zrcUBFf4zYSF0HmaL5y7 RTEZLvIvxohDkFK3sirmQ/0fOnvg7HjedT8d2TxyRM8RiHOUVYMalBvj4WBGTXAbGZG0B6iy j0hdrmMD7KDGjgREEiHBN/ARPqUhE+W4VcQYL10zMzMm5LwABxi4uyTKxrjmW/sUH4HFDXON s10IDrSNQrkmZLcuY1NWx6rJ0K6e/F7BQvjNwTXu4mKgAQnVkK03uxsN63cbefd+aN1tKSJs a0VhhiSEwhaSuXhKnKVjA0gXngww6P7Dbd826oXhFp/Suze5X28LrYrJMqMaP37w4X0P7G5N 6vZzycMhu/u0UiUTm/Ayay55C2/xEQGLvMXr4E5iGc4N2piMyMX0JC0wnBEeozqEr1hiJDDU o9HXCiTesZZwCR6OR4B66e0ADW0VIL9m2OI/fqmgxZ3IiytIzNGBtZguznhL7qfOrAUfud8T mIwmZ5wjpT+rwSJHClbeppCX+AvwhcU3Z1eHmNVsBls8IXKZQde1bjZ6uNtP+SgBrGb4S1Yj I5LncALgC1AjracBjHPToEDaPluz9ZK5ebAitpDNdlvrdtBlYp6bwwPbZmWSyF3/hDD1ouUk XX4fCBiSmd4ussBAw5idDC1brydPzo2P3R829/beuuyLm3/bPgm1WcJL9pgFf9Z02dFKc6nX rLy0+MKyyxi9jMvLLJYeV3CdFxnQ18rER4Hgvik2Hn698WoohkPMPSVbrycPHDUjEwXC1Gtf KoCwXKhnNnICMdphFnTiL02/9m3BjMdcNcjEMT4hTOC5hwPaj8Vqya28bsorRq44u//sTMav SVsvEYq+BEQ38BlPaPoNAFmj/8TgQpaDvK6dkrxLEy+rAPYlpF4kJggGymyKBpjdCkHV5nPs cmRkmYahTGnMTei0Ms2SHSiEVO12wXX8MG0tl8kSCbUsTdSb512TpK6xyXHX4nvamuuX3/dE U1M0o8Q5xOtNkUqzLmrGeL1rvr0Bu9llNBYzFitbb5J7TWmkQCYKhKmX9MnVeDRv0wqOi7TX utRLOzcLCTt7kJhdJxMrxPUJKQX1YvnajL68MUz82p7Xjo+PZzKEUYXG2HphwiSnGlSZgdbI jEDmBlIImF3pFYDDVrYxAYuirdTYMSH1uvbUSIssgTJwBLxdzcwccDg2W6/rZoBeuH1kg9kj 14HB2s+PCPThf2zkVMhLq7BbUVhP19bLEQkEynBRWLbe3G6chBVtGv/xAW98vSe8y6mI3+vx q33WNFmW8g8+5LB4NbQ3m2y9CW92JauaAo2olyQK9wZGfGtEvXQpgShIifTIRXcFoDAyurhs viW0+7rUy9VsjC7np77r168/pe+UeEPvp1d8GkejNNetv25B34LcehdDvbayyhiXtOeabMlh 7o/4pD1gIh1S3bVcYYAOhG5ITr3xNpJwyLMwfbrAyl5YU9nxQMuR3ozBTEDENE9ls44b5dOg a9xvbXats4GOUCI3RgShnI3hlwSXsxnSwf0SYl9R4iWSX28+t5iHOxJjz4XsHAbKArvWzhPn nhSvxueuv+nN7108o1E2owSy9eZzn6qWoAKT01OrttyJ454a77NAx1yTxqy5uEIg5hK0MPXS iGu7fpjvL3HW9vjgOkILPGflu9RLA7BbtW+TFcAKbI2hXjiOgkt65vbEpNlz9p65xXOI36WC P9Yb/1kwBzM3AumYBrhm3rGBkAL8iGRpfGbQ6VaRFvUm+Q8UNtO6ZlTyPf6i5STRwKI0Njtg 5w60PxBgIQn12tcAt2rUEnCiQEWUlM2w4SCImxWZwYYj1RD15vPo8JB6T5i/8OZbvlE6PM2o wX3vPjNejY8uvvh9nxpO8kjJIo2oN5/7VLUEFbj+gdu5NAFb70idtBQI4GxaxRZYDhaiAVjD cXldwAXvzki9iO+LjS3y6Ug89RLjjJwsblfApYGevqRAN8IAkrkfoTSzuZoZmK69rML1GOa/ EF5xLbXhNK39swnYobkwzqAcZbJh7BQqDXhu8NNAVLJA2/iVINB+elCEL1ovuL7NqnZFYxq3 YUjmOjwwo3uE46axEFFvPveXh9QLhgPJZQSRpSv2ymu+sOiCi2KaPe/kUz9x02hrD5n2c4l6 87lPVUtQAdtgHYEYpU5aClSPevEfbt+ufWOMuGcvOfvkM04G+MbbehcNLhocHExL5/hyUtyR OCZMLD5qeRO19v9ztFNCkti37ZQfkze+asBxO5KKevO5vzykXjAcSK50eJpRg7FY7c2nxKnx 8j1nD49NZ3SPz1isqDef+1S17KYAgi/S0Ns7MiBpUlQAvrkF7vGWYkesqPjoDTdsuGH/Q/a/ 6+m7ZqTewZHBD/d/OIsWhstMkXpnfIIrgT8KiHrzub88pF4wHEguI4gsXbFbJ5/Za6+9GjUb 21j8+d6dBd62ot587lPVspsCtr3kJZu+ImmkQIwC8dQL5AXvXnjNhTjB8fvIsLttUGxvRb0F /pupSdWi3nweZR5SL2Y4SA48VzpCzajB2J6tkRrFhi3DSIl687lPVctuCqzaspG2XpxIGlcB xCyDsZb7evCFt43Mt9z9zk3MLCykGkZfRBxD3LFGLEvYxcEwCMDfRik/NfypTw58Mp/JJltv TTA30E1Rbz73l5/UiwC04LmMILJ0xcLDoZEal11+1dv7lxb4iBD15nOfqpbdFLj4+zeSemH0 lTSmAPdOwwsAx7gNDGGGF6/bRnf4iFtUMDH3YOOLm1NYIWRfi91bOrWnpqb27tx7xv0pZvRw +ODAB4eHh/Ppvqi3wH9pBVYt6s3n/vKTet998dDHP/k3pcPTjBoMtL14YElk4cUuZZOtN5+b VLUEFYA7L5D3hFs+DgdfqUMFCLjcohl/ec6L3KOYAchsM2ecc9tnXiclM14v0sPcy+2gbfcK XC+p9fe4OcdhY+F24vUi70HdB01MTOQz2US9BaJngVWLevO5v/yk3s/eMdF10GEZQWTpisUu FdirItxsuPy+Yu/OFQ9sL/A+la03n/tUtbyoAII20NCLMA7SxRTgbhEw95JN8ZdL03DRtgvm xhPcuc32LjbYRQmGvywW+EV6Jg2XlHovH7z8Y4Mfm9HcG5Ng4+TG/bv2z22yiXoL/JdWYNWi 3nxuMT+pFxNPO7S5mBu5Q1uxu7Lx4SDqzec+VS0vKnDbI3eTehGyV7q4CtA5gX4L3E2N1Av7 LrCVLg20++KEhl7XTozrltE+4vYTpaZeODkgeFl8yN54Jn7f4vd9ZWV+6yZFvQWiZ4FVi3rz eZ57S70LFg1e8unLSmeXzajBSy69DEeg8MLdG0S9+dykqmU3BZbd/TVS79jkuKQJKAA7LnAW yGt2X0Iwrbw0+rq+EK5Nl9Tr+vji0wpQL3pxw/ANHxr4UGvm3jXja47sOTLPmSbqLRA9C6xa 1JvPXeYt9V46svmo178hI4gsXbHf+8G9xxx7vNtsH9wbRL353KSqZTcFFqxZRup97oXnJY0p AD8EECq8GniFmBvwcHAtuC7dchkciJl7EVsh9A8GRpfa1stez+udFxOYrBEQw0L81z1/nZtH r30JOfL43gLxS1UXooCoN5/nubfUi1n3qtd0PfTwY6Uj1IwavN/+B7hq+ODeIOrN5yZVLS8q 8NRzzxJ533P75dLFVYA+uDTo0taLk0bUS4ql5wMT083XLQRXLBaErXKjtwNeRsZlGYXp6ekj eo6A4Ta5xRfIO2/+vHXr1+XcR9l6C4HOwisV9eZzo/lMvYrk4AJ0IJIDDOEwhxd+n8qvN5/7 VLXsUmDjY/eTeq+451aJElAA0RgYdcGcGRiHgYEdAi9YcC2xmwDIRYsvPrUVb0hA47G9wlF+ /R8O/Lc7ds6xf7vyb5OA7x0Td7xuzuvWrF2Tf79EvYX/YyukAaLefO41n6n3C5um/nLfA341 NZ2R9bRcxWKjCph7qcbd9z54YPfRhdyYgUpFvfncp6pllwKAXVIv8FeiSIFmFdi+ffuixYuw b8VNozc1Yl9EbMDytUO6D8EOF82Wn0p6Ua8P/9vyb4OoN5XbZ8ZCfKZezLq3fXDgs9d8oVx4 ml1rF11w0ZW/V+Mt8991wXXr878rwzWKeme8xZQgTQUQrYzUC1eHNMtVWXVSADj71vlv3XP2 nqf3n75ocNGylcuuW38dTs5dei7i8iJIWZ4RG8LCi3p9+N+WfxtEvfk8hDynXkAVzL3ZcWS5 SoZfL7174fGc/y0ZWaOoN5/7VLXsVADL14i8p67e6YSqlxRoRwF4+o6MjAwODsL6u6BvAU6G hoZyXrgW2X5Rryf/3nJuhqi3nds5eV7PqRez7rg3nz6y+lvlwtPsWvv2dy445W3vfP8lwznf j42qE/Umv9eUsl0FEKqM1HvJpvyCp7bbaOWXAk0qIOr15N9bzs0Q9TZ5o7SY3H/q/cya8Vfu 3XnciScVdRx7wtyiqg7Xe/jRr5/10pcVux+b+ygQ9bZ44ylbCwpgWwpSLzaqaCG7skiBUigg 6s0ZNz2pTtSbz+3pP/ViQgJ8MR+KOhav+KeXnv+KroHjewc/fu4X/6GoZli9Q3f+0pObVJHL 8rlJVcsuBcypF5sSSxQpUFUFRL3+/IfLsyWi3nzu6FJQb54TL7KuSzaNdVzRweOVn+86aWTx RzeuHd48XXjDCm+AbL353KeqZccL//WfJ9zycRh6e0cGJIcUqLACot7C/7EV0gBRbz43tag3 4fR+37eGDXzt5MAb55zxzaHP/PN4wkKql0zUm899qlp2bHlqK90bLv7+jZJDClRYAVFv9f5T JumRqDefm1rUm2Q2Mk3PzX1h8OWVl14z+7ivLjxn/cgX7p9KXmAFUop687lPVQvuwI2kXpxI DilQYQVEvRX419hCF0S9+dzUot7kkxMuDXBvaAS+dn2/G3pO+cbAJ74/mrzk8qYU9eZzn6qW HYvuvJ7UC6Ov5JACFVagQOr9wJIbDj/uTTpMgcN6Tnj9yafn8x9a1JvPTS3qbWo+w5nhT66c NSP4IgGSLf/RZFOFlzGxqDef+1S17IA7L5AXrr1w8JUcqSuAqHCbfvGT1ItVgS0oUBT1cjfU dRs36TAFTnvXGft0vhoL6nP49yzqbeFmaSGLqLfZyQw3hiTU+8F/WtlsyWVML+pt4aZTlqYV QNAGGnph8W06szLMpIAFQsbJTGn1eeYKFEW92go1EGn/V1PT2BfqquXXzXtXfw7/nkW9md9a v69A1NvCZD7x7/vjwffQL/W2UGwZs4h687lP614LAvSSehGyt+5aZND/O352D+X90oPrMihe RTanQCHUiyDwr9i7c+vkM9ntsVS6kq+85guLLrgI7AsTOAzhWf+HFvU2d5+0mlrU28JMXvGT 7XDebQS+f3zlHnXwbaBuot5W7zzla0YBbMZGLJMxshnZkqa1+BjL7v5a0jxKl5kChVAvNvz8 yMcuLh2YZtpgGHofevgxVPHZa74AQ3gLrNBUFlFvZrfUbgWLepualpYYXIu4DZHg+z8++yc1 cW8Q9eZzk6qWXU69oN7nXnhecqSuwFPPPcsvFf3fuTb1wlVgswoUQr37Htj94wcfzhQiy1U4 XHtPnHsS2wwT+Mv3nN0aKyTPJept9k5pLb2oN/mcDKS84LvrY/wcEOasDttYyNbb2n2nXE0o YEyGvdmayKakiRXAAkFS74I1yxJnUsKsFMifevEcx4/45aLSrFt7zrnnf+76m6yW4048CVTa Mi4kySjqzeqO2r1cUW+S2dgoDSKUueD7p1fvecDwMe4ubpf+cHM75fufV9Sbz31a61o2Pna/ nHqzngGnrl5CkbOuSOXPqED+1Pvui4c+/sm/yZojy1X+Pvu86pHHfmltho/vW8/K1slB1Dvj rZFKAlFvm2SJhWuGuQjvgNJOWzPoojA2b2uzCp+zi3pTuQ1VSJwCV9xzK4EM+CulMlIAdnSK /Ozzv82oChWbUIH8qffQo9/wvR/cWy4qzbS1UOOYY493q4CD76te05XpP2NRb8IbpM1kot42 pzE2Y9tzqBOYe/hX5ltRl2wa40Ue+Kiqe7aJetu8AZV9ZgXwszuBDK4OM6dWipYUwD7PFBlB 4loqQJlSUyBn6kV0glfu3ZkpRJau8IsHllx2+VWBZncddNhn75hokxhisot6U7uFYgsS9bY/ h8G4WNkW4Fo49QJ2DXwBwZXcrU3Um899Wt9aYHqUy2kOw7/8vtuo8/1PPJpDdaoiRoGcqfeC 69a/Zf67SgemmTb4zaecuubbGwJVvHfh2ecM7vw9N6ND1JvPY0HUm8oEbmTKfd+3ht293Ob/ 49JUqvOnEFFvPvdpHWuBZRfRed/37c8es+pjoLFPbfpyHVXIq8+rtmwk9SJ2b151qp5oBXKm 3jMuGrpoYEmmEFm6wgNOvWx/1q69ot58ngii3qwJEpsYd17XbUbfA2+cU6VovqLefO7T2tWC 39m5BbF7yK83u3lgSwaBv9nVopKTKJAz9Z4wf+HNt3yjdGCaXYOxiA3UGy4fscwOP+5N2RGD qDfJ3dF+GlFvdnPYSsauFu52bnCH+OjGtTnUm0MVot7270GVEFQAgbQspEAAfOV1mtF0gWMD pcbawYyqULEJFciZeg/sPvruex/MDiKt5BU3f93Ol33msz+dmLS3Q58ffvzJXwMrcd09cJEf MSUS4G0gV+oth28DPBzCxWYdtVfUm/AGaTOZqDcHNGQViPDgbmxx0shi0HButWdUkai3zRtQ 2SMUsA1yA8iLt9qROKMZMzk9RbWxrC2jKlRsQgVypt6Ojo7UwTGyQAArsJUfHXjQwe847UVn 4jfMOfEH//wAeBfXA9R71of6jXRxjgSGyzjPouU3rvjq+886O7JkLPvLbmtiUW/CG6TNZKLe jHAwstjP3jMBDwfzdoDnA67k2YDU6xL1tnkD+p59+/btfQtO6Z3Xk+dx4sffGeZdXjn+yg/k 2ZJwXccf033xxRf6PmzNtw+b3lFhbQXSvHgp56gq9d7/0CPAVpd6DWeNenESwE1YiC0XPr3w ogHajEHJ4cSpQPCSSy/DEVkU9vLA/7zU/4+yQFFvyjdSg+JEvRlN4EbFwr6LNW0Gvljrxii/ JT1Evfncp4XVMnzDF/pP/9OxVR15Hn+3qqcR9X5w1dvzbEm4rhOO6tjnL16OLwOFDUlmFZ9w y8chO3xLMqtBBSdSIE/qzXlXNrPvwkwLCDbDbQz1wrJLukV6ZIe1mBAMk7Dr7ZAK77KQGOo9 7PCjP7NmPKP/1qLeRLdH24lEvRlN4PhiEcXMDeh73FcXlnT7YlFv27egxwWA7br2e8XUpo4d W3I9nrr/zxpR79jdXTk3xq1ufE1Hz6EdAx96Gb4MeDxuLTbtPbdfTtlbzK9sKSmQJ/UiAC3C 0KaIjPFFAVjpn0DnBGArOdioF+4W+MgOloZPkQuYSysv8+IiODiLlsO9AU4OkSVnui+xqDel G2iGYkS9hVAvKkWwM3dft1d+vquM2xeLevO5T4upZeXKlYvPfGkhlLl83bww+Pbf1ldIY6zS had2rF3ega8BnfvsWcyQZFnrojuv124gWQqctOw8qRekBZLLgh0jywS20kBrLrmgXlyJsfUi MbwaYOIl+xoiZ+TUi/JFvUlnajnTiXqLol7Wi/2KXW+H0m1fLOot532frNU9R/4VrJtFgeaX Nhx/wlfPM/a94p96X3jofxTVGNQL2O16dcf2B3YK0nfKXuvXr0+mYmlS2c7PjzzzeGkaXcWG 5km9l45sPur1b8iNelERjbvGrABZWna5mi3SVZdeDfYRKBlvzdk39caLeqt4V73YJ1FvsdSL 2mHihaG3pNsXi3or+3wA1YHtCqRMVP3cgy/ZMvZqHM9uLsbk7HZ/4KyO4U/t+g6w09XhyL+q 2Nh/6cF1/I4xNjlesa6Vqzt5Um8+fr1u9DHCq2upxadwbIiM4eDGfIDFl4BLh2A3Dlq64Lvo gouwIYU8HMp11yRvrai3cOpFA+DUC9ded/ti7HLsQ8NmbIOoN/m9VrKUC898B37NL5Z6vaq9 85U7zb3WpO6D9pyYmCjZoMY21wLG3fbI3VXqV+n6kif1Do9Nv3zP2elSY7g0l3pxDmyFWddN 1iher1Evc1kWZLcgvqk3XjEcSnfLNNVgUe+MYJdbAgRzsO2LcfLBf1qZW9UtVyTqbep2K01i rGPr3OfPpsdEvbsU2DzSMefI3dRYeu6soeVXlWZEEzQUJl7aerU9WwK1MkySJ/Xi0Z9bvN7U 8TSjAmHohbk3snBFLstw3udVtKi3ZeDLIiPC97rbF2MniyxqSbFMUW9ed2q+9YyOjs6fN9sr U2uxjVna3zF00W7Uu5ODj+vOd1iyre3Z53/L4GXa+TlboWcqPWfqha0Xu45lRJBlLBb7M/e9 +8zIlr9kj1krHshqcynFcJjpzkjnc1FvigiYSlEI6Ntzc595OyDOg89BzUS96dyHvpWyeNGH Vy6TodfxZ+jqmLgjKEjn3i+dmprybezaaQ82fMbWxO2UoLztK5Az9fbMfRv24C0jnmbUZuzP fMSRR4UL//GDD+97YHcq/+YjCxH1tn/vJClB1JvdHG6nZHcnC6x183YLN1FvkrusfGkQmSv/ ML3FWnNjagfvdndFfAdAWDcEdyvf6KrFfiuQM/W+9ayBRou3MsJKz4v91dT0Xnvthb+BdsIG fML8he38X4/PK+rN574U9WY3h9ss+aMb15qb70uvmY2NLdosMIvsot587tNca8EiLSzV8pZB 828YzN6L3xNBvVjthzV/uY6NKquBAjlT7weXrfxg//mek2jOzYOtFxbfQKUXDSw546KhLP6P skxRbz43t6g3uzncfsmf+edxdwu3931ruP0y0y1B1JvPfZprLWvXrl34dlHvi5gL5I3099hp Az7k1bmOjSqrgQI5Uy+22MVGuzljpefVwa8Xlt1AI+edfOonbsrQ+CTqzefmFvWmS4Gpl4Yt 3Pa7ocfcfE/8+344/qZeS8sFinrzuU9zrWXppUsCK7fyN696VSOiN2DtWmSTZu3xx4h3kevw qLKqK5Az9WJ51iv27tSCNpdxsSMx9qpwr8DhAcv+slvKJltvbre1qLdl4MstIzDXjeZ74I1z gMK51R5fkag3t1s1v4rmv3XO6E1ayvaiArNesmtLtjD4zumZvXnz5vzGRjXVQIGcqReP+Hnv 6gfneW5/zbN5+A4A1163Riz4w7K/TP/vytabz80t6s10GqdYuLt3Mda3wfkhxcJbLkrUm899 mmstWsrm0m2jpWxMowVtuU7NelSWP/Xih3v8fJ8nVvpf14lzT7I9MtBauD7DAbrl/5RJMop6 87m/Rb1JZqMnaS747np3Gwu8Lbxhot587tP8akEoLgTkasrBYNuPOq65sGNs1W7mYVzBdZaz +sqdCVZ8Omg/xpXI68iC6zy2rO54+q7dMqKiQFFb1+1KbG3AiZXAEzYGRbFSNClhH3cuWTu1 YWLsUTzwyQvyGx7VVAMF8qde/HCPn+/DUQv8Z9PsWvi5628659wXF/m9cu/OL2zK9jdWUW8+ N7eot3BwbKoBMPHC0GtuvqetGWwqe+qJRb353Kd51PLUc89ecc+tH7j9s6//8nnLvnXK/f/P fgm5EGCK1xknv4iGYEq8cB0lzO3pOO/0naC55OyOQ/bfhbAbbth5jit2HeTqVodPSavM5SI1 CsQVS8yimBgfIT2h2S4a9QJ5rVI0CYmTdHBksKN/QcOUOz/98HvzGB7VURsF8qde/GNATK7w +q3smNL/kh957Jf77X8Avwl87wf3Hnr0G1L/9xkoUNSbzy0u6s16JqdePjatgGuvgS9cfgtc 3ybqzec+zbwWbE/QOzLADWnt2HjXoUm4EHQbIFEQMPgS1/mRFQIkpZmWn9p1XCSt2uFyLbGV HwGOidFmrMVbgC8/hUGXGUnAgcaToe0iEgRQO7KzO625ZzWk3vXXdfQtODnz4VEFdVKgEOpV JIcwiL/9nQtGVn8L198y/10XXJf5T6ui3nzuclFv6lSaQ4HAXARzMPBFkIflP5rMod5wFaLe fO7TbGt54b/+M4y8ZN/JH8+eEXyJtgESxRVyLW2uLl8GUDiyfJd63ZJ5TvZlRgJu2L8iTL1I g2KRPeAyEd/BwUUdOBqlQZm983qyHR6VXjMFCqFePNxhzoRR038rbG4t5CZt+Htg99E5/H8V 9eZzo4t6c5jMGVWB8L0Gvgjre+kPN2dUUUyxot587tNsa9n0i58ErLz29ksbjk9IveA/OjkA K2G7NeoFYgJVgZs4cBIwxLoOuAFbL0rDQSuyQbPRsHsRNTKZ2X2BwnixUh4snI3kFbMfx3dw aX9HTBw3RDSbc1x35PDg2Qp8Wb9+/eDvX/Pnz6/Y9sXZTsoal14U9cKcCaNmbkxZioqwpu3t C979/kvyCJUv6s3nphf15k+KKdaIDduwbRvZFwvdsJ1bioUnKUrUm899mm0tX3pwXSPqveT2 UxNSL826+Ev2Neq17MRfHEBPM8SSeum828jDAQ4MTA+6RTLSsDG0m4sJUFGkh4Obkm1IsqYN Tr1w3m0kwuTGjn1f/ecjIyPg2qVLl/b+/jVr1qyd0L37a86cOdmOYkql3/bI3ZgM8PBOqTwV 07QCRVEvnvh/1X30cSeeVOzx+uNPLLYBbu0Hdx/+sj/bK9MwvfaPVtTb9K3SUgZYH16yx6wj j+/VUVIFDn3z8S+5dJYZff+if988O3JYz5yDDo02dbU0H1PO1JFyeRUtbtWWjalQL1enudQL oy/tuzzMtyHg14vrMdTLVWjkaXPhtYvEXNdbF6VFUi+yu5jrugvHkH2jjdmYBXHNDjmos7u7 O4y5gSsrV64sxfR5z+2XczKUorWVbGSB1IswBWCvAo8TTjtnz1d2nr98bYFtCFR95T9tTWIB aj+NqDe323l8fBx3mV7lVeDOH97Z88UX92+bu2IuruTWHfxckNtcbbYiUW8ixbCUrRH1bvrh QcltvfBDoOOsa+ulURYkSj8EYiuNsqBkXKc7hAvHNBtb6DFGZjDMtfaAYhmGjFZbFIVktAqH YzjAuEu/XkZDY6VJHHyT+PXiHujq6ooBX1h/y+Le0P+dazkZENMj0exRorQVKJB620e3dko4 bdEgb6JXvroLPyO2U1QZ84p6076TVF7FFVj83cVm8e25uWd6+3TFO5yge6LeBCL9PsnlYyNh 8F20ZsELD/2PGakXkRMsgK45y+KKxeulxRdI6q45ox8CyBV/A2vRiK128FMgdSBML66TsOkm QQg2/123BKvCrTQJ8qK0JNQLAXf6inV2NgLfY489NulIFJ3u4u/fyJmA70JFt6Wm9deTeg15 awu+ot6a3vDqdhsKrHxopcDX1U/Um3Q2Xf/A7QHqRcje5x58yYzIW/kEyeP14lez2bNnNwJf fLR48WKkSTokBaWDRy9nwpanthbUhLpXW0PqDSBvPcFX1Fv3O1/9b0mB0Z+Pzrp6l5svLL6T 05MtFVORTKLeRAOJ37JPuOXjZJ1b7vvOIW886Kn7/6zyOJuwg8mpF1oDaiOXsrkoDCfgoaEh bx0ebGnjxsfuTzR7lChtBepGvZHIW0PwFfWmfSepvLoo4IJv1xe76gy+ot5Ek/6STV8h8i6/ 77bt27fP3nPW9gcaRi1ICIuVSbYzIu8xDdVYeu4fA2FdlUdHRwPge+qppyKwQ8AGDD/g6enp RMOTb6KR8VFOBgRzyLdm1bZLgVpRbwzy1g18Rb16BEiBlhXY/OTm2dfuimhWZ/AV9c48hWwp G8y9zz7/W2ToOfKvxteIencpMD3WMfvPGqrRd8peiMgbUDkAvps3b0YCOP6Cj91oD36ae2Hi JfUissfMs0cpMlCgVtTrLjsD9pF0T1zQX8blaG22WdSbwc2kImukwPjUuIEvTvC2Rp3/Q1dF vTMP+qI7ryflwLWXqfs//N6YCLWVMeIm70jXqzsQlzcyfde+L48MYoIIvvz/DcwNjAG8IBDc N8zKMw9VLinGJsfN8J9LhaokqICot27UOzI2/chZA//rlZ2/fOlLd8yfvyP0RVo3iRSQAkkU AOl2XtfJ9W31BF9R7wzzxBDn1NVLsC8xUw8PDw98cI/kUFj5lH29Heuvi6DenWbgvf60kcQE 34D/Q5L7ttg0WMRG6l1299eKbUltaxf11op612ycnO7q3tHRsdsxMFDb+a+OS4F2FIBTLzwc DHzh+dBOaaXLK+qdYcg+cMdVYSdO/NPtPX525Vk2eQcbBS/b6fI7rydGYth023FjQF6MRTsl tHDHYmkjpwR+BGghu7K0r4Cot1bUO9nbF0ReEvDatTvnEqK+jI3tPGAAHhzcdfT17ejtbXgs XfpiSmYZGdlVCMrxOMB++/eOSpACUMAFX4R3wFq3+sgi6o0ba+49i8M19CIDVlnN3lO23heN uzD0wtwbpuThT3UMfPKC7G4n2/mir69vLf8FZv967oXnOSuwSVv2tamGCAVEvfWh3tvvmIhG 3oDpN/W32CAd6AwgxoMFKKyXFKiWAtixAlHMaPGtFfiKehtOZPgzAHbJN/BzCKSDCTO8c0Ry 42jFUiKiBRa0heNawCIOQMnuWRGI/suIv1wbl+nLvgtlWosKb6SAqLc+1Pv9m0aLod4wRnd1 7TQew048PLyTg6emdIdKgVIrEADfkfGRUncnYeNFvQ2Fwgp9wg2cHMKJ5NobAPewa2+8U2/C CRqfDOveFi5cGA4ADBswfCey2wp8wZplnBup9EKFNKuAqLc+1LvpuvUNqfeP/uhFHwa4+dJX gUjKIxD6EN+H7SOerFwZdHVYvHhnmbNnJ0LtWbN2Lq1DjRMTzc5hpZcCPigA8O29tdc2b6sD +Ip6oyceIpTZthT3P/FoOBGICtEJKmaybac74b0qdl758HtzuLHhcIKFceGIv1gqN2fOnJUr V6Ye99e8vRnJTq+cFRD11od6b3lg+3+9ZFY0g2a6oG379p1YDH9fkDQ4GKFm4p0oYAkGMcO3 GBn1kgLlUWD777bP/8f59QFfUW/03LT9h7E/RaPZq6i9LiWHo/ZGRurN9FEQjvhrO1/Q8Rc7 jKTSAAtmh5VtqRSoQppSQNRbH+pFiN/7lq2MIE6YY/P3McDKudHRnRzc378ThWHrjURhGYCb up+VuGgFAuA7ODZYdIsyrF/UGyEuDHj8/RoHtqhoJP/g5ZcNfuyP27GPViwvdmgzX+ednr7Y wS4lymz2DoDnAxx8Ozs7A/u9wRcCHhHtRwK+4p5bOT0QxazZtil9+wqIemtFvQDfBz41/MKf OV4HPT2+RFqA1wQ8fdGeSPyVAbj9u10l5KVA/3f6zeJbYfAV9UZMqCSGXmRDwKyufffU1sTG 7m4kh+ElfzzwifPzulsb1gPA7e/vDyx6AwrjCq637PmAjakbLXMsvMt1aICot27UC/DFRhVf uWT440f1eOpEC8MzvIQR9qGRAXjhwp12Yr2kgMcKuOA7cFc1Q2KLeoMTEKEbekcGZjT0Mtvi RR9euUxbE7+oQHdXx8QdO9927v3SnMPoxjxJYHKGe0N43Rvswa09f2ylI3Ynbq0E5WpHAVFv DakX4FuaHYlBt/A5jnQFxkXAcUE/grVz0ylvTRRYevdSs/gCgqvXa1FvcEwtRu/F379xxvHG L+k9r92rYo4K7XRnZ4Des3bu09a34OQZ1cs/Ade9wceXng8tbwt3x8/u4fci4G/+vVCNol5R bznuAsR2QIQHuPkG/B/glAy/CG2HUY5RrF0r4d5g4AsIrlj/Rb3BAcXWA039eA28i9yMtx12 LG9e+Ht0vbrj8EP2xPcBn28V4G87gYQ3/eInnCRwhvG5m1Vtm6hX1FuyuY0YakNDO+DmG8Bf uD1kH1+8ZFqpuR4o4ILv8OZhD1qUWhNEvbtJid0omt12C3jXuffLsB1DkcecvYusffe+H/Ca Wd2HdqU2Q70s6JFnHhf1Fjgyol5Rb4HTr62qsdMbdn0LsC8WwyFEmtwe2lJWmVNWwHV1WD+x PuXSiytO1Lub9vBqIM3AzyH5oAB88W+4qNeqb459fqSoyqPr/eUvf5lcPZ9TwiQMdwi84BcR WPoGKy+i2k1Oa3+mAgZQ1CvqLWDapVgl7LuIfRZg387OnTHR8g/HlmK/VFS1FFh4x0Lbsnjz k5lvepqPeKLeF3VGkDLbaRZr2vIZgPZrueDGh95/9f0v/O6/2y9KJQQUwA4XbuyzdIP+Su2W FRD1inpbnjweZQTgwrsXsOviL0JA4KLsvh6NU32b4sbxnX3t7IlfV2EPQlHvixPagrCWyFnz /kd/feqlYzjW3fdkfW/NzHq+cwe+rq7IoL8ICpFZtSp4BgVEvaLe6twkAFy4NwQCPgCFFeas OmNc4p5gy+Kem3to8e36YtfUttL/vCnq3TUdbQtibERcom1mYegl9crcm91zhUF/scNFAH8Z 9Lf9PS+ya3lVSxb1inorOLexATLC/bp2XwR/UJyHCo50ybo0OT0J3iX4goBhAC5ZB3Zvrqh3 lx4WgXXZ3V8ry4iaoVfm3hyGjEF/LeqZS8DC3xz0d6sQ9Yp6c55y+VUHE69r94XDA5x95fCQ 3wCopggFxqfG4eFA8J3/j/NLDb6i3p0DDC/eU1cvSbgzhT/3hBl6Ze7Nc1CwrA3+vr29vQHT r235Jutv1sMh6hX1Zj3HiiwfjIswZ+4eb+BgOTwUOSSqe8foz0dnXT2L4Fvq3StEvTtnM3bY IvIuuvP6sszugKFX5t78Bw6bz8XjbzshgfPvTolqFPWKeks0XVtsKta6BRwe8FYRHlpUU9lS UGDtv6613SsQ0DeFEosoQtS7U/UP3HFVUztTFDFSwToDhl6ZewsclBj8FfhmMS6iXlFvFvPK xzLDDg8wA+slBQpSYOi+IQPfkfGRglrRVrWi3h1bntpK5F2wZllbWuaYOdLQK3NvjiMQXVUY f+XtkMWg1Ip6zxkcOW3RII8TTjuHfjX7HdpjF3GyfOPkqi07Kn9csmrshHm9Wcwor8uMdHjQ jm5ej1mVG7f4u4sNfOH2ULquinp3YK+BFnamKHakIw29MvcWOyhu7cRf7G3hT5Oq1JJaUS+I 9pWvDobPc33KQb2V5112sKbUy1s37PAwPFylm1p9KZECfd/ss90rsNCtRC1HU+tOvc+98DxC lYF6e0cGyrIzRYyhV+bect1+am1rCtSKekF7MeBbH+StO/XyVgk4PCxcuGN6urWbSLmkQMsK IIbDnFvmEHw7r+tEaLOWi8o/Y92p19axYYuK/NVvrcYYQ6/Mva1JWmAubIQxf/78hQsXIiwa gqMV2JISVV036m0EvrVCXlHvrjsUT4nFi18M64vwDhNV2DGrRM8fNRUKYPcKC+KLE7wtiyx1 p96Lv38j3Rvuf+LRUowZdh7+6ePTdvz96OMk3S98a8K9vu3//K4U3Sl1Izf94ifL77sNPxe0 0wvscxHY9BiuEXCQaKfMyuetIfWGwbduyCvq3e2+hveUhTabPXvH+vWVv+vVQd8UgIkXhl5a fGH6LUsQ31pTbxndGwLzftOWKVLvN35Ypp8YfLt7W2iPbebX5v7Vo6OjtusbzL3gOb7+5V/+ 5cknn3z++baQuoV+lSJLPanXBd8aIq+oN3hvjo/v6Op60eiLzSz0kgL5KgCnXgviC2fffCtv sbZaU28Z3RtEvS3O9LSzPfXcs2nFeIZlF+ve4OTwy1/+slEzV6xYcc3vXwC+LVu2WDJecXOF rzQqc9u2bYHEGzZswJV4qVCdpWF6/s0zRltr1PuFTVNHzX3rXx8/r9THIUcf17n/gaXuAhv/ /iXXN7sIr9ar2SJvSzj19va+CL7YwVhuvmk/6lVevAII42AhHYY3D/svV62p19wb8FO1/0MV 2ULZeosaOKPe/u9cm0Mb5s6dC0eIQ37/wgneslK8DXBq+EpM85DYimJp7tvIjKgOyfDR1q1b 2RJemRGXU1SpNeoFMx181GtXja3SUbgCnxr+FMBX1JvOTTEw8CL4wvoLG7BeUiBHBQC7FtJh 4te+e5nXl3rNvQExHMoSvSE8jUW9Od7awaryDPMMuCRr4rV69WrgJinTcBMMShsw/j799NM8 IZvyBBftI+vJeeedhxKYnhSLwvkpEuMKz2EVZl77a81gerdkq9HKYXb8TWuwWqbennnHb0Fj dRStALBb1JvW7bCzHPj1wru3o2PnAX/ftWvTLFxlSYGZFJj/j/MJvt0ruj138K0v9cK+S2pZ dvfXZhpQfz8X9RY4NkVRL7oMCKZRltRLDiaAGgfTcEsj8RlnnEFuNsalbiRduE/gfMmSJWbE ZUq8gMX4CFWYpZmWXVAsrc52TgonRrMuQrMVxVpSeYl6yw7uot5UboTdCkEkB8RzIPjigAFY LymQlwJT26ZsZdvAXV7PvfpSL2CX1FJe9wbMZ1FvXjd1RD3YzI9TKIc2uLZeUi8JFX9BtKBP 4mmAenmRiWlwRUrXLZjpDaBRFK4QkXECuER6wCupF2/pCsyq3dKI2mRouPmyEJbGFqYrkahX 1JvujKpIaXDq7evbzc1XwRArMrQl6Ibr4Ovznm01pV64NHBzilK7N4h6i30SFEu9hqoMfGZu ta6tlxcNkSOplyZeoCq5lpxKVMULJ1xIR9LFK4Z6kZKevmZadik8xcEqhHpXb1l919N3lR03 PWm/bL0p3g7BohDMwSy+WN8m8M1QaxW9mwKw8trWFbD++qlOTam3Gu4Not5ibyqsY6OtFyvb sm6Ja+uldwHtuDwhidI9t1nqRS5zQmAvzH0C5zQMJ6Re2oaJzubpa+1JUaI8qXfd1nUnn3Hy /ofsj67hL44Lr7nQ2JEf4cCJXbxy9ZW8iAOsjMPehk+QCwUGrvfM7XFriczOGq1wnODt6eed jryfXvHpMN3GtIF5GyVgS8KNRHrUdcOGG1ogaVFvirdDRFFw87VovgLfbLVW6S8qAI/enpt7 CL7w9PVTmppSbzXcG0S9xd5Ui+68Pk/qpRmV+Iu/XBxmTIkrxsGBhW7xtl5irusjQZMtbMC0 9QKLE1KvETPtx/jrtjDFwcqNemHcNd4F4fEcL0NSXOQVfGTwB/TkRbwC1GuJDTEJlIHrfHv2 krNZpsvcltGo1ypCSrbHJWZrlQu1geqMeo3s3cRGveHG80oL4CvqTfF2iC4KexcLfDNXWRUE FUAMB4vg62cgszpSr+ve0ObGWoVPefn1FjgE9t3pkWcez7oZFq+Xa9esOguUyzC6bghe+4h5 kYWfhmMpMK9FbEBKVIEreNF+7MbotXO3NKuLiOw20j5KUaLcqBdGU1AdUDJAtMa4pExSKdnR INWFUcseSaWk3phaAuW7tlVUmpB6LVe4OrfZ1ouABTecC18J2B3Xzp3Q7ivqTfF2aFiUwDcP lVVHUIGVD630OZBZHanX3BsQr7fsE1bUW+AIXnHPrbT1bnlqV4SvAhtTq6pzo16iHqDTPHpx AhQ2NCT20bhLmyg8IoiwkaiakHoDLOsn9aKzsEYHeF3U69edGABfvxqn1lRWAezT5m0gszpS r8EK9mYr+6QT9RY4gtiLuAJhQAoUsOWqc6PegIcDIA9GShfsSLFw5DX4o3kYKduhXqNt1wqL WugvwYMfpW7rRctRu3uwooCtF8rAsYF9BPQnhF1LJltvy5O/6YwjIy8ubuvvbzq7MkiB5hXw OZBZHan3PbdfTlgpu3sDpqKot/n7MbUcq7Zs5ESqwNen1ETJpaDcqBeUBrYz5136EuBtwNZr S8qQHj/309W1Werl4jDXe9g8B8yfmA2g+Tkj6rUqAhU1cj52HTOSs6+oN5cb5Q+VxIMvlp/u vqt5rm1TZRVVYGxyzHYq9iqQWe2oF6Sb5+YCWc9nUW/WCseUf9sjd3Mu4aTAZtSw6jyplyQH SoMRNLx2jVdAvS7sAkl/tO1HzVKvi5vI6xpQWRSZmIcBcc62XqK5ra6D+Tk56bopRb1537aN wHd4WFta5D0WtanPz0BmtaPe+594lKRyyaavVGDuiXoLHESYeDmXYPRNtxkInmC7TsSUzBhh 8S+GzmWEhywWls1U/87tKlLclY3V5Ua9YEqAHVx13Z/myXx0dTDqpWMD2Zfmz2aplyZkHG51 M64zS516E65ms2V84dYm4WBR74w3TvoJAuCLOL6LF+9yfujpSb86lVh7BRDIbM4tc3wLZFY7 6h0ZHyWp4KQCc1LUW+Ag2rJIOPim2AxuL4yXG1QhXL4bVTemdsbitZBnKDYJK6fYnVLH67XF ai7JEWdp5jTq5SI2vhhxrAXqbcSLHq5mM49neTikeLNkXpQLvnvv/aK/L3a10GYWmatfxwo8 DGRWO+qFiZfUC6NvBeagqLfAQUToBs4lrI9MsRm2sZmZe93AYbCb4oUrxFmaUS1eWJhoibxs HvdmYxQzy8LYZHhZtDIWwkr5142VxmRmvmX8Mu5abJHOkJ3h0tjOyBpZMvaE46dNvXKz9XKZ GkEWRlBYKBmuwaI6GPUa5poZuEDqhck5sCINHheG1PGRy8Kr2bjnRTgXzdt4RYYHjrf4ytbb 1IRPM7ELvraFG04S/HCUZjNUVm0UGBkf8SqQWe2o13aRrcBSNtw1ot4CHx0I00vqReDetJrB ndKAjEDe8CbAqIVWW24kwY3ZQJxm0N3pY+pE80V6Ui94Fy8kpq2XtdCPgvtQ0MCMfSV4BYkB o7hC1wh+hNL4qe2UYSTNZEbYSIwsuML9L0jDgRpZPi82q15u1At0c7ecIOQBZ82f1aVeujfY OrMCqdesznbi+i3EU284L625kbmsy83u1SzqbXbOp5Ye27b9yZ/sZuUl+2IfY72kQDYKWCAz 7NyWTQ1NlFov6n32+d9WaSmbqLeJmZ5BUmxEzOmETdrSKp67mtHUaggLQDQCNscGQ0zuoMYG uKzMK/iIcMm/ZGK3QNpiyaConUxsaXjOYoHX1iSjc9qPWaw1njiOK0zG8q2R7hWzNDclYJ7U 6y5lA/8B/lzCg70TV2hJBcnh3HYDprXVNbIiDdMHwp8FMoatpJFFMRnKdz9l+eHDbUaj6iIz Wo8ic0EK5mp2ezZRb1MTPrXEQ0MRvEvq7etLrRYVJAV2V2B6+3TndZ20+K7917XFylMv6h2b HK/SUjZRb7E3j1Fv/3euTaslZrWllZTOCfHU6zr4uimNelkIyRUeBTgHKKNw/KU3BQmVCQjH dD8IGJsJuPhrJSONe9GykGvdZOEaw01NrmHO1JtkeZbSNKWAqDf5bE8nJdx2Fy5siLyg3tmz 06lIpUiBKAWwOzGpF/iLVW4FilQv6rUAq9VYyibqLfDOYdXp/nRA+y4spjSO0rWALrPgSHjQ 4mUmXjshrXKfYVKsK4slw0V6JtAT17LgHFXAWEtXXVCsa/2lj685QhjOmim6EfXSb4HJzNbL RrJGUW9TmFixxKLevJ9d09M7EKSsqysOfMfH826V6quTAnBvIPiCgAvsd72ot2JL2US9Bd45 rPoDd1yV4mo211cBhdM9AMRJdiS/GsXSGIwsSMbrfNGaay+XelkOCiQ92wsMilxMyaJo67VK XR8GWqCRhlwbSb30EmYyUm+4Rpd6L7vsslFsnZr41aytd3hs+n2fGt7v0J6X77XnifNPDDgY VAwoS9EdUW/iyZ52wrVrd8yZE82+K1emXZnKkwIvKrB+Yr2Ze+HzUJQ09aLeU1cvqcyubJwx Ws1W1J3Del/4r/9EJIe02gCCDEQrsyu4jnMALk6YBudueq5XC7vJBspkOWwws1jjWaAVYvbg yBLcjHYOtLVzqwhXaOIN1Ogm7urqAhyPJzY1NUW9yzdOdnZ1BxZpXTR0USnosKqNFPWm9dBo sRz8hgNHXjeGA861X3GLaipbUgXM3IsNLJLmSTtdjajXvDARxiFtGQsrT9RbmPRVr7gdD4Rm tQH1zpo1a2pqasaMk5OTQN7h4eEDu3uwS0SS48Aj54TjEuCKLL4FIrWod8apnkeCycmdG1XM mrULf+H/oJcUyFKB8alxi2I2tW3mB34WbakR9VZvKRsmhKg3i7tCZUIBN0hw1oJs3rwZODtj LcBiwHEAYV/6Z7MPPaYXx4kL+k9bNBg43ti30zc68rWgf0GB2FfzqkW9M872/BLA5RexHTo7 d7IvzvWSAlkqYFHMFn93cZb1NCy7RtRbiL5ZVyrqzVphle+PAiDjRgjbwvVXd7265uhZYPdF vZG31Tnn9J/0pjcVdQwddthHjjmmqNrD9c6dN+9Nb+r15/mjlqSigJl7YfTFeSplNlVIiamX MfDdV/wOrk3pAh9Hc0ZsKmPOiUW9OQuu6opVABbowcHBN7/5zS/bc6eJF4beFniXWY6cc2QM 9mFbB2wz4R4I1osdK9wsiFOLBNipwb2IZMyFPYqtEG4SwfQ8LAu39uUR3uTMPrV9MZgRhTML Sg431QoM12sfoZ0WZDemna4CSIbOBtrPQMW8GGhkjLyi3vB9tH79+lPecuq6jZt0UIGPfHTx X/zF3snd/Yt9NKn25ArAqZd+DrD7Js+VVsoSU68FNDXwTYt6uZ7dXa+TltyplyPqTV1SFei/ AuHVbJesGsPxiZtGzcOBVy4avvOP/+QlkWR81sBZ8dTLXIZ9fMuNyniEtyvjVm2EUSTAX+Yy +rSW2GZptukxPorc2pf7nwXYGvsGsyK3lgCmWzPYTrcv3DcOL4Jvo3YGCkQyUjgyogGmA3sd aGG8IVnUG77L3va2t6359oZnfrNdBxT41dT0fvsf8MUVXz399NP9fyKphU0pAI/eWVfPIviO TY41lbf9xOWmXrBpQAIswWHYUQYExV+6J/Kvu1krzi0x0jMBeBd/GVEfYVP9N/eKetu/B1RC 6RRoKoYDYpaFqRfuDWPTYzNSr2uUBSAS+MziG6DeAPI2okkWYoBLqOUrknqJxcjl7gnnoieZ 1W1qoF9hOkdRLqpGUq/L9wELt9ueyObN6Dsh6g3cdLBoHnnU0eJdU+Bz1990zrnn4+2hhx42 MTFRumeUGhyvgJl789+juPTUywD4xq9A3p2WldWrbcMqhh3lBlRkWQwGo+670U8tOinj/DNL Wsbj7G4AUW922qpkbxVoinoR5+GMi4ZcX4hDew7dOLkxnswiUZL4aHzp0iRQmB+ZEbcR9TKl MSXtqWTQSOpFOWRc2+sY7g2kZJxYLU1RL3LRWsxmNEW9SO8ScwDiZ+RdJhD1Bm4uWDRHVn9L 1GsKHHHkUXff+yDeXrX8C5/8ZGFRrrx9Bpa9YdiezfYoRhzfPLtTbuolm/LFXVWNaM1FgQGY GMeUsAuWJRnjCjcCACu7yUjA8nDIcyKqLimQXIFmqRfg+4VNU++7ZPgvu/ZbM74mCZlFUm8j OiTI4hVwbI1MD9w011jyKyAynnoDoOwCq0u9gGb3MEoO2Hph6A3YrRv1i07DPH607UemG5iV /aWhupFVWH69Cac0gpPsf8AB+E1f1EsF8AXg7e9cwHPIAnGShDVMqLaSeaKA7VHcvaI7zz2K y029YQ8HDCe8FPAgto/csKM8d3eTQnpushpIJur15MZQM6RAWIEWqBfgCzffnnnHJ0HeRgbU GD9dUmCA/yLTg0EJi2BHgClOQLHx1EvKNCeHgOnXamEb7GWNCfv1Blo7Y7+QPmCHJnnz1ULk Y9l63Vm9fPnQJwb+RshrCvS9+8ybb/mGvT3nI+ev1L5xlftP4Jp789yjuILU6+6DinlCwy3+ TZqtl/ZdXMcV7tFKH18XlEW9lbvF1KHqKOAh9TI+Q4AOG1Gvwa7hr0u9+JTWXzdqhJEuzcOu m6+ZpeNtvfSjYDmBeAuR7WR6O8xybF8bAl7OCb9OyMMhfB8e/4Y3fO8H94p6zbi7zz6v2jr5 jAmCRX5Y6led55d68gcF3D2KczP3lpt6adO1F4y49GEA18J/l7BrDrv01qVjAz8lH8ORl3Bs 1EtjcCnCOMivVw+QGipQLPUacZoNlY4NFleB7raN/GWRyxwbzNXBpV4r1jUem5MDa3EDJjS7 ms1W3cW3c0a/hXj7tGI4JLwx8dv9q17VKeR1GffNp5zqCgInB0g0rR00Ek6pUiWzPYpzM/eW mHrhngs8dV8Ya7y1JWg8J84iGoP7EVJads4QJrDZwmL9nzyi3sLHaNGd159wy8fvf+LRwltS nwYURb0B/9pwbASaP40XG9l6bYGaJXYJEr/+m9U2sIKNlIxcrgNxs9Rr0cfi2ynqzeeGwm/3 +AVf1PuiP8O55yOAQ0CQM97zvrVr1+YzIqolTwVGfz7KEGZdX8xpQ+wSU2/CgXGNuAmzlCiZ qLfYwZqcnjpm1SIcF3//xmJbUqva86ReA1ALMWabO4Sp14Lv0gs2hnqtNAa+TWI3tSC7gXAN jTwc0AZ63IbbSRcL88doNoYD7bhJ2tzI4iu/XrthFaY3ALhwb3jksV8GLsLN9/3vX1irp1x9 OovVbATfzU9uzqHX1adeOjnkIGUhVYh6C5HdKn3quWdJvbD4FtuSWtWeG/Xagi2eADfdRV1h mjQWREruzcaM7i4VLMG4k2CahCBtAVlgP4hGq9kMaiPbSeymt4aot8DbZ9asWYreYIz74wcf PviQw8KWb3AwnBwKHCZVnZ0CQ/cNkXoXf3dxdrVYydWn3hxELLAKUW+B4qNqUW8h+udAvQjU FVgcBjuuu08Eg84iTWCZF2CXGWEStkIY9ovpibn2Ea2hKMQ+amQfRe0s2fxxmTLcVGs564ps p5XWqJ3h5WuBhiVps2y98TcI9l/ALgxybzAFYNNFAIdIQUC9il9WyPM260qxVRupd/a1s3NY 0ybqzXpAsy1f1JutvjOV/sJ//Sdtve+5/fKZ0urz1BTIgXqbikigxM0qIA8H3gzwVYXHqqjX FLh4YMlll18VKcgpbzl1dHQ0tYeICvJJgd5bewm+OexYUQXqdcM48LzZ0TTf39I5AYt6mx3r 1NOTehesWZZ6ySqwkQKi3mYp07f0ol7O7aVLlzaCvHqiMKI3IE5ZZN8/MbBkaGhIT8VKKjAy PkLq7ftmX9YdrA712tbELXjxmu+vqDfrCVe98kW9+Y+pqNc3im22PaJe3jVaypZkKRvTaEFb /k/a3Gqc3j496+pZoF78hcNDpvVWhHoReTcgE6LwIjQv/uIjxCBDgF6c4C+TIawv9zEmImNH 4nDU3kx1T6tw2XrTUrLlck5dvYTg23IJytisAqLeZinTt/SiXs75Aw7oeujhx5o1667buOn+ hx5hrmWf+SyPH/zzAzh4cejzw7yIE1z86cRkILF9yusokFcspZWAj6xYNzESWGJeR5NYiLWN zUveOyxZQwCHRunvvvfBo48+utlnhdKXRYGFdyykuXflQyszbXNFqBdeDaRYvICwkIxXsDsx fR5At9yZAgRMgy4+si0t5OGQ6SSrduHwbRD15jzEol7fKLbZ9oh6ecvstddsdxOyhIAIrLzw ogEmPvCgg3FO3HzDnBPP+lA/LuLkHae9ixfxKdIAXgOJycS4iASWGCn/4bZvB0rApyiQ1eHc Tbzi5q/zOgpBmkAzWGPCTiEZvgDst/8BjdLjU3xJyPlRo+pyU8AC9865ZU6mlVaHes3DgZsP 257D3IANV7jjGveewF/AMajX5WBcl4dDprOtkoWLevMfVlFvs5TpW3pRL+8a/ANKDoVuSsNQ YKXZYh9/8tekTAKopcc5adhNbJ+6YArkBdSGS0CBqMXKYV7YepEXf4HU1h5+hLcE4qaoF9bc I448qpEg+HqALwn5P21UYz4KIHpD53WdNPdO/Hoiu0orQr1hD4cY6oXRF5/iL8BX1Jvd3KpJ yYjUS1svopjVpMuFd1PU6xvFNtseUS9uImyxC4xrjXpBsXQwSEK9SEwIjqReYC4SBNwYAtxM 6g1nR0YYjK186wuQl/TcFPWCnk+ce1KMIPh/XfjDRw3ITgHE6yX1Lr17aXa1VGEO0ZkhsDVx DPXSEYKWXVFvdnOrJiWLevMfaFFvs5TpW3pRL+6aycnJ/Q9o+IN+PA0DK82YCiS1g54PeAvc tIOGXjKoe5g9mN4R+AioSq9cvnVLjkRYc2mgX4QdQGRaf5uiXkRvQAyHmI5jR4/t27fn/8BR jfko8LP/+BlCmOGAj292NVaEegPBy6CXUS+WqZmHA07Mrxfn9OtlAAemkYdDdlOtqiUb9WJ3 4qr20bd+iXp9o9hm2yPqbZN6Yeg1Yyrwl0vZbHmZWWppoDUkjbT1upRJ/CX1AqBZrK1Oi7T1 0u0hsGoNTWqBem9c8dX3n3V2DPXiSwK+Kvj2OFJ7yqVAFai3XIqn21rFcEhXzxZKu+KeW+nh sOWprS1kV5YWFBD1NkuZvqUX9bZJvUBDo96Ac0LAKxduA6BVuPxGejiAaAMuuZGewSRR0K2t osNbuhEDtY1xDVjRthb8emM2ZmPJ2p6thaelsgQUEPWWe0qIegsfP1Fv/kMg6vWNYpttj6i3 NeoFwjIaAw7aYiPNtwGvXNCqrWazgA90TiA942DJxrWBEgxnGSYC9XIFm0EwLrIQfIRzd7Gd xVabMYqZ/Hrzf5ZmVyN/OXdf8CzdujUT2xDWaCUvWdSb3aDnUbKoNw+VY+tYft9ttPXe/8Sj hTemJg1ojXovHdn8sr327Jl3vI7CFTj4qNceNfetq7bsaOq4ZNXYCfN6qzTJm43h4FIvzLSw pwIlacd1D6wwMzjmdSZzAdSoF5+iHPAraNUikYVLsPK5fA3pA1WEC2G9ot4qzdjkfQH1BsIM wKeUGyOk/qLzasJia0S9Tz/37Kotd+K455cPJ1TH/2Si3sLHaNWWjaTejY/dX3hjatKA1qgX gAXwBTnp8EGBL2yaagp5kVjUG+PzWoGPFK+3Sg/wMPUCTLmAii/uDoZk27Ztsyt4tvM6dhmz NDznCwkQgAsAbReRnlG5WM7TTz+NMlECt24Iv2pEvQgsRTr5wB1XVWZuiXoLH0pRb/5D0DL1 NotZSu+VAtWj3tb2ZqsA4EZ2QdSb/7M0uxrjbb0wA4NcLboAgZW7KyAjiBYnZGKecx8GnuMv 3tpuuy71AnlZAkpuZFquEfVCMttQ4Nnnf5vdYOdZsqg3T7Uj6xoZH+W3qdseubvwxtSkAaJe r2A0t8ZUj3qxxS62ZqgqxTbbr19NIYDxXvgbmRFxzd72trfV5BFXgW4yMqzr12vuDXiAu0Zf 4CkSk3pxzr4HzpmAyMsEBFyem4cDzcCmXqTnQ72o1xYeVebHaFFv4U8HzCVSL4y+hTemJg0Q 9eYGml5VVD3qPeecfoTrapYOK5wee7M1+hpw5TVfGBgYqMkjrgLdpK2XGylwZZu53vItd06g fZcewPhLum10jpSA3TDUWuFWmpVsBVquelHv2OQ4AQX4W4FZhS6IegsfR1Fv/kMg6vUKRnNr TPWod3h4+GMXXFxhim22a4jX2+hrwMKzzh4ZGcn/aaMaW1Mg4OEAK6wtbnOBmFjMCAxJqNeN 1WCw61IvKnL3LDOn4ZpS73MvPE/qPXX1ktYG0rdcot7CRwShGzip4OpQeGNq0gBRb26g6VVF 1aPene6J8+L24G2WGsueHgbdRRdcFNmLI486enx8vCaPuAp0M+zXa5649HAwHrW1azNSr5vA dZMw6uU6NqqH8iNjpdXL1gshsJSNjLL12ScqMLFEvT4MIoKXXbLpK1gu6UNj6tAGUa9XMJpb Y6pHvdPT8GSdXXZUTbH9jUL2/t7ld7a2Iy7R4z1MvRs2bICnL9elwfuWCAtINRvwjNTLKBDI C4Ou6+NLxwYGbcA5l8G5nsGubrWj3i89uK5Ka49EvSV6CqipaSkg6s0NNL2qqHrUiztCYRxc aN46+QwWtIUxGs6+WPmX1gNE5eSgAEyt4Z0jzJkBDcCn4FRCMF+4YgbgRudIhgVteLkOvriI ki0vPYkbRfCtHfVi21hS76I7r29t4CcmJnrnvb53Xo8Px5vPOPfUS8dwnHLWUh/awzasXfON 1rRVLimQRAFRr1cwmltjKkm9WKGFn/VTNJeWvagT554U2P8CPVpy6WWDg4NJHg5KIwXiFagd 9b7wX/95wi0fB/XiL85bmB9wqJ8/90/HVnX4cPzw5pecednadyzd9M2bDvahPWjD0v6O/g+/ twVhlUUKJFRA1JsbaHpVUSWpV669AUyPdO2VU2/CZ6OSzahA7agXisDK284WsqDe/tNfvmNL hz/Htgc8as/IoKh3xvtOCdpSQNTrFYzm1phKUi/uBHis4pf9stto02p/eK8KXIEfSFuPDGWW An9QoI7Ui90ESL3XP3B7CzPBQ+r1h7/RElFvC5NKWZpSYPPmzS/fc/aRx/fqqJUCB76255S3 zm9qqpQisaL2Bog5ELVXkXpLMY3L0sg6Ui+iN5B633P75S2Mk6g3HrJFvS1MKmVpVgGALyy+ etVNgampqWaniv/pR0dHT3nLqWnZSitQDrx4cVhHENzNXfPk/4CqhT4rUEfqxXggXi/BF/tW NDs8ol5Rb7NzRumlgBSQAjEKFBvJ4d+nprddftULc0/6731e9X/fueA3395QLDo/8tgv99v/ AG5NrOgNunHSVaCm1GtODgjf26ygol5Rb7NzRumlgBSQAjEK3HBDYZu0/cdjv/zdIYft6Ohw j+cbbBWRGw2fc+75n7v+JlR3xnvet3btWk2ecimAiLkIoGsvhM7NyFrPCL5NiVNT6kX0BjP3 IpZZU5KJekW9TU0YJZYCUkAKxCuA/RcOOOAA2Dhzw0qr6P+cdXYAefn2f9/yjfwbYzXCxAvv XggCWbQ5ReluH3e/CQTWRfRcsGk4fG8q/WoUl7dR4TWlXsiB/WPp5IBdtZqSXtQr6m1qwiix FJACUmBGBZYuXXrZ4FU5gyYMvZHIi4u/O/KonBsTqO7t71zwtvnvhBV8RumUwDcFXOpl22D9 xZ5q1k7sT8Ed1GyzCe5YwevYhAIp3XNmxHXsyoYE3IYNL+xMgULsBASMBHiZaZnM7WapL/U+ +/xvGbi32d2JRb2iXt8eMWqPFJACZVcAC/Ve9apOrNzK81j214c3ot4X/uiP8mxJuK7Xvf71 s2bNkqG3jBM7TL3gVHNF4F7B3EENFwm+3FUYV4C2OCET85wIy02GuX7Xdhs2DwecYLtjErNb LMvEp6gRn6Kc+lIvOo/IZS2Ye0W9ot7AY+i5F56Hp3izrjJlfJapzVJACmSnADb+zDkox798 +csNqfcVr8i5MeHqfvrTn2antkrOToEw9RqeEmStasAoTLOkXjMGB85pzQU3m4/Ehg0bkAYX Xeo1gGZp3P0YF+kCAaswT2pNva65d3I6aUAcUa+oN/Cw4Ncn/HSAGZXdc0QlSwEpIAVSVmD7 9h2zZ0eD75lnplyXiquNAmHqNdgFwrquDrTgklNJtzHnAF/kpVU4knpNYFIv3gKpuagOJzQq 15p60X8z9ybfsULUK+oNPLuuuOdW/mggc29tnurqqBSoigIjI9HUe/LJO8DEekmB5hUIU685 GNDL1opMTr30DMYPArDgNrL1hqkXVwC7YG7kpTG47tRrO1YkN9SJekW9ot7mH4PKIQWkgK8K rFy5m8X3j/5oFwf39/vaYrXLawUC1AvohNMt3XPxF/QJfwN2wNaZzWjrNV8F5KLFFycBD4cA 9YKPmYwvllB36oUQiOHQ1AbFol5Rr6jX6yeuGicFpECzCmDTO0AJ8Hfz5h2u9Xfp0mZLUnop YE4IPMGLYRn4IrPS6GtUOiP1MrHlonNwPPUiAbJwYZzVJerd4Zp7k3j3inpFvYGHmvnJbPrF T/S8kwJSQAqUXoGhoRfdHoaHS98ddSBfBWBkBY/aK1w5EjC0gn2EK2YAbnTO0GZc02Z5wyf4 1I0NzGARlkzUu1PzZXd/jeZebNWGDSzip4eoV9QbmCGrtmzk/Nn42P35PltUmxSQAlIgGwUG Bl4E3/Xrs6lDpUqBvBUQ9e5UHEvvbau2Lz24TtQbz7WiXlFv3g8q1ScFpED+CixcuAt8Z83a 6f+glxQovwKi3l1jeP8Tj9JcN+NKfNl6Rb2i3vI/+tQDKSAFZlIAMRzmz98Fvp2dO+D7q5cU KLkCot4XB3D5fbeRehesWYZ9BxqNrKhX1BuYG9iigjMHJyV/IKj5UkAKSAFHgenpHT09u8AX pl+9pEBeCkz8emJscgzH9PbpFOsU9b4oJjx633P75cQXRGB1VX7quWdtAwJRr6g3cAfCnZfT Bg6+Kd6cKkoKSAEpULwCExM74OHQ0bHzQHgHvaRALgr0f6e/44oOHADfFCsU9e4m5iPPPI7A vSQYW4+PIA+w/tpCJVGvqFfUm+IzSEVJASnguwKIaEbqxUZuk5O+t1btq4QCot6chtHW4/eO DMDEC+TFCSAYYX3ZgnSpd8MNHXN7Orau6wBK4i/Ozzt95zkOnJxx8q7zay7c+RGOFZ/edQUf uW+R2M0byG6Fo4ptP+pAaWOrdpXTzsK1yLwjgx39H35vTqPlRzWy9foxDmqFFJACmSnQ27sL fHGilxTIXgFRb/Ya/6GG/u9cS3PvB//paiIvDtiAGdQsXeoFhuJFlgWM4nXI/rt4FCckYOAs z0G6eC05e+dFXMHLsJhvkZIk+vRduxIYJW/ZuTdKB/7yBHWlzrsssIbUi58FOElmDACS3yRW TVJACkiBFBXAUjYYemnxVQTfFIVVUQ0UWHjHQnk45DQ7YOI1PwcL7IATxHlInXrJry7dkk1J w6uv3AnEO7fy+4Np1gzAyEUaRgn4lG+NegG1gSui3uxmz5antka6g2dXo0qWAlJACuStgO3Z BjdfOPvqJQWyVKB7RTepV6vZspT5D2V//sdrXd7lOYI8ZEG9hFc4HuAvMBd/wayAXZzAZAtr rll/XessWRl/gbOw/hJ5jXpxHRlRmhGzqDe7eSPqzU5blSwFpIBHClgEXwR2QFwzvaRANgqA dIm8XV/sSrcGrWaL0NPcNAPgi50ssqBe2mXh4EvMJbySaM29IeyNQDjmX6Q38KXp12DXDMmi 3nTvHLc0UW922qpkKSAFPFIAgcwQuJd+DoODHjVMTamWAojbQOrt+2Zfuj0T9Qb1bIS8JGAE eUjXrxeQSh41my6tvEarhr8EX5hvcdAvArzLRWw4B+marZfuv3zLoqwW+fWme/+wNKNebG2d RfkqUwpIASngiwKjoy/uVDw+7kur1I5qKTC8eZjUO3TfULo9E/XupqcFcAi7N1hA1tSp15am 0buXHr106jXDLT8yS7BRL30YzCpMDwe6N4CJccAGjBdIWrbedO8ctzQ4gnN6LLrz+uxqUclS QApIAS8UWLx4F/j2pWyH86J3aoQHCsDES+od/flous0R9e6m5+T01PUP3A5PhkbU+4E7rsqC ekGr7pI1GmjBuLTvglx5hQf41aiXsRoIuxbaDEUxFBoPJghQr1tguvEcahjDQdSb7lNJpUkB KeC1AojnYPtWyNzr9VCVtXFw581iKRvkEPVGzwmEa8Cv1ZGRHG78+s39p7883bBfgFeyLA8w q/uWVl6Ydd0gu0iABXB0XbBwvzgJ57UrVib9HOxgOWkdot6yPmbUbikgBaRAQgUGBmTuTSiV kjWrQHZL2US9M4zFcy88Dzdf/Gztmn4vuWUodepNizh9KEfU2+wdrvRSQApIgZIpIHNvyQas TM2FV0NGS9lEvUnnAX7CHhkffc/tlwN/3/W1vxH1xuD13w11veMzZ0OxpOJWIh1cXzA3rrjn 1kr0Rp2QAlJACsykgMy9Mymkz1tTACvYSL1Y09ZaCTG55OHQnKSI4XDeLYPnvHsvH6yqHrZh 8sezzS6O8MbPPv/b5vQtbWr0FDu0cfc+vaSAFJAC1VdA5t7qj3ExPbSlbIhflnoLRL1NS5rF ajYP+bW1Jj27+aUnf+UDBr5wjMbqQDiKNK2yMkgBKSAFpIDnCsjc6/kAlbN52S1lgx6i3qYn RSrUa0F5LS6vUSYD9DJsGQ5uReEejEoWuMi9KvARc1kQX8Y+Y0BfroqzmA9uhIdAwIfWkJe5 vvzZl771s+e4ntC9IwMICSc7aNNTTRmkgBSQAj4rMDmp2L0+j08Z22ZL2bAjcRbtF/U2rWr7 1AtCxQt0i/3YGE/XaJWBxlwwBa1a2F3yLoiZJSAvg/LiQDJ3PwuUwATGzURS5OXLwkHwCv4y pftRa+zL1Wzw671k01dc9kU8uNseuVvs2/SEUwYpIAWkgLcKIGQvt2pT7F5vx6hUDbOlbAvv WJhFw0W9TavaPvVyFwljSrAvoRMHd50gCrsxdxlt1wLrEk8D0c2YF7lo3LWt2uyENmBuAuc2 gFdQGv4SlNs53BgOW5994uLv3+iy74I1yxAWo2nRlUEKSAEpIAU8VADxekm9OODpq5cUaE+B TJeyoWmi3qbHp03qDfCrBc0laAJAAaYIoBvwfIikXuKsOTZwUzcANLcpphMFiyLLgobxAhxz 2wvbBYNuDzza4V3mDUcuw4a9/d+51mVfRDwYmxxvWnplkAJSQApIAd8UMHPvypW+NU3tKZ0C 8/9xPgM4ZLGUTdTbynxIkXppXqU3As5JnzTo0v5qDBpJva6Hgznp0s8BHxkEm9OCuUAESkNe WpfNmbgd9m0UrxeYy9BvdiAQMoC4lTFQHikgBaSAFPBEgdHRXbbe+fM9aZGaUVIFprZNzbp6 FpAXf7f/bnsWvZCtt2lV26Reeu66DgbmrkD0NLOri6FJPByMlW3tWsCCS7w2znapOtJlojX2 jd+lAu4NgQ2f4QIBR4imh0EZpIAUkAJSwAcFtm/ftUExtimenvahRWpDSRUw94aMnHpl621l YrRPvaRbgCZYFuZVeCPQ1ksaNp8Hd01bJPUib2BXYS5NM5yFcRcvlG8ew5aFKW1NW27UC8Wx oA3L2hDYwbX7Yn8HBThrZToqjxSQAlKgcAUWLtxl7l27tvC2qAHlVcBilmXk3iDqbWVutE+9 FleBhAoqBYxyCZrrY0DvW65pIxO7q9nMjssTfoTEriEZpZlTr7umzdwhzOTMUGiB5XFZ2HpN cTAuwpkhoK+xL2zA2ASklSFRHikgBaSAFChQgZGRXdQL/NVLCrSkgEVvyChmGRslD4emBycV 6iVQulEaWkNMD3PFezgE5MaWZtjGwjX6funBdU0PiTJIASkgBaRAgQrAsQHuDQjjMHv2Djg8 6CUFmlfAtmTLYiNia46ot+mRSZF6PWTW9pvUFPVSfZh43YVuCPgwOa0IOE3PTGWQAlJAChSm QG/vLnMvFrfpJQWaVMBdx4bzJnM3kVzU24RYTCrqjSfjFqgXqsLZd/l9t7lbGZcrrC8W5MFD Ayvzmp5PyiAFpIAUqIACCFvGqL2LF1egN+pCzgrksI6NPRL1Nj2yot4sqJfDcP8Tj7oRHgCR ZVniZsgu1+Sm7yhlkAJSoAIK2O7EnZ0V6I26kLMCOaxjE/W2OKai3uyoF0MCT193OzdAMFC4 xaHKMRtiUNBQrQjEOaquqqSAFPBJgZ6eXebezZt9apba4rsC+axjE/W2OA9EvZlSL0fljp/d 44Z3wIo3uEC0OGC5ZDNbr/acy0VvVSIFpIB/Cixduot6h4f9a5xa5K8C+axjE/W2OANEvTlQ L8YGC9rcfYyx3M3nzSwQhY223nK5I7d4DyibFJACUiCsAIL10rV3YEDySIGECuS2jk3Um3BE gslEvflQL3SHfReBzNwlbiPjnq4OFvW2eDspmxSQApVRAI4NpF5tTVyZMc2+I7mtYxP1tjiY ot7cqJcjhPVh7hK3RXdeD9/fFgcvs2yi3sykVcFSQAqURAFE7SX1dneXpMVqZvEK5LaOTdTb 4mCLenOmXowTIjnYcjGYfhesWeZbQF9Rb4u3k7JJASlQJQWwSwXBVy8pkECBPNexiXoTDEhU ElFv/tTLcYDLbO/IAB0ecOKVmy+W37FhwN8WJ5aySQEpIAXKrsCcObuod2Ki7F1R+3NQIM91 bKLeFgdU1FsU9WLAnnruWRh6DXz9CWoGIhf1tnhHKZsUkAKVUWDhQu3QVpnBzLojm5/c3HFF B45ZV8/KdD82tyP6GaLpYRX1Fki9GC14O3zgjquImIhu5kmkMFFv0zeSMkgBKVA9BQYHFbys eqOaRY+2/257z809pN7BscEsqogsU9TbtNSi3mKpl+CLNW0W28GHYGGi3qZvJGWQAlKgegoo eFn1xjSbHg1vHibyYjUbCDibSiJKFfU2LbWot3DqxZghqJm7hVvhEc1EvU3fSMogBaRANRQY GtrR27vreP3rd9l6X/GKFy/i05GRavRVvUhFAYvRC+pdP7E+lTITFiLqTSjUi8lEvT5QL8HX DeyAyL5Nj2V6GUS96WmpkqSAFCiVAuPju0iX0RvCx6xZO6amStUlNTZbBRbesZCGXqxmy7am UOmi3qYFF/V6Qr0cOdsKGA4PgOCmhzOlDFhXR4+LAtuQUldUjBSQAlKgSQX6+uLAV1u1NSln tZNbtLI8F7GZpKLepmeXqNcr6sX4WaxcQOclm74CG3DTg9p2hi1PbRX1tq2iCpACUqCcCsSY e2XoLeeQZtRquPB2r+imoRe7smVUS0yxot6mNRf1+ka9GEILlwv0hL8vlrs1Pa7tZRD1tqef cksBKVByBRqZe2XoLfnAptt8238Y7JvnIjbZelsfR1Gvh9SL4TTPWoAvQpvlDL6i3tbvKOWU AlKgAgpEmntl6K3AyKbXhcnpSXg10NA7NjmWXsFNlCRbbxNiMamo10/qxdDAuRYRfOlp8J7b L8eWFk2PbqsZRL2tKqd8UkAKVEWBsLlXht6qjG0q/bCd2LCaLZUCWyhE1Nu0aKJeb6kXYwn6 tF2LAb65WXxFvU3fSMogBaRAxRQImHtl6K3Y+LbXHUQoy38ntnCTRb1ND6Oo12fqxXBuffYJ A1/4+DY9wC1lEPW2JJsySQEpUC0FXHOvDL3VGtt2egMX3s7rOkm92J+inaLazCvqbVpAUG/n 3rN6j5+tI1KB7gNfunjRh5uWNdUMAF9zdbj+gdtTLTu6sMnpKXpWIJJaDtWpCikgBaSAjwqY uVeGXh+Hp7A2Lb17KZEXuxAX1ojfVyzqbVr/7du3j/n0+u5dY0tu8qlBY2PT09NNy5p2hrHJ cduyGBEe0i4+ojxE6j119RIYfXOoS1VIASkgBTxVYM6cnbF7Zej1dHgKaNbErydsEdvmJzcX 0AKnSlFvsfqnUPudm5869dKx+x/9dQplVasIbFNM8IXdVzBarbFVb6SAFPBVgfXrd8jQ6+vg 5N8u+Db03tpLQ2//d/rzb0CgRlFv4UPQbgP+ZtU4qPf9V9//m+deaLesyuVfdvfXCL7w9M0z pEPlhFSHpECVFcDPU+9Y0HfCvF4dqShw9aHdqZSjQqDAlVcXsJVDinf74u8uJvLCr3dqW/Eb U4t6UxzcAooC6QJ5efzt139aQAv8rhL7tPV/51qLZVbItm1+K6TWSQEpsAMuYge+tueSVWM6 pIBXCnx0+drX7N9V3lsUC9eIvDgQw8GHjoh6fRiF1ttA9wY78Lb1siqa89nnf7tgzTKCL/Yr rmgv1S0pIAVaVwDUe+Txvau2YHtzHVLAIwWWb5wsL/ViHwpz5x0cG2z9/kw1p6g3VTlzL4zu DXacdtm9T/xH3pvx5t7ppit0Qzp86cF1TedXBikgBSqtgKhXuO+nAuWlXmzDNvva2bTyYnMK f54fol5/xqLplrjuDQa+n/zyv7zwu/9uuqyqZ3BDOmz6xU+q3l31TwpIgSYUEPX6yXxqVUmp FyvYuld0W6gyvG3ibsw4qag3Y4GzLD7g3mDg+40fTmZZbVnLhpXXQjo88szjZe2G2i0FpEDa CvhGvX+7egsOY77A2yvXbXU/RbKPXLm678Jr8DeAiZ+/62n7COf2KUtwC3Gv3PSjbfw0cCB7 4CPkagpMrRYrOZwdbrXoywc+vSJQeLjXKATtQQmRrW30kRUbyOXq01SnMk1cUuq1nYdh7oXR N+37ta3yRL1tyVds5oB7g+vq8G+/+m2xbfOzdvj1EnwRWFchHfwcI7VKCuSvgG/Ue3DP3H32 P4Qchr847+joAAsSsPgpzwG1/JQvnBvLXnjDBn5kf3HFSmB6Q0ArBNlRkRXoloy84Y9ed/IZ ybEPLQ+UjHpdDHX7gpRvPP08K9ztNUnXNAnkYhWUK/wRyrHsbmOQ0q0ueacyTVlG6rUNKeDU C9fe/G/n+BpFvb6NSNL2RLo3GPiefe1m+TmEpUQMhw/ccRXBFycK6ZB0timdFKi0Ar5RL+GS tlv8JZwR10hyPAcv4hwHcNZo1ZIRE0m6MJ26JRh94rqBNQGRBlTaQZkMDTDDsDUMV2CUZQIW kuRgk8zICspEduNmg3sm4KdGojHUy/QUCsn4lrZeauWadQnZhOZTz17Cj+wbQrPW6yS9bidN 6ah37b+utaANKx9a6eFjQ9Tr4aAkalIj9wYD3+u+NZGooJolgokXhl6FdKjZsKu7UiBOAd+o 15gMwAQoJLrRvut+RC50HRuAccagBGKwKakL1+0jlmb0TF5kaa7bA6HWvULqtSvMaEboGfEu klyJ6eTygLWVjQxbuAO2XiagMgb9gW8Igba5pmIrP9DZGbuTQ4JyUe/41LgFbRi4a8DPh46o 189xmblVke4Nb192D64vX/MzuPZqt7ZGIsKpF7u1EXy1sm3mqaYUUqDqCvhGva5Bl2xKKDSD Llk2AJEBCDNvBP52b/hrGXGRTEmwBjE3Rb0wiyJjC7ZeNIwHOZvQzHO3kWyYNSnG1htPvRTQ DqI/qRflW2Ncws4BZxNWUSLqxQ4UXV/soqEXm7F5tYLNfYCJekv5OKd7AwD3im/8KwD3yxt+ ThMv3payP7k3euNj95uD73MvpBPrDeWgWIQHzr03qlAKSIG2FPCQes0ZgFwIxOQJCdUMmXYe SVGwxbIc+kgEvAVoqQVoIgH5LyH1EhBZZsC2agBqThFuw2g8trw4cZ2Vw6ZWt0ktUy9rtIM1 knrdjkAB39wb0M6yUC8Yd84tc4i8YN/p7dNt3ZBZZhb1ZqluXmVv+z+/I/W++4r78qqz9PVc /P0bCb7L77stlc5wqdyiO69PpTQVIgWkQG4KeEi9tLy6Xgfm5xD40T8QnMGlTPq24gj4rdpq OfIu7bXJqRdto4k0HDXCgJJM7HpHuMZptoc+vmwh+xso0HWxaJl6G3E5v0VAvYADcUIrbD7J ykK9tu0wPBwmfu21d6WoN7fnarYVXXDjQwTfXzy1LduaqlL65PSU+TmkEsjMdoCrikLqhxSo iwIeUi9MsGaMJGART12TLUnRdaslSgJ2udDNDbDgArQRpJldkT459QZYNsB/qN3cBgy7zXfW kB3gyw4yja1Fs9JQS8Cvl5ZpJgi7FLfj10u8Tu6gnA/ylsXW6+G2wzFPLlFvRR7rK+/c5eSw 7r4nK9Kl7LuxasvGFOM5iHqzHzHVIAUyUcBD6gXxEEmNXC2YgxlEwYtMA6IFsRHdXDcG+4h8 HF4ZRhTm9bSoN4YIA/bacJQGukygJWgwu2adpWcznSJw8FPXD7gR9VoWY3EzSBvmWjQM36L2 +m/rHf35qAVtGLpvKJP7M9VCRb2pyllcYVi7JtfeZuVH5LL33H45wXdkfLTZ7IH0ot42BVR2 KVCUAn5SLxnRAi8wcC+OgEsDPX1JhG4MBCRzP2IALzMbk3QZ7pdgTZR07bjMHojhELjSlNXT dUpGRlK7WyAX2JmRO+DwYChs+OvWTttwIH4wyw8cpF7SsJXA7jcVfripvreW2HPqBfJa0Aav th2WrbeoZ2l+9cq1tzWttzy11TZsa3PfClFva0OgXFKgcAX8pN6mOCnG6wAf+WbCjO8aLK8x DcanHi47a2qwkif2mXpd5O25ucfboA2Bx4tsvYU/b1NrgFx7W5Ny2d1fI/hifVtrJTCXqLcd 9ZRXChSoQAWoNzlIKWWJFPCWegPI63PQBlFvgY/WbKuWa29r+iLWWO/IQPvhe0W9remvXFKg cAVEvSUCwVo11U/qxQZs5tgAK2+JkBePGtl6C3/eptYAufa2LOUdP7un/fC9ttdxWgGAW+6O MkoBKdCUAqLeWqFkiTrrIfWOjI/Y8rXSIa+ot6kHo++JzbX37Gs3+95W/9rX/51r2wzfi0i9 LKFN/2D/tFGLpEDFFRD1lggEa9VU36jXRd75/zi/XFZePsVk663U09xce5/5zfZKdSz7zmx9 9ok2w/eKerMfJdUgBTJRQNRbK5QsUWe9ot4A8pZl+VrgkSHqzeQZWlSh5tq7actUUW0ob73X P3B7O+F7Rb3eDv3WrVvn7v4677zzcDGLBm/btg0IlUXJaPAZZ5yResmQYsWKFakXW64CRb0l AsFaNdUf6h0cGzTHBlh5S4q8svWW68k8c2vNtfe6b3m9JeDMPSkiBcL3nrp6Scvhe0W9RQxa ojq3bNlyyCGH4K+9gHrA4ESZm0wEML3mmmuazJQoOXuRKGkziaBDRg1uphUFpxX11golS9RZ T6jXRd6FdywsL/KKegt+1KZevVx725R0bHK85fC9ot42xc8ueyQvkoNZ6dNPP7169WrXRguT LWyruA47KK3C7rk1FSVYAlxELkDkkiVLcMI0yIsEVlG4j+EEuEKDccAaHUO9jWpBIegXWm71 IiWuuBdFvRBH1FsiEKxVU32gXhd5+7/Tn92DOp+S5eGQj8751WKuvf/2q9/mV2uFarpk01cI vojj21S3RL1NyZVn4jAvgnJAvcRBICDOgao0APMizJ+4SITlp3aO9Gw8rtCyixPkxRUALhLj RZ8BFogESBbpnOAmMNszTlh1IEsj6o0sBHSLQvAR20+AZi/QHlzHRVK+qFfUWyuOLFdnC6fe pXcvNceGCiAvbnZRb57/fPOo6xs/nOTWxDetz8RtMY8+FFoHwvdyWRv+4jx5W66451biMvZ7 S55LKXNQALyILUxdz14wn8Gr8R9hl6xJ6qXJNnBOPAVBGpUimZGlQSS504y+SBxwnyV5hxOE eZcSRVJvo0JcRwu0H61FCbhodl+ALx0bRL2i3nKBYK1aWyz1AnMNeRd/d3EOz+ocqhD15iBy rlUgegOp991X3PfC7/4717qrUpkta8NJ8j6JepNrlXNK8iIgL2DmNJTkR6RD+s7Sgst2Rp7j U5dijR3thKxsJYfNvUbYgVoaYWgk9TYqxPXfcNWmSwa7Keo1ZeThUCuULFFnC6ReF3nh5JDz Qzu76kS92WlbWMl/+/WfEnzHHv73whpR5ooRxcy8e7HELWFXRL0Jhco/WYAXXdutC8RGqAmp 16zFrsW0EfWi8ICtlwhuahhbN0u9kYVEUi+t3agILQf4inpFvSXiv3o2tSjqrSry4pYX9eb/ LzjzGgG7pN6/WTWeeWUVrcC8e2975O6EXRT1JhQq/2RhK6l54uIXf3PwRcM2bNhANp3R1gvW dHEz7CZLd2EXagMRzQIJ6IPrAnRAqEhbb0whBuU4gaU5kD1snM5/XPypUbbeejKl/73On3qx 8UTfN/vMsaFKVl4+cES9/jx4U2sJHBvg3kDw1XYVrcn6yDOP2x7FCc29ot7WpM4hV+RqNnj6 gnFRO9d4MdyB+fvOSL1020UyFO7GQeM50ZlsjQS0LocjBAcS0Ok23tZrBmmc2HI0txYWgq6x LzzBX/I9A0pwNRupXX69EEHU6z//1bOFOVPvxK8nuld0G/JiW4ocns85VyHqzVnwnKrDUjZS Lxa35VRl5ar5wB1XEXw3PnZ/ks6JepOoVEgarBjjr/nuC/xnLgegQ9puycHEIPu00Tk4kmva XNcFXHSdGfAREiBZo00xmABZbJ0ZrkTuc8FehKkXrQ0Xwi6wU1aaXUF/GeyMeXF99Oejvbf2 4oCZB9YdO9b+69rNT1Z/h3NRbz2Z0v9e50m96yfWz752NpF31tWzKom8eOKJegv5L5x5pQhb Ruo9+9rq/8fKSE2L3Qv8TVKFqDeJSkrjpwLuXqNm6XFPYAHChkyg4UpysKjXf/6rZwtzo143 KG/ndZ0V/q4r6vXzf1AKrbLAvT99fDqF4mpZxII1y2juBQHPKAA8gJl4clrbQc+olhL4pcCM 1BtG4SpxsKi3nkzpf69zoN6AI++cW+ZMbavyvzBRr1//e1Jszbr7nqS5d/man6VYbK2KMpC9 +Ps3zthxuP/CF+L+Jx6dMaUSSAHfFMD/ubHJMTuGNw/TyQFBOuH2gJ87Iw3AgYs9N/fQQQI/ lY5PzfxF0R8RcqDe4bHpY05Z8NfHz9NRJQXe+8mrM0XnrKk34MiL+73Uuw0neaSIepOoVMo0 v3nuhdMuuxfUi7/YqbiUfSi60QDZU1cvoQUX4cyKbo7qlwKFKUAsBg0P3DUADjb/v3gaBgdj byf/fy3NgXovWTV28FGvXTW2SkdlFFi+dvk+++5fXuoNOPKufGhlYc+XHCsW9eYodu5VXfGN f6W5987NT+VeeUUq/NKD60i9iGVWkS6pG1IgDQXwwyg5GFwLDoYvYAwBg5IX3rEQfhR+/nia D/X2zDt+C7bY01EVBTZObiwv9bqOvF1f7CrXjzPtPMBEve2o53ve+x/9Nan3k1/+F9/b6mv7 Wt6g2NcOqV1SICsF8NsoOBgWo3gOhgEYBmNEjciqHc2XK+oVi7egQEmpN+DIi6+suNL8TVPW HKLeso5cknYjcO/7r76f4PvEfzyfJIvShBVobYNiKVlJBRiO114ISYaAYln0FAHF3F0wsqgi hzInpycBwXD2jfQMxkV8hARIlkNjYqoQ9bbAfMpSRuoNOPLi+2ext17+tYt689c81xr/fvRx Ui9Ocq24QpW5GxTD9FuhnqkrTSsA3gXpYqMHvLjnGa40XUqCDG6Q4ATJfU8CMzCcCLFWBr+l NoqMVqABuNTUu3rL6vYBFIXc9fRd7ZdTqxJKR70BR15EIfT9wZFB+0S9GYjqU5Ew8ZJ6saYN 69t8alqZ2tLCBsVl6p7amliB8E5m5GArADQMM627JwWu4FPu/cZk7jmvID0+xcv2qoAJmYXw BNfxKYuyF8uxLIk7UXBCWJvgDYzov5H4W4gBuFjqxequ/Q/ZH4ch45Wrr+SV08873S72zO3B lQuvuZBXkOvkM07GFewyiL/49IYNN1hifhQ4cHHd1nUumKIQFstC3PKZjOVYpbzIlABlHOFa 7ApSxiQgrEe2k1JYXqb89IpPo6muIPGddbvTqJHsV2QjUVeg12GgLxf14lul3XG1cuQNPO9E vQX/A8ihelvTtvLOn+dQXSWraGGD4krqoE6FqdfduxifcqM1bjVMubD3L9/SMMz90lwjMbdE Ri5uFMyt1KxY7mZMtmb5+JTbCyM9LnLD4TIOTRIDMPwfcnA6LJZ6yZHgTrPagu3wliRqsOWm ARZbAsNWXMF1psdFA1kyn6U3m26jQpDXRW1kDFMvW+vyopUfoN7wdYPmyHbaFwAUzryUBW3A udu2SOoNVMeWu1jvErBRb7iRvHL2krNjrNdloV7cQXDeNeTFF84c7ilvn0iiXm+HJrWG/eKp bTL3tq+mbVC86Rc/ab80lVBSBcLUC/sruBPd4e7E7BcMtLhIYy1ObD/kwDltt8hl9lqALBMH qJfew4RdnMCcbJ4VNBKXVE9rdowBGNbf/u/0Zxr+zBPqNbgMQyoR0CCYCczw+aNtPzLMdanX pVValJELRlOkAfvyLTIiO3PBWsyLRnssthH1ukQYmTLQ7DBBRuZisuTUa8U2qi7wpSLQjMhc /OLhfusoqa0XwRlctyKEbij7s6LN9ot62xSwHNll7m1/nLADBUOYYefh9ktTCSVVIEy9ACaS KD4CjFq/LCU+Nc+ERuf0i6DhNky9rusw6yL+0gDselOUVFW32bBCwd0QmBsOhYbd4DIy/RZO vWQs/NwPtIITAnmLREjzrWvpBLaGgQwUi0ICtt4ArbqIaYUY8pLqWJHRXm2pF18AKkC9iBVo C0kRPRB+vRV4RLTZBVFvmwKWI7uZe2H0xXk5Gu1ZK5974fkTbvk4qLd3ZAC7V3jWOjUnJwXC 1EvHA1Kva3NNTr2MCAHYRXaUloR62VuAMuzEdHXIqf/5VoPoZojyG3D/bcr0m3CjqcKpl84G ZE3yKAiYAEqDrkufROTI3/obeSaApFmsYTQLDBdC5saLfgVpUS/64h60N1v5MC3TX4JHRrZe 1BJohluRa9ZFGxrp41p8ffZwQGBs13Ue3xjxc0q+t6+ntYl6PR2Y1JsFp176OcDum3rhNSkQ +xLT3Ktth2sy4uFuBqiX7g2EXTrsWhbz0I239ZqDBDNa+a6HQ9jWC0ozrwk49dIAXNUX/n8j AHDY9DvnljkwZcVwLT7CP/sk4fcLp176G+DACXiXbOr+8u7+Rp8EyAJ+vQRZY+hGOEukC9fV poeD1W4nRttsZ+BF8E3dwyFQi2GuVWQuv0yJt/HxMbylXtwX7u6JiA9YZ0fewINR1FvV/xTB ftkGxTL3tjzkd/zsHlLv8vtuCxeCoGaL7rwe0R5kCW5ZYf8z2no1QGfAzgpPA/onAGQZ1pfd iade+irAastcZridkXpJ28xl/sT+C9hOC+H5EI78gP/uCIgWacdCpAjYiZFgRvAtnHqNNelZ S/zlRRyBX9ubol5b64YTl+FYSDgkgvn75mnrpTuHHQw0kTr1xtt6afk2Cp8xgANa6CH1Bky8 mPwg4HZuuurlFfVWb0wb9kjm3jYHG1xL6j119YuRqqxMY2Itd2tTZ5+zA0/Bo/YK+NQCYbmm zXXwRWLbySLyHMhFOzEoFgUyr8XrDQTuNRMvrofr8lm6tNqGLS2SmH5h6DXz8Izg6wP10sTL v2aGdC+afRT0FumcgOsWmMz1TGCkhUCWRm4SWPTGBhC70/JwCC8Fcz0cIhEzdeptZLgNrGaz ABrmJN2o8b5Rb8DEi6+Ifm4AntajoLVyRL2t6VbKXK65F5sVl7IPRTca1lyC75andi7Pd1+r tmzkR1j3VnQzVb8UqL4CMaZfkDENvXbEg68P1Gt+t64J1r1ocRUIpnjhxIAsfhUarcV4WSEW tizAdgFDctgkbI6/gdC/VYrhYP4h8Tt3+EO9cGBwPeBl4o15/Il6q/+/we3huvuepHfvBTc+ VK+ep9Tb2x65m2j7pQfXiXpTElXFSIHWFWhk+t3jqj0Cy+BiwNcH6jWadHE28iJI10zCwGKY Kom8Li6HGdRMmMbK9ms+F5MBf+2KbXhh2I3sbppwSK946g0sI8NbNiMyV8xqNtQbKMpF//jI ZWEPBy6qC+eC7LSOM6qG57ZeLPp0vd5l4o1/moh6W3/aljHnC7/77/dffT/BV+beFkbwqeee JfUuWLNM1NuCgMoiBbJQAP4M+HkX69si93ub0eLrA/Waa28AKIlfjSjTXaHlBmQI0yQilIX9 HMKLyZAm0vrrVkRX4wALxlBvYBkZ39KroVnqDRflekfEU284LxWLzGVfJMI9tY4XbuuFiRcx /mx6I7yJvHhnfLyIemeUqGoJfv2//+9PH5/GsfXJ56rWt1z60/+dawm+W599Qh4OuUjeeiXY 2uDSuy8dmxxzj/ufuP/x3zz+wn9pg+7WhfU2J5a1nb/x/D/67B81wt9Ii68n1AvTI2DLonqR riIv8iPgKUywQDc3Uq+by7WD4jre0lDqOifgIoygKAR2TdQV+Zu+VYRkyB6Zhu0M1AjUDlt5 eYUpI3OxC5aXEYWt8TG2XssSIPJGbaDU8bkCw+GWXCz1Bky8+Mqn2GRJnkui3iQqlTUNVsZg IXlGQewt8H5Z1Wm13ea/ixNRb6sqZp4Py/bD6/1njHWVebNUQfYKBDx6w/gbBl9PqDfmx3R9 5KECRVFv2MQ7dN9Q9jdWRWoQ9VZkICO7ATDFbzpZ4Ck3kaqydo37Njk9RVvve26/XNTr4RyA o6f7qx+hJ+stbT3UoZ5NckM3xHg7BMBX1OshU/rfpEKoVybeNp9sot42BfQ6u1Evgx8xsj1i 2qPRDL3E1vMiQzIh9BIv4oRpkItXkMBeQF7bOtVrCbJpHHiX4As3X6tBMRyyEbuJUmECGbhr wHbgZKxW7Duv8D1NiFjypDMaeg2Fu77YhS9I7K6o13/E9LCFmVLvip9s/+jGtX/9xVP3WDwL 20wAdmXiTeXhJOpNRUZPCzHqBbwCUhFGFDFBYf2F2wPj4TO4PRGWcfVxAt5lvH28cAXpufUU zy0vzmsSGz88ugjgQOodGR8V9fow+2Hhw2987nZEgBsQsHjXh9HJrQ3AgvAWbjEWXwNfUa+H TOl/k7KjXiDv4V+ZH5i6L73mpXZFXrwtP1VEvS1LV4KMAepFi3mFVl7wK7ePsu2guE2UbTrF HpKPmd68GtzzEgiRdhMfeeZxUi/C94p601a36fJWPrQywDoIXWlmvKaLU4aSK4Chx+JFfAvC 157eW3uBtjOCr6jXf8T0sIXZUe9JI4sbTVr8liUv3nYeUaLedtTzPW9y6jVvB1KvATF6SDux S8kBAvZdhWzah8hlBF9s2MYaYPflFcT0zaZOlRpUYP3E+u4V3e6/B1DOjNvPSscaKoBoHpgt cHfBNyJMEtcNBli8dnTtkcf3IqZAdsclq8Z65h3vIbqpSS0rkBH1Dm+e/pMrZ0VS78uXv1yB Gtp8fIl62xTQ6+zJqZe+CkgPwIXzLu273EYVH9Ek7KJwzW29UOP6B24n42IjYk4CbMnGK4HY Dl5PkdI2DsY8sIv7j6Hn5h5cLG2H1PC8FYA7BCYMfigACr/rq+86Ys5J2SEvShb1tgyX3mbM iHqX/2jyxSfbZzo65nR0fPTFXQbzvk8qV5+ot3JD6nQoOfXSi5eOvCgArg7kWr64AC5gAIan hDk8VFnEBn3DjsRk3Iu/f6OoN88JAFMH1na4vLvTVveva/Nsg+qqmAKl83BgmF47EGo3EEYX EXkZgtdFRqRhFsagxad2zvQ83HC8VhFOGtEn0jMZdq9g8GArwYp1IwTjU0YIRnocaEZgJwg2 zL0Y6A7a73bf1YGNDOhj0YjTBeg8qBchaN7b0bFvR0dnR0dfx6wrZlXs1su/O6Le/DXPtUaG LYPV1uKX4YRGXCxZYyhfejXgPBDjDG/xsqgOlp4d4Ke5dsazyk5dvQTUe8ItH3/uhefRNNl6 sx4fLE1b/N3d3N3gzos1+1nXq/Irr0DpqDe8pxr3b8M2YwS78H5j2GkisGsxt2rj3mZMz5e7 LwPT4OVu/Oayo23eS4RlYpwQfK1Yt2FuMqvUperwHnKB7tjGaYHt1mwHu0h9YnrRGg1nRL34 ZaDzut0ct3Z+yV+MMeiYNXvWwMDA5ORk5W/J7Doo6s1O29KUTOotTXO9aegV99xKcy/svqLe TIcFP0YvvXtpOCQZrmdarwqviQIlpV5YTIGDOEC05DzDvgAmhpEXnNeIes1CbLlieBG0ik+R hZiLHdRYLCk2QL1IY0TLvdkAzSwBL9vXzbDYdhuOpF50md13D/Ir1TB9kMBAObDfcmu8y1zZ US9iloX9evEA/OHPfjg8PNzV1TV//vz169fX5PZMt5ui3nT1LGVpblDeUnagoEbDo9ddviZb bxbjgJBksOYqJFkW2qpMU6Ck1GtQCAIzoCTVuZgImgxYeQltYeo1rwPzEyDvxlCv8aXhI1oF kKXBOEC9wFCiOTcZtgPQjCNMvUhJ14hG1NuIWdkqVx9D4cBFP6kXXwjO+OaQu6YNz0CE7LUZ Ozo62tfXB/wdGhqamprSvZxcAVFvcq2UUgrspsDWZ58g9V6y6Suy9WYxOeCtGwg7pZBkWeis MitAvUZ1tNQaJuKEdBvw8W1EveRFsiadFmiLbeThYDZUJMC5eTK4jhbIzuthRI6ETtbLxIHu MD0rDdt6DabD1Gs6uP4b7SBvprZeLqxEMIfT//7qPzt9NsKPRN6kcHVYunQp2Le/v3/z5s26 kZMoIOpNopLSSIEIBV74r/+EUy+oF1HMRL3pThG48M7/x92CtCskWboKqzRXgSpRL/HUjKyu E23Awhpp6yVQcm0c6dMQsxEjAkxd/1pmiaRet0YkQHuQ0g7jUdZrnArrdUK/XqvX/D240M18 jhuxe2v4m52Hg4UTWb5x8jX7d8Xfrdu3bx8ZGZkzZ05PTw9O8FZ3d4wCol6vpwd3CU6liQhG hpdbFDdjw2vJkiXuXsRtVodFbyiT6+Qq//rAHVfR3IsFbfJwSGu4R8ZHXJcGhSRLS1iV00iB ClMvbaKur60RXiT1ki+RhU69MPS61BvgVCsKzglI6S5ogzND2MMhQL3uEjrXnMxyzKaLczpp mNcym0R7sHsYNxv1utCfopWXHfeEem1Wj4+Pw+jb2dmpFW+i3rI+7VMMi+vGHaMctsOwBSmz cA3t6FUr6l1+322k3vufeFTU2860Yd6AiVe7ELUvqUpIokCVqNd1CTCUND8E851t5OFgjg20 4IJ9Xep1OdUYNBCVjB4R/DTg1xvwcDCGZl1miDXqNaeIwFq9Gc3ProdD5Eq+1oy7gVy+US+n +vT0tK14W7tWIR2DDwDZepM8EgtL04h6aQNevXq1tQznuOKabJnGrkRSrwXc5f4UZgwOlI+3 +K/AKhi/DCe4yNrxEStiexAWDef4yxMmtmYArPnWshcmbhoV24I2bMy26Rc/IQHjPI2ya1dG wMSrjeZrNwOK63A1qJd2TXcZmbtuLLwoLdLWa6BJcoWfg4uYblhf4jULcWHaSBeJE65mC1Cs S72I2mvuEwFbb4y7QsCv16A/XXOvn9RrtxFWvC1cuFAr3gLPFVFvcQ/aBDVHUi8v8i85FRCJ 54J5LOAKNlTDp3BdsI0n4qkXWSxBuHyryz5CXagR5MqNMOg+gRP887CtMXiCLNzpzd3gDQ3G FW4IV+qXu6ANTg5w8O0dGcDFUncq/8YHTLxwb9BG8/mPQp1rLCn1WmQuQCfNpcaF4Xi9FsmB vgcxtl5jRNfNoBFimpmWFl/uWNHI1huOXEaqJjpH2npRpoU2C1NvfOQyN1yDWYvdPTjatPh6 Tr28o7niDW4PWvFGQUS9Xj/qw9QL0AQv0hUBtlU8KWBMNfzFdRpccYIXuJP460KtdThQON9G lm9ATLzm5hQW5Zc7WWD/Nl4JUC/bQ/5mLpRG47HX0idrnC1ow44VyXIoVVABAK7rxYtFbIBg ySQF8lSgpNTrriEjaNp+ZmHqBeHZsjOaZhvZes1Ay5i78e4EtksFG2B+tG4ANXxksR0soG8g PTJaJF3X1kuSZrEB6g10n2/dYBEu9Vo7YzaZaxaCS0G9dh9xxVt3d3fNV7yJevN8tDZdV5h6 aSVlQcaX4W0mzMrbFPWiusjyY6iXXrxm0A1TLxHZigUcs1N4PFXA1ouu2YK2Z5//bdMDXO8M 2FsYbgwWjB3sCyeHekui3hejQOmoN7zjLqMuGLdF7kiMBFz7RfIL70hsROjuCcztf2NgkTtN EFVxuJF3k+xIjMIDjgcM3+syKLfhsIuNdiRGGpqcqU+gWEjE7gfCqzULu5a+XNTLW2tiYoIr 3hYvXlzPPd5EvcU8ZBPWGqZe2ndpKCVKws5q3gJkSlp/Ab5IQ+8CnMR7OMD4imLpmxsuP4Z6 DWfZjHjqNU9ft2EJpfA2mS1oG5sc97aRHjYMJl53rzWZeD0co/o0qXTU2zKoKWOKCpSRenlT Y8XbypUrucdb3Va8iXq9frAzzAJo0l5oLs23/IhoC1S1BOY+yzTGzZHU6xZuS9nC5cdQLynZ KprR1us6DVfD1msL2lZt2ej1ZPKmcTLxejMUasguBUS9KbJgfYoqL/XanV/DFW+iXq+f+7Da wkPAfbG5vOLGxKUXL90JLA0T8CJjL7i9dQsPxCwLlG95Yay1KnCCtyw5UIWbhjUGMgaa6vUY zNQ4W9B28fdvnCmtPt8hE68mgYcKiHrrg6op9rQC1MubsVYr3kS9Hj6B1aQyKWAL2hC9oUzt zr2t41Pjrhdv53WdjbbZzL1pqrDuCoh6U2TB+hRVGeq1+78OK95EvXV/3Kv/7StgC9qeeu7Z 9kurXgnbf7d96d1LbdUaTvq/0z+9fbp6PVWPSqqAqLc+qJpiT6tHvbx/q73iTdRb0qd03s1+ 7vn//Onj0zye+Y22+d5Nfy1oi5mOm5/c3L2i25AXJt7Rn2sXj7zvX9UXr4CoN0UWrE9RVaVe 3ixVXfEm6tW/g6QK3Ln5qVMvHeOB86TZapDOFrR96cF1Nehu0i7KxJtUKaUrWgFRb31QNcWe Vpt67aas2Io3UW/Rj9tS1f/3o48b+D702P8qVdszbKwtaFt05/VWzeT0VJ03acNOEwEvXpl4 M5yCKro9BUS9KbJgfYqqCfXy3qrMijdRb3sPy/rlvu5bEwTf0y67999+Vet9GbCObdndX/vw +qGFd1x57Fc/dsyqjx371cW9tw7MueVCnON4523LwME1ZN+xyTF3u7XF310sL976PSrK1GNR b31QNcWe1op67X4u+4o3UW+ZHs0+tPWF3/333379pwTfd19xH9x8fWhV/m24/4lHsQvxMasW xR9Y6JZ/24qtcXBs0N1uTYEaih0O1Z5EAVFviixYn6LqSb28odwVbzhPcpd5kkbU68lAlKkZ 2/7P7y648SGz+NbW1aH/O9fOSL212rANBl1ssWbI23NzDzakKNPMVlvrqoCotz6ommJP60y9 fFRwxVt3d3eJ9ngT9db1Md9ev13wBf5u2jLVXnmlzA3P3RNu+XgM+NbK0ItYDV1f7DLkRWwy rGYr5biq0fVTIAfqvXRk88v22rNn3vE6KqPAXx/X8+oDD121ZUd2x/KNk6/Zv8v/O5Ir3jo7 O4eGhqamvOYBUa//08nTFgJ8/2bVuC1u++bYrzxtaJbNsugNkexbH0PvyodWzrp6FpEXJ3ib peoqWwqkrEAO1AswAvhesmpMR5UUAJVmh7wouSzUyxsSvLt06VKwLwh48+bNKd+lO3Zs374d t2qbxYp62xSw1tnh43vFN/7VwHflnT+voRxYrxaJvDUx9MKgu/COhWbihbkXe7DVcBqoy6VW IB/qzRSPVHglFSgX9dpDYO3atXPmzIHnA/wfgKrtPBwQOwL24yN7ejo6OvaYNev43l6c4DWv t3d4eLgFu7Kot53hUN6dClhUB+AvzoHCtdIF+7FF+jnUwdALt1047xry9n2zT7EaajX5K9NZ UW8lkbECnSop9fLJgFVuixcvhukXf1tY8Qan4U8vXXpQd/e5S5euGR/fsmOHe6waG/vgwMDB 3d3XDA01Bdai3so8t4vsyDd+OGkWX0R4qBv4hv0czvzWFUWORy51IziDG54MoRtyqVaVSIH0 FRD1VgAQK9mFUlMvb9TWVryNj48f0dPziaGhB7ZvD/Cu+3ZsevojS5ceO2cOTMIJnwui3oRC KdkMCqy770kD309++V/g9VsryS763rDr51B5Q+/AXQNueDIE6K3VcKuzFVNA1FtJZKxApypA vfasSL7i7fujo6+bM2fj5GQM77ofwRJ8eE8PQDnJc0nUm0QlpUmkACI5YOsKsi9Cmz3zm7a8 eRJV6U2iZ5//7Ym3XETwPe22Zd60K/2GBDZdwwZsuJJ+NSpRCuSogKi3AoBYyS5UiXp5Q8+4 4g2+EEBeGHETIi+TAZGPmTMniZuvqDfHJ2sNqkLsXgPfs6/d/MR/PF+DTu/q4rp/+xGp94eP 4x6s5gs23c7rOs3KC4uvwpNVc6Rr1itRbyWRsQKdqh712qMlcsUbPHTh2HDHxERTyMvE8PTF ErcZH12i3hklUoLmFPjFU9uwZ5tt3oa3zeUvc+r33H5578hAmXsQ1/ah+4Zcr4a1/7q2qj1V v+qmgKi3AoBYyS5UmHr5kAmsePu7wcHFg4MtIC+zvGPhwjVrZ/jHJOqt2+M9j/6CdGHoLWTz tq9//esnvelNRR3z3vGWExadUVTt4XqPf8MbLrroovaHHJEZEJ/BkLd7Rbc2XWtfVZXgjwKi 3koiYwU6VXnq5UOAK94OPvjgV+yzT/zytXgg3jQ1tV9XV3xIB1GvPw/eSrUETr3nXfegrW9D kIccuoe5vtdes9dt3KSDCrz5lFP/9E9f2lRUl/AwIf6uu+kaovMqPFkOk1lV5KmAqLcCgFjJ LtSEenmzj4yMnHb22Y24dv9DDrFj9ZYtjZIhoG/8Thai3jwfrfWqK7BrMTZy+81zL2QqwQ03 DH/sgosB3DqgwCOP/XK//Q/46KILIUvLsgc2XRve3HpRLbdBGaVA1gqIeiuJjBXoVK2o963z 5980OhpDvWcvWXLhNdfg+NG2bY2SfWp4+JMDcX6Got6sH6e1Lh+Be909LN5/9f0/fXw6I0Vg 0TzggAOAekJeKrDogouuvOYLEASytGbuXfzdxebVgEVsm59Mf4fJjCaDipUCTSkg6q0AIFay C7Wi3v27uhpFK4NxF/uxkXrvevrpGD+HGde0iXqbejYqcSsKuBHN4POQkbcDFoSe8Z73CXmp wK+mpvfZ51VbJ5/BOWSBOE2NHCIzuI68vbf2yquhKQGVuFwKiHoriYwV6FStqBdc2whnAbv4 tGfuXDo5xIAvuBn0HPP8EfWW6+Fc1tYihJnr5puFt8PRRx99970PinqpAKy8sPXyHLJAnORT B4CLKLxm5V1699LkeZVSCpRRAVFvBQCxkl0Q9RoHr9u6FefgXVAvILgRH4t6y/gErmab4e1w 0/qttr4tXW+HzZs3H3vcG4S8psDBhxz24wcftrcQBxIlmViT05Pu2jX49SbJpTRSoNQKiHor iYwV6FStqHev2bMbbU4B5L1hwwaSbjz1Yp+2I3t6ZOst9QO5Uo0fe/jfLZpvit4OS5cuvWzw KlEvFQDvgnpdNSAOJJpxJiFcw+xrZ9PKO+vqWesn1s+YRQmkQAUUEPVWABAr2YVaUe8h3d2N 9qegh8OnV6w4/bzz4j0csB4Oq+JEvRV4LFenC/B2wH7FZvRNxdvhsMO6XdNmzfH3ssuvunhg iSvCQw8/dsABca5OmF6jPx8F6RJ5wb5au1adW049mUkBUW8lkbECnaoV9S5avHjZypWNXBew lA28C9deM/pGpjx36dLlQ0Oi3pmeefo8XwXS9XbA5i6HHrqbabPm1HvMscd/7wf3BkSId3IY GR8xR154OGgTinxvCNVWsAKi3goAYiW7UCvqHR0dnTd/fssbszHjQd3dQAJRb8GPVFUfqUBa 3g7Llw99YuBvak661n2EKkP0hrAaSy69bHBwMHIgBscGDXl7bu6Z2jalGSsFaqWAqLeSyFiB TtWKevHMgUsuHHNbBt/r1q9f0NcX/+xSDIdaPdu96yy8HT755X9p09sB++6GTZspQvDjT/76 /ocecQsMvP3BPz8QuILEuILrP52YZEacB44UW+gW9bnrbzrn3PPDhcMDBH4g4RnQ/51+Q975 /zhfEcq8u0nUoOwVEPVWABAr2YW6Ue/69etP6etrmXpf29MzPj4u6s3+kaka2lAA3g4r7/y5 gS/Wuq2778nk5XEXYoSnzQgiUeyyz3z2DXNOtPIBr/YWHx140MF4ywMfMZldwcmFFw3gyjtO exfOkdjSh0E5lS68/6yzb1zx1ciiIBS2OzdtEZQXmGvIC/zFleTKK6UUqIwCot5KImMFOlU3 6sUj5fzFiy9r7N0bA8TnLV16daxHL59XsvVW5rld7o7c/+iv3dgOMAD/4qltSbqEL3ZHHnV0 KrzYqJBG1Lvi5q8DZGEJZsZ/uO3bIFqcDH1++KwP9VtpuGiAGygqi2YfceRRjeIWu669sOnC mUFBeZPMMaWpvAKi3goAYiW7UEPqhSVrbm9vzNbEkeB7xcjIjL4Not7KP8lL1sHfPPfC3379 p2b0xcnfjz6+7f/8Lr4bIyMjC886Owt8tDIbUS+Qd93GTW7VMOgChUnD5tvg2nSzpl7YvPfa a69Glu9zPnL+ypU74+8qKG/J7g01N2MFRL2VRMYKdKqG1It7Hb9Jzuvt/cTQUBJXhwe2bz97 YODMhQuBy0meE7L1JlFJafJTAEZfbGDhbmaBKzHVDwwMYB+yrKkXkQLpnGAuCqgR54a2bACg FgdPmBJGX5eMs6ZeWHlh622kBoSCXArKm99sVk0lUUDUWwFArGQX6km9fGx8eulS+OmuGhuL YV8sX0PQhuuHh5M/aUS9ybVSypwUgH0XVl7X6AsbMEgusvq3ve1ta769IWvqjfTrdV0X2AC4 8JJ6ecDKS/w18M2aem++5Rt97z6zkRpoxuHvOVxBeXOax6qmPAqIeiuJjBXoVJ2pF88PeDDC 6Lt3Z+eZvw/lCwLm8anh4dP7+/ecPRteDZOTk009aUS9TcmlxPkp8G+/+q0b3uG0y+795tiv wtVjhdbWyWcKoV74M8CF162agBu27xoKZ029iy64KMbyfcVdn3OD8sLPIb/hVE1SwGMFRL0V AMRKdqHm1MtnxtTUFHzzsIcFCJjHJwcG4NzoLs5O/nQR9SbXSikLUADxHNxVbudd9yBomO1A 8IefPj79iv17Hn/6/y2EemHKBebCi5e1A3bBwTihXy/tu0jjuv9mTb2BAA7rHtmE41e/3hng 4uLvLnGD8ipCWQGzWVX6qoCot5LIWIFOiXpTf2aIelOXVAWmrABWuS1f8zPX4eG6b02s/edf ue6/V/3jo0/++vmM2DcQkwEgayEacM6QZDhc3waCL4OUIbaDNSxQVOoNfvs7F4ys/haKvfHH X91raC/D3L/64kF2fsrIKYpQlvIcVXElV0DUWwFArGQXRL2pP1pEvalLqgIzUeChx/4XDL0u +wbOz7/hwezAN3U8zajAE+eeBBszkNcYN3Dysg+9vFkvqEyGU4VKAZ8UEPWmgoxf+cl/L7tj 6uwv/vSD140vWjmxfNNvUym2zoWIelN/Toh6U5dUBWalAFwasMrttL+9txH7/sOmXRuhZcSU /heLAA7f+X/u3uOqWZHUO+/vT0Zs4xm3rslq/FSuFPBVAVFv+2QJ5AXvBh7On/zGZPsl17kE UW/qzwxRb+qSqsBsFfjGDycbUS9Wv/kPppm2cL/9D/jC6IpGht43j5w6d95J+Aef7QipdClQ NgVEve2TJYy7kU/mwQ2/br/w2pYg6k39WSLqTV1SFZitAljfJupthM777POqT2+4vBH1Hnzj YaDeVd8U9WY7RVV66RQQ9baJlTf9+IW3L4v+FQ7eDm0WXufsot7UHyai3tQlVYHZKjD28L83 ol6saUvXkgofWW48YbtR8C2OH/zzAzjc6pgY69UCW1cwai8O26QNmxgHQp6l1WzYem/a9LVG 1Nu35kxQ7+CqMSwEhK9IoxDI2Y6fSpcC/ikA6n35nrOPPL5XR2sKHHtqvz2W33LJpqPe9Xf2 9pRPrm+tTOWCAof1zNl3/y7/7pgSt0jUW+LBq2fT4d3rRm9wCfieh/89LXzklhOIz0BgRTQG hmLACbeiYAwyC+aAlG5iC2eGxAzv4KYHLrvbXqTY5mOOPX79XT+ETTcSfNeMbzj00MMeefTf TMArvvGvWCZYz4mkXksBVwGAr14tK/AP/zTmPooPeuM5OHjlzCtaLlUZdyowMTGhWzVFBUS9 KYqponJSAGF63SC+fLbetH5rivhIwLUCgbyMxYuLZuKFyZZpQLSGv3gLWy83K4b1N0C3eAsg zo56GcPhe/92rxu2jAR8zj+dj7btf8ABiOGATZ7df1FnX7sZO4AgQlxO46dqpIAUqJACT/zH 859Y8S+Bn+AMfBF3skJ9VVdKr4Cot/RDWM8O/OKpbYjae8bgj/CoRcyy7/3Pp9NFXpQGzAXL BtwYIqnXvchmICND87pBfHEdyItis6NebEeMTYlR0SP/v1++ffWC/W44ALx74i0nIZYZGzZr 1qzt23fu7YxNngP/pbD7HSS1TUDqOa/UaykgBZIrwLg6fJK89dO7mXtxBeB76Lx+PKuTF6iU UiBrBUS9WSus8rNVoKOjI3XetQLplgCoBarSK5cbT9gBB4aAVZh5zaXB3aIC18m72VFvYG+2 /3975/dix3necf8FkW+i+MayimOsYCtdE+L4QnICptROmyqmSIgmStwKqzI4sgiyLUckCq4t Uyp7SVC8qBAvVCCVErQ4oihqA1uTNsJYYa2LRFGMESbEm1402+BSQXPhfJKXvozm/Nhz5syP d2Y+h8MyOzvz/vg8c/Z855nnfZ5BMuAK9uCrCJk7NEKavMjnLv7ivf/9TbWWs3UJSKDNBHjm ls2hzvM3VlZk/6sQSfXo408dPXq0zbN07F0joOrtmkX7Np/bbtv8xps/rU74RhUbYhVCCeKw lC2uWhvq6w1hD4O+3kpV76Gnj/AeRePfX3/zzju3xCtk4dxbY6p+8B1G0AjPLvt2RTlfCUhg PAFuiXkulKuXGe6T+ck9M/klWXYcGkH1Kny9otIhoOpNxxaOpAiBHTt2hBq85b7x7OZCckMI 76DADfEMwekb3iHeF00c6hJnB4bPuNK4XlBQlHgUCv4Krkh5zLrA7PcZWZAvXFotYhvPkYAE OkeA/wbZ9cSsClh3RazCt3NXQYsnpOptsfEcenAkjPFuziKFQ1oGFofxjrp2qOqll5DPAQdw WMEWRTA7QyP8ie0ggtmmnZgErcQsZri9SV42atZHvvY3hw8fzl42Y9LAZYUvoXtebBKQQM8J sOA1tx6A/wzcPE+CReE7CSWPqYGAqrcGyHZRIYGlpaWQXaGKN35Z9CtqNWYiQ6riyh3aV1i+ xvFo3OwBg43QQpS8IcVviYPfsGHD1Wu/HNrgw3++68yZMzlj4ModE+fAn1yCXeHla9MSaAkB 0rxkY3b5vzHtMjWFb0tM3fFhqno7buDOT488XGTjKlE1tr2pkLxs6Cy2fvQPV1ZWcpcEX11j VO+TJ1cm9OV0/kpzghLoJwH+RWTvjdG+KOBiKBS+xbh5VokEVL0lwrSpZghs2HDzKO9m2yVs gfHve+zxZ5//u8ET31ldA1RIW5Z7jVrW9uln/u1HP/tVM0a1VwlIoGkC2cRk4d6YCIcZE3sr fJu2at/7V/X2/QrowPwrWtBWQHGmcMqoBW04gO//5CeHmnYnGSAAABMWSURBVJtl16PK3eHX OfuDn3fgInEKEpDAVARYo5ZNTMa/iLJWtSp8pzKEB5dLQNVbLk9ba4DA4uLi7r/Yk4LiTGEM v/fpbuBnbjBf/KtHFxYWRpmHZEPZOIc/+cpru5/7j7iHwsWm723gyrZLCTRBYExisrKGo/At i6TtTEtA1TstMY9PjsDa2u+e3aegOBMZA8nLBrO5fehDt6yujktA9tg33ogyl5LFfPMhduMe 8hNNu3gluQvFAUlAAusRwKGbrfeOu3fdxGTrNTn87wrfYtw8a0YCqt4ZAXp6EgR4dj9qCVci SrTOYXzjxN9TpC3b45jwhmi/uKwtG9LAdly4zQYu4STs7SAkIIGyCfAfo3BismJjUfgW4+ZZ sxBQ9c5Cz3NTITA/P//Xj32pTmWZcl+s7SPIITvCAwefPHbshXWtRTE23rnDfvLOr3H0Rqcv icyMdliXpAdIoF0EBhOT1VOXUeHbruukA6NV9XbAiE7hffOX5VR4Ln8Zyd1AtO6FMkrOsj/r BOKhp9EO68L0AAm0ggC3tdnEZIQ3FE5MVmy+Ct9i3DyrGAFVbzFunpUcATM5ZIVvNpNDrhBx YcvxXRg9vkY7FMboiRJIhEAVicmKTU3hW4ybZxUgoOotAM1TUiRA/QWqMKQceFDz2O7e+tHv v/Y6nQ4tTlHMhLiFsjnOjv/TFWtYFCPpWRJolgDVyLOfZbbZ0+CQFL4Nwu9V16reXpm745O9 9xOf+Od/ea1mcZlsd3/74je/+JePAgQsJRp+MNqhnvi/EqdgUxLoM4HLb69lE7bwAIfb1xSC 9RW+fb4sa5u7qrc21HZUOYGlpaVP/+mfJStDax4YKXtv3XTbA3/0x2ApHf0//Ou1bLRDWenr Sx+nDUpAApEA4fi5LA3IX0RwOogUvunYoqsjUfV21bI9ndedd27Ztv1+34HA5s1/sHHjxoou Bb4sjXaoiK3NSqBcApQRJj1LthINH940ExEqfMs1va3lCKh6vSQ6RYBMBcu+/p/AhQsXLl++ XJ2B+Sp98uRK/CrFb2S0Q3W0bVkCBQgQusCTmZh1m08rWRrYk3JEvsK3gKE9ZUICqt4JQXmY BCQwnEA22oEv1GbXxGgkCUggEqDKTPaBDJJ34dxb3Kymj0jhm76NWjpCVW9LDeewJZAQAaId slVMeZaasicpIXAORQLVEKCoeLa4DHqXAuPtehSj8K3m0uh7q6revl8Bzl8CpRDAgZTNdW+0 QylUbUQC0xIgvWA27gi9ywczqSVrk89I4Ts5K4+ckICqd0JQHiYBCaxP4Nvn345hvnh/ze2w PjKPkEBJBMgSg0M3u2QNdy9O35Kab6YZhW8z3Lvbq6q3u7Z1ZhJogsAbP/2vbLQDbqd2PVdt gpl9SmAmAjxpIWA3q3f5DBLU241AI4XvTBeHJ99IQNXrFSEBCZRMIBftwPrxxNeMlzx/m5NA XQTQtZQKz95n8nHjkUsKVSdKZKDwLRFmz5tS9fb8AnD6EqiKQO7LeO/x13EDV9WZ7UqgfwSI IMqlaDh2+setSNFQwFYK3wLQPGWQgKrXq0ICEqiKAF/AuUBDap929Vu5Koi2K4EBAtxA5qoK E0pE6bVuo1L4dtu+9cxO1VsPZ3uRQH8J8A2dTaLE09g0i0L110LOvD0EhlYV7s9TFIVvey7V REeq6k3UMA5LAl0iQPRhNr1DyKbkKrcumdi5VE2AhyQ8KmlFVeFKUSh8K8Xb+cZVvZ03sROU QCoEkLnZnL58fyOFu7HMPBXEjqOLBFiaxielXVWFK7WDwrdSvN1uXNXbbfs6OwkkR4AlONkl 5yzH6c/z2eSM4YDSJhBSkmU/Ly2qKlwpWoVvpXg73Liqt8PGdWoSSJQAvqvcs1oWvbnKLVFr OawmCPBgJPcZaWNV4UrJKXwrxdvVxlW9XbWs85JA6gSokko6s2wtN5KdpT5oxyeBignwuchl PuEz8pVXLre0qnCltBS+leLtZOOq3k6a1UlJoB0EQo79bMAigb8/eefX7Ri9o5RAqQSoHpwL fEfv4vHtfEqyWSgqfGeh18NzVb09NLpTlkBaBH75q+u4srKL04ll7FhxqbSIO5rECBDsnn3u wWeBW0E+BXw0EhtpisNR+KZolVTHpOpN1TKOSwI9I4CjK1toim329IyB0+0XAW7tzv7g57n6 avxKBW/v+qa6FBS+U+Hq88Gq3j5b37lLIC0CfNPj38o6ffEB6+5Ky0iOpgwCrN0kGVkuOQPF XCjgYi6/YoAVvsW49e0sVW/fLO58JZA6AeJ6c9GNhDaqfVM3m+ObjABXMtdzNpad2zzKCy+/ +Z+TNeBRIwmMEr7nz5/ft3/fxls23pR5bZ3b+vThp69cuSLQXhFQ9fbK3E5WAq0hwJPfnCcM rWA5t9bYz4EOEOB2bjA5w5MnV8xXXeLFkhO+y8vLqNvtD25/ZuGZC6sXLr1/Kb5Pr5x+/IXH b99y+87dO69du1biGGwqZQKq3pSt49gk0GsCIUV/ziuGbnBJe68vixZOHl2Lus2G7rB97PSP vZKrMGYUvl89+tV7P3Uv6jYrdge3j505dtfcXWeXzlYxGNtMjYCqNzWLOB4JSOAGAmpfL4j2 EiA5A9ELWb3LXdw3l64asVOpTY8cObL1nq37j+4fr3fjX5fXlh/47APPvfBcpaOy8RQIqHpT sIJjkIAE1iGg9vUSaREBVqQRosPqtKzeJWKH5AzWIKzBjnse2XP4W4cnlLzxsId2P/TK4is1 DM8uGiSg6m0Qvl1LQALTEQjaNxfvS8yDZaum4+jRlRHgEkXaDiZnQASbnKEy6jc0/PLCy7v2 75pW8nL8D6//8J777llZWalnnPbSCAFVbyPY7VQCEihOgARng8KCuEm1b3GmnjkzAZIwDC5W I7yBIIeZ27aBSQmsrq5+eMuHiVgooHo5ZfHi4sfv+/iknXlcCwmoeltoNIcsAQm8/77a16sg BQJkZiBON+fcJbDB5AyNWOfAwQOH5g+Nkbxnr54dL4gJ8F1aWmpk8HZaAwFVbw2Q7UICEqiK gNq3KrK2O5YAy9H+cfmdXORuqCRMij2TMzR1+Wy4ecMoR++eQ3s23bEpvE9dOjVK+x5fOv6Z z36mqfHbb9UEVL1VE7Z9CUigcgJh8VCusivONmsaV46+Zx1wpRGxMJiGDL1LHUH+ZPBug1cE 2XlJVTZUzuLipULFUyee+t6730P1zm2bG6V6ie79wM0fuH79eoMTsevqCKh6q2NryxKQQK0E hmpfAivVvrWaoaOdkXN3sKYaYhd3L05fM5GlYPb5+fnPHfzcKDkb/btI3jGql9M/MvcR17Sl YNAqxqDqrYKqbUpAAo0RGKV9z138BeEQjQ3LjttJgHKA3z7/9mAkA4G8hPMS1NvOaXVz1FQY ptza+LDdZ089i9OXn2MOo5YbRYy7yaj3s1L19v4SEIAEukggPIkeFCsUxNL120WDlzwnbpC4 TcoVmAjJd0nUQLoGIxlKJl5Gc1945AtHF4+OkbNB8u7Yu2O8Mt7xyI7FxcUyRmQbyRFQ9SZn EgckAQmUSGCo9iUCGEcdbrwSO7KpbhBA0XJrlKsezK97j79O7Lg1JlK2MrWI9x3dN0rRTih5 OZ3gYEKEU56pYytMQNVbGJ0nSkACrSEwKihTKdMaE1Y8ULIucCOUWxCJ2A03SOZkqBh/Oc0v LCzs3L9zqOoNi9hw9Iag3vHu3tu33H7lypVyxmQriRFQ9SZmEIcjAQlURoDH1qMW4PvYujLq STeM7xYPLjc/g85dPL74fZMevYO7kQBSFcE6VPW+9OpLQe+uq3ovrF7YeMtG0XaVgKq3q5Z1 XhKQwEgCo5KtskSJdfouUer8pYOJWaM2NGyXnUT0GsnQ0mtg0+ZN37323WKF2cJZRAYTH9zS 6TvsdQmoetdF5AESkEBnCYwqrMUyOIoem46qS4bHmshZPLiDddRCJMPCubcM9W67xV+af+nz Bz8/i+o1bVnbr4Hx41f1dtu+zk4CEpiIAM+yCXIYfMxNPQKCIlqR8uzq1asPP/zwRLOd5qAT J07s3bt3mjPSOpaQbuTs0BgGzI0CRgdzTFqDdjRFCVBd4u65u79z5TvFhO/XF7++55E9RTv3 vBYQUPW2wEgOUQISqIcAz7WH5qsKZWYT10aXLl264447Sgf1/PPPb9u2rfRmK20Qly3RuhRL w3CDdzLsIYyBCAdDWSq1QlONk37h/gfvp8TatMKX0IiP3fex1dXVpkZuvzUQUPXWANkuJCCB lhFANuEgHLqiH/mL9zfB4Icxqvfdd989derUYDIm9rCfv0bz4DBmT3ZnW1Qv/ngyMZNvYTBJ cxC+WBPb4dRvhee+ZR+YxIb74vyL5NydSvUury3P3Td38eLFxKbicEomoOotGajNSUACXSIw KuVZKEWblAIepXqRsPiADx06RKACG+haDMRPttnD/riTbdy6yNxwZFDJiatecopREPiJb/1o qE+XnXh88fuaeqxLn8pJ5oLw/V3a3bXlSbTv6ZXTd83dZY7eScC2/RhVb9st6PglIIHKCYxJ eRbEFgqY8FCiIxpcDjVK9Ub9GiRsiP3lJ9sBHBvo3bAz+n0RvuGABFUvgSi42wE+6IwP5iCK F1c9rl8rqFX+2Ui4A1TsrZtvPTR/aEy0A3nKdu3ftXVu67Vr1xKeikMrjYCqtzSUNiQBCXSe QHiMjqIamvQqPklvRAEPVb25nfFXpDDbg/ZiJ8vXggM4KdVLSAl+91HpxuK6NG48Egw+6fzn ItkJrq2tHTh44IO3fPCh3Q8dO3Ps5PLJ+P7y/Je3P7id1LwvL7yc7PgdWOkEVL2lI7VBCUig FwRSU8Czq17CG0KEA0ERCN8GVS8+2stvrxGZQJwuaTRGRS+wn9gG16X14vM2wyTRvmfOnNm5 e+f2T22P7ycOPnH+/PkZWvXUVhJQ9bbSbA5aAhJIikAKCnio6iViAa9tjFtAzoaEDPxkOzBk g9iG3OlB/vLXeiIciLtlnRk5kgnDHbUcLWpf16UldfE7GAm0iICqt0XGcqgSkEALCEyogHFh 4qRkJRZOzVLWWgXZikiNr7A6hwhdJGxI18ABr776Kjv5yTZ7wgY/gz4mvIF2wmq2kKa3CtUL ImbN3FkOOGYhWpS5JCADF4ElzUZOt+Dic4gSkMBYAqpeLxAJSEACVRGYRAFHbYePE23HM31c nsSwogunGtZ7772XlbxsxzXpwZtL0EJ2lTrb6FpecWfcw/EkeUABMwB2ho1ZXmTGZf0ZKp8J Di2NlothIGya2OjAwTjdWch7rgQkkCWg6vV6kIAEJFAHgakUcM7NiQQsxR9c3Tz/+3/+D5nO m9V+qFXeQeOOWfYX54gODp5vlLGVI6qzkS1LQAKqXq8BCUhAAnUTCI/4QyQrT/nRfKOScEVp iCKse5TT9LduMG7Wm0tUA7MO0R2kIZumH4+VgAQkUJyAqrc4O8+UgAQkUC4BPJ0IwaGO0vaq XgQ9sp5JofIT91iXa01bk4AEUiOg6k3NIo5HAhKQwA0ECGxFCjdY/2ISexCDEaRteIe4ZN7W iZiEnsdIQAL1EFD11sPZXiQgAQlIQAISkIAEmiSg6m2Svn1LQAISkIAEJCABCdRDQNVbD2d7 kYAEJDArgZB5N77IREa2slkbHXY+acvIdFZFy7YpAQlIoEECqt4G4du1BCQggSkIoHdRulSR 4BVS8IZCa6W/Qurf0pu1QQlIQALNElD1Nsvf3iUgAQlMSiBWCY4nBB0cfw2lJdDE2T1I2LA/ 1CXObofD2B9KUfCneGJsJGxwQLbCBXvYnztl0ml4nAQkIIGGCKh6GwJvtxKQgASmJDCoerPl gkP8A3uyPuAQDsGeUGQ4/DVsBxEcKhIjnXmFA4KiZTtu0AKncGLYySu0GXrPyu4pJ+ThEpCA BGoloOqtFbedSUACEihMYFD1RnmKIxZJGsN8kaShjHCQp1mpGreDwEXOInzDTqImQshEVvXe dNNN0ctLF/wJl3Dsi21jIQob1BMlIIGaCah6awZudxKQgAQKEhhUvUHs0lxw4sZ2ow84e8qo bZQrejecMqh6o383aOgQ8MAG+1HMubCHghPzNAlIQAK1EFD11oLZTiQgAQnMTGBQ9RJdEHQq mhUNWkD1hsAGfuIbxuk7oeoNjuEQKVHRirqZadmABCQggTwBVa/XhAQkIIF2EMip3hCHgPoM GjTrlEWPhnDbdX29IWghzD9q6Fxcb6QTfL3EUcRYXrazLbSDo6OUgAT6SkDV21fLO28JSKBt BOIashDPEGIMspKUX1Gl/DUuVltX9YaVavGs7CI2Wo7yN/QSIxzCurd4VttAOl4JSKCnBFS9 PTW805aABFpHgCAEtGZ8ZRONhblwQEitEPIzhD0x9HboNkfiuA2r32Ka3sGN2FpYMMdZQXln +2odTwcsAQn0jYCqt28Wd74SkIAEJCABCUigjwRUvX20unOWgAQkIAEJSEACfSOg6u2bxZ2v BCQgAQlIQAIS6COB3wLt6c0W3DcOmQAAAABJRU5ErkJggg== --------------060305030101060601020906-- From nobody Sun Oct 5 08:41:18 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A393A1A0371 for ; Sun, 5 Oct 2014 08:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.902 X-Spam-Level: X-Spam-Status: No, score=-98.902 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_16=0.6, J_CHICKENPOX_17=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5RbcAvgdDir9 for ; Sun, 5 Oct 2014 08:41:15 -0700 (PDT) Received: from secure.winserver.com (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 786C11A0123 for ; Sun, 5 Oct 2014 08:41:15 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2528; t=1412523674; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=wEeOcX+HTXiTrOlKz6iBnTC2q+Q=; b=sFvs0IDK4deG/SSa/1i6 qp2bh1rvLrJTV11EWlrKklG33GpBTeXoYWpmh5T/V/s3/l8KXoUcp2DXAzbXtbOj mrpt0oZXXZ6/L48eCBty3c8guijnhVydk+5JpED2lc8JgKzBtCU0JS69YnQwO+0b G2gE7S0hIOzVopHF72TC3kY= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sun, 05 Oct 2014 11:41:14 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3413746466.11276.888; Sun, 05 Oct 2014 11:41:13 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2528; t=1412523298; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=HkAqusg Vkb1FMfCDIDKyC/MSF+dEPzRJ+4cw8cidkBE=; b=eNs8F05fbJxU4u6BwoPMGnD Ugg69MQQiSwFrZqjlURCbIeuDj5eiQK4TU4jUCBzKZkq8DXUxY2EvwybBFlGD0z1 juFgufvVxhtKluhbMg5u7X87G9mwFnQr0fHBWRjPc6/66uLdaNjSk8rAJ4aivWrp 2dSC/ogARwnJtmiUyFSU= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sun, 05 Oct 2014 11:34:58 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2006177875.9.560; Sun, 05 Oct 2014 11:34:57 -0400 Message-ID: <54316696.7090605@isdg.net> Date: Sun, 05 Oct 2014 11:41:10 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Josh Aberant , dmarc@ietf.org References: <20141003022338.3339.qmail@ary.lan> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/QUU_T5MB-1YvbCZlenk-76OhUfY Subject: Re: [dmarc-ietf] yet more From rewriting, X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2014 15:41:16 -0000 I should add that if a system is not currently capable of accepting policy-failed transactions and separating it into an user's "spam box" then it SHOULD honor the Reject and reject the mail at SMTP. In other words, using quarantine for reject instead is only for systems that CAN separate the mail at ALL MUA type levels; online, offline and hybrids MUAs. Otherwise there is a security hole. Keep in mind that any protocol is generally OK as long the same security functional goals are achieve with the options of the protocol. Not honoring the reject and just accepting it with no separation is a SECURITY HOLE. If the USER is a POP3 user, in general, this is a single stream of mail collected and giving the the POP3 client. Its not like IMAP. The POP3 MUA will need to be able to separate it. On the other had, an IMAP client and/or the backend with a more modern Online HTML view or even downloaded frontend end client can separate the mail more easily. But the backend has to be ready for this separation. If it can not, it SHOULD NOT be ignoring the p=rejects and SHOULD perform the reject at SMTP. -- HLS On 10/4/2014 4:31 PM, Josh Aberant wrote: >> I'm not Doug, but Google unquestionably did that when AOL and Yahoo started >> publishing p=reject > > > Again, this is an assertion and where is the evidence for this? > > The reason I ask for evidence is that this doesn't match what we've seen at > Twitter. Google's already replied on this list that they didn't change > anything because of Yahoo & AOL. We observed Google's transitive trust > stuff long before those ISPs made their moves to protect their users. > > More importantly, there continues to be very real and significant > differences between reject & quarantine. #RejectPolicies result in a whole > lot of bounces which are both better user protection and also probably very > discouraging for the bad guys. > > Thanks to SonicWall and MDaemon for their replies on their approach. While > I very much appreciate the goal of reducing false positives, I would also > like to reply that enabling a #RejectPolicy tends to be a very considered > move. The senders I know with a current #RejectPolicy all had spent many > months inventorying their mailstreams prior - they knew what would be > "false positive" long before they turned it on. > > Josh > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > From nobody Mon Oct 6 13:24:54 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1721A89A3 for ; Mon, 6 Oct 2014 13:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEuj0aql6cTL for ; Mon, 6 Oct 2014 13:24:50 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 752481A89B4 for ; Mon, 6 Oct 2014 13:24:50 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id em10so5802982wid.16 for ; Mon, 06 Oct 2014 13:24:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=c4BQX+a5aHnyweWL5Ep+C4KYE+RpG74fi/0lJZAe68A=; b=de6fBzF49KogpSooGZOZsEVVPrX+UQpxlgUtv6exrtVxHWHZaDvTr4hATOd708RoQS butyrifJAW1F5tF1yVLQdMeGIwiz/8XfJKk72Y+cQ+tvHH79Rmqh4jfKV4PD2MIktoNF Se/FUWOoWiNsvG3UMY+ucJ7FkQR5hWJSH4pDMmbMOiqT8pSXfWhwhvoB94dJ5nQp7Ydo y409TK7N3TDXWrNVItmbyC7ttXcele31UL1aWyPK7ZHqCIVb7OqXyFXD6sEyqtFj4woO JmWwUBitDU4ZQD2HXJw0AAvxiyxsJk/jMKd+D9eeUxnKqtH29TpeUabYiB0xHr+OmtmB rNmw== MIME-Version: 1.0 X-Received: by 10.194.219.193 with SMTP id pq1mr33119534wjc.5.1412627089167; Mon, 06 Oct 2014 13:24:49 -0700 (PDT) Received: by 10.27.76.134 with HTTP; Mon, 6 Oct 2014 13:24:49 -0700 (PDT) In-Reply-To: References: <20140918134416.2051.qmail@joyce.lan> <541BABD0.10506@rolandturner.com> <87zjdvzzt1.fsf@uwakimon.sk.tsukuba.ac.jp> <541D67F0.5070800@tana.it> Date: Mon, 6 Oct 2014 13:24:49 -0700 Message-ID: From: "Murray S. Kucherawy" To: Tim Draegen Content-Type: multipart/alternative; boundary=001a11c28620d99da00504c6dfe5 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/IaUdE6q87FXr-xGkbmGywK2vmPo Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Modeling MLM behavior X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 20:24:52 -0000 --001a11c28620d99da00504c6dfe5 Content-Type: text/plain; charset=UTF-8 On Fri, Oct 3, 2014 at 9:05 AM, Tim Draegen wrote: > On Sep 20, 2014, at 7:41 AM, Alessandro Vesely wrote: > > IMHO, we should specify a credible MLM model, even if that can be > > slightly off topic for the WG, in order to maximize its probability of > > being adopted. The rest of this message has some notes to this end. > Can I get some clarification on the intent here? As worded, this paragraph suggests that we are looking to produce a model for MLMs to follow in a DMARC-aware world. I was under the impression that (a) this is a non-starter, and (b) we're not chartered to do so. -MSK --001a11c28620d99da00504c6dfe5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Oct 3, 2014 at 9:05 AM, Tim Draegen <tim@eudaemon.= net> wrote:
On Sep 20, 2014, at 7:41 AM, Alessan= dro Vesely <vesely@tana.it> wro= te:
> IMHO, we should specify a credible MLM model, even if that can be
> slightly off topic for the WG, in order to maximize its probability of=
> being adopted.=C2=A0 The rest of this message has some notes to this e= nd.

Can I get some clarification on the= intent here?=C2=A0 As worded, this paragraph suggests that we are looking = to produce a model for MLMs to follow in a DMARC-aware world.=C2=A0 I was u= nder the impression that (a) this is a non-starter, and (b) we're not c= hartered to do so.

-MSK

<= /div> --001a11c28620d99da00504c6dfe5-- From nobody Mon Oct 6 13:26:58 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 272DA1A89A4 for ; Mon, 6 Oct 2014 13:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rv6c57ZEl1RB for ; Mon, 6 Oct 2014 13:26:47 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49E091A89A3 for ; Mon, 6 Oct 2014 13:26:43 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id fb4so5856909wid.0 for ; Mon, 06 Oct 2014 13:26:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=5g8m9uAGY7FO41EFzInVYJFnP5HU7SOeQPlcG3HPiC8=; b=zlSF+FWMA3vWPfIYOitTxhidFaVWAAHaf/wOV3OjlXiygS8BgSg6S0RvFG8UH+pgPM 7kuOGwJbZFhHZcEvkATmpovIy+701LG5/iOtpFnaYjRPsXUI0sVXrjs0DzJjAHNfp57R 6Ib2SNGIDuGnFf+gQkUvq6JmyhGSJJdFkL984qOB9W9xlpdu8sJaoRGridvrQhmJNt6z S2k8v26qZS4LZ8FfL2FYw9RuohqYUremk0XLpU5mrR8M6SJpIZEsbhdaHFfqMTbT+dBM iE8PpaGmxQFTZNj4vYOgPtClx0mqMVF4s5yZb/pj/Sr1RuY3LHkcvyeGsEFTwk5b7q4I chpQ== MIME-Version: 1.0 X-Received: by 10.194.242.33 with SMTP id wn1mr7384071wjc.110.1412627201892; Mon, 06 Oct 2014 13:26:41 -0700 (PDT) Received: by 10.27.76.134 with HTTP; Mon, 6 Oct 2014 13:26:41 -0700 (PDT) Date: Mon, 6 Oct 2014 13:26:41 -0700 Message-ID: From: "Murray S. Kucherawy" To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=089e014942a091aac50504c6e645 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/ZLFPj7yGA4oxH1uo9J00uQeyk2c Subject: [dmarc-ietf] DMARC base draft expired X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 20:26:51 -0000 --089e014942a091aac50504c6e645 Content-Type: text/plain; charset=UTF-8 I know, I know. I've been sidetracked lately by $DAYJOB plus a big push to get the WEIRDS documents across the finish line and into Pete's hands. I expect to have a new version post-haircut out this week. Thanks to those who have sent suggestions, especially Stephen Turnbull and Eliot Lear. Once posted, after a short period to allow people to scream if I got it wrong, I'll notify the ISE that it's ready to go forward. -MSK --089e014942a091aac50504c6e645 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I know, I know.=C2=A0 I've been sidetracked = lately by $DAYJOB plus a big push to get the WEIRDS documents across the fi= nish line and into Pete's hands.

I expect to have a new ve= rsion post-haircut out this week.=C2=A0 Thanks to those who have sent sugge= stions, especially Stephen Turnbull and Eliot Lear.

Once = posted, after a short period to allow people to scream if I got it wrong, I= 'll notify the ISE that it's ready to go forward.

-MSK=
--089e014942a091aac50504c6e645-- From nobody Mon Oct 6 14:52:28 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 041EB1A8AB0 for ; Mon, 6 Oct 2014 14:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9D1YSo3LtZg for ; Mon, 6 Oct 2014 14:52:19 -0700 (PDT) Received: from mx10.mailtransaction.com (mx10.mailtransaction.com [88.198.59.241]) by ietfa.amsl.com (Postfix) with ESMTP id 4AFBA1A6F5B for ; Mon, 6 Oct 2014 14:52:18 -0700 (PDT) Received: from mx24.mailtransaction.com (mx21.mailtransaction.com [78.46.16.236]) by mx10.mailtransaction.com (Postfix) with ESMTP id 3jBbBS3gzwz5MhWg; Mon, 6 Oct 2014 23:52:16 +0200 (CEST) Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx24.mailtransaction.com (Postfix) with ESMTP id 3jBbBS261Vz1L8Tl; Mon, 6 Oct 2014 23:52:16 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id 927AC1233E0; Mon, 6 Oct 2014 23:52:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at sonnection.nl Received: from jaguar.sonnection.nl ([127.0.0.1]) by localhost (jaguar.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ZLA3Qx6XqeQy; Mon, 6 Oct 2014 23:52:12 +0200 (CEST) Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id 47EB712335C; Mon, 6 Oct 2014 23:52:12 +0200 (CEST) Message-ID: <54330F0A.10709@sonnection.nl> Date: Mon, 06 Oct 2014 23:52:10 +0200 From: "Rolf E. Sonneveld" Organization: Sonnection B.V. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: "Murray S. Kucherawy" , Tim Draegen References: <20140918134416.2051.qmail@joyce.lan> <541BABD0.10506@rolandturner.com> <87zjdvzzt1.fsf@uwakimon.sk.tsukuba.ac.jp> <541D67F0.5070800@tana.it> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020204070602070506050805" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1412632336; bh=i7clnw2qeA5iDx0l1Wqod7p5qY/CAKhQV//njBN3K6A=; h=Message-ID:Date:From:To:Subject:From; b=Ptt9UkOMctdI0Erhy6CSe+8qvFNSjEtKrF0UMi5hZYUoRnEPv3vE8+fHpw38vtkKt 9+IGxTBZ25v1OmsdbwZGYXtIViZE4TPfy7n4NvCs9F6h2wdkMIaS4goyO4D5vLma0j U88wJUwQionbVZbUPHeJAEBoQdvl1ocoAm7INY9w= DKIM-Filter: OpenDKIM Filter v2.8.2 mx10.mailtransaction.com 3jBbBS3gzwz5MhWg Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/7DYchJbgNpFUfVUj4qqqq_9hT1w Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Modeling MLM behavior X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: R.E.Sonneveld@sonnection.nl List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 21:52:26 -0000 This is a multi-part message in MIME format. --------------020204070602070506050805 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 10/06/2014 10:24 PM, Murray S. Kucherawy wrote: > On Fri, Oct 3, 2014 at 9:05 AM, Tim Draegen > wrote: > > On Sep 20, 2014, at 7:41 AM, Alessandro Vesely > wrote: > > IMHO, we should specify a credible MLM model, even if that can be > > slightly off topic for the WG, in order to maximize its > probability of > > being adopted. The rest of this message has some notes to this end. > > > Can I get some clarification on the intent here? As worded, this > paragraph suggests that we are looking to produce a model for MLMs to > follow in a DMARC-aware world. I was under the impression that (a) > this is a non-starter, and (b) we're not chartered to do so. I believe your impression is correct. Let's not start working on MLM's. /rolf --------------020204070602070506050805 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On 10/06/2014 10:24 PM, Murray S. Kucherawy wrote:
On Fri, Oct 3, 2014 at 9:05 AM, Tim Draegen <tim@eudaem= on.net> wrote:
On Sep 20, 2014, at 7:41 AM, Alessandro Vesely <v= esely@tana.it> wrote:
> IMHO, we should specify a credible MLM model, even if that can be
> slightly off topic for the WG, in order to maximize its probability of
> being adopted.=A0 The rest of this message has some notes to this end.

Can I get some clarification on the intent here?=A0 As worded, this paragraph suggests that we are looking to produce a model for MLMs to follow in a DMARC-aware world.=A0 I was under the impression that (a) this is a non-starter, and (b) we're not chartered to do so.

I=A0 believe your impression is correct. Let's not start working on MLM's.

/rolf

--------------020204070602070506050805-- From nobody Mon Oct 6 15:00:55 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D24681A032D for ; Mon, 6 Oct 2014 15:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.616 X-Spam-Level: X-Spam-Status: No, score=-1.616 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OiabLg-kjZma for ; Mon, 6 Oct 2014 15:00:50 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 934F91A6F3E for ; Mon, 6 Oct 2014 15:00:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1412618419; bh=Wz8DZMURgDNEihXH4vQZMyJ/qzmQxWXrbg58+jsWWw8=; l=623; h=Date:From:To:References:In-Reply-To; b=G4JYZaxS5b4rHrtK1a3izHTxOaSIFd8nMEjbgb09kq6xE/Q5z1yMpbrs+CRluMw/y cAMymi3Dn2KuANbJojABCjPeO4dle8CQeyfY/SRQvZyWdE9icszgJlDlvcOks/q/cC jb8FO8aKt9BCPguGt90oPxpBQY0LfI/oENYmVqXM= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.88] (pcale.tana [172.25.197.88]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Mon, 06 Oct 2014 20:00:19 +0200 id 00000000005DC035.000000005432D8B3.00003330 Message-ID: <5432D8B3.2070404@tana.it> Date: Mon, 06 Oct 2014 20:00:19 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <20140918134416.2051.qmail@joyce.lan> <541BABD0.10506@rolandturner.com> <87zjdvzzt1.fsf@uwakimon.sk.tsukuba.ac.jp> <541D67F0.5070800@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/ei2vWOuW678oia5OtlsK9qiscyE Subject: Re: [dmarc-ietf] Modeling MLM behavior X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 22:00:52 -0000 On Fri 03/Oct/2014 18:05:40 +0200 Tim Draegen wrote: > > The discussion of interoperability between DMARC and MLMs has > become opaque enough to warrant taking the time to document the > learning. I re-read Section 3.9 of RFC 5321 and it looks like current MLM behavior deviates considerably from the simple emulation of an MTA "as a continuation in email transit" which is envisaged there. While that was probably noted many times, I don't recall discussions on To: rewriting. Did we consider that? http://trac.tools.ietf.org/wg/dmarc/trac/wiki/MailingListModel Please feel free to change/comment Ale From nobody Mon Oct 6 16:16:01 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 580CD1A902E for ; Mon, 6 Oct 2014 16:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hOkzr7vbi_6x for ; Mon, 6 Oct 2014 16:15:51 -0700 (PDT) Received: from news.winserver.com (groups.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 42A3F1A8BBD for ; Mon, 6 Oct 2014 16:15:51 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=5149; t=1412637346; h=Received:Received: Message-Id:From:Subject:Date:To:Organization:List-ID; bh=haUDnYP UzpqV4Qy7s2gvVn4Sccc=; b=OenYSqtcD7f9ikn/vhtvYWQLZZFwr7QELTcWk7J GY6drTid4r/Fk6Il9roLKtGynQht+vWsgFkwiNIthVt+6JJ1s++rkJosM39GvUhP WCr4PEhbaJlkzo4Bl55eoeL4vqZuyB3hmI4x6WliqQwWym8/wJbxmrzRuY5rpPqd 2K80= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Mon, 06 Oct 2014 19:15:46 -0400 Received: from [192.168.1.221] (99-72-160-212.lightspeed.miamfl.sbcglobal.net [99.72.160.212]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3527416547.12383.5940; Mon, 06 Oct 2014 19:15:44 -0400 References: <20140918134416.2051.qmail@joyce.lan> <541BABD0.10506@rolandturner.com> <87zjdvzzt1.fsf@uwakimon.sk.tsukuba.ac.jp> <541D67F0.5070800@tana.it> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-AE5921A7-DF38-49AE-A156-D4712AB3C111 Content-Transfer-Encoding: 7bit Message-Id: <3556AB25-5376-48C3-A865-A99D23F946A3@isdg.net> X-Mailer: iPad Mail (12A405) From: Hector Santos Date: Mon, 6 Oct 2014 19:15:44 -0400 To: "Murray S. Kucherawy" Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/WMd8upCD5iQDpXpD4sNZ8maHykE Cc: "dmarc@ietf.org" , Tim Draegen Subject: Re: [dmarc-ietf] Modeling MLM behavior X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 23:15:58 -0000 --Apple-Mail-AE5921A7-DF38-49AE-A156-D4712AB3C111 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Murray, I think we need to make the distinction of two different concepts an= d acronyms; MLM "Mailing List Manager" and MLS "Mail List Servers" that serv= e the MLM market. There are some basic integration guidelines for both the M= LS and MLM. I understand we don't want to make any changes, but the front-e= nd, receivers, websites, i.e. Potential Entry Points, do need implementatio= n change considerations. I was able to minimize direct MLS changes to nil and added a few MLM operato= r features to existing operator configuration capabilities to fit into a DKI= M+ADSP+ATPS Mail I/O backend aware framework. I am waiting to do the DMARC p= lug and play, swap. The 2006 DSAP draft section 3.3 Mailing List Servers suggest some simple bas= ic concepts that I believe is near universal. But by 2009, the actual sugges= ted implementation changes were done outside the MLS component. See my poi= nt?=20 -- Hector Santos http://www.santronics.com > On Oct 6, 2014, at 4:24 PM, Murray S. Kucherawy wrot= e: >=20 >> On Fri, Oct 3, 2014 at 9:05 AM, Tim Draegen wrote: >> On Sep 20, 2014, at 7:41 AM, Alessandro Vesely wrote: >> > IMHO, we should specify a credible MLM model, even if that can be >> > slightly off topic for the WG, in order to maximize its probability of >> > being adopted. The rest of this message has some notes to this end. >=20 > Can I get some clarification on the intent here? As worded, this paragrap= h suggests that we are looking to produce a model for MLMs to follow in a DM= ARC-aware world. I was under the impression that (a) this is a non-starter,= and (b) we're not chartered to do so. >=20 > -MSK >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc --Apple-Mail-AE5921A7-DF38-49AE-A156-D4712AB3C111 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Murray, I think we need to make the di= stinction of two different concepts and acronyms; MLM "Mailing List Manager"= and MLS "Mail List Servers" that serve the MLM market.  There are some= basic integration guidelines for both the MLS and MLM.  I understand w= e don't want to make any changes, but the front-end, receivers, websites, i.= e.  Potential Entry Points, do need implementation change consideration= s.

I was able to minimize direct MLS changes to nil= and added a few MLM operator features to existing operator configuration ca= pabilities to fit into a DKIM+ADSP+ATPS Mail I/O backend aware framework. &n= bsp;I am waiting to do the DMARC plug and play, swap.

The 2006 DSAP draft section 3.3 Mailing List Servers suggest some simple b= asic concepts that I believe is near universal. But by 2009, the actual sugg= ested implementation changes were done outside the MLS component.   See= my point? 

On= Oct 6, 2014, at 4:24 PM, Murray S. Kucherawy <superuser@gmail.com> wrote:

= --Apple-Mail-AE5921A7-DF38-49AE-A156-D4712AB3C111-- From nobody Mon Oct 6 16:54:45 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A64051A013B for ; Mon, 6 Oct 2014 16:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGK6oNLXGYj1 for ; Mon, 6 Oct 2014 16:54:40 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55CF81A90C6 for ; Mon, 6 Oct 2014 16:54:40 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id hi2so6253237wib.8 for ; Mon, 06 Oct 2014 16:54:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=f0u4agMxY3RBBNJS2HzwRqlWQmtBbz6UcHXztxhDBUc=; b=iSe7WdqMp/jo1tzlKGhhGHnwEbAf6BQu3mGxkWdFvxNCWVVO+HmJIN1pjWS37jFA7L n69zmdaHNiL5ruT2v4SX6jtvXlKYfxGrE0YTvirb29jctEqY2QEF2d0eOm6DsnZq5UZg dSCY4rNNraiXga64xUsAKBy9pUWWzHf6SmXewS8bs2AtYjXbHGi5+hPb/7H7ppaM642i rHN51kLZ2jCJAhJ1RT0uRMkpYNGWHa/Bm587HIcz8VJpyzMvceGJAbLxftONKw3sm1PF kMmLm3XgwhrbI+NVzFyZWLvlFS/7ApMgdnzU4vlKcKp5RDUq9sh0ovY+MVWw7Oiium9H OEHQ== MIME-Version: 1.0 X-Received: by 10.180.10.38 with SMTP id f6mr144382wib.30.1412639679006; Mon, 06 Oct 2014 16:54:39 -0700 (PDT) Received: by 10.27.76.134 with HTTP; Mon, 6 Oct 2014 16:54:38 -0700 (PDT) In-Reply-To: <54330F0A.10709@sonnection.nl> References: <20140918134416.2051.qmail@joyce.lan> <541BABD0.10506@rolandturner.com> <87zjdvzzt1.fsf@uwakimon.sk.tsukuba.ac.jp> <541D67F0.5070800@tana.it> <54330F0A.10709@sonnection.nl> Date: Mon, 6 Oct 2014 16:54:38 -0700 Message-ID: From: "Murray S. Kucherawy" To: "" Content-Type: multipart/alternative; boundary=001a11c25d084350f70504c9cee0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/0HqT1Abde-EN2PUcv9b8wQfNANI Cc: "dmarc@ietf.org" , Tim Draegen Subject: Re: [dmarc-ietf] Modeling MLM behavior X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 23:54:42 -0000 --001a11c25d084350f70504c9cee0 Content-Type: text/plain; charset=UTF-8 On Mon, Oct 6, 2014 at 2:52 PM, Rolf E. Sonneveld < R.E.Sonneveld@sonnection.nl> wrote: > > Can I get some clarification on the intent here? As worded, this > paragraph suggests that we are looking to produce a model for MLMs to > follow in a DMARC-aware world. I was under the impression that (a) this is > a non-starter, and (b) we're not chartered to do so. > > > I believe your impression is correct. Let's not start working on MLM's. > Just to be clear, I think cataloging MLM interactions and all that stuff is potentially quite useful, but the suggestion was to "specify a credible MLM model" which to me sounds like we're going to propose something we have no business proposing; we're not chartered to do so, and history suggests there will be aggressive objection to any such effort even if we were. -MSK --001a11c25d084350f70504c9cee0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Oct 6, 2014 at 2:52 PM, Rolf E. Sonneveld <R.E.Sonneveld@sonnection.nl> wrote:
=20 =20 =20

Can I get some clarification on the intent here?=C2= =A0 As worded, this paragraph suggests that we are looking to produce a model for MLMs to follow in a DMARC-aware world.=C2=A0 I was under the impression that (a) this is a non-starter, and (b) we're not chartered to do so.

I=C2=A0 believe your impression is correct. Let's not start working= on MLM's.

Just to be clear, = I think cataloging MLM interactions and all that stuff is potentially quite= useful, but the suggestion was to "specify a credible MLM model"= which to me sounds like we're going to propose something we have no bu= siness proposing; we're not chartered to do so, and history suggests th= ere will be aggressive objection to any such effort even if we were.
<= div>
-MSK
--001a11c25d084350f70504c9cee0-- From nobody Mon Oct 6 17:03:54 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD4B1A90E0 for ; Mon, 6 Oct 2014 17:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qc7Bsr-gSJjQ for ; Mon, 6 Oct 2014 17:03:47 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EA821A90CD for ; Mon, 6 Oct 2014 17:03:47 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id m15so7951740wgh.14 for ; Mon, 06 Oct 2014 17:03:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=A1lWJO8SAUL9bg91sPalLJCm3GV578dx2QJCYRXvAqM=; b=uBs2wGyPxNHoxPTs/jwQLg7nAym8LmB7drCF6dcKWu+M7gMcoOSdbZMi/aUvA/5cXj egmIcdMyWhkqK9txxBGRuUiECGzFSJh1Uv9VzqVf9b13FdRcdmGJT5zeYuWv8Tlsw4W3 eNJljVwp0F2zt9toaYyGbjbi77uco5kwTEi7mt03JZHHQX2qEKtPxiY2gRewfsLBOKMA Q7LISa8ME79apc4NiwDedLltJaX3Ww8BJ58cfHVupeGZCDxZLiHirQ7BmwZP/jN0zYiC qrKCXf1h0E8D/53lDqxAClzoD06RxAvJUEmWepwaWBn425QCWXPot8qTal19A5BKFkQR 5XbQ== MIME-Version: 1.0 X-Received: by 10.180.86.73 with SMTP id n9mr23066122wiz.30.1412640225625; Mon, 06 Oct 2014 17:03:45 -0700 (PDT) Received: by 10.27.76.134 with HTTP; Mon, 6 Oct 2014 17:03:45 -0700 (PDT) In-Reply-To: <3556AB25-5376-48C3-A865-A99D23F946A3@isdg.net> References: <20140918134416.2051.qmail@joyce.lan> <541BABD0.10506@rolandturner.com> <87zjdvzzt1.fsf@uwakimon.sk.tsukuba.ac.jp> <541D67F0.5070800@tana.it> <3556AB25-5376-48C3-A865-A99D23F946A3@isdg.net> Date: Mon, 6 Oct 2014 17:03:45 -0700 Message-ID: From: "Murray S. Kucherawy" To: Hector Santos Content-Type: multipart/alternative; boundary=f46d0442806ed80d890504c9ee9b Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Ny3SVPB-uE3tzKdzxNId2KYbV5o Cc: "dmarc@ietf.org" , Tim Draegen Subject: Re: [dmarc-ietf] Modeling MLM behavior X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 00:03:51 -0000 --f46d0442806ed80d890504c9ee9b Content-Type: text/plain; charset=UTF-8 On Mon, Oct 6, 2014 at 4:15 PM, Hector Santos wrote: > Murray, I think we need to make the distinction of two different concepts > and acronyms; MLM "Mailing List Manager" and MLS "Mail List Servers" that > serve the MLM market. There are some basic integration guidelines for both > the MLS and MLM. I understand we don't want to make any changes, but the > front-end, receivers, websites, i.e. Potential Entry Points, do need > implementation change considerations. > [...] > I think this is unrelated to my point. It's my understanding that the idea of altering DMARC to better work with mailing lists is on the table, though later in our list of milestones. The idea of specifying how MLMs (or MLSes, or whatever) should operate in a DMARC world, however, is not. I just don't want any of us operating under the illusion that we can prescribe how extant MLMs need to change now that DMARC is in use if in fact we can't. There's obviously a lot of energy to be wasted in that direction. -MSK --f46d0442806ed80d890504c9ee9b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Oct 6, 2014 at 4:15 PM, Hector Santos <hsantos@isd= g.net> wrote:
Murray, I t= hink we need to make the distinction of two different concepts and acronyms= ; MLM "Mailing List Manager" and MLS "Mail List Servers"= ; that serve the MLM market.=C2=A0 There are some basic integration guideli= nes for both the MLS and MLM.=C2=A0 I understand we don't want to make = any changes, but the front-end, receivers, websites, i.e.=C2=A0 Potential E= ntry Points, do need implementation change considerations.
[...]<= br>

I think th= is is unrelated to my point.

It's my understanding that the idea= of altering DMARC to better work with mailing lists is on the table, thoug= h later in our list of milestones.=C2=A0 The idea of specifying how MLMs (o= r MLSes, or whatever) should operate in a DMARC world, however, is not.
=
I just don't want any of us operat= ing under the illusion that we can prescribe how extant MLMs need to change= now that DMARC is in use if in fact we can't.=C2=A0 There's obviou= sly a lot of energy to be wasted in that direction.

-MSK
--f46d0442806ed80d890504c9ee9b-- From nobody Mon Oct 6 19:29:11 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B31B81A9118 for ; Mon, 6 Oct 2014 19:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Brirr_fDtK3q for ; Mon, 6 Oct 2014 19:29:08 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id DBB4E1A9117 for ; Mon, 6 Oct 2014 19:29:07 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id 20F7F1C390A; Tue, 7 Oct 2014 11:29:05 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 127F81A2888; Tue, 7 Oct 2014 11:29:05 +0900 (JST) From: "Stephen J. Turnbull" To: Hector Santos In-Reply-To: <3556AB25-5376-48C3-A865-A99D23F946A3@isdg.net> References: <20140918134416.2051.qmail@joyce.lan> <541BABD0.10506@rolandturner.com> <87zjdvzzt1.fsf@uwakimon.sk.tsukuba.ac.jp> <541D67F0.5070800@tana.it> <3556AB25-5376-48C3-A865-A99D23F946A3@isdg.net> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Tue, 07 Oct 2014 11:29:04 +0900 Message-ID: <87k34csjdb.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/5kXm9Pf6Z8Pgdac39On4uIkQe5c Cc: Tim Draegen , "dmarc@ietf.org" , "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] Modeling MLM behavior X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 02:29:09 -0000 Hector Santos writes: > The 2006 DSAP draft section 3.3 Mailing List Servers suggest some > simple basic concepts that I believe is near universal. URL, please. I never heard of this concept before. To this MLM developer, your heavily abbreviated description doesn't make the utility of the concept clear, but I suppose the original document explains in more detail. > But by 2009, the actual suggested implementation changes were done > outside the MLS component. See my point? Nope. Need context. From nobody Tue Oct 7 04:57:29 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC85D1A1B84 for ; Tue, 7 Oct 2014 04:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.024 X-Spam-Level: X-Spam-Status: No, score=-99.024 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_46=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbAd33a8T_DE for ; Tue, 7 Oct 2014 04:57:25 -0700 (PDT) Received: from mail.winserver.com (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id EAAD41A1B81 for ; Tue, 7 Oct 2014 04:57:24 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4702; t=1412683038; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=aLEBA/C6xXZljF2akGsKRU2oIPI=; b=qP32FZV0tIsjcBf9or8Q io58lLPgDoaA7aho0FhqK5U8zGPKzbjK4rAIohTdJajOhErzMhxbOD/lDOXJLR1C vVNrY4aTbq9yqZIief8l/M0sdtq2RVV5a5+oR1d2BkgUUqCpuwVuEBfu9JlRUzNF 6O013lKuLmb+v7734QOrMBw= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 07 Oct 2014 07:57:18 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3573108772.13578.5732; Tue, 07 Oct 2014 07:57:17 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4702; t=1412682655; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=Dvw8xiJ jiwTFNeFSr5rEScP0SPRJx9FA6/ulnnqJq2A=; b=amrEMsReAgqvOZZ3juycHO7 jUXA6Jd9ci2h4wXO9qxSFFZZKv3SiyzN+9jUtn2djFtFIjuiLi1LDh24zGx8FIEp jlCOdztU/Fr1nHFFr2UHnFAYNee4945bY3yetgWbY20pIZGmA2a0jhAAk4qBJ+ly uUauTCOYV+LDFFm0FQyA= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 07 Oct 2014 07:50:55 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2165535141.9.5052; Tue, 07 Oct 2014 07:50:54 -0400 Message-ID: <5433D519.5060405@isdg.net> Date: Tue, 07 Oct 2014 07:57:13 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Stephen J. Turnbull" References: <20140918134416.2051.qmail@joyce.lan> <541BABD0.10506@rolandturner.com> <87zjdvzzt1.fsf@uwakimon.sk.tsukuba.ac.jp> <541D67F0.5070800@tana.it> <3556AB25-5376-48C3-A865-A99D23F946A3@isdg.net> <87k34csjdb.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87k34csjdb.fsf@uwakimon.sk.tsukuba.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/3L1aezqSkIW0BskiO74y8u41O5c Cc: "dmarc@ietf.org" , Tim Draegen , "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] Modeling MLM behavior X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 11:57:28 -0000 Hi Stephen, The 2006 DSAP "DKIM Signature Authorization Protocol" draft concentrated on the process boundary conditions (possible values for 1st and 3rd party conditions). Section 4.2 summaries the boundary conditions: http://tools.ietf.org/html/draft-santos-dkim-dsap-00#section-4.2 4.2. DSAP Tags: op=; 3p=; From the viewpoint of the verifier, when a message is received, there are two basic pieces of signature information to be of interest when analyzing the transaction: o Original Party Signatures (OP) * never expected * always expected * optional o 3rd Party Signatures (3P) * never expected * always expected * optional When the two signature types are combines, the possible policies are listed in this following table: +=================================================================+ | op= | 3p= | Domain Policy Semantics | |=================================================================| | empty | empty | No mail expected | |-----------------------------------------------------------------| | never | never | No signing expected | | never | always | Only 3P signing expected | | never | optional | Only 3P signing optional | |-----------------------------------------------------------------| | always | never | OP signature expected | | always | always | Both parties expected | | always | optional | OP expected, 3P may sign | |-----------------------------------------------------------------| | optional | never | Only OP signing expected | | optional | always | OP expected, 3P expected | | optional | optional | Both parties may sign. | +-----------------------------------------------------------------+ Figure 4: DSAP Message Signing Policies Section 3.3 basically provided some simple guidelines for a MLS: http://tools.ietf.org/html/draft-santos-dkim-dsap-00#section-3.3 The term DMARC can be swapped in the section since its really about a general DKIM+POLICY and it doesn't matter if it was SSP, ADSP, DSAP or DMARC: 3.3. Mailing List Servers Mailing List Servers (MLS) applications who are compliant with DKIM and DMARC operations, SHOULD adhere to the following guidelines: Subscription Controls MLS subscription processes should perform a DMARC check to determine if a subscribing email domain DMARC policy is restrictive in regards to mail integrity changes or 3rd party signatures. The MLS SHOULD only allow original domain policies who allow 3rd party signatures. Message Content Integrity Change List Servers which will alter the message content SHOULD only do so for original domains with optional DMARC signing practices and it should remove the original signature if present. If the List Server is not going to alter the message, it SHOULD NOT remove the signature, if present. However, the same issues of integrity changes was apparent then as it is now. The only way to minimize the impact is to first support it and only deal with the optional policies. In other words, allow the YAHOO's to change their policies to FIT a proper end to end protocol (that means DMARC MUST offer 3rd party policies) that does include and allow the MLS to fit in -- PROPERLY without all this hacking and "ignore DMARC" and 5322.From destruction mentality going on that is only going to work with selected groups or systems, if that, leaving a security hole for the rest of the world to deal with. Keep in mind that as much as DKIM wishes to separate the AUTHOR from the SIGNER domain, it can not. It is BURNED into the spec as the single most important binding requirement -- That means it can't change and thats the purpose of this *security* concept. Breaking it and assuming the original domains will allow this to occur unchallenged is not a good idea, playing with fire. Have a good day Stephen -- Hector Santos http://www.santronics.com On 10/6/2014 10:29 PM, Stephen J. Turnbull wrote: > Hector Santos writes: > > > The 2006 DSAP draft section 3.3 Mailing List Servers suggest some > > simple basic concepts that I believe is near universal. > > URL, please. I never heard of this concept before. To this MLM > developer, your heavily abbreviated description doesn't make the > utility of the concept clear, but I suppose the original document > explains in more detail. > > > But by 2009, the actual suggested implementation changes were done > > outside the MLS component. See my point? > > Nope. Need context. > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > From nobody Tue Oct 7 05:17:50 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32F5E1A1B8E for ; Tue, 7 Oct 2014 05:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.488 X-Spam-Level: X-Spam-Status: No, score=-100.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72g1vI1gB0Bl for ; Tue, 7 Oct 2014 05:17:48 -0700 (PDT) Received: from mail.winserver.com (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id D0CD11A1BAA for ; Tue, 7 Oct 2014 05:17:14 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2217; t=1412684228; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=1MqzUwQw2mweNAdngARz5xZdDow=; b=OhTU+QAebm2tFW6dv05j Yt9i9sIfTR2QEd3ZfC7kBvvbBP+ozvyHAMMbMOBtDk2v+FrQivSOnpf2PapCC7Qh 8LkdxWxDPxRiqgBJRokq7k3rt6jNIQjhOtQs/oDxo0XqlE6AHoBbALGJ3t6smfxH QpZuRAvEWnkWzEt9N4CRg1E= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 07 Oct 2014 08:17:08 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3574299122.13578.2104; Tue, 07 Oct 2014 08:17:07 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2217; t=1412683848; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=5zPQVgf V+7YahDAraF+4JQe2Ig8hM4TC/RtdOJbJHqs=; b=aN0Sv4X4GLY9LN/K0X0xbzW guYE7lxr4uPs2T8fYVTioCPH+mxutJtRFlfadOc8JyZq0a5vMsfPyOz9HVMiM6d7 Vbf1/5kO86EAOUJvCM2VOEvBLgCJ+ItHinKVoC/K9HSINAswgMLSAa5TrTEzDAXp KEH91Grzs2nXO9hGBL9U= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 07 Oct 2014 08:10:48 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2166728282.9.3532; Tue, 07 Oct 2014 08:10:47 -0400 Message-ID: <5433D9C2.1010403@isdg.net> Date: Tue, 07 Oct 2014 08:17:06 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <20140918134416.2051.qmail@joyce.lan> <541BABD0.10506@rolandturner.com> <87zjdvzzt1.fsf@uwakimon.sk.tsukuba.ac.jp> <541D67F0.5070800@tana.it> <3556AB25-5376-48C3-A865-A99D23F946A3@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/aQOdkdPDm0BfJzUikmZa7ZofNr0 Cc: Tim Draegen , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Modeling MLM behavior X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 12:17:49 -0000 But I am a commercial MLS producer and there are some considerations when you integrate it into the mail system. I think we covered most of the concepts over the years. But it is just lost in tons of verbiage and repeating it is just going to be as confusing. I suggest to summarize it in a technical summary and can get begin with a basic idea: MLS/MLM (entry points) SHOULD honor DMARC policies by controlling the subscription and submission process of restrictive domains. This is how we begin to minimize the impact. I think it will be a mistake to assume domains who will invest into DMARC will accept the idea of "Security Holes" existing at certain MLM setups. What I won't do is add the built-in out of the box MLS capability to satisfy this limited MLM and short term desire of rewriting 5322.From lines. It will have to be totally binding with original domain permission to do so that all downlinks can verify. But then we will have a backward compatibility loophole. Thanks Murray. Have a good day. -- Hector Santos http://www.santronics.com On 10/6/2014 8:03 PM, Murray S. Kucherawy wrote: > On Mon, Oct 6, 2014 at 4:15 PM, Hector Santos wrote: > >> Murray, I think we need to make the distinction of two different concepts >> and acronyms; MLM "Mailing List Manager" and MLS "Mail List Servers" that >> serve the MLM market. There are some basic integration guidelines for both >> the MLS and MLM. I understand we don't want to make any changes, but the >> front-end, receivers, websites, i.e. Potential Entry Points, do need >> implementation change considerations. >> [...] >> > > I think this is unrelated to my point. > > It's my understanding that the idea of altering DMARC to better work with > mailing lists is on the table, though later in our list of milestones. The > idea of specifying how MLMs (or MLSes, or whatever) should operate in a > DMARC world, however, is not. > > I just don't want any of us operating under the illusion that we can > prescribe how extant MLMs need to change now that DMARC is in use if in > fact we can't. There's obviously a lot of energy to be wasted in that > direction. > > -MSK From nobody Tue Oct 7 09:53:49 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60C441ACE71 for ; Tue, 7 Oct 2014 09:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iuyRma7mW3Tb for ; Tue, 7 Oct 2014 09:53:40 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 4DCBF1ACE6E for ; Tue, 7 Oct 2014 09:53:39 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id A727B1C38FA; Wed, 8 Oct 2014 01:53:38 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 993831A2888; Wed, 8 Oct 2014 01:53:38 +0900 (JST) From: "Stephen J. Turnbull" To: Hector Santos In-Reply-To: <5433D9C2.1010403@isdg.net> References: <20140918134416.2051.qmail@joyce.lan> <541BABD0.10506@rolandturner.com> <87zjdvzzt1.fsf@uwakimon.sk.tsukuba.ac.jp> <541D67F0.5070800@tana.it> <3556AB25-5376-48C3-A865-A99D23F946A3@isdg.net> <5433D9C2.1010403@isdg.net> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 08 Oct 2014 01:53:38 +0900 Message-ID: <877g0bstwt.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/LFNIsmKhkrHOdWZ7BiI5KIYuW3M Cc: "dmarc@ietf.org" , Tim Draegen , "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] Modeling MLM behavior X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 16:53:43 -0000 Hector Santos writes: > I suggest to summarize it in a technical summary and can get begin > with a basic idea: > > MLS/MLM (entry points) SHOULD honor DMARC policies by controlling > the subscription This is technologically infeasible. DMARC provides no guidance from the Domain Owner about what mailboxes are allowed to receive, so the DMARC policy record provides no guidance about subscription to mailing lists. > and submission process of restrictive domains. I think I'll just say no, at least for poster/subscriber combinations where the subscribers want to see the poster's messages. I really don't see why I should devote resources to this, as long as this protocol is available to be abused by Domain Owners who are unwilling to impose appropriate terms of service on their users so that it is absolutely clear that the Domain Owner forbids posting to my lists. (I want to cite the ToS in my rejection notice.) If this means that some spoofed transactional mail might get through my content filters and distributed to the list, I'm willing to take that risk. My filters are pretty good so far. From nobody Tue Oct 7 10:50:06 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 992AF1A7011 for ; Tue, 7 Oct 2014 10:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.009 X-Spam-Level: ** X-Spam-Status: No, score=2.009 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVRgTz6EkHzZ for ; Tue, 7 Oct 2014 10:49:58 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3541A0095 for ; Tue, 7 Oct 2014 10:49:58 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id 4BE8A1C3926; Wed, 8 Oct 2014 02:49:57 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 3C9271A2888; Wed, 8 Oct 2014 02:49:57 +0900 (JST) From: "Stephen J. Turnbull" To: Hector Santos In-Reply-To: <5433D519.5060405@isdg.net> References: <20140918134416.2051.qmail@joyce.lan> <541BABD0.10506@rolandturner.com> <87zjdvzzt1.fsf@uwakimon.sk.tsukuba.ac.jp> <541D67F0.5070800@tana.it> <3556AB25-5376-48C3-A865-A99D23F946A3@isdg.net> <87k34csjdb.fsf@uwakimon.sk.tsukuba.ac.jp> <5433D519.5060405@isdg.net> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 08 Oct 2014 02:49:57 +0900 Message-ID: <8761fvsray.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/W5B3m-0qbYQcWRGMuulxJeYXegE Cc: Tim Draegen , "dmarc@ietf.org" , "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] Modeling MLM behavior X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 17:50:00 -0000 Hector Santos writes: > http://tools.ietf.org/html/draft-santos-dkim-dsap-00#section-4.2 Thank you for the URL. In the following, I do not mean to discuss the concrete proposal as if it were WG business (I don't believe it is). I'm trying to understand what model of Internet mail system behavior is presumed, which I believe is WG business, as it is essential to framing BCPs and new protocols to improve security. > o Original Party Signatures (OP) > > * never expected > * always expected > * optional I don't understand the differentation between 'optional' and 'never' here in terms of real mail system behavior. What would the interpretation of a valid DKIM signature satisfying identity alignment? That's not a question about the spec (I can and will read the spec). The point is that in practice lots of admins do not read the spec, and even those who do often provide some heuristic interpretation rather than follow it precisely. I doubt the answers would be consistent with each other or with the spec. That sounds like trouble to me. We should prefer conceptualizations that are crisp and intuitive to non-IETF-ers. > o 3rd Party Signatures (3P) > > * never expected > * always expected > * optional Again, I don't understand the semantics of "expected" here, and they're quite different from the semantics of the same values for OP. Some 3rd parties will sign, others won't. What key do they sign with? Some will be authorized 3PS, some won't. etc. etc. I don't see how this three-valued parameter can possibly be a good fit for most "naive" admins' mental models, or for what they want the system to do. > Subscription Controls As I explain in more detail elsewhere, no policy framework I've seen can justify subscription controls. Overall, I get the impression that your mental model of email is framed almost entirely by the corporate transactional mail use case, where the employer can and does forbid "personal" and "indirect" use of mailboxes in the corporate domain. That's an important use case, but your proposals leave little room for reliable and convenient service to other use cases. Rather, they arrogate all policy decisions to Domain Owners, which will surely be a bottleneck for small organizations running mailing lists and new entrants wishing to develop new 3rd party email services. Such services will want to mitigate (ie, non-conforming behavior to avoid validation failure). You threaten non-conforming services with > thats the purpose of this *security* concept. Breaking it and > assuming the original domains will allow this to occur unchallenged > is not a good idea, playing with fire. but in practice it seems to me that the restrictions and inconvenience involved in conforming to your proposals is already everything those "original domains" can use to threaten mailing lists, and quite restrictive (at least) for other 3rd party services! In any case, Google and several MTA vendors were already providing relaxed implementations combining DMARC policy information with other metadata and content analysis in making acceptance decisions. Yahoo! and AOL quite obviously *want* the "security broken" (they thank us for doing exactly what you describe as "playing with fire"). Aren't they "original domains"? If they are, the "original domains" are going to have to sort things out among themselves to get a coherent protocol. If they aren't, aren't *they* the problem, not the 3rd party services who are only doing what their clients and their clients' domain owners want done? That is, shouldn't you advocates of full OP control figure out how to arrange that your protocol doesn't get hijacked by domains that permit unregulated use of 3rd party services by mailbox users? Steve From nobody Tue Oct 7 13:41:11 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7E81A8859 for ; Tue, 7 Oct 2014 13:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q11hZYV_C95v for ; Tue, 7 Oct 2014 13:41:08 -0700 (PDT) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 789281A8846 for ; Tue, 7 Oct 2014 13:41:08 -0700 (PDT) Received: from [10.0.1.119] (97-82-216-27.dhcp.hckr.nc.charter.com [97.82.216.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id DE10ACB46; Tue, 7 Oct 2014 16:41:07 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_B1D75015-C91D-4B17-A07A-E009BE2BE2D3" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Tim Draegen In-Reply-To: Date: Tue, 7 Oct 2014 16:41:05 -0400 Message-Id: References: <20140918134416.2051.qmail@joyce.lan> <541BABD0.10506@rolandturner.com> <87zjdvzzt1.fsf@uwakimon.sk.tsukuba.ac.jp> <541D67F0.5070800@tana.it> To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/XU3yrYkaEah1yOB8wi4Dt4YfOjc Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Modeling MLM behavior X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 20:41:10 -0000 --Apple-Mail=_B1D75015-C91D-4B17-A07A-E009BE2BE2D3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 6, 2014, at 4:24 PM, Murray S. Kucherawy = wrote: > On Fri, Oct 3, 2014 at 9:05 AM, Tim Draegen wrote: > On Sep 20, 2014, at 7:41 AM, Alessandro Vesely wrote: > > IMHO, we should specify a credible MLM model, even if that can be > > slightly off topic for the WG, in order to maximize its probability = of > > being adopted. The rest of this message has some notes to this end. >=20 > Can I get some clarification on the intent here? As worded, this = paragraph suggests that we are looking to produce a model for MLMs to = follow in a DMARC-aware world. I was under the impression that (a) this = is a non-starter, and (b) we're not chartered to do so. Sorry to inject confusion and not immediately follow up. The intention is to have something in place -- the MLM model -- that can = be used to quickly identify issues that are related to DMARC = interoperability with any given piece of MLM software. I read = Alessandro's model as a way to generically describe MLMs, which would = make comparing and contrasting of MLMs a lot easier. IOW, fleshing out a matrix of interoperability issues with respect to = MLMs is made easier (possible?) if we have a generic way to describe MLM = behavior. This is not meant to be a robust exercise in crafting the = ideal MLM. If something like this is NOT in place, my concern is that the WG will = only look at the big MLM packages. If the WG does not spend time = collecting input, the WG will not be able to make informed decisions = regarding solutions. =3D- Tim --Apple-Mail=_B1D75015-C91D-4B17-A07A-E009BE2BE2D3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Oct = 6, 2014, at 4:24 PM, Murray S. Kucherawy <superuser@gmail.com> = wrote:
On Fri, Oct 3, = 2014 at 9:05 AM, Tim Draegen <tim@eudaemon.net> wrote:
On Sep 20, 2014, at 7:41 AM, Alessandro Vesely <vesely@tana.it> wrote:
> IMHO, we should specify a credible MLM model, even if that can = be
> slightly off topic for the WG, in order to maximize its probability = of
> being adopted.  The rest of this message has some notes to = this end.

Can I get some = clarification on the intent here?  As worded, this paragraph = suggests that we are looking to produce a model for MLMs to follow in a = DMARC-aware world.  I was under the impression that (a) this is a = non-starter, and (b) we're not chartered to do = so.

Sorry to inject = confusion and not immediately follow up.

The = intention is to have something in place -- the MLM model -- that can be = used to quickly identify issues that are related to DMARC = interoperability with any given piece of MLM software.  I read = Alessandro's model as a way to generically describe MLMs, which would = make comparing and contrasting of MLMs a lot = easier.

IOW, fleshing out a matrix of = interoperability issues with respect to MLMs is made easier (possible?) = if we have a generic way to describe MLM behavior.  This is not = meant to be a robust exercise in crafting the ideal = MLM.

If something like this is NOT in place, my = concern is that the WG will only look at the big MLM packages.  If = the WG does not spend time collecting input, the WG will not be able to = make informed decisions regarding solutions.

=3D-= Tim

= --Apple-Mail=_B1D75015-C91D-4B17-A07A-E009BE2BE2D3-- From nobody Tue Oct 7 14:23:11 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D9F21A8862 for ; Tue, 7 Oct 2014 14:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3B_OTh0VR_NO for ; Tue, 7 Oct 2014 14:23:07 -0700 (PDT) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 26C361A0231 for ; Tue, 7 Oct 2014 14:23:07 -0700 (PDT) Received: from [10.0.1.119] (97-82-216-27.dhcp.hckr.nc.charter.com [97.82.216.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id E726CCB46; Tue, 7 Oct 2014 17:23:06 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Tim Draegen In-Reply-To: <87k34gtsam.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Tue, 7 Oct 2014 17:23:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2A17AAF4-80E3-40BD-A0D1-21D3CCA305D6@eudaemon.net> References: <542ED11B.5040405@dcrocker.net> <87k34gtsam.fsf@uwakimon.sk.tsukuba.ac.jp> To: "Stephen J. Turnbull" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/HU1N7JTkREkQliDNLOcZ-gsQ7Es Cc: dmarc@ietf.org, dcrocker@bbiw.net Subject: Re: [dmarc-ietf] documenting x-original-from usage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 21:23:09 -0000 On Oct 3, 2014, at 11:41 PM, Stephen J. Turnbull = wrote: > Dave Crocker writes: >=20 >> Along an entirely different line of analysis, note that Original-=46rom= is >> merely adding complexity to the 'who was the author of this message' >> assessment, very possibly creating yet-another security hole. >=20 > Messrs Chairguys, >=20 > Inquiring Minds Question a Point of Order: doesn't this kind of > comment belong on the wiki page, now that it's been created? >=20 > Feeling-guilty-about-own-too-long-threads-so-really-wanna-know-ly = y'rs, Yes, it does. I've added it to the wiki, 'cause it would have taken = longer to ask Dave to do it. WORDS OF ENCOURAGEMENT FOR THIS WG: Everybody should feel free to add to the wiki. If a long discussion = thread doesn't end up creating wiki content for newcomers, whatever = nuggets of wisdom are shared will remain buried. IMO that's no good, = 'cause there is deep and varied expertise in this WG already, but it's = very difficult to get at it (and therefore for a newcomer to figure out = where their own expertise fits in). =3D- Tim From nobody Tue Oct 7 14:38:47 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBBC1A8887 for ; Tue, 7 Oct 2014 14:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6pGrJ1YRA9Z for ; Tue, 7 Oct 2014 14:38:43 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 681741A8863 for ; Tue, 7 Oct 2014 14:38:43 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s97LcaIF017040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 7 Oct 2014 14:38:40 -0700 Message-ID: <54345D57.3000808@dcrocker.net> Date: Tue, 07 Oct 2014 14:38:31 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Tim Draegen , "Stephen J. Turnbull" References: <542ED11B.5040405@dcrocker.net> <87k34gtsam.fsf@uwakimon.sk.tsukuba.ac.jp> <2A17AAF4-80E3-40BD-A0D1-21D3CCA305D6@eudaemon.net> In-Reply-To: <2A17AAF4-80E3-40BD-A0D1-21D3CCA305D6@eudaemon.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 07 Oct 2014 14:38:40 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/-logftdLGdNhJx2AlRhTZVRH968 Cc: dmarc@ietf.org, dcrocker@bbiw.net Subject: Re: [dmarc-ietf] documenting x-original-from usage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 21:38:44 -0000 On 10/7/2014 2:23 PM, Tim Draegen wrote: > 'cause it would have taken longer to ask Dave to do it minutes vs. infinity, most probably. so yeah and thanks. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Oct 7 14:39:46 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10FF01A02D7 for ; Tue, 7 Oct 2014 14:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Osc80xjqqRi9 for ; Tue, 7 Oct 2014 14:39:43 -0700 (PDT) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 953461A0100 for ; Tue, 7 Oct 2014 14:39:43 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id hy4so5734784vcb.0 for ; Tue, 07 Oct 2014 14:39:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mhD3ec/32H1cn3QbjtI8nepcYkDmNaJB5BHd1la3yaY=; b=NDResnABzw+1HQpIHftv/0CF0k28Cco9A6ebRz8cBbz6IpxodX7KNVGX36zknLd5UZ 7JOyWzb21b/18P6ci0/p6zYpLBOGFhHqWq6jqMWXJizijpAOLI6oi4YasEdW9MR2ZwC1 8zLDZXDjR2EmQQPvMVOFr4Og1FvYDzUgbC4/vgBcuXsUZgiGjRiJQ7KB0iTrQrX02H5I Fdl3OiNeHBr3kOsius+zyOXg5TV4oDfaglZ0JxNGwCdANNEvJhHxnUbbnQrqXoZ+SLSr nZq8cXECgcbLOJzvw0KUo2hJnbWCYZyVlwrL3ih9F/adr4AlAq3oIBls+bM//2Vzsbek Fdow== MIME-Version: 1.0 X-Received: by 10.52.227.39 with SMTP id rx7mr4976484vdc.13.1412717982560; Tue, 07 Oct 2014 14:39:42 -0700 (PDT) Received: by 10.52.79.66 with HTTP; Tue, 7 Oct 2014 14:39:42 -0700 (PDT) In-Reply-To: References: <20140918134416.2051.qmail@joyce.lan> <541BABD0.10506@rolandturner.com> <87zjdvzzt1.fsf@uwakimon.sk.tsukuba.ac.jp> <541D67F0.5070800@tana.it> Date: Tue, 7 Oct 2014 14:39:42 -0700 Message-ID: From: "Murray S. Kucherawy" To: Tim Draegen Content-Type: multipart/alternative; boundary=089e01161ba684b9040504dc0926 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/5yc9srM3-savyuiL00bydiRi4Ko Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Modeling MLM behavior X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 21:39:45 -0000 --089e01161ba684b9040504dc0926 Content-Type: text/plain; charset=UTF-8 On Tue, Oct 7, 2014 at 1:41 PM, Tim Draegen wrote: > The intention is to have something in place -- the MLM model -- that can > be used to quickly identify issues that are related to DMARC > interoperability with any given piece of MLM software. I read Alessandro's > model as a way to generically describe MLMs, which would make comparing and > contrasting of MLMs a lot easier. > > IOW, fleshing out a matrix of interoperability issues with respect to MLMs > is made easier (possible?) if we have a generic way to describe MLM > behavior. This is not meant to be a robust exercise in crafting the ideal > MLM. > > If something like this is NOT in place, my concern is that the WG will > only look at the big MLM packages. If the WG does not spend time > collecting input, the WG will not be able to make informed decisions > regarding solutions. > > What I believe you're saying is that you want to have a description of the current MLM model, generalized or in the aggregate, as a place from which to start talking about DMARC's impact. I'm totally fine with that and agree that it's probably useful to write it down. The way Alessandro made his proposal suggested to me that we were starting down the road of some kind of formal description of how the DMARC world wants MLMs to behave, as different from the current model. That was a red flag to me. Thanks for clarifying. -MSK --089e01161ba684b9040504dc0926 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Oct 7, 2014 at 1:41 PM, Tim Draegen <tim@eudaemon.= net> wrote:
= The intention is to have something in place -- the = MLM model -- that can be used to quickly identify issues that are related t= o DMARC interoperability with any given piece of MLM software.=C2=A0 I read= Alessandro's model as a way to generically describe MLMs, which would = make comparing and contrasting of MLMs a lot easier.

IOW= , fleshing out a matrix of interoperability issues with respect to MLMs is = made easier (possible?) if we have a generic way to describe MLM behavior.= =C2=A0 This is not meant to be a robust exercise in crafting the ideal MLM.=

If something like this is NOT in place, my concer= n is that the WG will only look at the big MLM packages.=C2=A0 If the WG do= es not spend time collecting input, the WG will not be able to make informe= d decisions regarding solutions.


What I believe you're saying is that you want to have a description = of the current MLM model, generalized or in the aggregate, as a place from = which to start talking about DMARC's impact.=C2=A0 I'm totally fine= with that and agree that it's probably useful to write it down.
The way Alessandro made his proposal suggested to me that we were starting= down the road of some kind of formal description of how the DMARC world wa= nts MLMs to behave, as different from the current model.=C2=A0 That was a r= ed flag to me.

Thanks for clarifying.

-MSK
--089e01161ba684b9040504dc0926-- From nobody Wed Oct 8 10:42:48 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 110BA1ACD59 for ; Wed, 8 Oct 2014 10:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5YW_fOtu_3iH for ; Wed, 8 Oct 2014 10:42:45 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 081EC1ACD55 for ; Wed, 8 Oct 2014 10:42:45 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s98Hgd6t007145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 8 Oct 2014 10:42:43 -0700 Message-ID: <54357789.7@dcrocker.net> Date: Wed, 08 Oct 2014 10:42:33 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Tim Draegen References: <542ED11B.5040405@dcrocker.net> <87k34gtsam.fsf@uwakimon.sk.tsukuba.ac.jp> <2A17AAF4-80E3-40BD-A0D1-21D3CCA305D6@eudaemon.net> In-Reply-To: <2A17AAF4-80E3-40BD-A0D1-21D3CCA305D6@eudaemon.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 08 Oct 2014 10:42:43 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/sLDivCrEOKzNBjwxqd8tuTGT7xs Cc: dmarc@ietf.org Subject: [dmarc-ietf] wiki vs. list? (was Re: documenting x-original-from usage) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 17:42:47 -0000 On 10/7/2014 2:23 PM, Tim Draegen wrote: > On Oct 3, 2014, at 11:41 PM, Stephen J. Turnbull wrote: >> Dave Crocker writes: >> >>> Along an entirely different line of analysis, note that Original-From is >>> merely adding complexity to the 'who was the author of this message' >>> assessment, very possibly creating yet-another security hole. >> >> Messrs Chairguys, >> >> Inquiring Minds Question a Point of Order: doesn't this kind of >> comment belong on the wiki page, now that it's been created? >> >> Feeling-guilty-about-own-too-long-threads-so-really-wanna-know-ly y'rs, > > Yes, it does. I've added it to the wiki, 'cause it would have taken longer to ask Dave to do it. > > WORDS OF ENCOURAGEMENT FOR THIS WG: > > Everybody should feel free to add to the wiki. If a long discussion thread doesn't end up creating wiki content for newcomers, whatever nuggets of wisdom are shared will remain buried. IMO that's no good, 'cause there is deep and varied expertise in this WG already, but it's very difficult to get at it (and therefore for a newcomer to figure out where their own expertise fits in). Hmmm... I find myself unclear about whether the wiki is intended to be an alternative to posting one's thoughts, in which case how with the wg see them? I'd expect the wiki to be a place to capture thoughts/issues/decisions after they've been discussed to some level of stability -- note that stability doesn't require actual resolution. With respect to adding Origina-From, I don't see it at: http://wiki.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneOneWiki and don't know where else to look for it... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Oct 8 12:17:18 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 554E71A1A6A for ; Wed, 8 Oct 2014 12:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fy3n9srHSBE7 for ; Wed, 8 Oct 2014 12:17:12 -0700 (PDT) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id B73451A1A6E for ; Wed, 8 Oct 2014 12:17:12 -0700 (PDT) Received: from [10.0.1.119] (97-82-216-27.dhcp.hckr.nc.charter.com [97.82.216.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id 4B21DCB46; Wed, 8 Oct 2014 15:17:12 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Tim Draegen In-Reply-To: <54357789.7@dcrocker.net> Date: Wed, 8 Oct 2014 15:17:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <542ED11B.5040405@dcrocker.net> <87k34gtsam.fsf@uwakimon.sk.tsukuba.ac.jp> <2A17AAF4-80E3-40BD-A0D1-21D3CCA305D6@eudaemon.net> <54357789.7@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/miEIjNBD6CE-4lnDqxtcwQlegFM Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] wiki vs. list? (was Re: documenting x-original-from usage) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 19:17:15 -0000 On Oct 8, 2014, at 1:42 PM, Dave Crocker wrote: > Hmmm... >=20 > I find myself unclear about whether the wiki is intended to be an > alternative to posting one's thoughts, in which case how with the wg = see > them? >=20 > I'd expect the wiki to be a place to capture thoughts/issues/decisions > after they've been discussed to some level of stability -- note that > stability doesn't require actual resolution. You've got it. Capturing tidbits from the list discussion using the = wiki is it. There's not a lot of wiki modification going on, which is = why I'm pointing folks at it. >=20 > With respect to adding Origina-From, I don't see it at: >=20 > http://wiki.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneOneWiki >=20 > and don't know where else to look for it... It's linked off of = http://wiki.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneTwoWiki This is the "Milestone 2" wiki, as the topic appeared to be about how = people are using headers to convey information to determine "real source". A bit ahead = of the WG's focus. -=3D Tim From nobody Wed Oct 8 12:20:40 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 192551A0092 for ; Wed, 8 Oct 2014 12:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5j6WfjnkbBkM for ; Wed, 8 Oct 2014 12:20:30 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68A3F1A1A86 for ; Wed, 8 Oct 2014 12:20:30 -0700 (PDT) Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 9B94EC40187; Wed, 8 Oct 2014 14:20:29 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1412796029; bh=rpxq75ymd9l7XvK/fOgx5eBCDh4p+8xmEi1jwXqv/4E=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ERvaJubLA9g7etYPNQ16cE7WCE7IVmN1r49KPLuC5zhW1WNnRFbf4akQ3pS9wUsW9 OvbU9MaZbeEsWl4OR8LvyiBwv+ENDJoklKo3ZgLIqMDvGRe5URszH2xI+cD68nTDNA C34SicRIASgLlptHQPIIF6aGJQuZJ0IMLgFrdKho= From: Scott Kitterman To: dmarc@ietf.org Date: Wed, 08 Oct 2014 15:20:28 -0400 Message-ID: <2384496.t8VmieQIgD@scott-latitude-e6320> User-Agent: KMail/4.13.3 (Linux/3.13.0-36-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <54357789.7@dcrocker.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/QJvx23fjiHBxg-dadb0d-bZVLXo Subject: Re: [dmarc-ietf] wiki vs. list? (was Re: documenting x-original-from usage) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 19:20:38 -0000 On Wednesday, October 08, 2014 15:17:10 Tim Draegen wrote: > On Oct 8, 2014, at 1:42 PM, Dave Crocker wrote: > > Hmmm... > > > > I find myself unclear about whether the wiki is intended to be an > > alternative to posting one's thoughts, in which case how with the wg see > > them? > > > > I'd expect the wiki to be a place to capture thoughts/issues/decisions > > after they've been discussed to some level of stability -- note that > > stability doesn't require actual resolution. > > You've got it. Capturing tidbits from the list discussion using the wiki is > it. There's not a lot of wiki modification going on, which is why I'm > pointing folks at it. > > With respect to adding Origina-From, I don't see it at: > > http://wiki.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneOneWiki > > > > and don't know where else to look for it... > > It's linked off of > http://wiki.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneTwoWiki This is the > "Milestone 2" wiki, as the topic appeared to be about how people are using > headers to convey information to determine "real source". A bit ahead of > the WG's focus. We have one? Scott K From nobody Wed Oct 8 12:27:03 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF7261A0056 for ; Wed, 8 Oct 2014 12:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AL3F3jIL_WFY for ; Wed, 8 Oct 2014 12:26:59 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3CB41A0060 for ; Wed, 8 Oct 2014 12:26:56 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s98JQoq1010767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 8 Oct 2014 12:26:54 -0700 Message-ID: <54358FF5.3000907@dcrocker.net> Date: Wed, 08 Oct 2014 12:26:45 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Tim Draegen , dcrocker@bbiw.net References: <542ED11B.5040405@dcrocker.net> <87k34gtsam.fsf@uwakimon.sk.tsukuba.ac.jp> <2A17AAF4-80E3-40BD-A0D1-21D3CCA305D6@eudaemon.net> <54357789.7@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 08 Oct 2014 12:26:54 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/1Hcn5-H3OFIucSRER7_T-HMM90w Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] wiki vs. list? (was Re: documenting x-original-from usage) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 19:27:01 -0000 On 10/8/2014 12:17 PM, Tim Draegen wrote: > It's linked off of http://wiki.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneTwoWiki ack. tnx. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Oct 8 12:32:44 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD02B1A0162 for ; Wed, 8 Oct 2014 12:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xmW8NYc7asD for ; Wed, 8 Oct 2014 12:32:40 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4DBF1A0154 for ; Wed, 8 Oct 2014 12:32:40 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s98JWYSk010921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 8 Oct 2014 12:32:38 -0700 Message-ID: <5435914D.1090707@dcrocker.net> Date: Wed, 08 Oct 2014 12:32:29 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Tim Draegen , dcrocker@bbiw.net References: <542ED11B.5040405@dcrocker.net> <87k34gtsam.fsf@uwakimon.sk.tsukuba.ac.jp> <2A17AAF4-80E3-40BD-A0D1-21D3CCA305D6@eudaemon.net> <54357789.7@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 08 Oct 2014 12:32:38 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/6tyRGTtBcp7jmzd-mjPrDyw3oyk Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] wiki vs. list? (was Re: documenting x-original-from usage) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 19:32:41 -0000 On 10/8/2014 12:17 PM, Tim Draegen wrote: >> and don't know where else to look for it... > It's linked off of fwiw, I just added links on the dmarc wiki homepage to pages for all 3 milestones and added mnemoic labels to the phase numbers. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Oct 8 12:34:30 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A908C1A016D for ; Wed, 8 Oct 2014 12:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9J_s3L9wLfz for ; Wed, 8 Oct 2014 12:34:23 -0700 (PDT) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 7AABE1A0102 for ; Wed, 8 Oct 2014 12:34:23 -0700 (PDT) Received: from [10.0.1.119] (97-82-216-27.dhcp.hckr.nc.charter.com [97.82.216.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id 3033ECB46; Wed, 8 Oct 2014 15:34:23 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Tim Draegen In-Reply-To: <2384496.t8VmieQIgD@scott-latitude-e6320> Date: Wed, 8 Oct 2014 15:34:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54357789.7@dcrocker.net> <2384496.t8VmieQIgD@scott-latitude-e6320> To: Scott Kitterman X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/PuT3UDKacrTAn-g-mb4p6cafDbY Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] wiki vs. list? (was Re: documenting x-original-from usage) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 19:34:24 -0000 On Oct 8, 2014, at 3:20 PM, Scott Kitterman = wrote: >> A bit ahead of the WG's focus. >=20 > We have one? Ha! The WG is supposed to be focused on collecting all known issues = between DMARC and indirect email flows. Based on the collected set of = issues, we'll then switch gears and argue the heck out of possible = solutions. =3D- Tim From nobody Wed Oct 8 12:44:54 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABB01A01E1 for ; Wed, 8 Oct 2014 12:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dx7sBpu-SlG7 for ; Wed, 8 Oct 2014 12:44:52 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.41]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D59D71A01A8 for ; Wed, 8 Oct 2014 12:44:51 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES531.agna.amgreetings.com ([::1]) with mapi id 14.03.0158.001; Wed, 8 Oct 2014 15:44:51 -0400 From: "MH Michael Hammer (5304)" To: Tim Draegen , Scott Kitterman Thread-Topic: [dmarc-ietf] wiki vs. list? (was Re: documenting x-original-from usage) Thread-Index: AQHP4x9IMi7RWSwl2kq1LnCgmEr3GJwm1bkAgAAA7ACAAAPhgP//vZYw Date: Wed, 8 Oct 2014 19:44:50 +0000 Message-ID: References: <54357789.7@dcrocker.net> <2384496.t8VmieQIgD@scott-latitude-e6320> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.144.15.227] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/6EAwHEYWoOJTrDRFSVeeG7-nRsw Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] wiki vs. list? (was Re: documenting x-original-from usage) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 19:44:53 -0000 > -----Original Message----- > From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Tim Draegen > Sent: Wednesday, October 08, 2014 3:34 PM > To: Scott Kitterman > Cc: dmarc@ietf.org > Subject: Re: [dmarc-ietf] wiki vs. list? (was Re: documenting x-original-= from > usage) >=20 > On Oct 8, 2014, at 3:20 PM, Scott Kitterman wrote: > >> A bit ahead of the WG's focus. > > > > We have one? >=20 > Ha! The WG is supposed to be focused on collecting all known issues > between DMARC and indirect email flows. Based on the collected set of > issues, we'll then switch gears and argue the heck out of possible soluti= ons. >=20 To that point, everyone seems focused on MLMs. I was looking at data for DM= ARC pass/fail rates for IPs/hosts other than our own and was struck by the = variability of the rates across various domains. Excluding "known bad actor= s", DMARC pass rates ranged from low 60-something percent up to mid-90 some= thing percent. Such a large range is interesting. Because (aligned) SPF sho= uld almost always fail, the implication is that there are potentially bette= r and worse ways to maintain the integrity of the DKIM signature in transit= . Just a reminder, the mailstreams I'm looking at are transactional and ove= rwhelmingly do not include traffic transiting mailing lists. Mike From nobody Wed Oct 8 22:45:04 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAC51A90C4 for ; Wed, 8 Oct 2014 22:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.009 X-Spam-Level: ** X-Spam-Status: No, score=2.009 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ritq7xCJE7uM for ; Wed, 8 Oct 2014 22:44:58 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 70F3D1A90CE for ; Wed, 8 Oct 2014 22:44:57 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id DD0091C3A0A; Thu, 9 Oct 2014 14:44:56 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id D0DED1A2888; Thu, 9 Oct 2014 14:44:56 +0900 (JST) From: "Stephen J. Turnbull" To: "MH Michael Hammer (5304)" In-Reply-To: References: <54357789.7@dcrocker.net> <2384496.t8VmieQIgD@scott-latitude-e6320> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Thu, 09 Oct 2014 14:44:56 +0900 Message-ID: <871tqhre3r.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/enJx1sBDtkkCA15OsYxhnh3SN4M Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] wiki vs. list? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 05:45:00 -0000 MH Michael Hammer (5304) writes: > To that point, everyone seems focused on MLMs. Sure, and that's unfortunate. I discuss MLMs because that's what I do, and that's what I know. > I was looking at data for DMARC pass/fail rates for IPs/hosts other > than our own and was struck by the variability of the rates across > various domains. Excluding "known bad actors", By "bad actors", do you mean spammers and other miscreants, or do you mean 3rd party filtering services that append ads to the message body and other incompetents? > DMARC pass rates ranged from low 60-something percent up to mid-90 > something percent. Such a large range is interesting. Because > (aligned) SPF should almost always fail, the implication is that > there are potentially better and worse ways to maintain the > integrity of the DKIM signature in transit. Just a reminder, the > mailstreams I'm looking at are transactional and overwhelmingly do > not include traffic transiting mailing lists. I guess the obvious questions are "why are they transiting other hosts, then?" (eg, secondary MX provided by a third party should not break DKIM signatures), and "can you see anything about the mailstreams themselves that is different across mailstreams?" And then, can you ask those transited hosts what they're doing that might break DKIM? From nobody Thu Oct 9 05:44:43 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E7D1ACE4B for ; Thu, 9 Oct 2014 05:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-jj52eMXOju for ; Thu, 9 Oct 2014 05:44:35 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.31]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDA911ACE32 for ; Thu, 9 Oct 2014 05:44:34 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES533.agna.amgreetings.com ([::1]) with mapi id 14.03.0158.001; Thu, 9 Oct 2014 08:44:33 -0400 From: "MH Michael Hammer (5304)" To: "Stephen J. Turnbull" Thread-Topic: [dmarc-ietf] wiki vs. list? Thread-Index: AQHP44QrERHW1uewWkiShhuwYcrnwZwnsbJw Date: Thu, 9 Oct 2014 12:44:32 +0000 Message-ID: References: <54357789.7@dcrocker.net> <2384496.t8VmieQIgD@scott-latitude-e6320> <871tqhre3r.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <871tqhre3r.fsf@uwakimon.sk.tsukuba.ac.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.144.15.227] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/6XhltpjwA7bRR70bPrekAwx7Jgo Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] wiki vs. list? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 12:44:41 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogU3RlcGhlbiBKLiBUdXJu YnVsbCBbbWFpbHRvOnN0ZXBoZW5AeGVtYWNzLm9yZ10NCj4gU2VudDogVGh1cnNkYXksIE9jdG9i ZXIgMDksIDIwMTQgMTo0NSBBTQ0KPiBUbzogTUggTWljaGFlbCBIYW1tZXIgKDUzMDQpDQo+IENj OiBkbWFyY0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW2RtYXJjLWlldGZdIHdpa2kgdnMuIGxp c3Q/DQo+IA0KPiBNSCBNaWNoYWVsIEhhbW1lciAoNTMwNCkgd3JpdGVzOg0KPiANCj4gID4gVG8g dGhhdCBwb2ludCwgZXZlcnlvbmUgc2VlbXMgZm9jdXNlZCBvbiBNTE1zLg0KPiANCj4gU3VyZSwg YW5kIHRoYXQncyB1bmZvcnR1bmF0ZS4gIEkgZGlzY3VzcyBNTE1zIGJlY2F1c2UgdGhhdCdzIHdo YXQgSSBkbywgYW5kDQo+IHRoYXQncyB3aGF0IEkga25vdy4NCj4gDQo+ICA+IEkgd2FzIGxvb2tp bmcgYXQgZGF0YSBmb3IgRE1BUkMgcGFzcy9mYWlsIHJhdGVzIGZvciBJUHMvaG9zdHMgb3RoZXIg ID4gdGhhbg0KPiBvdXIgb3duIGFuZCB3YXMgc3RydWNrIGJ5IHRoZSB2YXJpYWJpbGl0eSBvZiB0 aGUgcmF0ZXMgYWNyb3NzICA+IHZhcmlvdXMNCj4gZG9tYWlucy4gRXhjbHVkaW5nICJrbm93biBi YWQgYWN0b3JzIiwNCj4gDQo+IEJ5ICJiYWQgYWN0b3JzIiwgZG8geW91IG1lYW4gc3BhbW1lcnMg YW5kIG90aGVyIG1pc2NyZWFudHMsIG9yIGRvIHlvdQ0KPiBtZWFuIDNyZCBwYXJ0eSBmaWx0ZXJp bmcgc2VydmljZXMgdGhhdCBhcHBlbmQgYWRzIHRvIHRoZSBtZXNzYWdlIGJvZHkgYW5kDQo+IG90 aGVyIGluY29tcGV0ZW50cz8NCj4gDQoNCkJ5IGJhZCBhY3RvcnMgSSBtZWFuIHNwYW1tZXJzLCBw aGlzaGVycyBhbmQgb3RoZXIgbWlzY3JlYW50cy4gSSBkZXRlcm1pbmUgdGhpcyBieSBsb29raW5n IGF0IHRoZSBoZWFkZXJzIGFuZCAobWVzc2FnZSBib2R5KSBVUkxzIHRoYXQgSSBnZXQgdGhyb3Vn aCBmZWVkYmFjayBsb29wcyBpbiBhZGRpdGlvbiB0byB3aGV0aGVyIHRoZSBtZXNzYWdlIHdhcyBE S0lNIHNpZ25lZCBhdCBhbGwuIEknbSBub3Qgb3Zlcmx5IGNvbmNlcm5lZCBhYm91dCAzcmQgcGFy dHkgZmlsdGVyaW5nIHNlcnZpY2VzIHRoYXQgYXBwZW5kIGFkcyB0byB0aGUgbWVzc2FnZSBib2R5 IGJlZm9yZSBES0lNIGlzIHZhbGlkYXRlZC4gVGhhdCBmYWxscyBpbnRvIHRoZSBjYXRlZ29yeSBv ZiBpbmNvbXBldGVudHMgYXMgeW91IHJpZ2h0bHkgcG9pbnQgb3V0LiBBcyBhbiBhc2lkZSwgSSBk aWQgbm90aWNlIG9uZSBtZXNzYWdlIHRoYXQgdGhlIHJlY2VpdmluZyB2YWxpZGF0b3IgYXBwYXJl bnRseSBkaWQgMiBTUEYgY2hlY2tzIG9uICh0aGlzIGlzIG1haWwgZGlyZWN0IGZyb20gb3VyIE1U QSB0byB0aGVtKSAtIHRoZSBmaXJzdCBvbmUgcGFzc2VkIGJ1dCB0aGUgc2Vjb25kIG9uZSBmYWls ZWQgYmVjYXVzZSB0aGV5IHdlcmUgYXR0ZW1wdGluZyB0byB2YWxpZGF0ZSAoYWxpZ25lZCkgU1BG IGluIGEgRE1BUkMgY29udGV4dCBmb3Igb3VyIGRvbWFpbiBhZ2FpbnN0IHRoZWlyIElQIC0gRE9I ISANCg0KPiAgPiBETUFSQyBwYXNzIHJhdGVzIHJhbmdlZCBmcm9tIGxvdyA2MC1zb21ldGhpbmcg cGVyY2VudCB1cCB0byBtaWQtOTAgID4NCj4gc29tZXRoaW5nIHBlcmNlbnQuIFN1Y2ggYSBsYXJn ZSByYW5nZSBpcyBpbnRlcmVzdGluZy4gQmVjYXVzZSAgPiAoYWxpZ25lZCkgU1BGDQo+IHNob3Vs ZCBhbG1vc3QgYWx3YXlzIGZhaWwsIHRoZSBpbXBsaWNhdGlvbiBpcyB0aGF0ICA+IHRoZXJlIGFy ZSBwb3RlbnRpYWxseQ0KPiBiZXR0ZXIgYW5kIHdvcnNlIHdheXMgdG8gbWFpbnRhaW4gdGhlICA+ IGludGVncml0eSBvZiB0aGUgREtJTSBzaWduYXR1cmUgaW4NCj4gdHJhbnNpdC4gSnVzdCBhIHJl bWluZGVyLCB0aGUgID4gbWFpbHN0cmVhbXMgSSdtIGxvb2tpbmcgYXQgYXJlIHRyYW5zYWN0aW9u YWwNCj4gYW5kIG92ZXJ3aGVsbWluZ2x5IGRvICA+IG5vdCBpbmNsdWRlIHRyYWZmaWMgdHJhbnNp dGluZyBtYWlsaW5nIGxpc3RzLg0KPiANCj4gSSBndWVzcyB0aGUgb2J2aW91cyBxdWVzdGlvbnMg YXJlICJ3aHkgYXJlIHRoZXkgdHJhbnNpdGluZyBvdGhlciBob3N0cywNCj4gdGhlbj8iIChlZywg c2Vjb25kYXJ5IE1YIHByb3ZpZGVkIGJ5IGEgdGhpcmQgcGFydHkgc2hvdWxkIG5vdCBicmVhayBE S0lNDQo+IHNpZ25hdHVyZXMpLCBhbmQgImNhbiB5b3Ugc2VlIGFueXRoaW5nIGFib3V0IHRoZSBt YWlsc3RyZWFtcyB0aGVtc2VsdmVzDQo+IHRoYXQgaXMgZGlmZmVyZW50IGFjcm9zcyBtYWlsc3Ry ZWFtcz8iDQo+IA0KDQpNeSBodW5jaCBpcyB0aGF0IG11Y2ggb2YgaXQgaXMgc29tZWhvdyByZWxh dGVkIHRvIGZvcndhcmRpbmcgYnkgZW5kIHVzZXJzIHRvIG90aGVyIGFjY291bnRzIHRoZXkgY29u dHJvbCAoY29uc29saWRhdGlvbiBvZiBtYWlsIGluIG9uZSBwbGFjZT8pIFRoYXQgaXMganVzdCBh IGd1ZXNzIHRob3VnaC4gSSBtYXkgcmVhY2ggb3V0IHRvIGEgY291cGxlIG9mIG1haWxib3ggcHJv dmlkZXJzIHRvIHNlZSBpZiB3ZSBjYW4gZmlndXJlIG91dCB0aGUgZGV0YWlscyBvZiB3aGF0IGlz IGhhcHBlbmluZy4gSSB3b3VsZCBhc3N1bWUgdGhhdCBwcm92aWRlcnMgYXQgdGhlIGxvdyBvZiB0 aGUgcmFuZ2Ugd291bGQgd2FudCB0byBpbXByb3ZlIHBlcmZvcm1hbmNlIGluIHRlcm1zIG9mIGxl c3MgcmVqZWN0ZWQgbWFpbC4gT24gdGhlIG90aGVyIGhhbmQsIGZyb20gbXkgcGVyc3BlY3RpdmUs IHRoZSBudW1iZXJzIG9mIG1haWwgaW52b2x2ZWQgZm9yIG91ciBtYWlsIHN0cmVhbXMgYXJlIHJl bGF0aXZlbHkgc21hbGwgc28gaXQgaXMgbW9yZSBjdXJpb3NpdHkgb24gbXkgcGFydCB0aGFuIGEg c2lnbmlmaWNhbnQgcHJvYmxlbS4NCg0KPiBBbmQgdGhlbiwgY2FuIHlvdSBhc2sgdGhvc2UgdHJh bnNpdGVkIGhvc3RzIHdoYXQgdGhleSdyZSBkb2luZyB0aGF0IG1pZ2h0DQo+IGJyZWFrIERLSU0/ DQoNCkFzIGEgZmlyc3Qgc3RlcCBJJ2QgYmUgaW50ZXJlc3RlZCBpbiBrbm93aW5nIGlmIGFueW9u ZSBlbHNlIGlzIHNlZWluZyBzaW1pbGFyIHZhcmlhdGlvbnMgZm9yIHRyYW5zYWN0aW9uYWwgbWFp bCBzdHJlYW1zIHRoYXQgb25lIHdvdWxkIG5vdCBleHBlY3QgdG8gYmUgZ29pbmcgdGhyb3VnaCBt YWlsaW5nIGxpc3RzLiBUaGF0IGlzLCBpcyB0aGlzIGEgc2lnbmlmaWNhbnQgZW5vdWdoIGNvbW11 bml0eSBwcm9ibGVtIHRoYXQgd2Ugc2hvdWxkIGJlIGNvbGxlY3RpdmVseSBzcGVuZGluZyB0aW1l IG9uIGl0Pw0KDQpNaWtlDQo= From nobody Thu Oct 9 14:28:56 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02F671A88A5 for ; Thu, 9 Oct 2014 14:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.802 X-Spam-Level: X-Spam-Status: No, score=-0.802 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xncJEWGKhEMp for ; Thu, 9 Oct 2014 14:28:50 -0700 (PDT) Received: from mx10.mailtransaction.com (mx10.mailtransaction.com [88.198.59.241]) by ietfa.amsl.com (Postfix) with ESMTP id 9FADD1A88A3 for ; Thu, 9 Oct 2014 14:28:49 -0700 (PDT) Received: from mx14.mailtransaction.com (mx11.mailtransaction.com [88.198.59.230]) by mx10.mailtransaction.com (Postfix) with ESMTP id 3jDQWz3988z5MhBy; Thu, 9 Oct 2014 23:28:47 +0200 (CEST) Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx14.mailtransaction.com (Postfix) with ESMTP id 3jDQWz1lnXz5MhBK; Thu, 9 Oct 2014 23:28:47 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id 28606123356; Thu, 9 Oct 2014 23:28:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at sonnection.nl Received: from jaguar.sonnection.nl ([127.0.0.1]) by localhost (jaguar.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id LnsqlcsMnR8N; Thu, 9 Oct 2014 23:28:42 +0200 (CEST) Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id 885E61231BC; Thu, 9 Oct 2014 23:28:42 +0200 (CEST) Message-ID: <5436FE09.4050104@sonnection.nl> Date: Thu, 09 Oct 2014 23:28:41 +0200 From: "Rolf E. Sonneveld" Organization: Sonnection B.V. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Tim Draegen , Scott Kitterman References: <54357789.7@dcrocker.net> <2384496.t8VmieQIgD@scott-latitude-e6320> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1412890127; bh=fdvGP8AhgP7uYi+wsKfzG1wEZJYlLKyTMRV97cqu0Cc=; h=Message-ID:Date:From:To:Subject:From; b=kpRa5XxN8VQ8cPo57LQvCXjjTsusfHqzED6w/4SmYS8Jx7N5jcbOq19FZvUxrrsAj nOB4EC6iWGJxve/p/wjmVnU6zIv4kM6KlU6/SQlZiRjduLYJ0ZTEEoV2YMuyChawDj i9pgOH6Nc6yx1M4YL5dvlWgaPMydCHpcPzkP0/3I= DKIM-Filter: OpenDKIM Filter v2.8.2 mx10.mailtransaction.com 3jDQWz3988z5MhBy Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/8A4kOgKOETeLM_Y7Padwmp3ZAFQ Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] wiki vs. list? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: R.E.Sonneveld@sonnection.nl List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 21:28:53 -0000 On 10/08/2014 09:34 PM, Tim Draegen wrote: > On Oct 8, 2014, at 3:20 PM, Scott Kitterman wrote: >>> A bit ahead of the WG's focus. >> We have one? > Ha! The WG is supposed to be focused on collecting all known issues between DMARC and indirect email flows. Based on the collected set of issues, we'll then switch gears and argue the heck out of possible solutions. FYI, I added some information about Sieve 'redirect', 'addheader', 'deleteheader' and 'replace' actions to the Wiki. A more general comment: reading the wiki and the discussions on this list, it get the impression that we seem to focus more on the issues related to the 'DKIM part of DMARC' then on issues related to the 'SPF part of DMARC'. Is my observation correct, do we tend to forget SPF here? /rolf From nobody Thu Oct 9 21:00:22 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7BF1A00BA for ; Thu, 9 Oct 2014 21:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWhGlpx_zdg0 for ; Thu, 9 Oct 2014 21:00:18 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1E271A0100 for ; Thu, 9 Oct 2014 21:00:18 -0700 (PDT) Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id C622AC40381; Thu, 9 Oct 2014 23:00:14 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1412913614; bh=U54G7sidacbbQ+LyQhwxVq72oxvJpOkEtgkybyfSMSg=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ZdVuYN3W59Bk11YXA8VUsh506y6kv98a19P568bNEVQZNkGM3WQm0q4gQCBj5/2Gi gAfRuqTB1NKfBIzGgwiJ1HwWX+CEsUcPETZhHv543jjmeCIlpmRCpzwtCnOymyjHwY TYB24TfM5cQUd4GdfC92I1t7imiM8BVF65tDKTdA= From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 10 Oct 2014 00:00:14 -0400 Message-ID: <3863863.Wb0YsJW3Qe@scott-latitude-e6320> User-Agent: KMail/4.13.3 (Linux/3.13.0-37-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <5436FE09.4050104@sonnection.nl> References: <5436FE09.4050104@sonnection.nl> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/N_NrJd8jv6CtyjKmpQtMFmrpAgI Subject: Re: [dmarc-ietf] wiki vs. list? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 04:00:20 -0000 On Thursday, October 09, 2014 23:28:41 Rolf E. Sonneveld wrote: > On 10/08/2014 09:34 PM, Tim Draegen wrote: > > On Oct 8, 2014, at 3:20 PM, Scott Kitterman wrote: > >>> A bit ahead of the WG's focus. > >> > >> We have one? > > > > Ha! The WG is supposed to be focused on collecting all known issues > > between DMARC and indirect email flows. Based on the collected set of > > issues, we'll then switch gears and argue the heck out of possible > > solutions. > FYI, I added some information about Sieve 'redirect', 'addheader', > 'deleteheader' and 'replace' actions to the Wiki. > > A more general comment: reading the wiki and the discussions on this > list, it get the impression that we seem to focus more on the issues > related to the 'DKIM part of DMARC' then on issues related to the 'SPF > part of DMARC'. Is my observation correct, do we tend to forget SPF here? Possible, but also we (in SPFbis) just finished up RFC 7208 and it goes into a lot of detail about ways SPF can fail and what can be done about it. I don't think there's a lot of fertile ground to plow. If someone has the time/motivation, it might be useful to see what of the SPF failure mitigations cause problems with DMARC alignment (as an example, SRS will allow the mail from to be changed when a message is forwarded, so the forwarder's SPF can be used, but the doesn't preserve DMARC alignment). Scott K From nobody Thu Oct 9 21:12:44 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28FED1A0110 for ; Thu, 9 Oct 2014 21:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3HSwdPAFgTVF for ; Thu, 9 Oct 2014 21:12:33 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EC331A010F for ; Thu, 9 Oct 2014 21:12:32 -0700 (PDT) Received: (qmail 36056 invoked from network); 10 Oct 2014 04:12:31 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 10 Oct 2014 04:12:31 -0000 Date: 10 Oct 2014 04:12:09 -0000 Message-ID: <20141010041209.2106.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <5436FE09.4050104@sonnection.nl> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/9HtvbPlW4DWqg6VAilxJZ0t5Fnk Cc: R.E.Sonneveld@sonnection.nl Subject: Re: [dmarc-ietf] wiki vs. list? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 04:12:34 -0000 >A more general comment: reading the wiki and the discussions on this >list, it get the impression that we seem to focus more on the issues >related to the 'DKIM part of DMARC' then on issues related to the 'SPF >part of DMARC'. Is my observation correct, do we tend to forget SPF here? I agree with Scott, there's not much to say about it. If you forward or remail a message, the origin IP changes, and there's nothing you can do about it. Perhaps we can note that in theory the original sender could add mailing list IPs to its own SPF, but I never heard of anyone doing that. From nobody Fri Oct 10 04:19:19 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC3C1A8A57 for ; Fri, 10 Oct 2014 04:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.208 X-Spam-Level: X-Spam-Status: No, score=-3.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXvllWRUW4x9 for ; Fri, 10 Oct 2014 04:19:13 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCE821A8A59 for ; Fri, 10 Oct 2014 04:19:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1412932392; bh=7F1v/vOa3/cXqSLoA4NlIOU9y2GXLzTVyze+DZORc5E=; l=1067; h=Date:From:To:References:In-Reply-To; b=NQlcLXZKx9A2eHn6m/vDSO0S3TW/L0WcjR+5Qm/TK+RzjG7kEMXejZ0PkxW9TXpXM csm5plG8y2pZAlKs4cmz5OPKMbjM6YYERLKFgFBTOpuoIGh2RpwJ+qlPBA+nCRvs4X cr69fmNsK78A3yV1J2tP/LCZMwFBeqqUqnK65vEw= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.88] (pcale.tana [172.25.197.88]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Fri, 10 Oct 2014 11:13:12 +0200 id 00000000005DC049.000000005437A328.00005B32 Message-ID: <5437A328.3090200@tana.it> Date: Fri, 10 Oct 2014 11:13:12 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <20141010041209.2106.qmail@ary.lan> In-Reply-To: <20141010041209.2106.qmail@ary.lan> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/XTCJlc9dLf4vJWMDbQGsg6-wv10 Subject: Re: [dmarc-ietf] wiki vs. list? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 11:19:15 -0000 On Fri 10/Oct/2014 06:12:09 +0200 John Levine wrote: >> A more general comment: reading the wiki and the discussions on this >> list, it get the impression that we seem to focus more on the issues >> related to the 'DKIM part of DMARC' then on issues related to the 'SPF >> part of DMARC'. Is my observation correct, do we tend to forget SPF here? > > I agree with Scott, there's not much to say about it. If you forward > or remail a message, the origin IP changes, and there's nothing you > can do about it. +1 if we are focusing on indirect flows, SPF is out of the game. > Perhaps we can note that in theory the original sender could add > mailing list IPs to its own SPF, but I never heard of anyone doing > that. I don't think that solution can be recommended, because of the guesswork implied in adding addresses in bulk. For example, the advice given in the first bullet of Appendix D.1[1] gives a "neutral" result, which is good for local SPF policies but not for DMARC. Ale [1] http://tools.ietf.org/html/rfc7208#appendix-D.1 From nobody Fri Oct 10 05:29:28 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B43B1A913D for ; Fri, 10 Oct 2014 05:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqTMD4vsabrT for ; Fri, 10 Oct 2014 05:29:15 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.31]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E49881A913A for ; Fri, 10 Oct 2014 05:29:14 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES533.agna.amgreetings.com ([::1]) with mapi id 14.03.0158.001; Fri, 10 Oct 2014 08:29:14 -0400 From: "MH Michael Hammer (5304)" To: John Levine , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] wiki vs. list? Thread-Index: AQHP5AgK6FG01F43gkajcQqfw9VGIJwo+7aAgABG2DA= Date: Fri, 10 Oct 2014 12:29:13 +0000 Message-ID: References: <5436FE09.4050104@sonnection.nl> <20141010041209.2106.qmail@ary.lan> In-Reply-To: <20141010041209.2106.qmail@ary.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.144.15.227] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/xwhXLvydFk0Qo8Kq286C8WM6jVQ Cc: "R.E.Sonneveld@sonnection.nl" Subject: Re: [dmarc-ietf] wiki vs. list? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 12:29:27 -0000 > -----Original Message----- > From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of John Levine > Sent: Friday, October 10, 2014 12:12 AM > To: dmarc@ietf.org > Cc: R.E.Sonneveld@sonnection.nl > Subject: Re: [dmarc-ietf] wiki vs. list? >=20 > >A more general comment: reading the wiki and the discussions on this > >list, it get the impression that we seem to focus more on the issues > >related to the 'DKIM part of DMARC' then on issues related to the 'SPF > >part of DMARC'. Is my observation correct, do we tend to forget SPF here= ? >=20 > I agree with Scott, there's not much to say about it. If you forward or = remail a > message, the origin IP changes, and there's nothing you can do about it. >=20 > Perhaps we can note that in theory the original sender could add mailing = list > IPs to its own SPF, but I never heard of anyone doing that. >=20 An issue that I have been thinking on - and it is the reverse of this discu= ssion - is that it is operationally difficult to maintain accurate SPF reco= rds for organizations with a lot of domains where the SPF records vary acro= ss the domains. I recently found this situation with one of our domains (an= acquisition). This is similar to other situations where organizations are = fairly good with adds and changes but not so much with deletes. This isn't = anything that can be addressed through an RFC but I think it is worth notin= g. Mike From nobody Fri Oct 10 08:18:07 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 957411A1A0A for ; Fri, 10 Oct 2014 08:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.788 X-Spam-Level: X-Spam-Status: No, score=-2.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPTP1ur73nU4 for ; Fri, 10 Oct 2014 08:17:55 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 85F841A1A12 for ; Fri, 10 Oct 2014 08:17:55 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PDKQLRM9JK000RLV@mauve.mrochek.com> for dmarc@ietf.org; Fri, 10 Oct 2014 08:12:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1412953974; bh=jzQ1IuVoPpeQ2o816lu744pfhoJjpjU89j26K1H3uPI=; h=From:Cc:Date:Subject:In-reply-to:References:To; b=R4SNphieC8pmWYZUsgRi0NYLWE3smAD74FHvGtTDx95DEcJvAAKUf09BBgWXkhU3X yB2CE/AgfomdTpsQ7gKHjYMwhMv6TpHV6FDvRyJHggk4i2Ks/q1pmMlLLpnYfAiduR VEW+3MTMjjfFiEF5ArgHghSYAsWZRfCQVjiOXBsY= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PDG0CNE5XS00005K@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dmarc@ietf.org; Fri, 10 Oct 2014 08:12:50 -0700 (PDT) From: ned+dmarc@mrochek.com Message-id: <01PDKQLQAPA200005K@mauve.mrochek.com> Date: Fri, 10 Oct 2014 08:07:20 -0700 (PDT) In-reply-to: "Your message dated Fri, 10 Oct 2014 12:29:13 +0000" References: <5436FE09.4050104@sonnection.nl> <20141010041209.2106.qmail@ary.lan> To: "MH Michael Hammer (5304)" Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/hyxcdsUVcMOXmeGWXvqiM6t4xSM Cc: "R.E.Sonneveld@sonnection.nl" , "dmarc@ietf.org" , John Levine Subject: Re: [dmarc-ietf] wiki vs. list? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 15:17:59 -0000 > > -----Original Message----- > > From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of John Levine > > Sent: Friday, October 10, 2014 12:12 AM > > To: dmarc@ietf.org > > Cc: R.E.Sonneveld@sonnection.nl > > Subject: Re: [dmarc-ietf] wiki vs. list? > > > > >A more general comment: reading the wiki and the discussions on this > > >list, it get the impression that we seem to focus more on the issues > > >related to the 'DKIM part of DMARC' then on issues related to the 'SPF > > >part of DMARC'. Is my observation correct, do we tend to forget SPF here? > > > > I agree with Scott, there's not much to say about it. If you forward or remail a > > message, the origin IP changes, and there's nothing you can do about it. > > > > Perhaps we can note that in theory the original sender could add mailing list > > IPs to its own SPF, but I never heard of anyone doing that. > > > An issue that I have been thinking on - and it is the reverse of this > discussion - is that it is operationally difficult to maintain accurate SPF > records for organizations with a lot of domains where the SPF records vary > across the domains. I recently found this situation with one of our domains (an > acquisition). This is similar to other situations where organizations are > fairly good with adds and changes but not so much with deletes. This isn't > anything that can be addressed through an RFC but I think it is worth noting. This looks to me to be an operational issue with deploying SPF at scale. This WG"s charter is pretty specific that we're focusing on issues caused by "mail that does not flow from operators having a relationship with the domain owner, directly to receivers operating the destination mailbox". I don't see how this fits within that scope. So, while I'm sympathetic to the difficulties using SPF in this way, I don't think it's in scope for the present effort. Ned From brettmcdowell@gmail.com Wed Oct 15 07:31:18 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 734BD1A870A for ; Wed, 15 Oct 2014 07:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMuTeQaJYhHO for ; Wed, 15 Oct 2014 07:31:17 -0700 (PDT) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28CC71A8711 for ; Wed, 15 Oct 2014 07:30:45 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id x3so1048940qcv.10 for ; Wed, 15 Oct 2014 07:30:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=u0ssOUBeo1ZMTLsVD9cbr/Wyslw61DBeU1XhBOUGf2w=; b=rvHTxiM5zfD9G0esuBeZRTg57f5Hc4CwS41DMPds2dAfrkXbVXsJmZIluU/uZXh5/A xB7x4bnbyl1j7iP0eG4ruF6SJ199Q0MfhZal1p4EzmeY1KcOyO/z7cVw603mbxBvqS+K GM0VuH6Np/efRruX5M1U1zsTTpzlTPWpKSmhHAyW3y3KNaYVN3WI44OJRLA9yNhNst++ BjUN7vFe6bkhLreBBlvHpUCyOJidzteWmUH/JoUrnbB0SRiqtgDWRiqMa46soOHEzz3T Eu3xxWitIogRnu7x42paAmWb6G3F78SaRaRCk3tbmmpQu8+Ri66FIjkSRU/dmqIgcKR9 Mumw== X-Received: by 10.224.136.72 with SMTP id q8mr20635380qat.33.1413383443437; Wed, 15 Oct 2014 07:30:43 -0700 (PDT) Received: from [10.0.1.136] (c-73-4-114-92.hsd1.ma.comcast.net. [73.4.114.92]) by mx.google.com with ESMTPSA id t106sm18278145qgd.24.2014.10.15.07.30.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 Oct 2014 07:30:42 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Brett McDowell In-Reply-To: <01PDKQLQAPA200005K@mauve.mrochek.com> Date: Wed, 15 Oct 2014 10:30:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5436FE09.4050104@sonnection.nl> <20141010041209.2106.qmail@ary.lan> <01PDKQLQAPA200005K@mauve.mrochek.com> To: ned+dmarc@mrochek.com X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/deMlpDdvw_oNvtzizzbAajmXiks Cc: "R.E.Sonneveld@sonnection.nl" , dmarc , "John R. Levine" , Mike Hammer Subject: Re: [dmarc-ietf] wiki vs. list? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 14:33:09 -0000 (note: this is my first post to dmarc@ietf.org but I participated in the = original creation of DMARC and I look forward to participating in this = WG) On Oct 10, 2014, at 11:07 AM, ned+dmarc@mrochek.com wrote: >=20 >=20 >>> -----Original Message----- >>> From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of John Levine >>> Sent: Friday, October 10, 2014 12:12 AM >>> To: dmarc@ietf.org >>> Cc: R.E.Sonneveld@sonnection.nl >>> Subject: Re: [dmarc-ietf] wiki vs. list? >>>=20 >>>> A more general comment: reading the wiki and the discussions on = this >>>> list, it get the impression that we seem to focus more on the = issues >>>> related to the 'DKIM part of DMARC' then on issues related to the = 'SPF >>>> part of DMARC'. Is my observation correct, do we tend to forget SPF = here? >>>=20 >>> I agree with Scott, there's not much to say about it. If you = forward or remail a >>> message, the origin IP changes, and there's nothing you can do about = it. >>>=20 >>> Perhaps we can note that in theory the original sender could add = mailing list >>> IPs to its own SPF, but I never heard of anyone doing that. >>>=20 >=20 >> An issue that I have been thinking on - and it is the reverse of this >> discussion - is that it is operationally difficult to maintain = accurate SPF >> records for organizations with a lot of domains where the SPF records = vary >> across the domains. I recently found this situation with one of our = domains (an >> acquisition). This is similar to other situations where organizations = are >> fairly good with adds and changes but not so much with deletes. This = isn't >> anything that can be addressed through an RFC but I think it is worth = noting. >=20 > I was surprised to see you take your chair hat off when responding to a = discussion of scope. Being still fairly green when it comes to IETF = process I=92m not sure about this, but I would have presumed one role of = the chair is to help ensure the WG stays within its approved scope. I=92m= asking about this because I believe managing scope is critically = important to the success of this WG and I=92d like to know who plays = what role in helping us stay on track. Thank you. >=20 > This looks to me to be an operational issue with deploying SPF at = scale. This > WG"s charter is pretty specific that we're focusing on issues caused = by "mail > that does not flow from operators having a relationship with the = domain owner, > directly to receivers operating the destination mailbox". I don't see = how this > fits within that scope. >=20 > So, while I'm sympathetic to the difficulties using SPF in this way, > I don't think it's in scope for the present effort. >=20 > Ned The charter also states the WG "will also provide technical = implementation guidance and review possible enhancements elsewhere in = the mail handling sequence that could improve DMARC compatibility.=94 = While I=92m personally not too concerned about deploying SPF at scale, I = am concerned about this particular aspect of the charter and preserving = it. If we forget this aspect of our charter then we are left with = nothing in our toolbox but to change DMARC itself to accommodate MLM=92s = and other "mail that does not flow from operators having a relationship = with the domain owner, directly to receivers operating the destination = mailbox=94 with no ability to at least =93guide=94 other processors = toward practices that would help them improve their compatibility with = DMARC. -Brett From nobody Thu Oct 16 11:44:53 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A387D1A8704 for ; Thu, 16 Oct 2014 11:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujU6IBza1eCz for ; Thu, 16 Oct 2014 11:44:46 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0756B1A8707 for ; Thu, 16 Oct 2014 11:44:45 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id q1so3438853lam.18 for ; Thu, 16 Oct 2014 11:44:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=J2t1K5u5GhqIl+h6wAg2UhPf7F5OyvMOpMN3Qck1asw=; b=zkmku/X93JGkyMGmcwOWiNrILo5FXD/SLU2LB5W4NpmkHaTo1nBzlmdZHIYgxYMtj8 EfHWROLGICGk1l6OQUrgdOqkbmESCbQL1Z11RcpzZOy3RcrxR8N9TPAYP4nhWCjDra8k h5N5eJrx3TE7/yO9knbPQx2KEy6owUnHO5P8wyCNmriBNVAif+o5DvoIhSTO9Vzqcu41 BpuwnZKHpfQTrr5dJ6xhUiZ4Y5WFvJOWNd7BL1UhdNbFRjB1AJB0sS2LHD4beNvkwBY3 FyOjSBgbhV0KUqQDOcLpupuKgffK1TSzmLNxxE3J+93h9eh0dl+x9D1d55WG1fwbrNAR CLuw== MIME-Version: 1.0 X-Received: by 10.152.204.103 with SMTP id kx7mr3615595lac.7.1413485084113; Thu, 16 Oct 2014 11:44:44 -0700 (PDT) Received: by 10.25.211.11 with HTTP; Thu, 16 Oct 2014 11:44:44 -0700 (PDT) In-Reply-To: <5421AA3B.3080607@dcrocker.net> References: <54208E47.9000705@crash.com> <542090CE.7010102@dcrocker.net> <87zjdqxnzy.fsf@uwakimon.sk.tsukuba.ac.jp> <5421AA3B.3080607@dcrocker.net> Date: Thu, 16 Oct 2014 11:44:44 -0700 Message-ID: From: "Murray S. Kucherawy" To: Dave Crocker Content-Type: multipart/alternative; boundary=001a113429ba558cf705058ea40e Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/LobcikR12Q9A4aTjae3Ce591rOU Cc: "Stephen J. Turnbull" , "dmarc@ietf.org" , Steve Jones Subject: Re: [dmarc-ietf] Cataloging MLM manipulations of messages X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 18:44:50 -0000 --001a113429ba558cf705058ea40e Content-Type: text/plain; charset=UTF-8 On Tue, Sep 23, 2014 at 10:13 AM, Dave Crocker wrote: > On 9/23/2014 10:09 AM, Stephen J. Turnbull wrote: > > I suspect such a thing will quickly become obsolete. > > I'm sure it will. The point is that I think it can have utility to get > folks thinking in terms of a potentially wide /range/ of choice, with > the document giving a snapshot in time of choices that have been made. ...much like RFC7103, I would think. Dave? -MSK --001a113429ba558cf705058ea40e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Sep 23, 2014 at 10:13 AM, Dave Crocker <dhc@dcro= cker.net> wrote:
On 9/23/2014 1= 0:09 AM, Stephen J. Turnbull wrote:
> I suspect such a thing will quickly become obsolete.

I'm sure it will.=C2=A0 The point is that I think it can have ut= ility to get
folks thinking in terms of a potentially wide /range/ of choice, with
the document giving a snapshot in time of choices that have been made.

...much like RFC7103, I would think.=C2=A0 Dave= ?

-MSK
--001a113429ba558cf705058ea40e-- From nobody Thu Oct 16 16:17:02 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 265AC1A8AD6 for ; Thu, 16 Oct 2014 16:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wefDZoHsWXA0 for ; Thu, 16 Oct 2014 16:16:59 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDA921A70FD for ; Thu, 16 Oct 2014 16:16:58 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s9GNG5sj005182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 16 Oct 2014 16:16:08 -0700 Message-ID: <544051B3.6080705@dcrocker.net> Date: Thu, 16 Oct 2014 16:16:03 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <54208E47.9000705@crash.com> <542090CE.7010102@dcrocker.net> <87zjdqxnzy.fsf@uwakimon.sk.tsukuba.ac.jp> <5421AA3B.3080607@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Thu, 16 Oct 2014 16:16:08 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/MQKOYziyIPewpcXNZCD8--x3RsQ Cc: "Stephen J. Turnbull" , "dmarc@ietf.org" , Steve Jones Subject: Re: [dmarc-ietf] Cataloging MLM manipulations of messages X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 23:17:00 -0000 On 10/16/2014 11:44 AM, Murray S. Kucherawy wrote: > On Tue, Sep 23, 2014 at 10:13 AM, Dave Crocker > wrote: > > On 9/23/2014 10:09 AM, Stephen J. Turnbull wrote: > > I suspect such a thing will quickly become obsolete. > > I'm sure it will. The point is that I think it can have utility to get > folks thinking in terms of a potentially wide /range/ of choice, with > the document giving a snapshot in time of choices that have been made. > > > ...much like RFC7103, I would think. Dave? ok. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Oct 17 11:36:39 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E3C31A1A10 for ; Fri, 17 Oct 2014 11:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.113 X-Spam-Level: X-Spam-Status: No, score=-0.113 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXRV83Nb7ZZm for ; Fri, 17 Oct 2014 11:36:34 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3D81A1A36 for ; Fri, 17 Oct 2014 11:36:34 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PDUPKGOCRK001QH0@mauve.mrochek.com> for dmarc@ietf.org; Fri, 17 Oct 2014 11:31:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1413570694; bh=9ChXb+/lNDNjOQLq5dcQzR366AlPcik5G/sMjlGvwGU=; h=From:Cc:Date:Subject:In-reply-to:References:To; b=IwAKGFdSZRUXvSa0DPy7N576dabvve1IhjIUEF4Hey22R3e99fEt7+D8CIHg4xCyE bUlwZF/KojAxntxJO9YPq2FxDuLbiaXXD/svgkX6xVkTFtE2utKOR9B+vKALtpbXXk dmLgLzAgkc3R9tt5TVQyxCvvGjVDCnKYFWHmzop8= MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=windows-1252 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PDU0RJGGDS00005L@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dmarc@ietf.org; Fri, 17 Oct 2014 11:31:27 -0700 (PDT) From: ned+dmarc@mrochek.com Message-id: <01PDUPKE1KHQ00005L@mauve.mrochek.com> Date: Fri, 17 Oct 2014 11:09:37 -0700 (PDT) In-reply-to: "Your message dated Wed, 15 Oct 2014 10:30:38 -0400" References: <5436FE09.4050104@sonnection.nl> <20141010041209.2106.qmail@ary.lan> <01PDKQLQAPA200005K@mauve.mrochek.com> To: Brett McDowell Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/0IbDh_EjM33Qk0ADFX050GuU7YE Cc: "R.E.Sonneveld@sonnection.nl" , dmarc , "John R. Levine" , Mike Hammer , ned+dmarc@mrochek.com Subject: Re: [dmarc-ietf] wiki vs. list? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 18:36:37 -0000 > >> An issue that I have been thinking on - and it is the reverse of this > >> discussion - is that it is operationally difficult to maintain accurate SPF > >> records for organizations with a lot of domains where the SPF records vary > >> across the domains. I recently found this situation with one of our domains (an > >> acquisition). This is similar to other situations where organizations are > >> fairly good with adds and changes but not so much with deletes. This isn't > >> anything that can be addressed through an RFC but I think it is worth noting. > > > > > I was surprised to see you take your chair hat off when responding to a > discussion of scope. Being still fairly green when it comes to IETF process > I’m not sure about this, but I would have presumed one role of the chair is to > help ensure the WG stays within its approved scope. Your presumption is correct. > I’m asking about thi because I believe managing scope is critically > important to the success of this WG and I’d like to know who plays what > role in helping us stay on track. Thank you. That would be the chairs. > > This looks to me to be an operational issue with deploying SPF at scale. This > > WG"s charter is pretty specific that we're focusing on issues caused by "mail > > that does not flow from operators having a relationship with the domain owner, > > directly to receivers operating the destination mailbox". I don't see how this > > fits within that scope. > > > > So, while I'm sympathetic to the difficulties using SPF in this way, > > I don't think it's in scope for the present effort. > > > > Ned > The charter also states the WG "will also provide technical implementation > guidance and review possible enhancements elsewhere in the mail handling > sequence that could improve DMARC compatibility.” While I’m personally not too > concerned about deploying SPF at scale, I am concerned about this particular > aspect of the charter and preserving it. If we forget this aspect of our > charter then we are left with nothing in our toolbox but to change DMARC itself > to accommodate MLM’s and other "mail that does not flow from operators having a > relationship with the domain owner, directly to receivers operating the > destination mailbox” with no ability to at least “guide” other processors > toward practices that would help them improve their compatibility with DMARC. So let me see if I understand you correctly. You were surprised that I posted a query (not an assertion) about something being in scope in my capacity as a WG participant rather than as chair. And you are concerned that there be effective scope management. But at the same time you're concerned that we not tighten the scope so much as to exclude implmentation guidance that you view as an important tool in addressing DMARC issues. If that's correct, then I confess I completely fail to understand your concern/point here. The reason I posted as a participant and not as chair was precisely because I *didn't* want to make an ex cathedra statement about the appropriateness of discussing this SPF issue. What I wanted was feedback as to whether or not people consider SPF deployment advice on this issue to be in scope of the WG. I received one private response to that agreeing that it isn't in scope and notihng on the list. And since public discussion of that point has ceased, further consideration of the matter seems moot. Finally, in regards to the implementation advice aspect of our work, and again speaking as a participant, I don't see how this particular issue meets the criteria for that either since it has everything to do with not sending out bogus SPF information and nothing to with with the interaction of SPF with DMARC. Ned From nobody Sat Oct 18 10:06:14 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92BF61A8939 for ; Sat, 18 Oct 2014 10:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sM4sQXY9Us6l for ; Sat, 18 Oct 2014 10:06:12 -0700 (PDT) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32C131A8937 for ; Sat, 18 Oct 2014 10:06:12 -0700 (PDT) Received: by mail-qa0-f49.google.com with SMTP id f12so1764012qad.36 for ; Sat, 18 Oct 2014 10:06:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KLXLbY+UnbBF58LzTdSRbdODjwX/Z55kX3RNLEKqgGw=; b=LI1f6M1z551rn8GAODRNiC2hI2iE6+ifQ4kzkF1ni4sEip29GnEdcgK9u8xf9fuyIR bBxugOSZsBIoNAf2akdSJzZiaboGhITzrang0P18KuN4nu9RMAGgAHUabcNuOKs0GfKb vT87X/EddlOePKxNv5tK96Jz4B9M2WRyef+jFhcqJyC/sMHaD/B2MvsshrCgVcC2auvw kNUu8TvB+wZcKwbNXebDMPpieILE+ewsxPyNpGA3kDx7oe35eJmAIuUtelBHwDemksjQ a5C2dNV3yZTEoIkrhncX9xifEkFnf93c28W7oUrcs3U/SB8ThxBE/TS7lG4tOVclFZaw CYJg== X-Received: by 10.140.95.225 with SMTP id i88mr3741158qge.2.1413651971293; Sat, 18 Oct 2014 10:06:11 -0700 (PDT) Received: from [10.0.1.136] (c-24-91-28-122.hsd1.ma.comcast.net. [24.91.28.122]) by mx.google.com with ESMTPSA id g30sm3641343qgg.1.2014.10.18.10.06.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 18 Oct 2014 10:06:09 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Brett McDowell In-Reply-To: <01PDUPKE1KHQ00005L@mauve.mrochek.com> Date: Sat, 18 Oct 2014 13:06:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5436FE09.4050104@sonnection.nl> <20141010041209.2106.qmail@ary.lan> <01PDKQLQAPA200005K@mauve.mrochek.com> <01PDUPKE1KHQ00005L@mauve.mrochek.com> To: Ned Freed X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/1jp_WC1LGUqnw4OGB-k2zOBJPpc Cc: "R.E.Sonneveld@sonnection.nl" , dmarc , "John R. Levine" , Mike Hammer , ned+dmarc@mrochek.com Subject: Re: [dmarc-ietf] wiki vs. list? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 17:06:13 -0000 > On Oct 17, 2014, at 2:09 PM, Ned Freed wrote: >=20 > So let me see if I understand you correctly. You were surprised that I = posted > a query (not an assertion) about something being in scope in my = capacity > as a WG participant rather than as chair. And you are concerned that > there be effective scope management. Correct. >=20 > But at the same time you're concerned that we not tighten the scope so = much as > to exclude implmentation guidance that you view as an important tool = in > addressing DMARC issues. Correct, and I believe that is consistent with my concern that there be = effective scope management. > If that's correct, then I confess I completely fail to understand your > concern/point here. That is probably because the topic at hand was SPF. To clarify, I was = not trying to weigh-in on SPF at all. I was raising an orthogonal = issue, motivated by how the SPF topic was being discussed vis-a-vis = scope and charter, but entirely unrelated to SPF. =20 > The reason I posted as a participant and not as chair was > precisely because I *didn't* want to make an ex cathedra statement = about the > appropriateness of discussing this SPF issue. I appreciate your approach. I was seeking clarity. I was not trying to = insinuate that you should not have commented as a participant. I just = wanted to be sure I understood who was helping us manage scope = effectively and you clarified that. It=92s all good. Just chalk this = up to me being new to this WG. From nobody Thu Oct 23 11:05:11 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61AE81A9100 for ; Thu, 23 Oct 2014 11:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.102 X-Spam-Level: X-Spam-Status: No, score=-100.102 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YlikGqT6q8F for ; Thu, 23 Oct 2014 11:05:07 -0700 (PDT) Received: from pop3.winserver.com (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id B7A281ACDD3 for ; Thu, 23 Oct 2014 11:05:06 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=5253; t=1414087495; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=FlO7eb4qeQu4rc+Xyp+fwKso3mg=; b=bYF/p9jC9O3htBtBoLbT JZozNIONye3NC1DDsqQS6xulbfGnU7/I3jcr58luj7J9D0Wdys0VsAFIP3C7xMkn NoIkSxr86uBf+0Vxc7F0xwuLqOR/JKuNcngUg3Av3zTG5KY5BvoLz1mEU69RffAm AJC/hWMPX1t7BzU7LnUigX4= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 23 Oct 2014 14:04:55 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from hector.wildcatblog.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 682583065.80081.5276; Thu, 23 Oct 2014 14:04:55 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=5253; t=1414087086; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=GxlJi+r YB62fDOZTNFGZYFODVy/4uIZqy+1bnjC0I8I=; b=SaTWmAnxr6wiydBKXGHEoXx kaDljzDcH8K5Vu/EpFrknyd8k6JjvF8keh2qBrQMqs6MMhZ5WPEjc00F8fZzYbeY 9+JvA1bTvETKnR9g+CCRmF8pgWCU02Oan0u5cUkIo26lwT7ZSNnlmdew0vJjXnKd a5SPwF+XZrjBvf2Ae/5M= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 23 Oct 2014 13:58:06 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3569966532.9.2632; Thu, 23 Oct 2014 13:58:06 -0400 Message-ID: <54494348.4090306@isdg.net> Date: Thu, 23 Oct 2014 14:04:56 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <5436FE09.4050104@sonnection.nl> <20141010041209.2106.qmail@ary.lan> <01PDKQLQAPA200005K@mauve.mrochek.com> <01PDUPKE1KHQ00005L@mauve.mrochek.com> In-Reply-To: <01PDUPKE1KHQ00005L@mauve.mrochek.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/HiEn7ZUubi_Qboc1y85gStWaJeM Subject: Re: [dmarc-ietf] wiki vs. list? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 18:05:09 -0000 I'm already lost of whats going on. It seems we are waiting of Murray. Its all Murray. Geez, Its all really Murray's framework to all this. Not a negative, but there has to be more. There is more. There has always been more, that is why we are lost here after 9 years. We need policy and we are wasting so much time not establishing how DMARC has brought back the importance of a DKIM Policy Framework back into the picture as it always was the case but became unfocused with a 3rd party trust framework, which btw breaks down when no signature is valid, i.e. no valid SDID (Signer Identity) The 1st party author party provides the best pure anchoring information on whats to be expected . If we wish to include 1st party authorization for a list path and/or SPF path, it all needs to be discussed. We always know that DMARC always fails on a SPF failure as well. DMARC = DKIM + SPF So any failure on DKIM or SPF is part of a DKIM failure. If that is not TRUE, then it needs to be part of the discussion. A SPF failure fails DMARC despite how verifiable the DKIM layer is. -- HLS On 10/17/2014 2:09 PM, ned+dmarc@mrochek.com wrote: >>>> An issue that I have been thinking on - and it is the reverse of this >>>> discussion - is that it is operationally difficult to maintain accurate SPF >>>> records for organizations with a lot of domains where the SPF records vary >>>> across the domains. I recently found this situation with one of our domains (an >>>> acquisition). This is similar to other situations where organizations are >>>> fairly good with adds and changes but not so much with deletes. This isn't >>>> anything that can be addressed through an RFC but I think it is worth noting. >>> >>> > >> I was surprised to see you take your chair hat off when responding to a >> discussion of scope. Being still fairly green when it comes to IETF process >> I�m not sure about this, but I would have presumed one role of the chair is to >> help ensure the WG stays within its approved scope. > > Your presumption is correct. > >> I�m asking about thi because I believe managing scope is critically >> important to the success of this WG and I�d like to know who plays what >> role in helping us stay on track. Thank you. > > That would be the chairs. > >>> This looks to me to be an operational issue with deploying SPF at scale. This >>> WG"s charter is pretty specific that we're focusing on issues caused by "mail >>> that does not flow from operators having a relationship with the domain owner, >>> directly to receivers operating the destination mailbox". I don't see how this >>> fits within that scope. >>> >>> So, while I'm sympathetic to the difficulties using SPF in this way, >>> I don't think it's in scope for the present effort. >>> >>> Ned > >> The charter also states the WG "will also provide technical implementation >> guidance and review possible enhancements elsewhere in the mail handling >> sequence that could improve DMARC compatibility.� While I�m personally not too >> concerned about deploying SPF at scale, I am concerned about this particular >> aspect of the charter and preserving it. If we forget this aspect of our >> charter then we are left with nothing in our toolbox but to change DMARC itself >> to accommodate MLM�s and other "mail that does not flow from operators having a >> relationship with the domain owner, directly to receivers operating the >> destination mailbox� with no ability to at least �guide� other processors >> toward practices that would help them improve their compatibility with DMARC. > > So let me see if I understand you correctly. You were surprised that I posted > a query (not an assertion) about something being in scope in my capacity > as a WG participant rather than as chair. And you are concerned that > there be effective scope management. > > But at the same time you're concerned that we not tighten the scope so much as > to exclude implmentation guidance that you view as an important tool in > addressing DMARC issues. > > If that's correct, then I confess I completely fail to understand your > concern/point here. The reason I posted as a participant and not as chair was > precisely because I *didn't* want to make an ex cathedra statement about the > appropriateness of discussing this SPF issue. > > What I wanted was feedback as to whether or not people consider SPF deployment > advice on this issue to be in scope of the WG. I received one private response > to that agreeing that it isn't in scope and notihng on the list. And since > public discussion of that point has ceased, further consideration of the matter > seems moot. > > Finally, in regards to the implementation advice aspect of our work, and again > speaking as a participant, I don't see how this particular issue meets the > criteria for that either since it has everything to do with not sending out > bogus SPF information and nothing to with with the interaction of SPF with > DMARC. > > Ned > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > -- HLS From nobody Thu Oct 23 11:21:17 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AEF01A9138 for ; Thu, 23 Oct 2014 11:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z6HbOawS_Pwq for ; Thu, 23 Oct 2014 11:21:13 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA6751A90FC for ; Thu, 23 Oct 2014 11:21:12 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id n3so2737839wiv.14 for ; Thu, 23 Oct 2014 11:21:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=mE6WHO1t540emeuQm+z8F3YwLqxZztt4pm9uzbHBKAs=; b=bseyXo0HKOslgnOSAfQscmrsrXKAVhtsL3d6jvv7NzJbDnZN9kU160cpgIp+IxQTV8 IKgRZctp6wWFSYXX1Mf3fhV4PxJoWrXR4eg71GE1mkarLr9wohbGJ5v5zDAQI+eEEk8c JFq2KFk/cRbEhx183vPf/xeqaJU+ml5u6hN9k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to:cc:content-type; bh=mE6WHO1t540emeuQm+z8F3YwLqxZztt4pm9uzbHBKAs=; b=WVdlxXeHyDh5AL77+bO8/wwt4V8C1dtBFQPM6mGrifcHtfN/jLy5k8nx2hsftKQ5lo G0zNu+LdvoqAu2TiA9+tNTIM3VbEowjAM21hTITKhxDlSaFaDGch/K541+jBK6ggZsSs uiPrzsP3DbUiMHEhZWts2ZKRKs8PRnhDxEPauTZT6ypvDXyF/2MrKehti4tYzB3HJGDJ sMLAg3P2hTAWat27duZocOYGP8FfnTOfFe1Mw7wf7J8VE7mD0cIRGWXhjcu9J2VEkwh3 YUmA3SNBirfdt15QbgXnrRgV83Yg4iFARM/x4hA2LTuOVrObfJ6gSNA4mGyAInT2mSJn ePXw== X-Gm-Message-State: ALoCoQkG5S1Q76RnsXN2FJoI59neXA8Rp+q7LfWOUM7HdJUsneMzoGtMg/Ib5Kn/fh8l8kbV30fH MIME-Version: 1.0 X-Received: by 10.180.187.44 with SMTP id fp12mr14975315wic.72.1414088469340; Thu, 23 Oct 2014 11:21:09 -0700 (PDT) Sender: kurta@drkurt.com Received: by 10.194.188.115 with HTTP; Thu, 23 Oct 2014 11:21:09 -0700 (PDT) Date: Thu, 23 Oct 2014 14:21:09 -0400 X-Google-Sender-Auth: zCmaLHrIKz4v3UAV3x-8RBgGyAs Message-ID: From: Kurt Andersen To: Hector Santos Content-Type: multipart/alternative; boundary=001a11c38190e5796605061b203b Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/mIpJTgMGK3hgxyI-dnxQaqNhoNg Cc: "dmarc@ietf.org" Subject: [dmarc-ietf] AND vs. OR (was Re: wiki vs. list?) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 18:21:14 -0000 --001a11c38190e5796605061b203b Content-Type: text/plain; charset=UTF-8 On Thu, Oct 23, 2014 at 2:04 PM, Hector Santos wrote: > We always know that DMARC always fails on a SPF failure as well. > > DMARC = DKIM + SPF > > So any failure on DKIM or SPF is part of a DKIM failure. If that is not > TRUE, then it needs to be part of the discussion. A SPF failure fails > DMARC despite how verifiable the DKIM layer is. > This is completely incorrect and false. I'm not sure why the falsity of this contention should be any part of the discussion. DMARC = DKIM ^ SPF not DKIM & SPF. --Kurt Andersen --001a11c38190e5796605061b203b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Thu, Oct 23, 2014 at 2:04 PM, Hector Santos <hsantos@isdg.net> wrote:
We always know that DMARC always fails on a SPF= failure as well.

=C2=A0 =C2=A0DMARC =3D=C2=A0 DKIM + SPF

So any failure on DKIM or SPF is part of a DKIM failure.=C2=A0 If that is n= ot TRUE, then it needs to be part of the discussion.=C2=A0 A SPF failure fa= ils DMARC despite how verifiable the DKIM layer is.


This is completely incorrect and = false. I'm not sure why the falsity of this contention should be any pa= rt of the discussion. DMARC =3D DKIM ^ SPF not DKIM & SPF.

--Kurt Andersen
--001a11c38190e5796605061b203b-- From nobody Thu Oct 23 15:14:12 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4142A1A6EE5 for ; Thu, 23 Oct 2014 15:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ihj5xjP61zno for ; Thu, 23 Oct 2014 15:14:04 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 434EB1A1B35 for ; Thu, 23 Oct 2014 15:14:04 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id mc6so1679963lab.30 for ; Thu, 23 Oct 2014 15:14:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KIYVE+3PxXlyvEx2XkDPaxPa+YxKlxc9cdngmyeKCqs=; b=cOjT6FlePKkBkIwzdruTujeDfla0SO73RrUSxTVHsY/XiwZcM3I55F8x9zCavRtt0P 9ggdLYxpLtDY5XYhTQetQu9SE1tQS3QZqXwKJMx0ue2y+x2tC7e6G2/wPXHAw44VGi/l VhYt8G1gXIKALrIlH0VROVBgnz/OTKu01PxfMkFSgq5/DVTz6C01/cj1LnaeIXWsOnFa wY+1wOFIDBhReHBPcJedxYrRNnoeeXQC7Q2SGwfD4TCG2owNoMiJyuRUEww0TTTFrfLz TfSrkWfdMy97lmRAy6B5jBlznH7n3MAd8qjQVuHlmVebljCsTGt1DnBbiysAT6NrKPXN F76w== MIME-Version: 1.0 X-Received: by 10.152.36.230 with SMTP id t6mr397982laj.88.1414102442527; Thu, 23 Oct 2014 15:14:02 -0700 (PDT) Received: by 10.25.14.205 with HTTP; Thu, 23 Oct 2014 15:14:02 -0700 (PDT) In-Reply-To: <54494348.4090306@isdg.net> References: <5436FE09.4050104@sonnection.nl> <20141010041209.2106.qmail@ary.lan> <01PDKQLQAPA200005K@mauve.mrochek.com> <01PDUPKE1KHQ00005L@mauve.mrochek.com> <54494348.4090306@isdg.net> Date: Thu, 23 Oct 2014 15:14:02 -0700 Message-ID: From: "Murray S. Kucherawy" To: Hector Santos Content-Type: multipart/alternative; boundary=089e0160c0dcc3510005061e618a Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/xM4r3RH1BEw57BqFRv9dtZJZbJA Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] wiki vs. list? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 22:14:06 -0000 --089e0160c0dcc3510005061e618a Content-Type: text/plain; charset=UTF-8 On Thu, Oct 23, 2014 at 11:04 AM, Hector Santos wrote: > I'm already lost of whats going on. It seems we are waiting of Murray. Its > all Murray. Geez, Its all really Murray's framework to all this. Not a > negative, but there has to be more. There is more. There has always been > more, that is why we are lost here after 9 years. > Sorry, but I have no idea what this is about. The only thing I think anyone's waiting on me for is a revision to draft-kucherawy-dmarc-base for publication as an RFC through the ISE. It will contain no technical changes, so either way, this WG shouldn't be blocked waiting on me for anything. Confused, -MSK --089e0160c0dcc3510005061e618a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Oct 23, 2014 at 11:04 AM, Hector Santos <hsantos@= isdg.net> wrote:
I'm already lost of whats g= oing on. It seems we are waiting of Murray. Its all Murray. Geez, Its all r= eally Murray's framework to all this. Not a negative, but there has to = be more.=C2=A0 There is more. There has always been more, that is why we ar= e lost here after 9 years.

Sorry, but I= have no idea what this is about.=C2=A0 The only thing I think anyone's= waiting on me for is a revision to draft-kucherawy-dmarc-base for publicat= ion as an RFC through the ISE.=C2=A0 It will contain no technical changes, = so either way, this WG shouldn't be blocked waiting on me for anything.=

Confused,
-MSK
--089e0160c0dcc3510005061e618a-- From nobody Thu Oct 23 15:50:20 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FCB81A873F for ; Thu, 23 Oct 2014 15:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.209 X-Spam-Level: * X-Spam-Status: No, score=1.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_16=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQgFtQxicpss for ; Thu, 23 Oct 2014 15:50:12 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id DF0151A8731 for ; Thu, 23 Oct 2014 15:50:11 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id A6EA11C3CC3; Fri, 24 Oct 2014 07:50:10 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 98D291A2D06; Fri, 24 Oct 2014 07:50:10 +0900 (JST) From: "Stephen J. Turnbull" To: "Murray S. Kucherawy" In-Reply-To: References: <5436FE09.4050104@sonnection.nl> <20141010041209.2106.qmail@ary.lan> <01PDKQLQAPA200005K@mauve.mrochek.com> <01PDUPKE1KHQ00005L@mauve.mrochek.com> <54494348.4090306@isdg.net> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Fri, 24 Oct 2014 07:50:10 +0900 Message-ID: <871tpyieot.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/akmt0Rj0j5dSaQXMBx2rBp7WnL0 Cc: "dmarc@ietf.org" , Hector Santos Subject: Re: [dmarc-ietf] wiki vs. list? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 22:50:14 -0000 Murray S. Kucherawy writes: > On Thu, Oct 23, 2014 at 11:04 AM, Hector Santos wrote: > > > I'm already lost of whats going on. It seems we are waiting of Murray. Its > > all Murray. Geez, Its all really Murray's framework to all this. Not a > > negative, but there has to be more. There is more. There has always been > > more, that is why we are lost here after 9 years. > > > > Sorry, but I have no idea what this is about. The only thing I think > anyone's waiting on me for is a revision to draft-kucherawy-dmarc-base for > publication as an RFC through the ISE. It will contain no technical > changes, so either way, this WG shouldn't be blocked waiting on me for > anything. +1. I don't think it's blocked on Murray; I certainly am not waiting on Murray (or anybody else) for anything. I just don't have time to do much more than I already have done, nor any pressing new ideas that make it worth sacrificing other work to get them out in front of people immediately. As for the "there is more", I don't agree with your position on Domain Owner control of all uses of mailboxes. As I see it, most Domains where the mailboxes are primarily for transactional mail flows already have that control and enforce it externally to Internet standards, and p=reject works fine for them. Domains where the mailboxes are used by individuals for personal use don't have the control and can't exercise it, and another Internet standard won't help -- it will be honored more in the breach than the observance just as Yahoo!'s "p=reject" is already. I gather that most WG participants are closer to my position than to yours, which is why no progress is being made in the direction you think best. You're going to have to stop asserting your position, and start persuading others of its correctness, if you want to move discussion in that direction. Regards, Steve From nobody Thu Oct 23 16:16:14 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95F661A6F21 for ; Thu, 23 Oct 2014 16:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_AFFORDABLE=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stlc5ZJYwVXN for ; Thu, 23 Oct 2014 16:16:10 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B4DD1A6EFB for ; Thu, 23 Oct 2014 16:16:09 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id r10so339959pdi.3 for ; Thu, 23 Oct 2014 16:16:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=6OoZxH2KsivVycoGAJ1mJbTwu/xotDicfEs7tY2JPKs=; b=ccguOpU6OOHWDjIboFQVmL7gtM5qrhpMN6BhYB2+alb4oYGB6v1i2Q+/mwM8qfiMxj tmptvf9nqgxJWR4rxnp0W8xCiFIB2BkxqR8FDra8SsrFYDCD6Fw8WIDROcc65QyiPvCk c90c6by3vlFfOWcuF4nDn60ekkdcC2WE1tse4LxXE2mfknDNX0ivpr2zFEx3DG5HQ1TK cNte/FnKWAvhEhU7prKhUf9gnIXsudaIw2Ca3+SkI4nbymXtuNTobEoXcti4wshR1u5K xd1IEHlU5zNZLyntlQTSIZ51hK0uVYShW27mLCp3X8I8a8z7vaFoPSPgEHb+76B84n+q R9qQ== X-Received: by 10.70.129.46 with SMTP id nt14mr574436pdb.73.1414106169671; Thu, 23 Oct 2014 16:16:09 -0700 (PDT) Received: from [192.168.2.234] (c-67-188-1-12.hsd1.ca.comcast.net. [67.188.1.12]) by mx.google.com with ESMTPSA id ib8sm2430598pad.43.2014.10.23.16.16.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 Oct 2014 16:16:08 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_3D943D14-5713-4384-A3A7-BF8E07FE6E9C" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Douglas Otis In-Reply-To: Date: Thu, 23 Oct 2014 16:16:06 -0700 Message-Id: References: <5436FE09.4050104@sonnection.nl> <20141010041209.2106.qmail@ary.lan> <01PDKQLQAPA200005K@mauve.mrochek.com> <01PDUPKE1KHQ00005L@mauve.mrochek.com> <54494348.4090306@isdg.net> To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/X-4vPUKzIxOVlq8XgpmRLzG_cCs Cc: "dmarc@ietf.org" , Hector Santos , Douglas Otis Subject: Re: [dmarc-ietf] wiki vs. list? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 23:16:11 -0000 --Apple-Mail=_3D943D14-5713-4384-A3A7-BF8E07FE6E9C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear Hector and Murray, Those in a good position to deal with an abuse problem don't want = resulting disruptions seen as being within their bailiwick. Instead = expect documentation explaining why it is not affordable for DMARC = domains to directly deal with their policy induced disruptions of = legitimate email, such as discussion forums and other third-party = services employed by their users. Without taking ownership, results of = this WG efforts seem at best modest changes in the nature of abuse while = disrupting many valuable and legitimate email services. There is a = genuine scaling concern when suggested solutions expect millions of = users to "vote with their feet". Without taking greater ownership as = permitted by schemes like TPA-Label, or allowing valid and compatible = exceptions such as a permitted and conditional group syntax policy = exclusion, is there another reasonable strategy to be moved forward? I'll be the first to say expanding on SPF authorized address list won't = work, but related limitations can be avoided with a cacheable domain = hash list. This approach would be more proactive at curtailing abuse = and we would like to help large ISPs prove the feasibility of this = strategy. Then again, perhaps a rewriting scheme would be able to = safely deal with =46rom domain conflicts without use of a broken alias = scheme such as *.invalid. In that light, a group syntax scheme seems = much less problematic. How does the base document currently deal with = this valid form of email? Regards, Douglas Otis =20 On Oct 23, 2014, at 3:14 PM, Murray S. Kucherawy = wrote: > On Thu, Oct 23, 2014 at 11:04 AM, Hector Santos = wrote: > I'm already lost of whats going on. It seems we are waiting of Murray. = Its all Murray. Geez, Its all really Murray's framework to all this. Not = a negative, but there has to be more. There is more. There has always = been more, that is why we are lost here after 9 years. >=20 > Sorry, but I have no idea what this is about. The only thing I think = anyone's waiting on me for is a revision to draft-kucherawy-dmarc-base = for publication as an RFC through the ISE. It will contain no technical = changes, so either way, this WG shouldn't be blocked waiting on me for = anything. >=20 > Confused, > -MSK=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc --Apple-Mail=_3D943D14-5713-4384-A3A7-BF8E07FE6E9C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear = Hector and Murray,

Those in a good position to deal = with an abuse problem don't want resulting disruptions seen as being = within their bailiwick.  Instead expect documentation explaining = why it is not affordable for DMARC domains to directly deal with their = policy induced disruptions of legitimate email, such as discussion = forums and other third-party services employed by their users. =  Without taking ownership, results of this WG efforts seem at best = modest changes in the nature of abuse while disrupting many valuable and = legitimate email services.  There is a genuine scaling concern when = suggested solutions expect millions of users to "vote with their feet". =  Without taking greater ownership as permitted by schemes like = TPA-Label, or allowing valid and compatible exceptions such as a = permitted and conditional group syntax policy exclusion, is there = another reasonable strategy to be moved = forward?

I'll be the first to say expanding on = SPF authorized address list won't work, but related limitations can be = avoided with a cacheable domain hash list.  This approach would be = more proactive at curtailing abuse and we would like to help large ISPs = prove the feasibility of this strategy.  Then again, perhaps a = rewriting scheme would be able to safely deal with =46rom domain = conflicts without use of a broken alias scheme such as  *.invalid. =  In that light, a group syntax scheme seems much less problematic. =  How does the base document currently deal with this valid form of = email?

Regards,
Douglas = Otis

  
On = Oct 23, 2014, at 3:14 PM, Murray S. Kucherawy <superuser@gmail.com> = wrote:

On Thu, Oct 23, 2014 at 11:04 AM, Hector = Santos <hsantos@isdg.net> wrote:
I'm already lost of whats going on. It seems we = are waiting of Murray. Its all Murray. Geez, Its all really Murray's = framework to all this. Not a negative, but there has to be more.  = There is more. There has always been more, that is why we are lost here = after 9 years.

Sorry, but I have no = idea what this is about.  The only thing I think anyone's waiting = on me for is a revision to draft-kucherawy-dmarc-base for publication as = an RFC through the ISE.  It will contain no technical changes, so = either way, this WG shouldn't be blocked waiting on me for = anything.

Confused,
-MSK =
_______________________________________________
dmarc mailing = list
dmarc@ietf.org
https://www.ietf.org/= mailman/listinfo/dmarc

= --Apple-Mail=_3D943D14-5713-4384-A3A7-BF8E07FE6E9C-- From nobody Fri Oct 24 05:11:11 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCD3D1A8A82 for ; Fri, 24 Oct 2014 05:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.137 X-Spam-Level: X-Spam-Status: No, score=-101.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mT9-tnkkta5Y for ; Fri, 24 Oct 2014 05:11:05 -0700 (PDT) Received: from ntbbs.santronics.com (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id F1B031A7001 for ; Fri, 24 Oct 2014 05:11:04 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2282; t=1414152657; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=zSwbL8MKE2cvcYpUB3v9Z4OZXBQ=; b=jjO5cNaKAKsP4HHtqIk9 LW/30bKjxULPl/D+8MVfCnjHlSTUi+YaTBoHhAJ0BLkOHv78064Fc5HSjwrOnzfM IOsSiMXL3Yx+YbfJoyZ7vTtDWoPA9izROEoACJTzfFyqtvT/29abigadRYyd6toG 63bxcbpkRdC7A68wOccoXuU= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Fri, 24 Oct 2014 08:10:57 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 747743950.81236.4052; Fri, 24 Oct 2014 08:10:56 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2282; t=1414152249; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=l1P2TvF 1TIJID/F/Gx4MS0fnWTsCILWDcM2TZ1qqCfQ=; b=Cqp+XSBCwuCXvRvctPljTTP buR5mtcaMQe7OGn5EYdKDI5JH8qEGvbczv/9lGJAC6s1/9eVPoLbRH+AUkhxYkyA RhtHaUJIRbyMS+9sYWiAsqgYCk6dOZwq9DegT2KOMvFjIFvyoJTk3tCQLdj8Kqou zXZsytrNmnAXXmSPpDjw= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Fri, 24 Oct 2014 08:04:09 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3635128891.9.6888; Fri, 24 Oct 2014 08:04:08 -0400 Message-ID: <544A41D4.2000206@isdg.net> Date: Fri, 24 Oct 2014 08:11:00 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Kurt Andersen References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/O_21T-GevELfJsESi8QhomkvTNY Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] AND vs. OR (was Re: wiki vs. list?) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 12:11:09 -0000 Hi Kurt, If we are going to be picky about logic, then lets consider the symbolic correctness with short circuiting optimization, and it would be: DMARC = SPF or DKIM which can be computed with a plus ('+') not with a caret ('^'). A caret symbolically represents an "exclusive or" logic [1] within many languages, i.e. C/C++ and finally SPF would be first computed logic for short circuiting. I think there is a major presumption that processing DMARC requires the SMTP processor to delay its SMTP Level (before DATA) SPF processing until the PAYLOAD is receive, i.e. wait until the DKIM can be processed and 5322.From domain can read to lookup the DMARC AUTHOR DOMAIN POLICY. The practical reality is that SPF will most likely be processed first by implementations of SPF at the SMTP level before DATA is reached. But until DMARC, SPF never needed the PAYLOAD. Actually, if your package is still supporting SENDER-ID, it could be delaying SPF until the payload is reached or it supports the optimizing extended SMTP extension, the SUBMITTER protocol [2]. Murray always wanted to delay SPF processing or at least get actually explicit assistance from a "Domain Policy" to determine how to handle a SPF failure. Remember that idea of rejections due to SPF fails was argued and weaken down in the original SPF specs. Have a great day, Mr. Andersen. -- HLS [1] http://msdn.microsoft.com/en-us/library/3akey979.aspx [2] http://tools.ietf.org/html/rfc4405 On 10/23/2014 2:21 PM, Kurt Andersen wrote: > On Thu, Oct 23, 2014 at 2:04 PM, Hector Santos wrote: > >> We always know that DMARC always fails on a SPF failure as well. >> >> DMARC = DKIM + SPF >> >> So any failure on DKIM or SPF is part of a DKIM failure. If that is not >> TRUE, then it needs to be part of the discussion. A SPF failure fails >> DMARC despite how verifiable the DKIM layer is. >> > > > This is completely incorrect and false. I'm not sure why the falsity of > this contention should be any part of the discussion. DMARC = DKIM ^ SPF > not DKIM & SPF. > > --Kurt Andersen > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > From nobody Fri Oct 24 05:19:49 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF2D51A8AEF for ; Fri, 24 Oct 2014 05:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.401 X-Spam-Level: X-Spam-Status: No, score=-101.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64Zg8mZRYxQr for ; Fri, 24 Oct 2014 05:19:39 -0700 (PDT) Received: from ntbbs.santronics.com (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id BFCF81A8AA4 for ; Fri, 24 Oct 2014 05:19:34 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2847; t=1414153173; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=2dr0fjVxI37bD3UQuwmVy31c7s0=; b=NGyy92QH2oJdF9NHioGd hqMYCCYjKQqVYyJ5iZMfYjn8O327+01RlPM+ydHK0oIWNMvomFzXwm6sVEQC8Uh4 D3PwFmdEdjSXXNa3H5tU9XGVsAsyAQ2k+VOK6VSHQhRqo6z6oRS6P0hAppkBAg+T +6Y5n4XlqyLn49Thhx4pw0s= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Fri, 24 Oct 2014 08:19:33 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 748259252.81236.3980; Fri, 24 Oct 2014 08:19:31 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2847; t=1414152761; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=lV/b9Cx VrVPAJUjwzqIr+avVDrSI+IHJdBfj5rbsXNM=; b=Jfp/ZDXxLx7PWrOsN490Kqj GucifiCi7AqAlLsbr+L/Q9NKNUmv6PmucgmsYjR5qf17+kNJ0Cj85VnHiidq5rc2 rzyZJL+LfBPqI9sODkp8EUi4JxqqSrGur2/9zKBGLS6T5yxIzUI+7t7BMCDVuuik gAKU3m/pTLpFQpEBmtu8= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Fri, 24 Oct 2014 08:12:41 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3635640469.9.4796; Fri, 24 Oct 2014 08:12:40 -0400 Message-ID: <544A43D4.5070903@isdg.net> Date: Fri, 24 Oct 2014 08:19:32 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Stephen J. Turnbull" , "Murray S. Kucherawy" References: <5436FE09.4050104@sonnection.nl> <20141010041209.2106.qmail@ary.lan> <01PDKQLQAPA200005K@mauve.mrochek.com> <01PDUPKE1KHQ00005L@mauve.mrochek.com> <54494348.4090306@isdg.net> <871tpyieot.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <871tpyieot.fsf@uwakimon.sk.tsukuba.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Yh3xCQZx5m-GJo3eS8TCU9qNtEQ Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] wiki vs. list? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 12:19:42 -0000 Stephen, This is not about you and me. POLICY has been reestablished as the DKIM framework long ago. It just had taking a white before its impact was felt. Things were neglected and we are here today to finally try to resolve the issues for LIST operators. But DKIM DOMAIN POLICY is HERE. No need to prove that anymore. Doug's TPA proposal is now officially part of the charter. I wanted Murray's simpler version of the solution for the 3rd party extension. TPA is actually very simple, the spec is complex. So if that is where we go, we go. But until them are we wasting time? Yes, I think so. Thanks and have a great day. -- HLS On 10/23/2014 6:50 PM, Stephen J. Turnbull wrote: > Murray S. Kucherawy writes: > > On Thu, Oct 23, 2014 at 11:04 AM, Hector Santos wrote: > > > > > I'm already lost of whats going on. It seems we are waiting of Murray. Its > > > all Murray. Geez, Its all really Murray's framework to all this. Not a > > > negative, but there has to be more. There is more. There has always been > > > more, that is why we are lost here after 9 years. > > > > > > > Sorry, but I have no idea what this is about. The only thing I think > > anyone's waiting on me for is a revision to draft-kucherawy-dmarc-base for > > publication as an RFC through the ISE. It will contain no technical > > changes, so either way, this WG shouldn't be blocked waiting on me for > > anything. > > +1. I don't think it's blocked on Murray; I certainly am not waiting > on Murray (or anybody else) for anything. I just don't have time to > do much more than I already have done, nor any pressing new ideas that > make it worth sacrificing other work to get them out in front of > people immediately. > > As for the "there is more", I don't agree with your position on Domain > Owner control of all uses of mailboxes. As I see it, most Domains > where the mailboxes are primarily for transactional mail flows already > have that control and enforce it externally to Internet standards, and > p=reject works fine for them. Domains where the mailboxes are used by > individuals for personal use don't have the control and can't exercise > it, and another Internet standard won't help -- it will be honored > more in the breach than the observance just as Yahoo!'s "p=reject" is > already. > > I gather that most WG participants are closer to my position than to > yours, which is why no progress is being made in the direction you > think best. You're going to have to stop asserting your position, and > start persuading others of its correctness, if you want to move > discussion in that direction. > > Regards, > Steve > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > From nobody Fri Oct 24 07:09:22 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3890D1A01FA for ; Fri, 24 Oct 2014 07:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.138 X-Spam-Level: X-Spam-Status: No, score=-100.138 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_AFFORDABLE=1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 508f9WMdHyxF for ; Fri, 24 Oct 2014 07:09:10 -0700 (PDT) Received: from listserv.winserver.com (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 808321A0097 for ; Fri, 24 Oct 2014 07:08:06 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4268; t=1414159678; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=aO4M3nyQEI5A3tw1jkkLiLFPFzw=; b=SuL0fZnBRIA7S4tUAdqQ qlU5M7Iff1ofUMpz9HlB4Ow8hrtmbIFkHEYfbi7z+u3TQStQ1Hzhe/z1oLXnFP1K lThjRTwSbf/Cc8ApXoxl5QEg4q5hZ6qeCicQm2kgOMUw8ZOuPfAFZlBfWRU4zctd JEdi0jFyrZgQiN834NaPiSE= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Fri, 24 Oct 2014 10:07:58 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 754764603.81236.3292; Fri, 24 Oct 2014 10:07:57 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4268; t=1414159267; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=jIiMSZj oZRBdSVXWveNaTS0QPzjB8tyTRmh2a452CKk=; b=RVDTWZ0ShCBEPh0fP3bQzxg sFvlYs55YIgSaW1r7kKeSsyTBrQFs+fuAYHsw8Od5/HB3PpXHSCoZOj2CPLGZjJt 8iTK5JJbNZ8P0l6rXSkXLOM/nlg1MxN4c7QB/DvvKjJSf43Q8XbPDkn5ukjz8j1p 4T2vfiJNb9bYwya1qYBs= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Fri, 24 Oct 2014 10:01:07 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3642146735.9.4492; Fri, 24 Oct 2014 10:01:06 -0400 Message-ID: <544A5D3E.1050300@isdg.net> Date: Fri, 24 Oct 2014 10:07:58 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Douglas Otis , "Murray S. Kucherawy" References: <5436FE09.4050104@sonnection.nl> <20141010041209.2106.qmail@ary.lan> <01PDKQLQAPA200005K@mauve.mrochek.com> <01PDUPKE1KHQ00005L@mauve.mrochek.com> <54494348.4090306@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/48jPU31lFWi9hZq4kGduIAwxQ9E Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] wiki vs. list? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 14:09:14 -0000 On 10/23/2014 7:16 PM, Douglas Otis wrote: > Dear Hector and Murray, > > Those in a good position to deal with an abuse problem don't want resulting disruptions seen as being within their bailiwick. Instead expect documentation explaining why it is not affordable for DMARC domains to directly deal with their policy induced disruptions of legitimate email, such as discussion forums and other third-party services employed by their users. Without taking ownership, results of this WG efforts seem at best modest changes in the nature of abuse while disrupting many valuable and legitimate email services. There is a genuine scaling concern when suggested solutions expect millions of users to "vote with their feet". Without taking greater ownership as permitted by schemes like TPA-Label, or allowing valid and compatible exceptions such as a permitted and conditional group syntax policy exclusion, is there another reasonable strategy to be moved forward? > All I am saying it needs to be part of the protocol framework so that implementators provide it as operational choice to admins, sysops and list operators who are looking and waiting for these software changes to take place. Otherwise most of them are clueness about what's going on. First, its complex. To the layman, its either ON and OFF and if ON, automated to the point where there is minimal false positives. I prefer ZERO false positive because it minimizes the support cost for our small low overhead software company. But on occasion, an operator will find a frustrating reason to the turn off the "out of the box" AVS feattures. Some do only to find there spam problem is worst, so it goes back on. But for most, along with an advanced Greylisting system, Callback Verifiers, etc, for nearly 10 years now, with very little negative impact, its all on auto-pilot. Of course, if I was to add DMARC by replacing or adding it to the current ADSP+ATPS+ASL framework, I will immediately have to consider this stupid rewrite thing. But thats it, consider it, no way I will help contribute to opening Pandora's box here. If I do, only to give the 3rd party developers an API way to script it themselves. But not built-in, out of the box, for operators. Too problematic and I have a strong feeling it goes to bite people here in the future. I advise the younger mail engineers to reconsider the product design ethical choices being made here. > I'll be the first to say expanding on SPF authorized address list won't work, but related limitations can be avoided with a cacheable domain hash list. This approach would be more proactive at curtailing abuse and we would like to help large ISPs prove the feasibility of this strategy. Then again, perhaps a rewriting scheme would be able to safely deal with From domain conflicts without use of a broken alias scheme such as *.invalid. In that light, a group syntax scheme seems much less problematic. How does the base document currently deal with this valid form of email? > Consideration of rewriting MUST come with the Authorizing Domain Expectation and Authorization to do so or if the policy is relax or non-existing, the default, it would implicitly allow for any operation to take place on its domain, i.e no strong controls. Its going to be a very complex change and for more complex than just having a "database" of authorized list. That is simpler, i.e. create a database for simple queries. Today, we currently lean towards doing this with DNS with TXT based DNS Applications. But there is no reason why it can't be an other socket port protocol, UDP/TCP, whatever, if its more optimal to do so. Whatever, it can be done. Our small company did it. Any big company it can handle it too. But DNS is fine too. Is this a BIG DATA problem? I am suppose to believe that the "Yahoo's" don't have the engineering to explore if they can't handle the high potential of 30,000 list to authorized? Its going to take a while for them to even collect them. I bet its very limited, 500? 1000? Maybe just 40. Whatever. Its doable folks, the software dudes at these "BIG" companies are not exploring enough. The Project R&D was done!! Where is the Product R&D? Have a great day guys. -- HLS From nobody Fri Oct 24 07:22:52 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA78C1A0204 for ; Fri, 24 Oct 2014 07:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.519 X-Spam-Level: X-Spam-Status: No, score=0.519 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, MISSING_HEADERS=1.021, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AuDASGULb_Ke for ; Fri, 24 Oct 2014 07:22:49 -0700 (PDT) Received: from server1.neighborhoods.net (server1.neighborhoods.net [207.154.13.48]) by ietfa.amsl.com (Postfix) with ESMTP id E994B1A01EC for ; Fri, 24 Oct 2014 07:22:45 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by server1.neighborhoods.net (Postfix) with ESMTP id 13429CC166 for ; Fri, 24 Oct 2014 10:22:45 -0400 (EDT) X-Virus-Scanned: by amavisd-new-2.6.2 (20081215) (Debian) at neighborhoods.net Received: from server1.neighborhoods.net ([127.0.0.1]) by localhost (server1.neighborhoods.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id i4ebhdm0Xnwa for ; Fri, 24 Oct 2014 10:22:36 -0400 (EDT) Received: from new-host.home (pool-96-237-159-213.bstnma.fios.verizon.net [96.237.159.213]) by server1.neighborhoods.net (Postfix) with ESMTPSA id 3ADD0CC163 for ; Fri, 24 Oct 2014 10:22:36 -0400 (EDT) Message-ID: <544A60AB.3020308@meetinghouse.net> Date: Fri, 24 Oct 2014 10:22:35 -0400 From: Miles Fidelman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:33.0) Gecko/20100101 Firefox/33.0 SeaMonkey/2.30 MIME-Version: 1.0 CC: "dmarc@ietf.org" References: <544A41D4.2000206@isdg.net> In-Reply-To: <544A41D4.2000206@isdg.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/4m-e2dBA88nFOrPY29JMzmHkCjY Subject: Re: [dmarc-ietf] AND vs. OR (was Re: wiki vs. list?) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 14:22:50 -0000 Hector Santos wrote: > Hi Kurt, > > If we are going to be picky about logic, then lets consider the > symbolic correctness with short circuiting optimization, and it would be: > > DMARC = SPF or DKIM > Am I missing something here? As I understand it, DMARC is MORE than SPF and DKIM. Specifically, as I understand it, sender field alignment, that's bit all of us who run mailing lists, is specific to DMARC. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From nobody Fri Oct 24 07:54:38 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 167C91A19EE for ; Fri, 24 Oct 2014 07:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ai_RuxLfvmrO for ; Fri, 24 Oct 2014 07:54:33 -0700 (PDT) Received: from server1.neighborhoods.net (server1.neighborhoods.net [207.154.13.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0754C1A19EB for ; Fri, 24 Oct 2014 07:54:32 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by server1.neighborhoods.net (Postfix) with ESMTP id 02EA0CC162 for ; Fri, 24 Oct 2014 10:54:32 -0400 (EDT) X-Virus-Scanned: by amavisd-new-2.6.2 (20081215) (Debian) at neighborhoods.net Received: from server1.neighborhoods.net ([127.0.0.1]) by localhost (server1.neighborhoods.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id FI7jG8kgjidM for ; Fri, 24 Oct 2014 10:54:23 -0400 (EDT) Received: from new-host.home (pool-96-237-159-213.bstnma.fios.verizon.net [96.237.159.213]) by server1.neighborhoods.net (Postfix) with ESMTPSA id 2F66CCC135 for ; Fri, 24 Oct 2014 10:54:23 -0400 (EDT) Message-ID: <544A681E.1000500@meetinghouse.net> Date: Fri, 24 Oct 2014 10:54:22 -0400 From: Miles Fidelman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:33.0) Gecko/20100101 Firefox/33.0 SeaMonkey/2.30 MIME-Version: 1.0 To: "dmarc@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/JlH7--mV-mwllZtilRuUTLgN3QA Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 14:54:36 -0000 Can we step back from the weeds, for a second and talk practicalities? The suggestion that started this thread was to add a List-* header to indicate the original author of a mailing list posting - in order to, hopefully, lead to MUAs that make it easier to reply to that original author. The discussion has quickly wandered into discussion that seems to be very far from the original suggestion. Speaking as one who both is on a bunch of mailing lists, and who hosts a bunch of mailing lists, the suggestion strikes me as almost a no-brainer. It solves a very big problem, in a very straightforward way. 1. Right now, for mailing lists that munge DMARC damage (pretty much all lists at this point, as far as I can tell), and depending on MUA, about the only way to reply to the original author of a message is to actually find the original author's address and manually cut and paste it into the To: field of your reply. Not all that easy for non-technical folk (at least based on support questions I get). 2. RFC2369 - 16 years old now - specifies a short list of List-*headers that are incredibly useful for things like finding list archives, finding list help, unsubscribing, etc. - not all MUAs support them directly, but, - they're easy to find, simply by looking in the headers - in most GUI-based MUAs, they're easy to use - simply click on an exposed URL (how I typically get to the archive of this list, for example) - by being standardized, it makes it easier, and hence more likely, that MUA developers might start adding "reply to list" and "reply to author" buttons in their interfaces 3. More important, perhaps, is that if we simply picked a name, and standardized a "List-original-author:" header - it would allow the SMALL NUMBER of mailing list software developers (mailman, sympa, ezmlm, a few more) to support that header, probably in the same code module where they already support the existing RFC239 headers. I expect that within a week of agreeing on a field name, all the major mailing list managers would have patches written. Unless I'm missing something, there's no downside. Which leads to the purely procedural question: What would be the most straightforward process for writing and promulgating an RFC that essentially updates RFC2369 by adding one section that defines an additional header to the current list of List-* headers? Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From nobody Fri Oct 24 08:24:23 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FCCD1A0364 for ; Fri, 24 Oct 2014 08:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.138 X-Spam-Level: X-Spam-Status: No, score=-101.138 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T502UuIlfitU for ; Fri, 24 Oct 2014 08:24:17 -0700 (PDT) Received: from mail.winserver.com (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 124CB1A00D6 for ; Fri, 24 Oct 2014 08:24:16 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3507; t=1414164253; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=QN3IQok5KxSmofMpZhsKOmjxFBs=; b=EfkEapGBQkzv1tmESm/t p9lupa3lVcCmZcbeUhAgboFM96S6s+VAOLwMIWFxjoScvZtCyk9h44TMgqFUxucl b0cvfxgrm/9V0KCn4gbwyPLYkEPlxJfrnM/sCIbuRf7kjuX64DePXztaLL97OmZb tJSwjkoA1AeRzhGhEUxEKZc= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Fri, 24 Oct 2014 11:24:13 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 759340003.81236.4080; Fri, 24 Oct 2014 11:24:12 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3507; t=1414163843; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=nWdDtjv MXVhKc0FXFyqOAELtsqhZIdYUUHbQCP0NVQ0=; b=C4xKKGbELJ5eJHyKano0XHQ 4AnAJf/V4UN78ywADshPvqbVt8f/n+Mkywpz9E9xUWCfnaqvhTzzbMAIUoLR/69x XPTndIUxwTIcrqfO7b9RjbzIC6W7Dh9bwCM1w5JKAPMT9t429FPkU+rKi/QIPtwG rWbI52RoJBPT9wAJP/oU= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Fri, 24 Oct 2014 11:17:23 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3646723157.9.3696; Fri, 24 Oct 2014 11:17:22 -0400 Message-ID: <544A6F1F.10407@isdg.net> Date: Fri, 24 Oct 2014 11:24:15 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Miles Fidelman , "dmarc@ietf.org" References: <544A681E.1000500@meetinghouse.net> In-Reply-To: <544A681E.1000500@meetinghouse.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/725bE6r_YE3UvewcuDe_Y-NZjIQ Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 15:24:20 -0000 Adding a new List-XXXXX for the original author is based on the premise that the 5322.From header will therefore be open for destruction. That means there is a new dependency on future verifiers and MUAs to support the List-XXXXXX header in order to make a "tie-in," hopefully, verifiable, which means a LOOKUP is necessary anyway. A POLICY lookup is needed no matter what -- in order to maintain some sort of security control. If its done open ended, it will be leveraged and abuse across other areas -- we will see more this "List-XXXXX" in mail in order to give the "illusion" that the mail is ok because some reputable "List" did it. If the DOMAIN policy exposed a logic that says: "It is OK for LIST ABC to rewrite our mail and add LIST-XXXXX" than I can better support such ideas. But it needs to come from the domain, otherwise we have a major mail security loophole. -- HLS On 10/24/2014 10:54 AM, Miles Fidelman wrote: > Can we step back from the weeds, for a second and talk practicalities? > > The suggestion that started this thread was to add a List-* header to > indicate the original author of a mailing list posting - in order to, > hopefully, lead to MUAs that make it easier to reply to that original > author. > > The discussion has quickly wandered into discussion that seems to be > very far from the original suggestion. > > Speaking as one who both is on a bunch of mailing lists, and who hosts > a bunch of mailing lists, the suggestion strikes me as almost a > no-brainer. It solves a very big problem, in a very straightforward way. > > 1. Right now, for mailing lists that munge DMARC damage (pretty much > all lists at this point, as far as I can tell), and depending on MUA, > about the only way to reply to the original author of a message is to > actually find the original author's address and manually cut and paste > it into the To: field of your reply. Not all that easy for > non-technical folk (at least based on support questions I get). > > 2. RFC2369 - 16 years old now - specifies a short list of > List-*headers that are incredibly useful for things like finding list > archives, finding list help, unsubscribing, etc. > - not all MUAs support them directly, but, > - they're easy to find, simply by looking in the headers > - in most GUI-based MUAs, they're easy to use - simply click on an > exposed URL (how I typically get to the archive of this list, for > example) > - by being standardized, it makes it easier, and hence more likely, > that MUA developers might start adding "reply to list" and "reply to > author" buttons in their interfaces > > 3. More important, perhaps, is that if we simply picked a name, and > standardized a "List-original-author:" header - it would allow the > SMALL NUMBER of mailing list software developers (mailman, sympa, > ezmlm, a few more) to support that header, probably in the same code > module where they already support the existing RFC239 headers. I > expect that within a week of agreeing on a field name, all the major > mailing list managers would have patches written. > > Unless I'm missing something, there's no downside. > > Which leads to the purely procedural question: > What would be the most straightforward process for writing and > promulgating an RFC that essentially updates RFC2369 by adding one > section that defines an additional header to the current list of > List-* headers? > > Miles Fidelman > > -- HLS From nobody Fri Oct 24 14:17:11 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5011A9174 for ; Fri, 24 Oct 2014 14:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25Wx3H_rKkxL for ; Fri, 24 Oct 2014 14:17:06 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id A42471A8A91 for ; Fri, 24 Oct 2014 14:17:06 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id 47BCA1C3D72; Sat, 25 Oct 2014 06:17:05 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 385E41A2D06; Sat, 25 Oct 2014 06:17:05 +0900 (JST) From: "Stephen J. Turnbull" To: Hector Santos In-Reply-To: <544A43D4.5070903@isdg.net> References: <5436FE09.4050104@sonnection.nl> <20141010041209.2106.qmail@ary.lan> <01PDKQLQAPA200005K@mauve.mrochek.com> <01PDUPKE1KHQ00005L@mauve.mrochek.com> <54494348.4090306@isdg.net> <871tpyieot.fsf@uwakimon.sk.tsukuba.ac.jp> <544A43D4.5070903@isdg.net> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Sat, 25 Oct 2014 06:17:05 +0900 Message-ID: <87tx2tgoby.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/h4wTK8VGNc5CN6jpYJPVHqDFfHA Cc: "dmarc@ietf.org" , "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] wiki vs. list? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 21:17:09 -0000 Hector Santos writes: > POLICY has been reestablished as the DKIM framework long ago. I have no clue what this sentence means. What is "POLICY"? What is "the DKIM framework"? > Things were neglected and we are here today to finally try to > resolve the issues for LIST operators. As I see it, no, we're not. The issues go beyond mailing lists, and since the lists and other affected indirect mailers do not themselves participate in these protocols, talking about the list operators is moot. It's somebody else who has to "do something", and what is here today is destinations which are interpreting Author Domain DMARC policy to suit themselves and their users. > But until them are we wasting time? Yes, I think so. Let me rephrase what I wrote before: Most WG participants seem to be closer to the position that currently available proposals are unlikely to solve the indirect mail problems, and are unlikely to achieve widespread adoption by Author Domains just because they get standardized here or in other venues. The proposals themselves (TPA, John Levine's delegation scheme, Dave Crocker and Murray Kucherawy's delegation scheme, others?) have been developed and will contine to be discussed and improved here and in other channels, but they don't seem to be anything like a general solution, and most WG participants seem to be of the opinion that clarifying and documenting the issues and their relation to proposed solutions is not a waste of time. From nobody Fri Oct 24 15:49:14 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 160C41A040C for ; Fri, 24 Oct 2014 15:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bKL3uwNuEJM for ; Fri, 24 Oct 2014 15:49:11 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id 949B41A00D4 for ; Fri, 24 Oct 2014 15:49:11 -0700 (PDT) Received: from satsuke.wordtothewise.com (204.11.227.194.static.etheric.net [204.11.227.194]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 16EEF812CF for ; Fri, 24 Oct 2014 15:49:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1414190951; bh=zR8zfDMsdmiYOE4zZdRD2tkvNhd/rWDrsunhm+/Z69I=; h=Subject:From:In-Reply-To:Date:References:To:From; b=FGajRrMJ+CXApaWlfBKKmnp5ngNtdluRihMGPjpVIynoKG2WonfeHQllIhadS+JBP 0NTAl/wJbTlD/tHkwqrhX/L2C7574+tyR+R2+C8UrbtZgZVTf1zDGSHIQc1D6GsqGp 8c67YsRwBRy19S7h2UlLcHSs/NyoeRFZ6QFAU85Q= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Steve Atkins In-Reply-To: <544A681E.1000500@meetinghouse.net> Date: Fri, 24 Oct 2014 18:49:11 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <544A681E.1000500@meetinghouse.net> To: "dmarc@ietf.org" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/UIK59QaWSc9rnZcAkFm-UV8CE44 Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 22:49:13 -0000 On Oct 24, 2014, at 10:54 AM, Miles Fidelman = wrote: > Can we step back from the weeds, for a second and talk practicalities? >=20 > The suggestion that started this thread was to add a List-* header to = indicate the original author of a mailing list posting - in order to, = hopefully, lead to MUAs that make it easier to reply to that original = author. >=20 > The discussion has quickly wandered into discussion that seems to be = very far from the original suggestion. >=20 > Speaking as one who both is on a bunch of mailing lists, and who hosts = a bunch of mailing lists, the suggestion strikes me as almost a = no-brainer. It solves a very big problem, in a very straightforward = way. >=20 > 1. Right now, for mailing lists that munge DMARC damage (pretty much = all lists at this point, as far as I can tell), and depending on MUA, = about the only way to reply to the original author of a message is to = actually find the original author's address and manually cut and paste = it into the To: field of your reply. Not all that easy for = non-technical folk (at least based on support questions I get). >=20 > 2. RFC2369 - 16 years old now - specifies a short list of = List-*headers that are incredibly useful for things like finding list = archives, finding list help, unsubscribing, etc. > - not all MUAs support them directly, but, > - they're easy to find, simply by looking in the headers > - in most GUI-based MUAs, they're easy to use - simply click on an = exposed URL (how I typically get to the archive of this list, for = example) > - by being standardized, it makes it easier, and hence more likely, = that MUA developers might start adding "reply to list" and "reply to = author" buttons in their interfaces >=20 > 3. More important, perhaps, is that if we simply picked a name, and = standardized a "List-original-author:" header - it would allow the SMALL = NUMBER of mailing list software developers (mailman, sympa, ezmlm, a few = more) to support that header, probably in the same code module where = they already support the existing RFC239 headers. I expect that within = a week of agreeing on a field name, all the major mailing list managers = would have patches written. >=20 > Unless I'm missing something, there's no downside. If I'm understanding you, your intent is to define (for the subset of = email that is received from mailing lists) the "List-original-author:" = field as containing the author of the message, i.e. the mailbox of the = person or system that was responsible for writing the message, while the = "From:" field would specify the mailbox of the mailing list - the agent = responsible for the actual transmission of the message? And there's a hope that that would lead to MUA developers making the = List-original-author field available to users - to filter by, to use as = a target to "reply to author", and to be visible to identify the = original sender? >=20 > Which leads to the purely procedural question: > What would be the most straightforward process for writing and = promulgating an RFC that essentially updates RFC2369 by adding one = section that defines an additional header to the current list of List-* = headers? Cheers, Steve From nobody Fri Oct 24 16:00:33 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2CC31A1AE1 for ; Fri, 24 Oct 2014 16:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3kjnkSDSV9Mq for ; Fri, 24 Oct 2014 16:00:14 -0700 (PDT) Received: from server1.neighborhoods.net (server1.neighborhoods.net [207.154.13.48]) by ietfa.amsl.com (Postfix) with ESMTP id 84F881A1AD0 for ; Fri, 24 Oct 2014 16:00:13 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by server1.neighborhoods.net (Postfix) with ESMTP id DCB9BCC180 for ; Fri, 24 Oct 2014 19:00:12 -0400 (EDT) X-Virus-Scanned: by amavisd-new-2.6.2 (20081215) (Debian) at neighborhoods.net Received: from server1.neighborhoods.net ([127.0.0.1]) by localhost (server1.neighborhoods.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id uc86mRL5ZANd for ; Fri, 24 Oct 2014 19:00:04 -0400 (EDT) Received: from new-host.home (pool-96-237-159-213.bstnma.fios.verizon.net [96.237.159.213]) by server1.neighborhoods.net (Postfix) with ESMTPSA id 0B4DECC17C for ; Fri, 24 Oct 2014 19:00:04 -0400 (EDT) Message-ID: <544AD9F3.9080304@meetinghouse.net> Date: Fri, 24 Oct 2014 19:00:03 -0400 From: Miles Fidelman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:33.0) Gecko/20100101 Firefox/33.0 SeaMonkey/2.30 MIME-Version: 1.0 To: "dmarc@ietf.org" References: <544A681E.1000500@meetinghouse.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/vG6_Cf_xdMi1Kl9ptoaTLOdEumY Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 23:00:25 -0000 Steve Atkins wrote: > On Oct 24, 2014, at 10:54 AM, Miles Fidelman wrote: > >> Can we step back from the weeds, for a second and talk practicalities? >> >> The suggestion that started this thread was to add a List-* header to indicate the original author of a mailing list posting - in order to, hopefully, lead to MUAs that make it easier to reply to that original author. >> >> The discussion has quickly wandered into discussion that seems to be very far from the original suggestion. >> >> Speaking as one who both is on a bunch of mailing lists, and who hosts a bunch of mailing lists, the suggestion strikes me as almost a no-brainer. It solves a very big problem, in a very straightforward way. >> >> 1. Right now, for mailing lists that munge DMARC damage (pretty much all lists at this point, as far as I can tell), and depending on MUA, about the only way to reply to the original author of a message is to actually find the original author's address and manually cut and paste it into the To: field of your reply. Not all that easy for non-technical folk (at least based on support questions I get). >> >> 2. RFC2369 - 16 years old now - specifies a short list of List-*headers that are incredibly useful for things like finding list archives, finding list help, unsubscribing, etc. >> - not all MUAs support them directly, but, >> - they're easy to find, simply by looking in the headers >> - in most GUI-based MUAs, they're easy to use - simply click on an exposed URL (how I typically get to the archive of this list, for example) >> - by being standardized, it makes it easier, and hence more likely, that MUA developers might start adding "reply to list" and "reply to author" buttons in their interfaces >> >> 3. More important, perhaps, is that if we simply picked a name, and standardized a "List-original-author:" header - it would allow the SMALL NUMBER of mailing list software developers (mailman, sympa, ezmlm, a few more) to support that header, probably in the same code module where they already support the existing RFC239 headers. I expect that within a week of agreeing on a field name, all the major mailing list managers would have patches written. >> >> Unless I'm missing something, there's no downside. > > If I'm understanding you, your intent is to define (for the subset of email that is received from mailing lists) the "List-original-author:" field as containing the author of the message, i.e. the mailbox of the person or system that was responsible for writing the message, while the "From:" field would specify the mailbox of the mailing list - the agent responsible for the actual transmission of the message? Well, my proposal is to be agnostic about the From: field - what it's supposed to be is well defined, despite various mailing list packages munging it in non-standard ways, to get list traffic past restrictive DMARC sender alignment policies. At the moment, different list managers are implementing various different From: re-writing options (e.g., From: by way of ; rewriting to the list address, etc.). I propose that we don't touch the From: field. What I propose is ADDING, a new List-original author: field that provides an unequivocal place find the (avowed) original email, to be written by the mailing list software. That leaves the list software free to use the Reply-To: field as originally intended - something that can be set by list policy to either the author or the list, as configured for the list in question. Though.. it might make some sense to also define a couple of more fields: List-reply-to: (the reply to address as set by the list manager) List-original-reply-to: (the reply to address as set by the original author) > > And there's a hope that that would lead to MUA developers making the List-original-author field available to users - to filter by, to use as a target to "reply to author", and to be visible to identify the original sender? Exactly! And to reduce the need to play with and overload the semantics of the From: and Reply-To: fields. Which still leaves this as an open question: > > >> Which leads to the purely procedural question: >> What would be the most straightforward process for writing and promulgating an RFC that essentially updates RFC2369 by adding one section that defines an additional header to the current list of List-* headers? > Miles -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From nobody Fri Oct 24 16:19:43 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 812121A1B34 for ; Fri, 24 Oct 2014 16:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLvAT_ZW6UAP for ; Fri, 24 Oct 2014 16:19:39 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 304821A6EE9 for ; Fri, 24 Oct 2014 16:19:39 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id ey11so1964048pad.7 for ; Fri, 24 Oct 2014 16:19:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nUcAtGWoT9VtxCUmHjzoOOOGQNDLmOuO+YXqFAZ76bA=; b=aQAqOZT3n1u/rnBrGc0jXNTVp/9TfmHZ6s7fFFxQm2Oc4Ax+0tBYKhrcw8uJb/BecA IOJJ0Kwjo1M3Bm70FhT7ZY1e8YZxQcNi3VEs7HCtI/N5jy1q72sChf5TM2Z+ySwePnMh 1kQKh13FYr8k498iU9PSTjXCrIFLR937i5rUUgG6gNYwabCpUSDQSqNvOj3iyH2AzCnE 8IkI+ovTv/fyCcqYbcL0fzcP0ZZ7uf8YUqdK9TvJUMrsUIMFFxM1YsNeG1sFfAuETyEa s1TLHM8dJ479nnPG7x9VsnGDJkGOjA6NTVDnsuuzBfizyaEuyz55A5vlkdxoY4Xnvizj 4UBg== X-Received: by 10.68.235.103 with SMTP id ul7mr7705404pbc.63.1414192778864; Fri, 24 Oct 2014 16:19:38 -0700 (PDT) Received: from [192.168.2.235] (c-67-188-1-12.hsd1.ca.comcast.net. [67.188.1.12]) by mx.google.com with ESMTPSA id up5sm4802617pac.8.2014.10.24.16.19.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 24 Oct 2014 16:19:38 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Douglas Otis In-Reply-To: <544A681E.1000500@meetinghouse.net> Date: Fri, 24 Oct 2014 16:19:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2F6164AC-59A4-44CB-A499-4FA08E83DE9A@gmail.com> References: <544A681E.1000500@meetinghouse.net> To: Miles Fidelman X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Fu7anasnEu757uFV8g1ITs9SSKk Cc: "dmarc@ietf.org" , Douglas Otis Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 23:19:42 -0000 On Oct 24, 2014, at 7:54 AM, Miles Fidelman = wrote: > Can we step back from the weeds, for a second and talk practicalities? >=20 > The suggestion that started this thread was to add a List-* header to = indicate the original author of a mailing list posting - in order to, = hopefully, lead to MUAs that make it easier to reply to that original = author. Dear Miles,=20 DMARC policy affects any message where the =46rom header field domain = does not align with either an SPF or DKIM domain. The problem that needs to be addressed relates to all possible = third-party related services, which includes but is not limited to use = of discussion lists. There are many other equally legitimate examples = of valid third-party messages (third-party defined as when the =46rom = and DKIM or SPF domains do not align).=20 > The discussion has quickly wandered into discussion that seems to be = very far from the original suggestion. >=20 > Speaking as one who both is on a bunch of mailing lists, and who hosts = a bunch of mailing lists, the suggestion strikes me as almost a = no-brainer. It solves a very big problem, in a very straightforward = way. Modifying =46rom header fields destroys functionality and dangerously = expects users to "repair" the damage caused, such as responding to = messages in their spam folder or modifying return addresses by hand. > 1. Right now, for mailing lists that munge DMARC damage (pretty much = all lists at this point, as far as I can tell), and depending on MUA, = about the only way to reply to the original author of a message is to = actually find the original author's address and manually cut and paste = it into the To: field of your reply. Not all that easy for = non-technical folk (at least based on support questions I get). >=20 > 2. RFC2369 - 16 years old now - specifies a short list of = List-*headers that are incredibly useful for things like finding list = archives, finding list help, unsubscribing, etc. > - not all MUAs support them directly, but, > - they're easy to find, simply by looking in the headers > - in most GUI-based MUAs, they're easy to use - simply click on an = exposed URL (how I typically get to the archive of this list, for = example) > - by being standardized, it makes it easier, and hence more likely, = that MUA developers might start adding "reply to list" and "reply to = author" buttons in their interfaces How is a List-* header better than permitting exceptions for specific = forms of group syntax? In that way, =46rom header field function can be = retained while avoiding possible deceptions caused by normally unseen = header fields. The DMARC goal was to ensure recipients are aware of = possible misdirection. TPA-Label is more secure because it requires = DMARC domains to make specific exceptions based on third-party services = used by their senders and NOTHING ELSE NEEDS TO CHANGE. A specific = group syntax represents a less secure "least effort" alternative, but is = still better than what you're suggesting. > 3. More important, perhaps, is that if we simply picked a name, and = standardized a "List-original-author:" header - it would allow the SMALL = NUMBER of mailing list software developers (mailman, sympa, ezmlm, a few = more) to support that header, probably in the same code module where = they already support the existing RFC239 headers. I expect that within = a week of agreeing on a field name, all the major mailing list managers = would have patches written. >=20 > Unless I'm missing something, there's no downside. There are a few: 1) The problem is not limited to just mailing-lists so it would be = better to define a general purpose header field to mitigate DMARC policy = disruptions. 2) Use of a new header field creates another problem in that they would = not be seen by recipients. Ensuring an origination header can be seen is better solved by making = specific exceptions for valid use of =46rom header field group syntax = permitted by RFC6854 which amended RFC5322. > Which leads to the purely procedural question: > What would be the most straightforward process for writing and = promulgating an RFC that essentially updates RFC2369 by adding one = section that defines an additional header to the current list of List-* = headers? It is not RFC2369 that needs to change. DMARC needs to either permit = exceptions based on a defined group syntax or have DMARC allow an = explicit authorization scheme. Otherwise expect ad hoc hacks to create = an even more pernicious spoofing problem. In my view, such results = would be a major downside. Regards, Douglas Otis From nobody Fri Oct 24 18:38:17 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 195681A1AF7 for ; Fri, 24 Oct 2014 18:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.002 X-Spam-Level: X-Spam-Status: No, score=-102.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGUAPNL3uUSS for ; Fri, 24 Oct 2014 18:38:11 -0700 (PDT) Received: from winserver.com (secure.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id B09351A1B6C for ; Fri, 24 Oct 2014 18:38:10 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1637; t=1414201079; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=ZO0BMcGz3uvk1iCfOPrPXCyDgxQ=; b=oYb8Brth0wmSZUNsA5GV cviadsPiDvcAxWl6q4usXLm2ZmO3I41F2Qi5FkoDOknHyOFOATK5U5FEOK9PlLuY Esptl5NpwPN4/hv+DQFAG+b8GVcoqLJjKzaa+YuBcXeYZ/rwrO4Asxil7fWoUdhP vQ8SllTymV2hr4I7G2hi+ks= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Fri, 24 Oct 2014 21:37:59 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 796165459.81236.2236; Fri, 24 Oct 2014 21:37:58 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1637; t=1414200669; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=oLFJ9A+ wzoK2wy2Cs7DBke6Qd1AZsXOC7hh/+YZLDHA=; b=dqugzZY3vm/6rIABDvf7bTW knUTqrt/zHQzqFuaIeMZ+bKm+EMc55HVilurzoZBdJ4w7znfzokme7UcnyPfpULe i1Ea+OlYx9r1O7054MghneMUpIcIjiSPyEzlphoyDFw66QJ8hIkhW1o3VM49qSVA WESVxrEva5sEEduI4rIY= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Fri, 24 Oct 2014 21:31:09 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3683549157.9.6772; Fri, 24 Oct 2014 21:31:08 -0400 Message-ID: <544AFEFA.1060506@isdg.net> Date: Fri, 24 Oct 2014 21:38:02 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Stephen J. Turnbull" References: <5436FE09.4050104@sonnection.nl> <20141010041209.2106.qmail@ary.lan> <01PDKQLQAPA200005K@mauve.mrochek.com> <01PDUPKE1KHQ00005L@mauve.mrochek.com> <54494348.4090306@isdg.net> <871tpyieot.fsf@uwakimon.sk.tsukuba.ac.jp> <544A43D4.5070903@isdg.net> <87tx2tgoby.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87tx2tgoby.fsf@uwakimon.sk.tsukuba.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/SKMdeyIfM-ryc1u46kIZWRyqpDE Cc: "dmarc@ietf.org" , "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] wiki vs. list? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Oct 2014 01:38:14 -0000 On 10/24/2014 5:17 PM, Stephen J. Turnbull wrote: > Hector Santos writes: > > > POLICY has been reestablished as the DKIM framework long ago. > > I have no clue what this sentence means. What is "POLICY"? DMARC rev 4 spec has 184 global search references to the term POLICY. DKIM has a 9 year history regarding a POLICY framework. > What is "the DKIM framework"? Framework is a well understand term, Stephen. > > But until them are we wasting time? Yes, I think so. > > Let me rephrase what I wrote before: > > Most WG participants seem to be closer to the position that > currently available proposals are unlikely to solve the indirect > mail problems, and are unlikely to achieve widespread adoption by > Author Domains just because they get standardized here or in other > venues. DMARC is a DKIM Policy Framework. According the marketing, it has gain widespread adoption especially among your list users domains. Isn't why you are here, to stop it? >The proposals themselves (TPA, John Levine's delegation > scheme, Dave Crocker and Murray Kucherawy's delegation scheme, > others?) have been developed and will contine to be discussed and > improved here and in other channels, but they don't seem to be > anything like a general solution, and most WG participants seem to > be of the opinion that clarifying and documenting the issues and > their relation to proposed solutions is not a waste of time. Great, then since you have purport to have a "consensus," with "most WG participants," you should be able to get something done pretty quickly. Thanks for your comments. -- HLS From nobody Sat Oct 25 09:32:41 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4564C1A1A93 for ; Sat, 25 Oct 2014 09:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KM1aGv9bh4ex for ; Sat, 25 Oct 2014 09:32:38 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6C891A1A63 for ; Sat, 25 Oct 2014 09:32:35 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.298.1; Sat, 25 Oct 2014 18:32:33 +0200 Message-ID: <036E3CA0799048928F761B1C43905335@fgsr.local> From: "J. Gomez" To: References: <5436FE09.4050104@sonnection.nl><20141010041209.2106.qmail@ary.lan><01PDKQLQAPA200005K@mauve.mrochek.com><01PDUPKE1KHQ00005L@mauve.mrochek.com> <54494348.4090306@isdg.net><871tpyieot.fsf@uwakimon.sk.tsukuba.ac.jp> <544A43D4.5070903@isdg.net> <87tx2tgoby.fsf@uwakimon.sk.tsukuba.ac.jp> <544AFEFA.1060506@isdg.net> Date: Sat, 25 Oct 2014 18:34:55 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/9T7zPtR_jTCFjLHg1CnOpBKRrZw Subject: Re: [dmarc-ietf] wiki vs. list? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Oct 2014 16:32:40 -0000 On Saturday, October 25, 2014 3:38 AM [GMT+1=3DCET], Hector Santos = wrote: > DMARC is a DKIM Policy Framework. According the marketing, it has gain > widespread adoption especially among your list users domains. Isn't > why you are here, to stop it? If by "widespread adoption" you mean that major mailbox providers (Gmail = and others) are ignoring the Sender's DMARC policy (Yahoo, AOL and = others), then yes: DMARC defines a DKIM policy which has widespread = adoption. Regards, J. Gomez From nobody Sat Oct 25 09:58:04 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 128251A1A86 for ; Sat, 25 Oct 2014 09:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fW7deFfbRWyB for ; Sat, 25 Oct 2014 09:58:02 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21A961A1A69 for ; Sat, 25 Oct 2014 09:58:02 -0700 (PDT) Received: from [172.18.50.144] (wss1-20-mss.prud.ma.towerstream.com [64.119.139.20] (may be forged)) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s9PGvvqr026506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 25 Oct 2014 09:58:01 -0700 Message-ID: <544BD68B.6030905@dcrocker.net> Date: Sat, 25 Oct 2014 12:57:47 -0400 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "J. Gomez" , dmarc@ietf.org References: <5436FE09.4050104@sonnection.nl><20141010041209.2106.qmail@ary.lan><01PDKQLQAPA200005K@mauve.mrochek.com><01PDUPKE1KHQ00005L@mauve.mrochek.com> <54494348.4090306@isdg.net><871tpyieot.fsf@uwakimon.sk.tsukuba.ac.jp> <544A43D4.5070903@isdg.net> <87tx2tgoby.fsf@uwakimon.sk.tsukuba.ac.jp> <544AFEFA.1060506@isdg.net> <036E3CA0799048928F761B1C43905335@fgsr.local> In-Reply-To: <036E3CA0799048928F761B1C43905335@fgsr.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Sat, 25 Oct 2014 09:58:01 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/ikxCHEyx55wAI7ptYf0UCHuzCaI Subject: Re: [dmarc-ietf] wiki vs. list? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Oct 2014 16:58:03 -0000 On 10/25/2014 12:34 PM, J. Gomez wrote: > On Saturday, October 25, 2014 3:38 AM [GMT+1=CET], Hector Santos wrote: > >> DMARC is a DKIM Policy Framework. According the marketing, it has gain >> widespread adoption especially among your list users domains. Isn't >> why you are here, to stop it? > > If by "widespread adoption" you mean that major mailbox providers (Gmail and others) are ignoring the Sender's DMARC policy (Yahoo, AOL and others), then yes: DMARC defines a DKIM policy which has widespread adoption. DMARC defines DMARC-related 'policies'. It does not affect DKIM in any way. It is an overlay to DKIM and/or SPF use. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Oct 26 07:10:36 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C24E1A8839 for ; Sun, 26 Oct 2014 07:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebz_cGuxG1Bv for ; Sun, 26 Oct 2014 07:10:33 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B61C1A8822 for ; Sun, 26 Oct 2014 07:10:33 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id q5so4450907wiv.11 for ; Sun, 26 Oct 2014 07:10:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7jUWdZkfnOUtni6x/3NdRbrhdS4TZVhvelW61sEKxfE=; b=ZeEFNMngh/CEFTVWI1R/xT/YuP+ycpOTQMy/CDdqOeIzjusAHP9+8CGwhoZSVmEUqV pwQHSzaPPbD7J0gLWw77mkiTUor/D7ERSlk18bt8Sr5w71Ji+eat9EtP+/O0PPMFQs79 81YEeCMcIGJUrBg+OBkS+JmpISYg8igifE8OnE5k3XWbYhro4NeAMfqlu5fywKtMxE+Z +yoMSO1QLHmY8YKMPuSUjm9BWYxyCcY0LKN3GFau7bVXv8yYt+ssfGc6a6S7C5E1dF1n YgZY0WQ9tBUS4JqmL1e8qFJfIqyOaqpiJIh8sLrzdVB/TgAOpma7qN7JUSdufurszGri cEkw== MIME-Version: 1.0 X-Received: by 10.180.73.40 with SMTP id i8mr15263610wiv.30.1414332631481; Sun, 26 Oct 2014 07:10:31 -0700 (PDT) Received: by 10.27.76.134 with HTTP; Sun, 26 Oct 2014 07:10:31 -0700 (PDT) In-Reply-To: <87tx2tgoby.fsf@uwakimon.sk.tsukuba.ac.jp> References: <5436FE09.4050104@sonnection.nl> <20141010041209.2106.qmail@ary.lan> <01PDKQLQAPA200005K@mauve.mrochek.com> <01PDUPKE1KHQ00005L@mauve.mrochek.com> <54494348.4090306@isdg.net> <871tpyieot.fsf@uwakimon.sk.tsukuba.ac.jp> <544A43D4.5070903@isdg.net> <87tx2tgoby.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Sun, 26 Oct 2014 07:10:31 -0700 Message-ID: From: "Murray S. Kucherawy" To: "Stephen J. Turnbull" Content-Type: multipart/alternative; boundary=f46d0438907d1801b0050653fa0a Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/O0werobaae1KH2u34tIyMJR-F_I Cc: "dmarc@ietf.org" , Hector Santos Subject: Re: [dmarc-ietf] wiki vs. list? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 14:10:35 -0000 --f46d0438907d1801b0050653fa0a Content-Type: text/plain; charset=UTF-8 On Fri, Oct 24, 2014 at 2:17 PM, Stephen J. Turnbull wrote: > Hector Santos writes: > > > POLICY has been reestablished as the DKIM framework long ago. > > I have no clue what this sentence means. What is "POLICY"? What is > "the DKIM framework"? > For any definition of "the DKIM framework", the claim is incorrect. DKIM has never had policy inherent within it since it was published. ADSP and ATPS are failed experiments to add some. > Most WG participants seem to be closer to the position that > currently available proposals are unlikely to solve the indirect > mail problems, and are unlikely to achieve widespread adoption by > Author Domains just because they get standardized here or in other > venues. The proposals themselves (TPA, John Levine's delegation > scheme, Dave Crocker and Murray Kucherawy's delegation scheme, > others?) have been developed and will contine to be discussed and > improved here and in other channels, but they don't seem to be > anything like a general solution, and most WG participants seem to > be of the opinion that clarifying and documenting the issues and > their relation to proposed solutions is not a waste of time. > I don't think we've finished hashing on these, so some solution may rise from their collective ashes. I do agree though that none of them seem to have enough favor here at this point to be a clear winner, all for good reasons. If such a possible solution does exist, we still have to put more work into finding, testing, and describing it. -MSK --f46d0438907d1801b0050653fa0a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Oct 24, 2014 at 2:17 PM, Stephen J. Turnbull <st= ephen@xemacs.org> wrote:
Hector= Santos writes:

=C2=A0> POLICY has been reestablished as the DKIM framework long ago.
I have no clue what this sentence means.=C2=A0 What is "POLICY&= quot;?=C2=A0 What is
"the DKIM framework"?

For any= definition of "the DKIM framework", the claim is incorrect.=C2= =A0 DKIM has never had policy inherent within it since it was published.=C2= =A0 ADSP and ATPS are failed experiments to add some.
=C2=A0
=C2=A0 Most WG participants seem to be closer = to the position that
=C2=A0 =C2=A0 currently available proposals are unlikely to solve the indir= ect
=C2=A0 =C2=A0 mail problems, and are unlikely to achieve widespread adoptio= n by
=C2=A0 =C2=A0 Author Domains just because they get standardized here or in = other
=C2=A0 =C2=A0 venues.=C2=A0 The proposals themselves (TPA, John Levine'= s delegation
=C2=A0 =C2=A0 scheme, Dave Crocker and Murray Kucherawy's delegation sc= heme,
=C2=A0 =C2=A0 others?) have been developed and will contine to be discussed= and
=C2=A0 =C2=A0 improved here and in other channels, but they don't seem = to be
=C2=A0 =C2=A0 anything like a general solution, and most WG participants se= em to
=C2=A0 =C2=A0 be of the opinion that clarifying and documenting the issues = and
=C2=A0 =C2=A0 their relation to proposed solutions is not a waste of time.<= br>

I don't think w= e've finished hashing on these, so some solution may rise from their co= llective ashes.=C2=A0 I do agree though that none of them seem to have enou= gh favor here at this point to be a clear winner, all for good reasons.=C2= =A0 If such a possible solution does exist, we still have to put more work = into finding, testing, and describing it.

-MSK
--f46d0438907d1801b0050653fa0a-- From nobody Sun Oct 26 07:11:30 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1FA1A8841 for ; Sun, 26 Oct 2014 07:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEnZcNtiaOT4 for ; Sun, 26 Oct 2014 07:11:26 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F3E11A8839 for ; Sun, 26 Oct 2014 07:11:25 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id y10so1401141wgg.11 for ; Sun, 26 Oct 2014 07:11:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PntAr9Hd1wlVEb2P8UE3Sh8xaYkREep48YMGOhxsAMg=; b=T5OJmQZg2PCbXWPtkQdMSiL3XJzjbdRdCCtIJvuP/8+E6XmEhcJeeqGW2ASvOCK090 kP86PFubed7noxx7q1jRRcw2ZMkupX8s5QX9BB0a9NQCrl9E0LQvgi0tPH69bcDa2p6I WguK3JgTqB4VXQHZgks+6tIGorLHH+ev9IPrp8lZcjnVRbIGcsYX1l5DvPVDHMxlfZxk 0nUkAxByef6W1ANJNXbRo3sWnBzdhCu77EsX08cwGqshlRwpyCPPMJjlCZ7RzwCgQsnk wibEaF2IsoXeLS5pVWse8/jju7uk8++di+Z5c8QVwCj22ZFgEE06VD3vO0zZsIyjxWqa HDrA== MIME-Version: 1.0 X-Received: by 10.180.9.65 with SMTP id x1mr15286642wia.30.1414332684726; Sun, 26 Oct 2014 07:11:24 -0700 (PDT) Received: by 10.27.76.134 with HTTP; Sun, 26 Oct 2014 07:11:24 -0700 (PDT) In-Reply-To: <544BD68B.6030905@dcrocker.net> References: <5436FE09.4050104@sonnection.nl> <20141010041209.2106.qmail@ary.lan> <01PDKQLQAPA200005K@mauve.mrochek.com> <01PDUPKE1KHQ00005L@mauve.mrochek.com> <54494348.4090306@isdg.net> <871tpyieot.fsf@uwakimon.sk.tsukuba.ac.jp> <544A43D4.5070903@isdg.net> <87tx2tgoby.fsf@uwakimon.sk.tsukuba.ac.jp> <544AFEFA.1060506@isdg.net> <036E3CA0799048928F761B1C43905335@fgsr.local> <544BD68B.6030905@dcrocker.net> Date: Sun, 26 Oct 2014 07:11:24 -0700 Message-ID: From: "Murray S. Kucherawy" To: Dave Crocker Content-Type: multipart/alternative; boundary=001a11c245ca44789f050653fded Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/_GSKBGPrOJk1_yo8YdMQzScMgr8 Cc: "dmarc@ietf.org" , "J. Gomez" Subject: Re: [dmarc-ietf] wiki vs. list? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 14:11:28 -0000 --001a11c245ca44789f050653fded Content-Type: text/plain; charset=UTF-8 On Sat, Oct 25, 2014 at 9:57 AM, Dave Crocker wrote: > On 10/25/2014 12:34 PM, J. Gomez wrote: > >> DMARC is a DKIM Policy Framework. According the marketing, it has gain > >> widespread adoption especially among your list users domains. Isn't > >> why you are here, to stop it? > > > > If by "widespread adoption" you mean that major mailbox providers (Gmail > and others) are ignoring the Sender's DMARC policy (Yahoo, AOL and others), > then yes: DMARC defines a DKIM policy which has widespread adoption. > > DMARC defines DMARC-related 'policies'. > > It does not affect DKIM in any way. It is an overlay to DKIM and/or SPF > use. Yes, this. +1, etc. -MSK --001a11c245ca44789f050653fded Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Oct 25, 2014 at 9:57 AM, Dave Crocker <dhc@dcrocke= r.net> wrote:
On 10/25/2014 12:= 34 PM, J. Gomez wrote:
>> DMARC is a DKIM Policy Framework. According the marketing, it has = gain
>> widespread adoption especially among your list users domains.=C2= =A0 Isn't
>> why you are here, to stop it?
>
> If by "widespread adoption" you mean that major mailbox prov= iders (Gmail and others) are ignoring the Sender's DMARC policy (Yahoo,= AOL and others), then yes: DMARC defines a DKIM policy which has widesprea= d adoption.

DMARC defines DMARC-related 'policies'.

It does not affect DKIM in any way.=C2=A0 It is an overlay to DKIM and/or S= PF
use.

Yes, this.=C2=A0 +1, etc.

-MSK
--001a11c245ca44789f050653fded-- From nobody Sun Oct 26 08:09:21 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E6B1A88DD for ; Sun, 26 Oct 2014 08:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.903 X-Spam-Level: X-Spam-Status: No, score=-98.903 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id loF67hKJ2Fhl for ; Sun, 26 Oct 2014 08:09:07 -0700 (PDT) Received: from winserver.com (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 058E91A88DB for ; Sun, 26 Oct 2014 08:09:06 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4204; t=1414336142; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=JJUfQpndccM9/RTaeLo8P9sOqY8=; b=K6CbWqTtNAR0zp0DmPPQ 1aTMTkg3EtSh17JsRVA13YjFUTAqSYaOlSydvHMl6dvtLbQD15xQ0n9QN/tylNxc j/IOQ4C9tpvZCHMwHU2VpJ8o8avQNY6o4n+6Helu+KCpm39hRbj/zYIDdOH++CGd f8ZRBJtm4naJAG865xV2mHw= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sun, 26 Oct 2014 10:09:02 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 931227022.83325.5544; Sun, 26 Oct 2014 10:09:01 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4204; t=1414335731; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=3KQtxZH ptktUB2+Mws1vlC0AWVjvn9/iDM/q+zUhm4o=; b=YtOTjeD/IpKIxEXsmKfmcxu WBh+n3m6xHRGNbAIxlkiqec9e5urgpo/09iVWhUQnGSBNmrbCXqP9Ri1MU76iz32 32zDPDkzUkkct8RaLYtXfsHG0C/33kDMHmz5aacaluVbeZRSXcaGnLRzHI7HEZ3S q06MtirBPSti1a/+Z/Fg= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sun, 26 Oct 2014 11:02:11 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3818610641.9.348; Sun, 26 Oct 2014 11:02:10 -0400 Message-ID: <544D0E8B.10508@isdg.net> Date: Sun, 26 Oct 2014 11:08:59 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" , "Stephen J. Turnbull" References: <5436FE09.4050104@sonnection.nl> <20141010041209.2106.qmail@ary.lan> <01PDKQLQAPA200005K@mauve.mrochek.com> <01PDUPKE1KHQ00005L@mauve.mrochek.com> <54494348.4090306@isdg.net> <871tpyieot.fsf@uwakimon.sk.tsukuba.ac.jp> <544A43D4.5070903@isdg.net> <87tx2tgoby.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/iEhokkga08d1spb5ReGC7le0n2E Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] wiki vs. list? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 15:09:10 -0000 On 10/26/2014 10:10 AM, Murray S. Kucherawy wrote: > On Fri, Oct 24, 2014 at 2:17 PM, Stephen J. Turnbull > wrote: > >> Hector Santos writes: >> >> > POLICY has been reestablished as the DKIM framework long ago. >> >> I have no clue what this sentence means. What is "POLICY"? What is >> "the DKIM framework"? >> > > For any definition of "the DKIM framework", the claim is incorrect. DKIM > has never had policy inherent within it since it was published. ADSP and > ATPS are failed experiments to add some. > This is MY VIEW as an external long time participant with early explorer SPF/DKIM add-on products in our mail system. Nothing personal nor negative intended, especially towards you, but you are in fact the "leader" and in charge of this work. DKIM had its origins from Domainkeys (DKEYS) which had a built-in POLICY framework Murry. DKIM, when it was first released, also carried over the built-in policy framework and it public domain APIs with API functions "hooks" for POLICY logic. DKIM had an expanded set above and beyond what DKEYS offered. For the most part, the specs and API reduced the functional logic to: IF DKIM.VALID and DKIM.SIGNER.DOMAIN != FROM.DOMAIN then LOOKUP AUTHOR POLICY FOR EXCLUSIVE/RESTRICTIVE OPERATIONS Thats no claim. Thats a public domain API fact with original API libraries for DKEYS and DKIM. It is an historical, public domain fact and there shouldn't any debate about its origins nor how it been reestablished with your new published draft DMARC work. The concept of policy is peppered all over the document. There should be no dispute DMARC is a "DKIM Policy Framework" or "DKIM Policy Protocol" or "DKIM Policy Specification" or "DKIM Policy Layout" whatever other terminology we wish to use. DKIM had two frameworks -- a POLICY and TRUST and there lied the long time problem and continued conflict when in fact, DMARC itself is about POLICY and DKIM STD is about TRUST. When Policy was removed from the DKIM RFC/STD work and replaced with TRUST. Folks were warned of the mistake to inherently exclude the Author Domain Identity (ADID) from the assessment algorithm (remember that discussion?) and we are here today because it was left out, trying to reestablishing it via DMARC. Finally, Its easy to dispute ADSP/ATPS as "failed experiments" by the fact it wasn't giving a chance at all. In other words, the effort didn't have the proper both project/product development champions and the fact that DMARC is being adopted and now discussed, proves the Proof of Concept (Policy in principle) had never gone away and it is still alive and well. It won't go away either as it should finally realized by now. Call it any name we want -- it is a DKIM POLICY framework and we should save time by recognizing this fact and develop the proper tools to allow the world to adjust to it. Its unfortunate the DKIM progress for both an integrated TRUST and POLICY framework has been held back for some time now. Policy was always the first layer (expectation), TRUST was always the second layer (valid signature true). But DKIM project leaders pushed for TRUST only which the POLICY advocated warned that was going to be a problem in the future -- and it did, hasn't it? But ignoring POLICY, we weren't ready for it. I should note, that DMARC repeated what Levine did with ADSP -- ignore all 3rd party control concepts in an attempt to reduce conflicts with 3rd party resigners. I think it should be determine asap if 3rd party policy ideas are in fact going to be developed for DMARC, and by that, I mean, you PUSH IT, You CHAMPION IT. Otherwise it ain't going anywhere for awhile. It shouldn't had never been a difficult total TRUST/POLICY integrated product solution and since the same folks are behind it, well, its progress seems to be in a status quo direction for its future. Not a negative towards you, you are doing good work for all the work you do. But it does seem to be too much and overwhelming. You need help. No doubt. But thats also a management problem. So, I'll leave it at that. I really hope you guys moving with this. -- HLS From nobody Mon Oct 27 04:36:50 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93D0A1A90D0 for ; Mon, 27 Oct 2014 04:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.533 X-Spam-Level: X-Spam-Status: No, score=-0.533 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zuRPAO-QG_sy for ; Mon, 27 Oct 2014 04:36:46 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 751DD1A9095 for ; Mon, 27 Oct 2014 04:36:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1414409803; bh=L1NtCTFW9U348Mh5WoqAHCNCgc92F25HGulJiT7+CZM=; l=4215; h=Date:From:To:References:In-Reply-To; b=xIKrHlbpPytOgjRszCWqREc4ryCw2qYok1zmePXbxc7IUheQ6EEvUg1EXvUHTlxi8 AHASA5SKlExNo0LM25fihQkeTPaXdG2rEZctv/Dzy/lJgGVjYe3U3XywFXjw5zyI10 EDX/ElAiWXc0JHR8Or4tCIZJ6QkhgqXztqj03uG8= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.88] (pcale.tana [172.25.197.88]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Mon, 27 Oct 2014 12:36:43 +0100 id 00000000005DC04C.00000000544E2E4B.000017DD Message-ID: <544E2E4B.8080509@tana.it> Date: Mon, 27 Oct 2014 12:36:43 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.8.1 MIME-Version: 1.0 To: dmarc@ietf.org References: <544A681E.1000500@meetinghouse.net> <544AD9F3.9080304@meetinghouse.net> In-Reply-To: <544AD9F3.9080304@meetinghouse.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/nmLOFLmfFj4_lmJxnVaZkd1R1EM Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 11:36:48 -0000 On Sat 25/Oct/2014 01:00:03 +0200 Miles Fidelman wrote: > Steve Atkins wrote: >> On Oct 24, 2014, at 10:54 AM, Miles Fidelman wrote: >> >>> 1. Right now, for mailing lists that munge DMARC damage (pretty >>> much all lists at this point, as far as I can tell), and depending >>> on MUA, about the only way to reply to the original author of a >>> message is to actually find the original author's address and >>> manually cut and paste it into the To: field of your reply. Not >>> all that easy for non-technical folk (at least based on support >>> questions I get). Yes, except some lists didn't care at all (lucky them). >>> 2. RFC2369 - 16 years old now - specifies a short list of >>> List-*headers that are incredibly useful for things like finding >>> list archives, finding list help, unsubscribing, etc. >>> - not all MUAs support them directly, but, >>> - they're easy to find, simply by looking in the headers >>> - in most GUI-based MUAs, they're easy to use - simply click on an >>> exposed URL (how I typically get to the archive of this list, for >>> example) >>> - by being standardized, it makes it easier, and hence more likely, >>> that MUA developers might start adding "reply to list" and "reply >>> to author" buttons in their interfaces Hm... the resulting likelihood would still be very low, IMHO. >>> 3. More important, perhaps, is that if we simply picked a name, and >>> standardized a "List-original-author:" header - it would allow the >>> SMALL NUMBER of mailing list software developers (mailman, sympa, >>> ezmlm, a few more) to support that header, probably in the same >>> code module where they already support the existing RFC239 >>> headers. I expect that within a week of agreeing on a field name, >>> all the major mailing list managers would have patches written. >>> >>> Unless I'm missing something, there's no downside. >> >> If I'm understanding you, your intent is to define (for the subset >> of email that is received from mailing lists) the >> "List-original-author:" field as containing the author of the >> message, i.e. the mailbox of the person or system that was >> responsible for writing the message, while the "From:" field would >> specify the mailbox of the mailing list - the agent responsible for >> the actual transmission of the message? > > Well, my proposal is to be agnostic about the From: field - what it's > supposed to be is well defined, despite various mailing list packages > munging it in non-standard ways, to get list traffic past restrictive > DMARC sender alignment policies. At the moment, different list > managers are implementing various different From: re-writing options > (e.g., From: by way of ; rewriting to the list > address, etc.). I propose that we don't touch the From: field. > > What I propose is ADDING, a new List-original author: field that > provides an unequivocal place find the (avowed) original email, to be > written by the mailing list software. That's very equivocal. It goes without saying that From: is going to be munged, so why don't we say it explicitly? In addition, if we propose a simple munging scheme --one that can be easily undone manually-- we provide users with the ability to reply to authors even if their MUA doesn't recognize the new field. Consider: From: John Doe List-Original-Author: John Doe We can even set up a dummy server which always replies: 551 User not local; please try The RFC ought to also tell that that is a temporary solution, until general solutions for every indirect flow case are agreed upon. > That leaves the list software free to use the Reply-To: field as > originally intended - something that can be set by list policy to > either the author or the list, as configured for the list in question. Yes. > Though.. it might make some sense to also define a couple of more fields: > List-reply-to: (the reply to address as set by the list manager) > List-original-reply-to: (the reply to address as set by the original > author) Please, no. jm2c From nobody Mon Oct 27 08:22:41 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF9F11ACE0A for ; Mon, 27 Oct 2014 08:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.788 X-Spam-Level: X-Spam-Status: No, score=0.788 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVp6P7nfo93s for ; Mon, 27 Oct 2014 08:22:38 -0700 (PDT) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0751ACE1B for ; Mon, 27 Oct 2014 08:22:37 -0700 (PDT) Received: from [192.168.82.61] (unknown [72.250.228.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id 2A8C6CB46 for ; Mon, 27 Oct 2014 11:22:36 -0400 (EDT) From: Tim Draegen Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <2DC66C27-2924-475A-BB46-1EB7F05861B4@eudaemon.net> Date: Mon, 27 Oct 2014 11:22:36 -0400 To: dmarc@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/n_agSlnXZpI88B1zLBYmxLLIAv0 Subject: [dmarc-ietf] progress towards milestone 1 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 15:22:40 -0000 WG, During the WG's allotted IETF91 time (Friday November 14th @ 9 AM Hawaii = time), we=E2=80=99ll need to make a decision as to whether or not = we=E2=80=99ve adequately documented all known issues between DMARC and = indirect email flows. I don=E2=80=99t think we=E2=80=99re quite there = yet, but we=E2=80=99re close. I=E2=80=99ll be spending a lot of time with the Wiki over the next week = primarily to make sure the WG has an easy-to-reference resource for the = next deliverables, but secondarily to make sure those folks that are = late to the party have something they can immediately review. If anyone = would like to dedicate some time to this, please contact me directly and = we=E2=80=99ll coordinate. In the week leading up to IETF91, I=E2=80=99ll be chasing down reviewers = with the intention of showing up at IETF91 with a piece of documentation = that is comprehensive enough to move on to the next milestone. In this = area I=E2=80=99m not looking for perfection=E2=80=A6 just enough review = so that the WG doesn=E2=80=99t get side-tracked by, for example, an = unexpected new category of indirect email flow. Hopefully, if everything can be locked down in time, the IETF91 meeting = will be a review of the collected data, an acknowledgement that we=E2=80=99= re ready for the next milestone, and a call for volunteers to begin = stitching together the next deliverable. 1/2 of the WG=E2=80=99s Chair, =3D- Tim From nobody Mon Oct 27 09:47:59 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C812C1A1A19 for ; Mon, 27 Oct 2014 09:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oPspHh3Rv1VQ for ; Mon, 27 Oct 2014 09:47:53 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 793271A014C for ; Mon, 27 Oct 2014 09:47:53 -0700 (PDT) Received: by mail-ig0-f172.google.com with SMTP id h15so5134856igd.17 for ; Mon, 27 Oct 2014 09:47:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=DgnvtCXPqtUQyswIAkiJdVQFFXms9WMSRNGa5O8GEFY=; b=LaxQGJW4gHKKjLX/4mMqP3W8HacD9Edhv6ICCYf1aSF9qQE0Op6JDoIlgVlvwTQm6g A72SxbhN9gKGMtf8mH47v9Hms/4SX3iqQVyPArqF/FsbHE9S18Zwm6oYIHfkyg/VeCXL M55FEe0bfP5Psm9+fzfj3r2jAaLjbGj8FULA91UgynqhkePUBmbW50nQyyOnJ2tw2r9d 2mmtxM4VMTvHnxbFg22mgEF+DCae1PN4OEcJBbA1im6FgjXXzUN2alF0TNUxKkgrD0Iy SiM+uLEZ4IKVWX2IpkQw0i59BWlEQWYFNedWq73pnOAZmuGJB+c/rP7KE5ECfJ16bSt/ HZaw== X-Received: by 10.107.30.136 with SMTP id e130mr24894273ioe.9.1414428472802; Mon, 27 Oct 2014 09:47:52 -0700 (PDT) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id m7sm5164906igj.18.2014.10.27.09.47.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Oct 2014 09:47:51 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_97D7FA34-4594-4093-B9F1-A0E3A5138441" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Douglas Otis In-Reply-To: <544E2E4B.8080509@tana.it> Date: Mon, 27 Oct 2014 09:47:49 -0700 Message-Id: <64E2B9BD-3A33-4C0C-A196-55D818FF8DE6@gmail.com> References: <544A681E.1000500@meetinghouse.net> <544AD9F3.9080304@meetinghouse.net> <544E2E4B.8080509@tana.it> To: Alessandro Vesely X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/mpDUkKFgzSx_oXPXa7pgZ7sekrk Cc: dmarc WG , Douglas Otis Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 16:47:56 -0000 --Apple-Mail=_97D7FA34-4594-4093-B9F1-A0E3A5138441 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Oct 27, 2014, at 4:36 AM, Alessandro Vesely wrote: > That's very equivocal. It goes without saying that From: is going to = be munged, so why don't we say it explicitly? In addition, if we = propose a simple munging scheme --one that can be easily undone = manually-- we provide users with the ability to reply to authors even if = their MUA doesn't recognize the new field. Consider: >=20 > From: John Doe > List-Original-Author: John Doe >=20 > We can even set up a dummy server which always replies: >=20 > 551 User not local; please try Dear Alessandro, DMARC affects many third-party services, only one being a mailing list. = Rather than munging =46rom header fields and expect users to change it, = especially when dealing with different languages, a more concise and = compliant scheme would be to have DMARC adopt specific policy exceptions = for group syntax. Such exceptions would then permit third-party = services a means to modify their =46rom in a manner not requiring hand = editing and yet be DMARC compliant. Hand editing defeats protections = due to the many diverse ways of saying "Do not trust this From" as = would defining an unseen replacement for the =46rom header field to = stand in its place. In addition, only group syntax ensures the =46rom = header field being relied upon remains visible. The =46rom header field = being visible is a key aspect of DMARC. =20 It still makes far more sense for DMARC to declare a group such as =E2=98=A0= : or DMARC-UNKNOWN:. Group syntax would offer a fairly uniform way for = any third-party service to side-set DMARC policy restrictions. It would = also require faster adoption of code able to handle group syntax, which = should be seen as a win in both camps. Regards, Douglas Otis --Apple-Mail=_97D7FA34-4594-4093-B9F1-A0E3A5138441 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Oct 27, 2014, at 4:36 AM, = Alessandro Vesely <vesely@tana.it> wrote:

That's very equivocal.  It goes = without saying that From: is going to be munged, so why don't we say it = explicitly?  In addition, if we propose a simple munging scheme = --one that can be easily undone manually-- we provide users with the = ability to reply to authors even if their MUA doesn't recognize the new = field.  Consider:

  From: John Doe <john.doe@example.org.REMOVE.THE.TRAILING.PARTS>
  List-Original-Author:  John Doe = <john.doe@example.org>

We can even set up a dummy server which always = replies:

  551 User not local; please try = <john.doe@example.org>

Dear = Alessandro,

DMARC affects many third-party = services, only one being a mailing list.  Rather than munging =46rom = header fields and expect users to change it, especially when dealing = with different languages, a more concise and compliant scheme would be = to have DMARC adopt specific policy exceptions for group syntax. =  Such exceptions would then permit third-party services a means to = modify their =46rom in a manner not requiring hand editing and yet be = DMARC compliant.  Hand editing defeats protections due to the many = diverse ways of saying "Do not trust this From"  as would defining = an unseen replacement for the =46rom header field to stand in its place. =  In addition, only group syntax ensures the =46rom header field = being relied upon remains visible.  The =46rom header field being = visible is a key aspect of DMARC.  

It = still makes far more sense for DMARC to declare a group such as =E2=98=A0:= or DMARC-UNKNOWN:.  Group syntax would offer a fairly uniform way = for any third-party service to side-set DMARC policy restrictions. It = would also require faster adoption of code able to handle group syntax, = which should be seen as a win in both = camps.

Regards,
Douglas = Otis





= = --Apple-Mail=_97D7FA34-4594-4093-B9F1-A0E3A5138441-- From nobody Mon Oct 27 10:36:21 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 022111A6FFB for ; Mon, 27 Oct 2014 10:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AoVNowaxQu21 for ; Mon, 27 Oct 2014 10:30:36 -0700 (PDT) Received: from mail-yh0-f48.google.com (mail-yh0-f48.google.com [209.85.213.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D3241A6F3F for ; Mon, 27 Oct 2014 10:30:34 -0700 (PDT) Received: by mail-yh0-f48.google.com with SMTP id v1so4906061yhn.35 for ; Mon, 27 Oct 2014 10:30:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=zfo4uDkBUWHqRTmuJh3d1BkdeBapHfjEitaYfQEVs+Y=; b=D3TygN8ICD5uUXwBucLGr0uGLAueHUKsFD5nXCkPUrDew6K90mbtnkaq+cbL6yDZkZ tzNo1S+MRwoy7U38OYKE2Ath2tZPsmUOOs+L9HIhDRofaodnSxjPzzCvarpt+UGGHVDo bhX2eE1BauDSjvg+FUYwX1W9vFhFLtdRPZs0XU9gU5sOS1q+zKlJEMw/n0JSqhor4/Xw BeDSlFl3FnnX7X+YShft+KQD0E/V6eiLj04bCsibf1R9eMNLN86gOIjjwhUYfV3S2CBV UCK+YY4ylxd6h9hVKzWCmm8Wr3H3gs4eNbvGZAU99N/1cPpN0Mmx9BwU0Mqa+8bv3fxt dX+A== X-Gm-Message-State: ALoCoQl1dGUaxGo/OUZkB1EMosWOahAg/N5NJdozPAN6C+Cx6m/ye7FrDmG1aT7Q4sy5DA4tyP1d MIME-Version: 1.0 X-Received: by 10.236.231.161 with SMTP id l31mr23540865yhq.104.1414431033391; Mon, 27 Oct 2014 10:30:33 -0700 (PDT) Received: by 10.170.126.133 with HTTP; Mon, 27 Oct 2014 10:30:33 -0700 (PDT) In-Reply-To: <544A60AB.3020308@meetinghouse.net> References: <544A41D4.2000206@isdg.net> <544A60AB.3020308@meetinghouse.net> Date: Mon, 27 Oct 2014 10:30:33 -0700 Message-ID: From: Mike Jones To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=047d7b6727524e685805066ae3d2 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/w--9FA3yZcnDKqIAzt_ZoXgRmzE X-Mailman-Approved-At: Mon, 27 Oct 2014 10:36:16 -0700 Subject: Re: [dmarc-ietf] AND vs. OR (was Re: wiki vs. list?) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 17:30:40 -0000 --047d7b6727524e685805066ae3d2 Content-Type: text/plain; charset=UTF-8 On Fri, Oct 24, 2014 at 7:22 AM, Miles Fidelman wrote: > Hector Santos wrote: > >> Hi Kurt, >> >> If we are going to be picky about logic, then lets consider the symbolic >> correctness with short circuiting optimization, and it would be: >> >> DMARC = SPF or DKIM >> >> > > > Am I missing something here? As I understand it, DMARC is MORE than SPF > and DKIM. Specifically, as I understand it, sender field alignment, > that's bit all of us who run mailing lists, is specific to DMARC. > > You're not missing anything. aligned SPF pass OR aligned DKIM pass = DMARC pass Mike --047d7b6727524e685805066ae3d2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Oct 24, 2014 at 7:22 AM, Miles Fidelman <<= a href=3D"mailto:mfidelman@meetinghouse.net" target=3D"_blank">mfidelman@me= etinghouse.net> wrote:
Hector Santos wrote:
Hi Kurt,

If we are going to be picky about logic, then lets consider the symbolic co= rrectness with short circuiting optimization, and it would be:

=C2=A0 =C2=A0DMARC =3D SPF or DKIM


<snip>

Am I missing something here?=C2=A0 As I understand it, DMARC is MORE than S= PF and DKIM.=C2=A0 Specifically, as I understand it,=C2=A0 sender field ali= gnment, that's bit all of us who run mailing lists, is specific to DMAR= C.



You'r= e not missing anything. =C2=A0

aligned SPF pass OR= aligned DKIM pass =3D DMARC pass


M= ike =C2=A0
--047d7b6727524e685805066ae3d2-- From nobody Mon Oct 27 11:33:02 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54F611A908B for ; Mon, 27 Oct 2014 11:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDVZbwPHzEwB for ; Mon, 27 Oct 2014 11:32:32 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15F891ACEB8 for ; Mon, 27 Oct 2014 11:30:22 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s9RIUIEU015447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 27 Oct 2014 11:30:21 -0700 Message-ID: <544E8F30.6050602@dcrocker.net> Date: Mon, 27 Oct 2014 11:30:08 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Mike Jones References: <544A41D4.2000206@isdg.net> <544A60AB.3020308@meetinghouse.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 27 Oct 2014 11:30:21 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/784kgaFwvfsH1doMYX7pELg2wJA Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] AND vs. OR (was Re: wiki vs. list?) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 18:32:37 -0000 On 10/27/2014 10:30 AM, Mike Jones wrote: > aligned SPF pass OR aligned DKIM pass = DMARC pass +1 And the presence of the alignment requirement is what makes DMARC "more than" either of those individual mechanisms. This is not a small point of additional requirement. That one change imposes the policy requirement that the owner of the domain name in the rfc5322.From field and the operator of the originating ADMD explicitly coordinate operation. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Oct 27 11:57:02 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2FFE1ACF76 for ; Mon, 27 Oct 2014 11:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eF9Krh63nEG1 for ; Mon, 27 Oct 2014 11:56:28 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E094E1ACF74 for ; Mon, 27 Oct 2014 11:56:27 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id x19so5015594ier.16 for ; Mon, 27 Oct 2014 11:56:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=u7pr0Orkxt/GMq873Mlt+KZxyIH2cbLfDnQkKYSgfwk=; b=VAIRoehNEBcxN2q5Tl2xuwxwK6k3O1DJIknCQnSGfvIBs/b2KsY3KzOpTrxvorEvpn Q3OmCLggzjchXYI1T81DJs+9zVCue/LvCqLuooEyBx0zuIHIiVpwUBtIx9IwSGx8EUdW k9eA1y9dKp79VbI0rUYcfvY0vw/3YDpaHuHLGTn0aJlqCJR2vCV/TKyU6VJfqrb0RTSp BRE3vFwj64Up8+afcMb6yOr2fToXbtlFZFnSpdO1GKU8CA0ULVpC8KdSnTtFXOW/ctca BGvE8g0HNR1RTQPeB1NkaKHq8k3buriZxk5fQ5vFTOBnHOpczxz7KSvnTKyY0FM+wjx1 sY0g== X-Received: by 10.50.61.226 with SMTP id t2mr24793076igr.27.1414436187328; Mon, 27 Oct 2014 11:56:27 -0700 (PDT) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id v133sm6595999ioe.18.2014.10.27.11.56.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Oct 2014 11:56:26 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_7099C8C1-7228-4DC8-9F09-8C945E2F73C2" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Douglas Otis In-Reply-To: Date: Mon, 27 Oct 2014 11:56:25 -0700 Message-Id: References: <544A41D4.2000206@isdg.net> <544A60AB.3020308@meetinghouse.net> To: Mike Jones X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Z5khJe9V7lciTxIadwCLnOMWcXM Cc: "dmarc@ietf.org" , Douglas Otis Subject: Re: [dmarc-ietf] AND vs. OR (was Re: wiki vs. list?) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 18:56:30 -0000 --Apple-Mail=_7099C8C1-7228-4DC8-9F09-8C945E2F73C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 27, 2014, at 10:30 AM, Mike Jones wrote: > On Fri, Oct 24, 2014 at 7:22 AM, Miles Fidelman = wrote: > Hector Santos wrote: > Hi Kurt, >=20 > If we are going to be picky about logic, then lets consider the = symbolic correctness with short circuiting optimization, and it would = be: >=20 > DMARC =3D SPF or DKIM >=20 > >=20 > Am I missing something here? As I understand it, DMARC is MORE than = SPF and DKIM. Specifically, as I understand it, sender field = alignment, that's bit all of us who run mailing lists, is specific to = DMARC. >=20 > You're not missing anything. =20 >=20 > aligned SPF pass OR aligned DKIM pass =3D DMARC pass Dear Mike, Agreed. To further clarify the obvious, the WG needs to deal with large = ISPs asserting DMARC p=3Dreject against normal user accounts where, for = legitimate messages, the =46rom header field offered by various = third-party services can not be aligned with either SPF or DKIM. Possible mitigations:=20 1) Develop a scheme for the DMARC domain to assert domain specific = policy exceptions in the case of legitimate third-party services. 2) Create a group syntax able to bypass DMARC p=3D policy assertions by = offering visual indications in the =46rom header field that an exception = may have been made. 3) Munge the domain of the =46rom header field and expect users to hand = edit addresses. 4) Adopt a new generic method (not list specific) conditionally = replacing the role of the =46rom header field with a new (invisible) = header field. IMHO, options 3 and 4 should be avoided.=20 Regards, Douglas Otis --Apple-Mail=_7099C8C1-7228-4DC8-9F09-8C945E2F73C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Oct 27, 2014, at 10:30 AM, Mike = Jones <mjones@mail.agari.com> = wrote:

On Fri, Oct 24, 2014 at = 7:22 AM, Miles Fidelman <mfidelman@meetinghouse.net> = wrote:
Hector Santos wrote:
Hi Kurt,

If we are going to be picky about logic, then lets consider the symbolic = correctness with short circuiting optimization, and it would be:

   DMARC =3D SPF or DKIM

 <snip>

Am I missing something here?  As I understand it, DMARC is MORE = than SPF and DKIM.  Specifically, as I understand it,  sender = field alignment, that's bit all of us who run mailing lists, is specific = to DMARC.

You'r= e not missing anything.  

aligned SPF pass = OR aligned DKIM pass =3D DMARC = pass

Dear = Mike,

Agreed.  To further clarify the = obvious, the WG needs to deal with large ISPs asserting DMARC p=3Dreject = against normal user accounts where, for legitimate messages, the =46rom = header field offered by various third-party services can not be aligned = with either SPF or DKIM.

Possible = mitigations: 

1) Develop a scheme for the = DMARC domain to assert domain specific policy exceptions in the case of = legitimate third-party services.

2) Create a = group syntax able to bypass DMARC p=3D policy assertions by offering = visual indications in the =46rom header field that an exception may have = been made.

3) Munge the domain of the =46rom = header field and expect users to hand edit = addresses.

4) Adopt a new generic method (not = list specific) conditionally replacing the role of the =46rom header = field with a new (invisible) header = field.

IMHO, options 3 and 4 should be = avoided. 

Regards,
Douglas = Otis



= --Apple-Mail=_7099C8C1-7228-4DC8-9F09-8C945E2F73C2-- From nobody Mon Oct 27 12:22:32 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99E581AD06C for ; Mon, 27 Oct 2014 12:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jE0uNmAWlp0u for ; Mon, 27 Oct 2014 12:22:07 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03FE01AD080 for ; Mon, 27 Oct 2014 12:20:59 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.298.1; Mon, 27 Oct 2014 20:20:55 +0100 Message-ID: From: "J. Gomez" To: References: <5436FE09.4050104@sonnection.nl><20141010041209.2106.qmail@ary.lan><01PDKQLQAPA200005K@mauve.mrochek.com><01PDUPKE1KHQ00005L@mauve.mrochek.com><54494348.4090306@isdg.net><871tpyieot.fsf@uwakimon.sk.tsukuba.ac.jp><544A43D4.5070903@isdg.net> <87tx2tgoby.fsf@uwakimon.sk.tsukuba.ac.jp> <544AFEFA.1060506@isdg.net> <036E3CA0799048928F761B1C43905335@fgsr.local> <544BD68B.6030905@dcrocker.net> Date: Mon, 27 Oct 2014 20:23:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/ZfgofKnKwJafo3YlziNzBaSRIt8 Subject: Re: [dmarc-ietf] wiki vs. list? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 19:22:09 -0000 On Saturday, October 25, 2014 5:57 PM [GMT+1=3DCET], Dave Crocker wrote: > On 10/25/2014 12:34 PM, J. Gomez wrote: > > On Saturday, October 25, 2014 3:38 AM [GMT+1=3DCET], Hector Santos > > wrote:=20 > >=20 > > > DMARC is a DKIM Policy Framework. According the marketing, it has > > > gain widespread adoption especially among your list users > > > domains. Isn't why you are here, to stop it? > >=20 > > If by "widespread adoption" you mean that major mailbox providers > > (Gmail and others) are ignoring the Sender's DMARC policy (Yahoo, > > AOL and others), then yes: DMARC defines a DKIM policy which has > > widespread adoption. =20 >=20 > DMARC defines DMARC-related 'policies'. >=20 > It does not affect DKIM in any way. It is an overlay to DKIM and/or > SPF use. DMARC defines DMARC-related 'policies' which are an overlay on DKIM, = which to me could be also aptly phrased as "DMARC creates a policy = framework for DKIM", and more succintly "DMARC is a DKIM Policy = Framework". Yes, DMARC does not change DKIM de-iure. But also, yes, DMARC does bring = POLICY to DKIM. The truth here is that DMARC is going to be a de-facto DKIM 2.0. And = when I say "de-facto", I mean in production systems, on the trenches, in = the muddy world of reality where support costs do exist and ivory towers = are far in the distance and rest high away from all the mudd. Regards, J. Gomez From nobody Mon Oct 27 13:55:58 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 522441AD4BC for ; Mon, 27 Oct 2014 13:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.397 X-Spam-Level: X-Spam-Status: No, score=-1.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSpsYYfX3LpG for ; Mon, 27 Oct 2014 13:55:34 -0700 (PDT) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A7B81AD3E9 for ; Mon, 27 Oct 2014 13:55:31 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id cs9so4464086qab.15 for ; Mon, 27 Oct 2014 13:55:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=gyAKy6MhQz0x5s10cCHXI16EuW1naCuDzBkLkObO/mw=; b=qPBqg/9+1lV8WPpzxPguKBLF3+iKTGWILU/EB5sIty6Z10Mr2LGBZoe9Up9jz3Axv3 JkJBAiGtieods4oKGn/LAA+h9G9HQM2BTd+P3GGzhhdZCIciEL7PcpV/K7PIYBxvXq3s oi2dCzofuOm2Y5ehjTuVP6/i9x40Yy+1cT3Qib3etoA3OawUbu2Rlf/LPaNwiunFtheh z7qf7O4iKXbDOI/r1GUXExixIZ3NxI8SjJof6MpRF+jwHLTxpC2HdzUf8o4KJk4hbyL3 aqCe1j4RgARtU8TCI2ANKVFCcnKN9MtZEUgvjvcQZZbddfEbZF4p/zJFgnn479hn+OFJ Apqw== X-Received: by 10.224.38.130 with SMTP id b2mr37026543qae.11.1414443330375; Mon, 27 Oct 2014 13:55:30 -0700 (PDT) Received: from [192.168.1.114] (c-24-91-31-164.hsd1.ma.comcast.net. [24.91.31.164]) by mx.google.com with ESMTPSA id u46sm12079312qgd.3.2014.10.27.13.55.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Oct 2014 13:55:29 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_41466453-C974-42F7-9B64-C565B5EB1C35" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Brett McDowell In-Reply-To: Date: Mon, 27 Oct 2014 16:55:25 -0400 Message-Id: <19409258-9DAE-49CF-BD37-DDD648BAFBED@gmail.com> References: <544A41D4.2000206@isdg.net> <544A60AB.3020308@meetinghouse.net> To: Douglas Otis X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/zek2_nS2YnZMtOll0Czphsn9wvQ Cc: dmarc , Mike Jones Subject: Re: [dmarc-ietf] AND vs. OR (was Re: wiki vs. list?) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 20:55:37 -0000 --Apple-Mail=_41466453-C974-42F7-9B64-C565B5EB1C35 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Doug, you missed (at least) one option which I will characterize as = =E2=80=9Ctransient trust=E2=80=9D. I suggest transient trust could be = implemented at scale (for many use cases) via something like OAR [1] and = a companion BCP. -Brett [1] http://tools.ietf.org/html/draft-kucherawy-original-authres-00 = > On Oct 27, 2014, at 2:56 PM, Douglas Otis = wrote: >=20 >=20 > On Oct 27, 2014, at 10:30 AM, Mike Jones > wrote: >=20 >> On Fri, Oct 24, 2014 at 7:22 AM, Miles Fidelman = > wrote: >> Hector Santos wrote: >> Hi Kurt, >>=20 >> If we are going to be picky about logic, then lets consider the = symbolic correctness with short circuiting optimization, and it would = be: >>=20 >> DMARC =3D SPF or DKIM >>=20 >> >>=20 >> Am I missing something here? As I understand it, DMARC is MORE than = SPF and DKIM. Specifically, as I understand it, sender field = alignment, that's bit all of us who run mailing lists, is specific to = DMARC. >>=20 >> You're not missing anything. =20 >>=20 >> aligned SPF pass OR aligned DKIM pass =3D DMARC pass >=20 > Dear Mike, >=20 > Agreed. To further clarify the obvious, the WG needs to deal with = large ISPs asserting DMARC p=3Dreject against normal user accounts = where, for legitimate messages, the =46rom header field offered by = various third-party services can not be aligned with either SPF or DKIM. >=20 > Possible mitigations:=20 >=20 > 1) Develop a scheme for the DMARC domain to assert domain specific = policy exceptions in the case of legitimate third-party services. >=20 > 2) Create a group syntax able to bypass DMARC p=3D policy assertions = by offering visual indications in the =46rom header field that an = exception may have been made. >=20 > 3) Munge the domain of the =46rom header field and expect users to = hand edit addresses. >=20 > 4) Adopt a new generic method (not list specific) conditionally = replacing the role of the =46rom header field with a new (invisible) = header field. >=20 > IMHO, options 3 and 4 should be avoided.=20 >=20 > Regards, > Douglas Otis >=20 >=20 >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc = --Apple-Mail=_41466453-C974-42F7-9B64-C565B5EB1C35 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Doug, you missed (at least) one option which I will = characterize as =E2=80=9Ctransient trust=E2=80=9D.  I suggest = transient trust could be implemented at scale (for many use cases) via = something like OAR [1] and a companion BCP.

-Brett

[1] http://tools.ietf.org/html/draft-kucherawy-original-authres-00<= /a>



On Oct 27, 2014, at 2:56 PM, = Douglas Otis <doug.mtview@gmail.com> wrote:


On Oct 27, 2014, at 10:30 AM, Mike = Jones <mjones@mail.agari.com> wrote:

On Fri, = Oct 24, 2014 at 7:22 AM, Miles Fidelman <mfidelman@meetinghouse.net> wrote:
Hector Santos wrote:
Hi Kurt,

If we are going to = be picky about logic, then lets consider the symbolic correctness with = short circuiting optimization, and it would be:

   DMARC =3D SPF or DKIM

<snip>

Am I missing something here?  As I = understand it, DMARC is MORE than SPF and DKIM.  Specifically, as I = understand it,  sender field alignment, that's bit all of us who = run mailing lists, is specific to DMARC.

You're not missing anything. =  

aligned = SPF pass OR aligned DKIM pass =3D DMARC = pass

Dear Mike,

Agreed.  To = further clarify the obvious, the WG needs to deal with large ISPs = asserting DMARC p=3Dreject against normal user accounts where, for = legitimate messages, the =46rom header field offered by various = third-party services can not be aligned with either SPF or = DKIM.

Possible mitigations: 

1) Develop a scheme for = the DMARC domain to assert domain specific policy exceptions in the case = of legitimate third-party services.

2) Create a group = syntax able to bypass DMARC p=3D policy assertions by offering visual = indications in the =46rom header field that an exception may have been = made.

3) Munge the domain of the =46rom header field and = expect users to hand edit addresses.

4) Adopt a new generic = method (not list specific) conditionally replacing the role of the =46rom = header field with a new (invisible) header field.

IMHO, options 3 and 4 = should be avoided. 

Regards,
Douglas Otis



_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

= --Apple-Mail=_41466453-C974-42F7-9B64-C565B5EB1C35-- From nobody Mon Oct 27 13:59:46 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 690311AD4E7 for ; Mon, 27 Oct 2014 13:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qgq8WZVHaeE for ; Mon, 27 Oct 2014 13:59:14 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F7C21AD4EF for ; Mon, 27 Oct 2014 13:59:03 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s9RKwxju026340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 27 Oct 2014 13:59:03 -0700 Message-ID: <544EB20A.2050602@dcrocker.net> Date: Mon, 27 Oct 2014 13:58:50 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "J. Gomez" References: <5436FE09.4050104@sonnection.nl><20141010041209.2106.qmail@ary.lan><01PDKQLQAPA200005K@mauve.mrochek.com><01PDUPKE1KHQ00005L@mauve.mrochek.com><54494348.4090306@isdg.net><871tpyieot.fsf@uwakimon.sk.tsukuba.ac.jp><544A43D4.5070903@isdg.net> <87tx2tgoby.fsf@uwakimon.sk.tsukuba.ac.jp> <544AFEFA.1060506@isdg.net> <036E3CA0799048928F761B1C43905335@fgsr.local> <544BD68B.6030905@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 27 Oct 2014 13:59:03 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/V7a-ozzufn9SvzI5O-u7kbP7oEc Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] wiki vs. list? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 20:59:19 -0000 On 10/27/2014 12:23 PM, J. Gomez wrote: > On Saturday, October 25, 2014 5:57 PM [GMT+1=CET], Dave Crocker > wrote: >> DMARC defines DMARC-related 'policies'. >> >> It does not affect DKIM in any way. It is an overlay to DKIM >> and/or SPF use. > > DMARC defines DMARC-related 'policies' which are an overlay on DKIM, > which to me could be also aptly phrased as "DMARC creates a policy > framework for DKIM", and more succintly "DMARC is a DKIM Policy > Framework". > > Yes, DMARC does not change DKIM de-iure. But also, yes, DMARC does > bring POLICY to DKIM. No it does not. The relationship between DMARC and DKIM (and SPF) is like the relationship between TCP and IP. TCP does not 'bring reliability and congestion control to IP'. Rather, TCP /uses/ IP as a transfer component to the TCP reliability and congestion control framework that TCP creates. DMARC creates an authorization framework for the rfc5322.From (author) field. It uses DKIM and SPF for some authentication components to the DMARC framework. This is a fundamentally different relationship than what you are asserting. Your statement confuses roles and relationships. > The truth here is that DMARC is going to be a de-facto DKIM 2.0. And Nope. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Oct 27 14:16:59 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D966C1AD53D for ; Mon, 27 Oct 2014 14:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnEubWpNdKKB for ; Mon, 27 Oct 2014 14:16:33 -0700 (PDT) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CF061ACE30 for ; Mon, 27 Oct 2014 14:16:33 -0700 (PDT) Received: by mail-qa0-f54.google.com with SMTP id u7so3101284qaz.13 for ; Mon, 27 Oct 2014 14:16:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PEaYd3h4L03Ai8e0Cv64wyt/c1u51oXdfTlwQ2lana8=; b=ywkhrtheDPx2oIjdmgXud5F/OgA58BpSKDPRZRMXNyeMuJvz2C8KgB6obsY/H4hEmh 36ON3Shq5zUB/rYfRT0i1eepcLLwK3U70v5OE/eo9rbSyAW9QwgQQcrzxQ4sjGs2Y98E 7hT2GXJQOR2l4beblbfijz8JpiTPrWb+mx5a5+4oA9z7ofre8GY0GQHGQKJFW05xorcd b1QHQoHri0Hw++rv5Z7eX1C4+92BqaxMjHrHPvjccabXM6KFtIDCzPsArlNqOAphsJXQ FQuEca0KHP4gcljxKv/cNYK3lgHcRM9JePF/2xsIIFl0ny10bacxsdL1AZSscuVM7X0o 5ZdA== X-Received: by 10.140.95.225 with SMTP id i88mr35103663qge.2.1414444591269; Mon, 27 Oct 2014 14:16:31 -0700 (PDT) Received: from [192.168.1.114] (c-24-91-31-164.hsd1.ma.comcast.net. [24.91.31.164]) by mx.google.com with ESMTPSA id q6sm12203940qas.16.2014.10.27.14.16.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Oct 2014 14:16:30 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Brett McDowell In-Reply-To: <544EB20A.2050602@dcrocker.net> Date: Mon, 27 Oct 2014 17:16:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <67037945-4C30-43A9-9030-0A7A2A061C15@gmail.com> References: <5436FE09.4050104@sonnection.nl> <20141010041209.2106.qmail@ary.lan> <01PDKQLQAPA200005K@mauve.mrochek.com> <01PDUPKE1KHQ00005L@mauve.mrochek.com> <54494348.4090306@isdg.net> <871tpyieot.fsf@uwakimon.sk.tsukuba.ac.jp> <544A43D4.5070903@isdg.net> <87tx2tgoby.fsf@uwakimon.sk.tsukuba.ac.jp> <544AFEFA.1060506@isdg.net> <036E3CA0799048928F761B1C43905335@fgsr.local> <544BD68B.6030905@dcrocker.net> <544EB20A.2050602@dcrocker.net> To: Dave Crocker X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/kC_tabin9Uar_UfzGETSCsMXMEs Cc: dmarc , "J. Gomez" Subject: Re: [dmarc-ietf] wiki vs. list? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 21:16:35 -0000 I=E2=80=99m not sure what the relevance of this particular debate is, = but in hopes of moving us forward, I offer another data point. Please remember that you can deploy DMARC and get exactly the desired = result from your DMARC deployment, without deploying any DKIM = infrastructure. Example: you can push a p=3Dreject on a domain that = never sends mail. You can push any p=3D value for a domain that is only = =E2=80=9Cprotected=E2=80=9D by SPF records, even one that is in use, and = get exactly the desired result. DKIM is of course required to achieve = the desired result for most mail flows, but DKIM it is not in any way = required for all successful deployments of DMARC. Given that fact, perhaps we can stop debating whether or not DMARC is a = DKIM Policy Framework. But what was the point of that debate in the = first place? If we all agreed that DMARC was a DKIM Policy Framework, = what outcome would that have brought us closer to? I suspect there was = a purpose for that argument that might still be relevant to our work = even though the argument doesn=E2=80=99t seem to be supported, but I=E2=80= =99m not seeing it yet. -Brett > On Oct 27, 2014, at 4:58 PM, Dave Crocker wrote: >=20 > On 10/27/2014 12:23 PM, J. Gomez wrote: >> On Saturday, October 25, 2014 5:57 PM [GMT+1=3DCET], Dave Crocker >> wrote: >>> DMARC defines DMARC-related 'policies'. >>>=20 >>> It does not affect DKIM in any way. It is an overlay to DKIM >>> and/or SPF use. >>=20 >> DMARC defines DMARC-related 'policies' which are an overlay on DKIM, >> which to me could be also aptly phrased as "DMARC creates a policy >> framework for DKIM", and more succintly "DMARC is a DKIM Policy >> Framework". >>=20 >> Yes, DMARC does not change DKIM de-iure. But also, yes, DMARC does >> bring POLICY to DKIM. >=20 > No it does not. >=20 > The relationship between DMARC and DKIM (and SPF) is like the > relationship between TCP and IP. TCP does not 'bring reliability and > congestion control to IP'. Rather, TCP /uses/ IP as a transfer > component to the TCP reliability and congestion control framework that > TCP creates. >=20 > DMARC creates an authorization framework for the rfc5322.=46rom = (author) > field. It uses DKIM and SPF for some authentication components to the > DMARC framework. >=20 > This is a fundamentally different relationship than what you are > asserting. Your statement confuses roles and relationships. >=20 >=20 >> The truth here is that DMARC is going to be a de-facto DKIM 2.0. And >=20 > Nope. >=20 >=20 > d/ >=20 > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Mon Oct 27 14:18:08 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D37F91AD540 for ; Mon, 27 Oct 2014 14:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0V98absCzyv9 for ; Mon, 27 Oct 2014 14:17:31 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 052431AD53A for ; Mon, 27 Oct 2014 14:17:30 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id x19so5116119ier.5 for ; Mon, 27 Oct 2014 14:17:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=3GX0kvuI2Wx92Uk3XivI7QyLQ+GlXuBfld+AmzcIJ2g=; b=Yn5+YQVIUhybadXz9USfdB//53eZTLUTxhpoZ8WAWHs62WDVOd4/1mwI33dxRJI/q+ CMOztv5s5EdG5gDcKXVaiVMcfhz+VfpCmuVt0BB2aPb3tQf4PbyGrDPrsvpublUCG5b+ ceKoQ7TutmMP0e7dxFEqotCSSXeonTBFUgbJglseeppXvDI2G8FUz3Fnm8PS0UbgWhX7 /PjiImIn+lPTdDVrSYO4zG+rUw0H2lf5sH3AASm8EnYfyImVBOGnR6VhkaFYxmlZKjtL NUINq218TaEk/y7TL4MMpNaNpnc1oTUdGH2Y1+g4LmJmxapiWObNHWpjr1hMFFmpCxZe R9tQ== X-Received: by 10.50.79.193 with SMTP id l1mr31209igx.10.1414444650224; Mon, 27 Oct 2014 14:17:30 -0700 (PDT) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id jd6sm5475890igb.16.2014.10.27.14.17.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Oct 2014 14:17:29 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_B70A82E6-6B08-4E80-A28C-61C1A072AE9B" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Douglas Otis In-Reply-To: <19409258-9DAE-49CF-BD37-DDD648BAFBED@gmail.com> Date: Mon, 27 Oct 2014 14:17:27 -0700 Message-Id: <71411CDC-1413-4901-BA73-BB0B1C5260B4@gmail.com> References: <544A41D4.2000206@isdg.net> <544A60AB.3020308@meetinghouse.net> <19409258-9DAE-49CF-BD37-DDD648BAFBED@gmail.com> To: Brett McDowell X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/IYsrzIlFXulYa3MzIgimlxMZZio Cc: dmarc , Douglas Otis , Mike Jones Subject: Re: [dmarc-ietf] AND vs. OR (was Re: wiki vs. list?) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 21:17:33 -0000 --Apple-Mail=_B70A82E6-6B08-4E80-A28C-61C1A072AE9B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 27, 2014, at 1:55 PM, Brett McDowell = wrote: > Doug, you missed (at least) one option which I will characterize as = =93transient trust=94. I suggest transient trust could be implemented = at scale (for many use cases) via something like OAR [1] and a companion = BCP. >=20 > -Brett >=20 > [1] http://tools.ietf.org/html/draft-kucherawy-original-authres-00 Dear Brett, Original-Authentication-Results Header Field should fall under option 4 = which is trivially spoofed. OAR represent a new (invisible) header not = signed by the DMARC domain. Such information can not safely be trusted = unless authorized by DMARC domain, i.e. TPA-Labels which falls under = option 1. TPA-Label has provisions covering OAR requirements among = other elements. Regards, Douglas Otis >> On Oct 27, 2014, at 2:56 PM, Douglas Otis = wrote: >>=20 >>=20 >> On Oct 27, 2014, at 10:30 AM, Mike Jones = wrote: >>=20 >>> On Fri, Oct 24, 2014 at 7:22 AM, Miles Fidelman = wrote: >>> Hector Santos wrote: >>> Hi Kurt, >>>=20 >>> If we are going to be picky about logic, then lets consider the = symbolic correctness with short circuiting optimization, and it would = be: >>>=20 >>> DMARC =3D SPF or DKIM >>>=20 >>> >>>=20 >>> Am I missing something here? As I understand it, DMARC is MORE than = SPF and DKIM. Specifically, as I understand it, sender field = alignment, that's bit all of us who run mailing lists, is specific to = DMARC. >>>=20 >>> You're not missing anything. =20 >>>=20 >>> aligned SPF pass OR aligned DKIM pass =3D DMARC pass >>=20 >> Dear Mike, >>=20 >> Agreed. To further clarify the obvious, the WG needs to deal with = large ISPs asserting DMARC p=3Dreject against normal user accounts = where, for legitimate messages, the =46rom header field offered by = various third-party services can not be aligned with either SPF or DKIM. >>=20 >> Possible mitigations:=20 >>=20 >> 1) Develop a scheme for the DMARC domain to assert domain specific = policy exceptions in the case of legitimate third-party services. >>=20 >> 2) Create a group syntax able to bypass DMARC p=3D policy assertions = by offering visual indications in the =46rom header field that an = exception may have been made. >>=20 >> 3) Munge the domain of the =46rom header field and expect users to = hand edit addresses. >>=20 >> 4) Adopt a new generic method (not list specific) conditionally = replacing the role of the =46rom header field with a new (invisible) = header field. >>=20 >> IMHO, options 3 and 4 should be avoided.=20 >>=20 >> Regards, >> Douglas Otis >>=20 >>=20 >>=20 >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >=20 --Apple-Mail=_B70A82E6-6B08-4E80-A28C-61C1A072AE9B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Oct 27, 2014, at 1:55 PM, Brett = McDowell <brettmcdowell@gmail.com> = wrote:

Doug, you = missed (at least) one option which I will characterize as =93transient = trust=94.  I suggest transient trust could be implemented at scale = (for many use cases) via something like OAR [1] and a companion BCP.

-Brett

[1] http://tools.ietf.org/html/draft-kucherawy-original-authres-00<= /a>

Dear = Brett,




On Oct 27, 2014, at 2:56 PM, Douglas Otis <doug.mtview@gmail.com> wrote:


On Oct 27, 2014, at 10:30 AM, Mike = Jones <mjones@mail.agari.com> wrote:

On Fri, = Oct 24, 2014 at 7:22 AM, Miles Fidelman <mfidelman@meetinghouse.net> wrote:
Hector Santos wrote:
Hi Kurt,

If we are going to = be picky about logic, then lets consider the symbolic correctness with = short circuiting optimization, and it would be:

   DMARC =3D SPF or DKIM

<snip>

Am I missing something here?  As I = understand it, DMARC is MORE than SPF and DKIM.  Specifically, as I = understand it,  sender field alignment, that's bit all of us who = run mailing lists, is specific to DMARC.

You're not missing anything. =  

aligned = SPF pass OR aligned DKIM pass =3D DMARC = pass

Dear Mike,

Agreed.  To = further clarify the obvious, the WG needs to deal with large ISPs = asserting DMARC p=3Dreject against normal user accounts where, for = legitimate messages, the =46rom header field offered by various = third-party services can not be aligned with either SPF or = DKIM.

Possible mitigations: 

1) Develop a scheme for = the DMARC domain to assert domain specific policy exceptions in the case = of legitimate third-party services.

2) Create a group = syntax able to bypass DMARC p=3D policy assertions by offering visual = indications in the =46rom header field that an exception may have been = made.

3) Munge the domain of the =46rom header field and = expect users to hand edit addresses.

4) Adopt a new generic = method (not list specific) conditionally replacing the role of the =46rom = header field with a new (invisible) header field.

IMHO, options 3 and 4 = should be avoided. 

Regards,
Douglas Otis



_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


= --Apple-Mail=_B70A82E6-6B08-4E80-A28C-61C1A072AE9B-- From nobody Mon Oct 27 14:20:53 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4E41AD54B for ; Mon, 27 Oct 2014 14:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.397 X-Spam-Level: X-Spam-Status: No, score=-1.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id unZWHbw3JCsW for ; Mon, 27 Oct 2014 14:20:25 -0700 (PDT) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF6341AD549 for ; Mon, 27 Oct 2014 14:20:24 -0700 (PDT) Received: by mail-qg0-f50.google.com with SMTP id a108so2113112qge.9 for ; Mon, 27 Oct 2014 14:20:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=qNGKnck0Nhc0c/DDt/vBwVMvWMZUplenxaF0sVq69KU=; b=mW3v0ABEeCCn5Aaz4flbgKt9zOll4UWTfkYn4KC/4oWAix2TsRDKA4sxTXjxrgoW7B KjNoCjBvVcjCEjEFyiUtfsiV5Iw4wiFCydPmc5KZbajkCehrEQ9G56z/ZTNGItQrrwaL vgvHkaLK/RoV3qRJ6nNmcXc+1Jao/HgbRc1PorWr2uRSWASc9+UqjOme2vTZ0cDGjYJ5 kRAk89c6t8HJBK1HihX/KRC7VrcjXpc/Q89ra+RtYlyfkG3UqgvDRx9JGSmPmISuycyN mWVw5x5/L6NKUEu7LBK5yDS/evKsR2f0Qbr0IQBU9rv/ncWV6251VpoJOz4r8uDsUi+S oEYQ== X-Received: by 10.140.86.135 with SMTP id p7mr36029670qgd.54.1414444824152; Mon, 27 Oct 2014 14:20:24 -0700 (PDT) Received: from [192.168.1.114] (c-24-91-31-164.hsd1.ma.comcast.net. [24.91.31.164]) by mx.google.com with ESMTPSA id k4sm12207085qaj.21.2014.10.27.14.20.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Oct 2014 14:20:23 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_824140EC-D26E-4B9A-8D1B-95C0AD0B8DFE" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Brett McDowell In-Reply-To: <71411CDC-1413-4901-BA73-BB0B1C5260B4@gmail.com> Date: Mon, 27 Oct 2014 17:20:20 -0400 Message-Id: <0DC6DB4D-D209-4D27-92BB-13C08CBA344A@gmail.com> References: <544A41D4.2000206@isdg.net> <544A60AB.3020308@meetinghouse.net> <19409258-9DAE-49CF-BD37-DDD648BAFBED@gmail.com> <71411CDC-1413-4901-BA73-BB0B1C5260B4@gmail.com> To: Douglas Otis X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/97v7yTJo_TQ3GYHQ_-5ZwIXaH-I Cc: dmarc , Mike Jones Subject: Re: [dmarc-ietf] AND vs. OR (was Re: wiki vs. list?) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 21:20:27 -0000 --Apple-Mail=_824140EC-D26E-4B9A-8D1B-95C0AD0B8DFE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks Doug. I may not agree with your assessment of OAR, but it is = good to know you had it in mind. As for TPA-Labels, it=92s been a long = time since I looked at that proposal and I=92ll be brushing up on it = between now and IETF91. -Brett > On Oct 27, 2014, at 5:17 PM, Douglas Otis = wrote: >=20 >=20 > On Oct 27, 2014, at 1:55 PM, Brett McDowell > wrote: >=20 >> Doug, you missed (at least) one option which I will characterize as = =93transient trust=94. I suggest transient trust could be implemented = at scale (for many use cases) via something like OAR [1] and a companion = BCP. >>=20 >> -Brett >>=20 >> [1] http://tools.ietf.org/html/draft-kucherawy-original-authres-00 = > Dear Brett, >=20 > Original-Authentication-Results Header Field should fall under option = 4 which is trivially spoofed. OAR represent a new (invisible) header = not signed by the DMARC domain. Such information can not safely be = trusted unless authorized by DMARC domain, i.e. TPA-Labels which falls = under option 1. TPA-Label has provisions covering OAR requirements = among other elements. >=20 > Regards, > Douglas Otis >=20 >=20 >=20 >>> On Oct 27, 2014, at 2:56 PM, Douglas Otis > wrote: >>>=20 >>>=20 >>> On Oct 27, 2014, at 10:30 AM, Mike Jones > wrote: >>>=20 >>>> On Fri, Oct 24, 2014 at 7:22 AM, Miles Fidelman = > wrote: >>>> Hector Santos wrote: >>>> Hi Kurt, >>>>=20 >>>> If we are going to be picky about logic, then lets consider the = symbolic correctness with short circuiting optimization, and it would = be: >>>>=20 >>>> DMARC =3D SPF or DKIM >>>>=20 >>>> >>>>=20 >>>> Am I missing something here? As I understand it, DMARC is MORE = than SPF and DKIM. Specifically, as I understand it, sender field = alignment, that's bit all of us who run mailing lists, is specific to = DMARC. >>>>=20 >>>> You're not missing anything. =20 >>>>=20 >>>> aligned SPF pass OR aligned DKIM pass =3D DMARC pass >>>=20 >>> Dear Mike, >>>=20 >>> Agreed. To further clarify the obvious, the WG needs to deal with = large ISPs asserting DMARC p=3Dreject against normal user accounts = where, for legitimate messages, the =46rom header field offered by = various third-party services can not be aligned with either SPF or DKIM. >>>=20 >>> Possible mitigations:=20 >>>=20 >>> 1) Develop a scheme for the DMARC domain to assert domain specific = policy exceptions in the case of legitimate third-party services. >>>=20 >>> 2) Create a group syntax able to bypass DMARC p=3D policy assertions = by offering visual indications in the =46rom header field that an = exception may have been made. >>>=20 >>> 3) Munge the domain of the =46rom header field and expect users to = hand edit addresses. >>>=20 >>> 4) Adopt a new generic method (not list specific) conditionally = replacing the role of the =46rom header field with a new (invisible) = header field. >>>=20 >>> IMHO, options 3 and 4 should be avoided.=20 >>>=20 >>> Regards, >>> Douglas Otis >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> dmarc mailing list >>> dmarc@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmarc = >=20 --Apple-Mail=_824140EC-D26E-4B9A-8D1B-95C0AD0B8DFE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Thanks Doug.  I may not agree with your assessment of = OAR, but it is good to know you had it in mind.  As for TPA-Labels, = it=92s been a long time since I looked at that proposal and I=92ll be = brushing up on it between now and IETF91.

-Brett


On Oct 27, 2014, at 5:17 PM, = Douglas Otis <doug.mtview@gmail.com> wrote:


On Oct 27, 2014, at 1:55 PM, = Brett McDowell <brettmcdowell@gmail.com> wrote:

Doug, you missed (at least) one option which I will = characterize as =93transient trust=94.  I suggest transient trust = could be implemented at scale (for many use cases) via something like = OAR [1] and a companion BCP.

-Brett

[1] http://tools.ietf.org/html/draft-kucherawy-original-authres-00<= /a>

Dear = Brett,

Original-Authentication-Results Header Field should = fall under option 4 which is trivially spoofed.  OAR represent a = new (invisible) header not signed by the DMARC domain.  Such = information can not safely be trusted unless authorized by DMARC domain, = i.e. TPA-Labels which falls under option 1.  TPA-Label has = provisions covering OAR requirements among other elements.

Regards,
Douglas Otis



On Oct = 27, 2014, at 2:56 PM, Douglas Otis <doug.mtview@gmail.com> wrote:


On Oct 27, 2014, at 10:30 AM, Mike = Jones <mjones@mail.agari.com> wrote:

On Fri, = Oct 24, 2014 at 7:22 AM, Miles Fidelman <mfidelman@meetinghouse.net> wrote:
Hector Santos wrote:
Hi Kurt,

If we are going to = be picky about logic, then lets consider the symbolic correctness with = short circuiting optimization, and it would be:

   DMARC =3D SPF or DKIM

<snip>

Am I missing something here?  As I = understand it, DMARC is MORE than SPF and DKIM.  Specifically, as I = understand it,  sender field alignment, that's bit all of us who = run mailing lists, is specific to DMARC.

You're not missing anything. =  

aligned = SPF pass OR aligned DKIM pass =3D DMARC = pass

Dear Mike,

Agreed.  To = further clarify the obvious, the WG needs to deal with large ISPs = asserting DMARC p=3Dreject against normal user accounts where, for = legitimate messages, the =46rom header field offered by various = third-party services can not be aligned with either SPF or = DKIM.

Possible mitigations: 

1) Develop a scheme for = the DMARC domain to assert domain specific policy exceptions in the case = of legitimate third-party services.

2) Create a group = syntax able to bypass DMARC p=3D policy assertions by offering visual = indications in the =46rom header field that an exception may have been = made.

3) Munge the domain of the =46rom header field and = expect users to hand edit addresses.

4) Adopt a new generic = method (not list specific) conditionally replacing the role of the =46rom = header field with a new (invisible) header field.

IMHO, options 3 and 4 = should be avoided. 

Regards,
Douglas Otis



_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc



= --Apple-Mail=_824140EC-D26E-4B9A-8D1B-95C0AD0B8DFE-- From nobody Mon Oct 27 14:49:35 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 033351A0060 for ; Mon, 27 Oct 2014 14:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K24OY7S3FGo5 for ; Mon, 27 Oct 2014 14:49:30 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E52A51A0111 for ; Mon, 27 Oct 2014 14:49:23 -0700 (PDT) Received: by mail-ig0-f177.google.com with SMTP id h18so4061762igc.16 for ; Mon, 27 Oct 2014 14:49:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=i5zQTdZ7QeMOWy9AlTUxKwgfzd9Ik2uDt856z00laks=; b=jzgke0Lrj2Lab1U9CNFFNxWyJ2R016lUHSUeSm34Q1aXGDVjBvMaA6MZosvMlB1c9R vTHceRvqbf9eZpTKUgVS5xndB7tCsKu6l4ZZnP8yIN9b9/nr2sU5XgXVrOCcXBMy8xFO GnKwTtrxO6yDmSgED62wTShWnZm29taYHe/SzDiJbrn9E0u7zuSRsrdzjMd/HYvorcwj 6ioflklAeAKRrRRgwAYOPxkNG+7JcELTfuDpa/Z8ZEHtT4z9dIKA8hWBOFaQh0gzFlZk pknXVeJrFn5AV+YCiHph4C5QXSSfe70Z53GI4oSJlViDAItjPfAECWCfb9eQ61/dSGcT WtbA== X-Received: by 10.50.79.232 with SMTP id m8mr25586289igx.11.1414446563378; Mon, 27 Oct 2014 14:49:23 -0700 (PDT) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id p62sm6781030ioe.33.2014.10.27.14.49.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Oct 2014 14:49:22 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_CAD3F6CD-A0B2-4F5E-9ED0-CEA30A1104D0" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Douglas Otis In-Reply-To: <67037945-4C30-43A9-9030-0A7A2A061C15@gmail.com> Date: Mon, 27 Oct 2014 14:49:21 -0700 Message-Id: <76282ACB-FFAD-4177-8A28-9C78A43B2D2E@gmail.com> References: <5436FE09.4050104@sonnection.nl> <20141010041209.2106.qmail@ary.lan> <01PDKQLQAPA200005K@mauve.mrochek.com> <01PDUPKE1KHQ00005L@mauve.mrochek.com> <54494348.4090306@isdg.net> <871tpyieot.fsf@uwakimon.sk.tsukuba.ac.jp> <544A43D4.5070903@isdg.net> <87tx2tgoby.fsf@uwakimon.sk.tsukuba.ac.jp> <544AFEFA.1060506@isdg.net> <036E3CA0799048928F761B1C43905335@fgsr.local> <544BD68B.6030905@dcrocker.net> <544EB20A.2050602@dcrocker.net> <67037945-4C30-43A9-9030-0A7A2A061C15@gmail.com> To: Brett McDowell X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/0uQKFagCr_YuUi_Q36p8Qg2tHbY Cc: dmarc , "J. Gomez" , Douglas Otis , Dave Crocker Subject: Re: [dmarc-ietf] wiki vs. list? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 21:49:32 -0000 --Apple-Mail=_CAD3F6CD-A0B2-4F5E-9ED0-CEA30A1104D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 27, 2014, at 2:16 PM, Brett McDowell = wrote: > I=92m not sure what the relevance of this particular debate is, but in = hopes of moving us forward, I offer another data point. >=20 > Please remember that you can deploy DMARC and get exactly the desired = result from your DMARC deployment, without deploying any DKIM = infrastructure. Example: you can push a p=3Dreject on a domain that = never sends mail. You can push any p=3D value for a domain that is only = =93protected=94 by SPF records, even one that is in use, and get exactly = the desired result. DKIM is of course required to achieve the desired = result for most mail flows, but DKIM it is not in any way required for = all successful deployments of DMARC. >=20 > Given that fact, perhaps we can stop debating whether or not DMARC is = a DKIM Policy Framework. But what was the point of that debate in the = first place? If we all agreed that DMARC was a DKIM Policy Framework, = what outcome would that have brought us closer to? I suspect there was = a purpose for that argument that might still be relevant to our work = even though the argument doesn=92t seem to be supported, but I=92m not = seeing it yet. Dear Brett, DMARC/SPF hinders third-party services to a greater extent, since DKIM = still permits messages that lack modification and SPF does not. A DMARC = policy of p=3Dreject against user email accounts will not obtain desired = results when third-party services are utilized. This problem can be = transparently repaired through the use of TPA-Label at any scale, or = eventually through adoption of an excluded but obvious group syntax. An = excluded group syntax would not be as secure as TPA-Label, since use of = group syntax depends on cautious recipients. There are still many cases = where email includes malicious active-content acted upon by MUAs where = users prove themselves easily intrigued, even to the point of opening = messages in their spam folder (where growing amounts of legitimate email = is being found largely because of downgraded DMARC policy). Regards, Douglas Otis=20= --Apple-Mail=_CAD3F6CD-A0B2-4F5E-9ED0-CEA30A1104D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Oct 27, 2014, at 2:16 PM, Brett = McDowell <brettmcdowell@gmail.com> = wrote:

I=92m not sure what the relevance of = this particular debate is, but in hopes of moving us forward, I offer = another data point.

Please remember that you can deploy DMARC = and get exactly the desired result from your DMARC deployment, without = deploying any DKIM infrastructure.  Example: you can push a = p=3Dreject on a domain that never sends mail.  You can push any p=3D = value for a domain that is only =93protected=94 by SPF records, even one = that is in use, and get exactly the desired result.  DKIM is of = course required to achieve the desired result for most mail flows, but = DKIM it is not in any way required for all successful deployments of = DMARC.

Given that fact, perhaps we can stop = debating whether or not DMARC is a DKIM Policy Framework.  But what = was the point of that debate in the first place?  If we all agreed = that DMARC was a DKIM Policy Framework, what outcome would that have = brought us closer to?  I suspect there was a purpose for that = argument that might still be relevant to our work even though the = argument doesn=92t seem to be supported, but I=92m not seeing it = yet.

Dear = Brett,

DMARC/SPF hinders third-party services = to a greater extent, since DKIM still permits messages that lack = modification and SPF does not.  A DMARC policy of p=3Dreject = against user email accounts will not obtain desired results when = third-party services are utilized.  This problem can be = transparently repaired through the use of TPA-Label at any scale, or = eventually through adoption of an excluded but obvious group syntax. =  An excluded group syntax would not be as secure as TPA-Label, = since use of group syntax depends on cautious recipients.  There = are still many cases where email includes malicious active-content acted = upon by MUAs where users prove themselves easily intrigued, even to the = point of opening messages in their spam folder (where growing amounts of = legitimate email is being found largely because of downgraded DMARC = policy).

Regards,
Douglas = Otis 
= --Apple-Mail=_CAD3F6CD-A0B2-4F5E-9ED0-CEA30A1104D0-- From nobody Mon Oct 27 15:28:00 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 598491A1A74 for ; Mon, 27 Oct 2014 15:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBg6s5YR84Hr for ; Mon, 27 Oct 2014 15:27:54 -0700 (PDT) Received: from mail-yh0-f49.google.com (mail-yh0-f49.google.com [209.85.213.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4300D1A0AF8 for ; Mon, 27 Oct 2014 15:27:54 -0700 (PDT) Received: by mail-yh0-f49.google.com with SMTP id t59so823488yho.8 for ; Mon, 27 Oct 2014 15:27:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=SYaIOhfJReXKEnJZzLVlzlVZZcqDJl7BFGsJT9xnPWA=; b=NqiBXDRONkUbfIFovegs3PIjuoJNTDw5XdUUHPSkn+uvPMCyIEeV5DAZDRJcZMzykE Fqr95FLHOz2JkCDdfYYV5ezVI0r87XpR/c2CV0cdA67nIji1pQQhzpjrDiET9t2zrwYG gOQEN5oJzqUNhNLvMj88+uS7RI3aGW1Wx/bpkmxKYKiSPko4dB1RsCaZvYbDYx5Q7uV8 tDjYVWvVkrNi0im+Q7VTpN71KSo0jFDZ8E/s3D/mkOykQZ7jVJQk7HPtwIUb9h7F3A+c M7j1cKLL3yAZJESaT/cHDj5vFvYINf5FxmqYtYs28VZy7Yboq25LaKurBgM5KXuggMki tnUg== X-Gm-Message-State: ALoCoQmQBxu0XJ5g2GIRTf9fy3AFXjkM9xs6ivVosJXenWH7oUjbDlTr0uYEJ7ZNStSaoUuU3no4 MIME-Version: 1.0 X-Received: by 10.236.210.80 with SMTP id t56mr25489365yho.110.1414448873521; Mon, 27 Oct 2014 15:27:53 -0700 (PDT) Received: by 10.170.126.133 with HTTP; Mon, 27 Oct 2014 15:27:53 -0700 (PDT) Date: Mon, 27 Oct 2014 15:27:53 -0700 Message-ID: From: Mike Jones To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=089e0160a44ea8dba805066f0a1d Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/dTkOHa5ZyLgVW9XTTYcmxlc3IXs Subject: [dmarc-ietf] Deliverable #4 - DMARC Usage Guide X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 22:27:56 -0000 --089e0160a44ea8dba805066f0a1d Content-Type: text/plain; charset=UTF-8 The working group charter has a deliverable to produce "A Usage Guide to document DMARC-related operational practices". I believe we have discussed on this list that the existing 'Using DMARC' document, http://tools.ietf.org/html/draft-crocker-dmarc-bcp-03, will be the basis of this usage guide. The charter also indicates the work on the usage guide will be in phases 2 & 3, while we are currently in phase 1. But I believe there are many areas of the existing document that could be reviewed and updated in parallel with the phase 1 activities around the discovery and documentation of issues with DMARC and indirect mail flows. For example, I wrote most of sections 7 & 8 of the existing document (Report Generation & Report Receipt and Analysis) about 2 years ago based on observed and anticipated practice at that time. A lot of this could be reviewed an updated now, based on experience since then, without waiting for the output from phase 1. I would like to start reviewing and suggesting edits to the 'Using DMARC' guide sooner rather than later. Will this violate any procedural rules of the working group? If not, does anyone think this will detract from the ongoing phase 1 work? Thanks, Mike --089e0160a44ea8dba805066f0a1d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

The working group charter has a delive= rable to produce "A Usage Guide to document DMARC-related operational = practices".=C2=A0 I believe we have discussed on this list that the ex= isting 'Using DMARC' document,=C2=A0http://tools.ietf.org/html/draft-crocker= -dmarc-bcp-03, will be the basis of this usage guide. =C2=A0 =C2=A0The = charter also indicates the work on the usage guide will be in phases 2 &= ; 3, while we are currently in phase 1.=C2=A0 But I believe there are many = areas of the existing document that could be reviewed and updated in parall= el with the phase 1 activities around the discovery and documentation of is= sues with DMARC and indirect mail flows.=C2=A0 For example, I wrote most of= sections 7 & 8 =C2=A0of the existing document (Report Generation &= Report Receipt and Analysis) about 2 years ago based on observed and antic= ipated practice at that time.=C2=A0 A lot of this could be reviewed an upda= ted now, based on experience since then, without waiting for the output fro= m phase 1. =C2=A0

I would like to start reviewing = and suggesting edits to the 'Using DMARC' guide sooner rather than = later. Will this violate any procedural rules of the working group? If not,= does anyone think this will detract from the ongoing phase 1 work? =C2=A0<= br>

Thanks,=C2=A0
Mike



--089e0160a44ea8dba805066f0a1d-- From nobody Mon Oct 27 17:20:14 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3A441A87C8 for ; Mon, 27 Oct 2014 17:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.281 X-Spam-Level: X-Spam-Status: No, score=-0.281 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_16=0.6, MISSING_HEADERS=1.021, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZMgj2T84_0D for ; Mon, 27 Oct 2014 17:20:07 -0700 (PDT) Received: from server1.neighborhoods.net (server1.neighborhoods.net [207.154.13.48]) by ietfa.amsl.com (Postfix) with ESMTP id D758C1A87C7 for ; Mon, 27 Oct 2014 17:20:06 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by server1.neighborhoods.net (Postfix) with ESMTP id 16B42CC047 for ; Mon, 27 Oct 2014 20:20:06 -0400 (EDT) X-Virus-Scanned: by amavisd-new-2.6.2 (20081215) (Debian) at neighborhoods.net Received: from server1.neighborhoods.net ([127.0.0.1]) by localhost (server1.neighborhoods.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 6h0rj7fmN3yo for ; Mon, 27 Oct 2014 20:19:57 -0400 (EDT) Received: from Miles-Fidelmans-MacBook-Pro.local (static-173-56-67-50.nycmny.fios.verizon.net [173.56.67.50]) by server1.neighborhoods.net (Postfix) with ESMTPSA id 0E723CC03C for ; Mon, 27 Oct 2014 20:19:57 -0400 (EDT) Message-ID: <544EE12C.40503@meetinghouse.net> Date: Mon, 27 Oct 2014 20:19:56 -0400 From: Miles Fidelman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:33.0) Gecko/20100101 Firefox/33.0 SeaMonkey/2.30 MIME-Version: 1.0 CC: "dmarc@ietf.org" References: <544A681E.1000500@meetinghouse.net> <2F6164AC-59A4-44CB-A499-4FA08E83DE9A@gmail.com> In-Reply-To: <2F6164AC-59A4-44CB-A499-4FA08E83DE9A@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/AHLk2113T7yZTpJTj2PkANPBu7A Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 00:20:09 -0000 Douglas Otis wrote: > On Oct 24, 2014, at 7:54 AM, Miles Fidelman wrote: > >> Can we step back from the weeds, for a second and talk practicalities? >> >> The suggestion that started this thread was to add a List-* header to indicate the original author of a mailing list posting - in order to, hopefully, lead to MUAs that make it easier to reply to that original author. > Dear Miles, > > DMARC policy affects any message where the From header field domain does not align with either an SPF or DKIM domain. > > The problem that needs to be addressed relates to all possible third-party related services, which includes but is not limited to use of discussion lists. There are many other equally legitimate examples of valid third-party messages (third-party defined as when the From and DKIM or SPF domains do not align). Seems to me that this is a case of the perfect being the enemy of the good. What say we try to deal with three issues separately: 1. short-term standardization of measures that people are taking to deal with the impact of DMARC on specific classes of breakage - in particular, dealing with mailing list breakage 2. more general mechanisms for dealing with the impacts of DMARC 3. "enhancing" or "fixing" DMARC Right now, the most pressing issue is that a number of large players have imposed DMARC on the rest of the net. As a matter of policy, DMARC expects receiving MTAs to impose a sender's policy - whereas the traditional mechanism for dealing with authentication is for receiving MTAs to make their own decisions based on multiple inputs. And, in the process, the DMARC approach essentially tells intermediate services to go screw. The Internet is reacting as it traditionally does - it's routing around breakage. Unfortunately, it's doing so in lots of different ways, that make life rather difficult. Somehow, given the way that DMARC came to be, and particularly the way several large players have chosen to use p=reject, I would say that "fixing" DMARC is a long-term proposition, at best (sort of like IPv6). What say we spend some of our efforts on dealing with narrow, and tractable issues. Such as my proposal re. mailing lists, by a straightforward extension to an existing practice (the List-* headers). Or.. how about a proposal for a somewhat more general mechanism (see below). > >> The discussion has quickly wandered into discussion that seems to be very far from the original suggestion. >> >> Speaking as one who both is on a bunch of mailing lists, and who hosts a bunch of mailing lists, the suggestion strikes me as almost a no-brainer. It solves a very big problem, in a very straightforward way. > Modifying From header fields destroys functionality and dangerously expects users to "repair" the damage caused, such as responding to messages in their spam folder or modifying return addresses by hand. This is going to happen, no matter what. How do we mitigate the damage? (By analogy - NAT was a short term solution to the long-delayed adoption of IPv6 - which we're still waiting for. Let's deal with what we can deal with, while sorting out larger issues.) > >> 1. Right now, for mailing lists that munge DMARC damage (pretty much all lists at this point, as far as I can tell), and depending on MUA, about the only way to reply to the original author of a message is to actually find the original author's address and manually cut and paste it into the To: field of your reply. Not all that easy for non-technical folk (at least based on support questions I get). >> >> 2. RFC2369 - 16 years old now - specifies a short list of List-*headers that are incredibly useful for things like finding list archives, finding list help, unsubscribing, etc. >> - not all MUAs support them directly, but, >> - they're easy to find, simply by looking in the headers >> - in most GUI-based MUAs, they're easy to use - simply click on an exposed URL (how I typically get to the archive of this list, for example) >> - by being standardized, it makes it easier, and hence more likely, that MUA developers might start adding "reply to list" and "reply to author" buttons in their interfaces > How is a List-* header better than permitting exceptions for specific forms of group syntax? In that way, From header field function can be retained while avoiding possible deceptions caused by normally unseen header fields. The DMARC goal was to ensure recipients are aware of possible misdirection. TPA-Label is more secure because it requires DMARC domains to make specific exceptions based on third-party services used by their senders and NOTHING ELSE NEEDS TO CHANGE. A specific group syntax represents a less secure "least effort" alternative, but is still better than what you're suggesting. > >> 3. More important, perhaps, is that if we simply picked a name, and standardized a "List-original-author:" header - it would allow the SMALL NUMBER of mailing list software developers (mailman, sympa, ezmlm, a few more) to support that header, probably in the same code module where they already support the existing RFC239 headers. I expect that within a week of agreeing on a field name, all the major mailing list managers would have patches written. >> >> Unless I'm missing something, there's no downside. > There are a few: > 1) The problem is not limited to just mailing-lists so it would be better to define a general purpose header field to mitigate DMARC policy disruptions. > 2) Use of a new header field creates another problem in that they would not be seen by recipients. > > Ensuring an origination header can be seen is better solved by making specific exceptions for valid use of From header field group syntax permitted by RFC6854 which amended RFC5322. Can you make a clear proposal? For the case of lists, the semantics and syntactic of how to use From: and Reply-To: have never been quite clear, and DMARC simply makes things murkier. It strikes me that adding a couple of List-* headers clarifies things all around. Adding some authentication mechanisms, through modifications to DMARC, can come later. If you have a more general case solution - that doesn't require cooperation of Yahoo et al, let's see it! > >> Which leads to the purely procedural question: >> What would be the most straightforward process for writing and promulgating an RFC that essentially updates RFC2369 by adding one section that defines an additional header to the current list of List-* headers? > It is not RFC2369 that needs to change. DMARC needs to either permit exceptions based on a defined group syntax or have DMARC allow an explicit authorization scheme. Otherwise expect ad hoc hacks to create an even more pernicious spoofing problem. In my view, such results would be a major downside. > I'd argue that point. At this point, the community hasn't accepted the DMARC approach to imposing sender authentication - rather, a popular reaction has been to ignore DMARC policies. I suggest that this is a situation that will continue. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From nobody Mon Oct 27 17:45:45 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D44911A03D0 for ; Mon, 27 Oct 2014 17:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_FROM_12LTRDOM=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fk9a3vDY53qo for ; Mon, 27 Oct 2014 17:45:42 -0700 (PDT) Received: from server1.neighborhoods.net (server1.neighborhoods.net [207.154.13.48]) by ietfa.amsl.com (Postfix) with ESMTP id 188591A0360 for ; Mon, 27 Oct 2014 17:45:41 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by server1.neighborhoods.net (Postfix) with ESMTP id 71107CC047; Mon, 27 Oct 2014 20:45:41 -0400 (EDT) X-Virus-Scanned: by amavisd-new-2.6.2 (20081215) (Debian) at neighborhoods.net Received: from server1.neighborhoods.net ([127.0.0.1]) by localhost (server1.neighborhoods.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5aAvyO64p4oC; Mon, 27 Oct 2014 20:45:32 -0400 (EDT) Received: from Miles-Fidelmans-MacBook-Pro.local (static-173-56-67-50.nycmny.fios.verizon.net [173.56.67.50]) by server1.neighborhoods.net (Postfix) with ESMTPSA id AB39CCC03C; Mon, 27 Oct 2014 20:45:32 -0400 (EDT) Message-ID: <544EE72C.2080708@meetinghouse.net> Date: Mon, 27 Oct 2014 20:45:32 -0400 From: Miles Fidelman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:33.0) Gecko/20100101 Firefox/33.0 SeaMonkey/2.30 MIME-Version: 1.0 To: "sympa-users@cru.fr" , "dmarc@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/uNHVkePAUZF12Z6jNqOFdaEGBP8 Subject: [dmarc-ietf] thoughts re. DMARC impacts X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 00:45:44 -0000 Folks, Many of us just had to deal with the impacts of DMARC on our lists. In the aftermath, I've been participating on the dmarc-ietf email list - trying to discuss ways to "fix DMARC" to better coexist with lists and other 3rd-party services (like "send this article to...."). Unfortunately, it seems like the discussion is bogged down in two regards: - the ietf-dmarc working group is charted to "enhance DMARC" - dealing with its impacts is not really the focus - folks want a general purpose solution Personally, I'd like to see a short-term solution to make our lives easier, as list managers - sort of the way that NAT has been dealing with IPv4 address exhaustion, while we wait for IPv6 to happen. I've been thinking along the lines of an update to RFC2369 - the 16-year-old document defines the List-* headers. Say by adding a couple of headers along the lines of: List-Original-Author: List-Original-Reply-To: List-Reply-To: Seems to me that this would: 1. give us a standard way to find the original author (and for HTML mail, to reply by clicking on a mailto: URL in the header) 2. provide standardized information that could be used by MUAs for identifying, and presenting reply options (maybe leading to "reply to list" and "reply to author" buttons starting to show up on toolbars) 3. set the stage for adding some authentication mechanisms that accomplish what DMARC is intended to do (e.g. by adding a few more headers that cryptographically authenticate the new List- headers and bind them to the message body) It strikes me that this might proceed rather quickly, if incorporated into an RFC co-authored and submitted by folks from the mailing list software community (i.e., the folks who'd write the patches to Sympa, Mailman, ezmlm, etc) - particularly if some running code were to be implemented as part of the process. (Can you say, "rough consensus and running code?") Reactions? Anybody want to collaborate on a draft RFC for submission through the independent submissions path? Any thoughts on who needs to be involved from the Sympa community, and/or from the other mailing list software communities? Miles Fidelman (a frustrated sympa administrator) -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From nobody Mon Oct 27 17:52:13 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C73F1A1BA5 for ; Mon, 27 Oct 2014 17:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4r4vIP9USzQh for ; Mon, 27 Oct 2014 17:52:09 -0700 (PDT) Received: from server1.neighborhoods.net (server1.neighborhoods.net [207.154.13.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7778E1A03D0 for ; Mon, 27 Oct 2014 17:52:09 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by server1.neighborhoods.net (Postfix) with ESMTP id BFA5ECC051 for ; Mon, 27 Oct 2014 20:52:06 -0400 (EDT) X-Virus-Scanned: by amavisd-new-2.6.2 (20081215) (Debian) at neighborhoods.net Received: from server1.neighborhoods.net ([127.0.0.1]) by localhost (server1.neighborhoods.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id G3+hDv0rK2pI for ; Mon, 27 Oct 2014 20:51:58 -0400 (EDT) Received: from Miles-Fidelmans-MacBook-Pro.local (static-173-56-67-50.nycmny.fios.verizon.net [173.56.67.50]) by server1.neighborhoods.net (Postfix) with ESMTPSA id DD7BDCC03C for ; Mon, 27 Oct 2014 20:51:57 -0400 (EDT) Message-ID: <544EE8AD.4020605@meetinghouse.net> Date: Mon, 27 Oct 2014 20:51:57 -0400 From: Miles Fidelman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:33.0) Gecko/20100101 Firefox/33.0 SeaMonkey/2.30 MIME-Version: 1.0 To: "dmarc@ietf.org" References: <544EE72C.2080708@meetinghouse.net> In-Reply-To: <544EE72C.2080708@meetinghouse.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/S2sfm4ehpbBDTnL-gLatoiGFdqk Subject: Re: [dmarc-ietf] thoughts re. DMARC impacts X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 00:52:11 -0000 Didn't actually mean to send this to the dmarc-ietf list - but, since I did... any mailing list developers out there who want to play? Miles Fidelman Miles Fidelman wrote: > Folks, > > Many of us just had to deal with the impacts of DMARC on our lists. > > In the aftermath, I've been participating on the dmarc-ietf email list > - trying to discuss ways to "fix DMARC" to better coexist with lists > and other 3rd-party services (like "send this article to...."). > > Unfortunately, it seems like the discussion is bogged down in two > regards: > - the ietf-dmarc working group is charted to "enhance DMARC" - dealing > with its impacts is not really the focus > - folks want a general purpose solution > > Personally, I'd like to see a short-term solution to make our lives > easier, as list managers - sort of the way that NAT has been dealing > with IPv4 address exhaustion, while we wait for IPv6 to happen. > > I've been thinking along the lines of an update to RFC2369 - the > 16-year-old document defines the List-* headers. Say by adding a > couple of headers along the lines of: > List-Original-Author: > List-Original-Reply-To: > List-Reply-To: > > Seems to me that this would: > 1. give us a standard way to find the original author (and for HTML > mail, to reply by clicking on a mailto: URL in the header) > 2. provide standardized information that could be used by MUAs for > identifying, and presenting reply options (maybe leading to "reply to > list" and "reply to author" buttons starting to show up on toolbars) > 3. set the stage for adding some authentication mechanisms that > accomplish what DMARC is intended to do (e.g. by adding a few more > headers that cryptographically authenticate the new List- headers and > bind them to the message body) > > It strikes me that this might proceed rather quickly, if incorporated > into an RFC co-authored and submitted by folks from the mailing list > software community (i.e., the folks who'd write the patches to Sympa, > Mailman, ezmlm, etc) - particularly if some running code were to be > implemented as part of the process. (Can you say, "rough consensus > and running code?") > > Reactions? Anybody want to collaborate on a draft RFC for submission > through the independent submissions path? Any thoughts on who needs to > be involved from the Sympa community, and/or from the other mailing > list software communities? > > Miles Fidelman (a frustrated sympa administrator) > > > > > -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From nobody Mon Oct 27 17:58:04 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C86331A8715 for ; Mon, 27 Oct 2014 17:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jf7RCujF_0b8 for ; Mon, 27 Oct 2014 17:58:01 -0700 (PDT) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E77FC1A870E for ; Mon, 27 Oct 2014 17:58:00 -0700 (PDT) Received: by mail-ig0-f170.google.com with SMTP id hn18so6984170igb.3 for ; Mon, 27 Oct 2014 17:58:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GrTs6CoNMUfBDKpVCidGgN0EMRu/9r02fym/p4PiJas=; b=MGRxQHrARIYBsx3RJSHGu6ehWRZGOfO0dCc+dbWduBNA2oy2C2jKhhij/Pk9B7INyG N+EDvwO4TM39qmGVZMpZEBe5zkjOc6WgvDpugWlqzWML5NzJLqAkhyjmj+sP3OCtkWiv e5U9bWwh43rffljMInkl2/gxseNbtCs5MbzipPsxT3AnKsmU8ewF5OxdXYpM0DqOUvDX hIrDMYvKWBuN7AD43bX0wqw4ySPFKCX76kcAFTgar9+gaIMta1F4z8L0uHS964NxawnK mWlGP3PuJLtL6VdODqqarze3fY/Mv44u8p01HAyFPjVIzhvzMU6nQn+doWlQSA7sbmcm K9wQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=GrTs6CoNMUfBDKpVCidGgN0EMRu/9r02fym/p4PiJas=; b=LRd+DwNOSFeuFHutQ1I2joNr+ArHML2mxguvqXlsMeWQk5CE+saZq0F62orXfDSqKF seHdtXk72nRPTW63xTeRhUGEmOLRXv5EnUk7E6lk4CstMgp/+g+macNCGmtCjg0lA1Az jm9vCd+fSjU2GJJa935YVrY+QygeuHSygUxj4b2grQBn2M+0vIqEMJmmd+w7+mg3JJDv 8bA+12LT+H3GGYuRU/L/9hMk/jnUjxQxlgEQKVuWbAQJA9N+KmqfzCQ6PzzJ8/RO1ZbS SJY4TQ4wyURZOvNoB+ZxKBQ9QnF6lTaGoqkvPLqALAYTYam/PUHyjZPqn39zo4ZdhcrS ePPQ== X-Gm-Message-State: ALoCoQlUlI5B24orJ/2DWSR+aYWbHTxvbXES5VZKyIbhoMF2sPQ628RpjMEGok6yMAoWiYDmTFbD MIME-Version: 1.0 X-Received: by 10.107.5.195 with SMTP id 186mr59590iof.74.1414457880337; Mon, 27 Oct 2014 17:58:00 -0700 (PDT) Received: by 10.64.62.78 with HTTP; Mon, 27 Oct 2014 17:58:00 -0700 (PDT) In-Reply-To: <544EE72C.2080708@meetinghouse.net> References: <544EE72C.2080708@meetinghouse.net> Date: Mon, 27 Oct 2014 17:58:00 -0700 Message-ID: From: Brandon Long To: Miles Fidelman Content-Type: multipart/alternative; boundary=001a113efa6482110705067123fc Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/KF87vHkRY_wnlM61fiiwyk0pfA8 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] thoughts re. DMARC impacts X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 00:58:03 -0000 --001a113efa6482110705067123fc Content-Type: text/plain; charset=UTF-8 Some predecessors: http://cr.yp.to/proto/replyto.html Mail-Reply-To and Mail-Followup-To. We implemented Mail-Reply-To at eGroups/YGroups, iirc, but looks like we didn't do it at Google Groups.. Implementation is obviously trivial, do we actually think that list-reply would result any time soon? We also considered adding a header/footer to the message with the poster/author email address in it. Brandon On Mon, Oct 27, 2014 at 5:45 PM, Miles Fidelman wrote: > Folks, > > Many of us just had to deal with the impacts of DMARC on our lists. > > In the aftermath, I've been participating on the dmarc-ietf email list - > trying to discuss ways to "fix DMARC" to better coexist with lists and > other 3rd-party services (like "send this article to...."). > > Unfortunately, it seems like the discussion is bogged down in two regards: > - the ietf-dmarc working group is charted to "enhance DMARC" - dealing > with its impacts is not really the focus > - folks want a general purpose solution > > Personally, I'd like to see a short-term solution to make our lives > easier, as list managers - sort of the way that NAT has been dealing with > IPv4 address exhaustion, while we wait for IPv6 to happen. > > I've been thinking along the lines of an update to RFC2369 - the > 16-year-old document defines the List-* headers. Say by adding a couple of > headers along the lines of: > List-Original-Author: > List-Original-Reply-To: > List-Reply-To: > > Seems to me that this would: > 1. give us a standard way to find the original author (and for HTML mail, > to reply by clicking on a mailto: URL in the header) > 2. provide standardized information that could be used by MUAs for > identifying, and presenting reply options (maybe leading to "reply to list" > and "reply to author" buttons starting to show up on toolbars) > 3. set the stage for adding some authentication mechanisms that accomplish > what DMARC is intended to do (e.g. by adding a few more headers that > cryptographically authenticate the new List- headers and bind them to the > message body) > > It strikes me that this might proceed rather quickly, if incorporated into > an RFC co-authored and submitted by folks from the mailing list software > community (i.e., the folks who'd write the patches to Sympa, Mailman, > ezmlm, etc) - particularly if some running code were to be implemented as > part of the process. (Can you say, "rough consensus and running code?") > > Reactions? Anybody want to collaborate on a draft RFC for submission > through the independent submissions path? Any thoughts on who needs to be > involved from the Sympa community, and/or from the other mailing list > software communities? > > Miles Fidelman (a frustrated sympa administrator) > > > > > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --001a113efa6482110705067123fc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Some predecessors:=C2=A0http://cr.yp.to/proto/replyto.html

Mail= -Reply-To and Mail-Followup-To.=C2=A0 We implemented Mail-Reply-To at eGrou= ps/YGroups, iirc, but looks like we didn't do it at Google Groups..

Implementation is obviously trivial, do we actually t= hink that list-reply would result any time soon?

W= e also considered adding a header/footer to the message with the poster/aut= hor email address in it.

Brandon

On Mon, Oct 27, 201= 4 at 5:45 PM, Miles Fidelman <mfidelman@meetinghouse.net><= /span> wrote:
Folks,

Many of us just had to deal with the impacts of DMARC on our lists.

In the aftermath, I've been participating on the dmarc-ietf email list = - trying to discuss ways to "fix DMARC" to better coexist with li= sts and other 3rd-party services (like "send this article to...."= ).

Unfortunately, it seems like the discussion is bogged down in two regards:<= br> - the ietf-dmarc working group is charted to "enhance DMARC" - de= aling with its impacts is not really the focus
- folks want a general purpose solution

Personally, I'd like to see a short-term solution to make our lives eas= ier, as list managers - sort of the way that NAT has been dealing with IPv4= address exhaustion, while we wait for IPv6 to happen.

I've been thinking along the lines of an update to RFC2369 - the 16-yea= r-old document defines the List-* headers.=C2=A0 Say by adding a couple of = headers along the lines of:
List-Original-Author: <the original author>
List-Original-Reply-To: <the original message's Reply-To>
List-Reply-To: <the list-specific reply-to - either author of list>
Seems to me that this would:
1. give us a standard way to find the original author (and for HTML mail, t= o reply by clicking on a mailto: URL in the header)
2. provide standardized information that could be used by MUAs for identify= ing, and presenting reply options (maybe leading to "reply to list&quo= t; and "reply to author" buttons starting to show up on toolbars)=
3. set the stage for adding some authentication mechanisms that accomplish = what DMARC is intended to do (e.g. by adding a few more headers that crypto= graphically authenticate the new List- headers and bind them to the message= body)

It strikes me that this might proceed rather quickly, if incorporated into = an RFC co-authored and submitted by folks from the mailing list software co= mmunity (i.e., the folks who'd write the patches to Sympa, Mailman, ezm= lm, etc) - particularly if some running code were to be implemented as part= of the process.=C2=A0 (Can you say, "rough consensus and running code= ?")

Reactions?=C2=A0 Anybody want to collaborate on a draft RFC for submission = through the independent submissions path? Any thoughts on who needs to be i= nvolved from the Sympa community, and/or from the other mailing list softwa= re communities?

Miles Fidelman (a frustrated sympa administrator)





--
In theory, there is no difference between theory and practice.
In practice, there is.=C2=A0 =C2=A0.... Yogi Berra

_______________________________________________
dmarc mailing list
dmarc@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dmarc

--001a113efa6482110705067123fc-- From nobody Mon Oct 27 18:02:55 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 594F01A87E6 for ; Mon, 27 Oct 2014 18:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.881 X-Spam-Level: X-Spam-Status: No, score=-0.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oz-Z8SUQeczj for ; Mon, 27 Oct 2014 18:02:53 -0700 (PDT) Received: from server1.neighborhoods.net (server1.neighborhoods.net [207.154.13.48]) by ietfa.amsl.com (Postfix) with ESMTP id D4BF31A87DB for ; Mon, 27 Oct 2014 18:02:52 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by server1.neighborhoods.net (Postfix) with ESMTP id 36824CC04F for ; Mon, 27 Oct 2014 21:02:52 -0400 (EDT) X-Virus-Scanned: by amavisd-new-2.6.2 (20081215) (Debian) at neighborhoods.net Received: from server1.neighborhoods.net ([127.0.0.1]) by localhost (server1.neighborhoods.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 0SWVh1XhYJTg for ; Mon, 27 Oct 2014 21:02:48 -0400 (EDT) Received: from Miles-Fidelmans-MacBook-Pro.local (static-173-56-67-50.nycmny.fios.verizon.net [173.56.67.50]) by server1.neighborhoods.net (Postfix) with ESMTPSA id C9C0CCC03C for ; Mon, 27 Oct 2014 21:02:47 -0400 (EDT) Message-ID: <544EEB37.3020509@meetinghouse.net> Date: Mon, 27 Oct 2014 21:02:47 -0400 From: Miles Fidelman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:33.0) Gecko/20100101 Firefox/33.0 SeaMonkey/2.30 MIME-Version: 1.0 CC: "dmarc@ietf.org" References: <544EE72C.2080708@meetinghouse.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/d1DLKlW8L8tUNx4QHpJ858jwxhI Subject: Re: [dmarc-ietf] thoughts re. DMARC impacts X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 01:02:54 -0000 Kind of depends. Agreement on two header fields, by the developers of Mailman and Sympa - yes, that could happen overnight if the right few people agree. Miles Brandon Long wrote: > Some predecessors: http://cr.yp.to/proto/replyto.html > > Mail-Reply-To and Mail-Followup-To. We implemented Mail-Reply-To at > eGroups/YGroups, iirc, but looks like we didn't do it at Google Groups.. > > Implementation is obviously trivial, do we actually think that > list-reply would result any time soon? > > We also considered adding a header/footer to the message with the > poster/author email address in it. > > Brandon > > On Mon, Oct 27, 2014 at 5:45 PM, Miles Fidelman > > wrote: > > Folks, > > Many of us just had to deal with the impacts of DMARC on our lists. > > In the aftermath, I've been participating on the dmarc-ietf email > list - trying to discuss ways to "fix DMARC" to better coexist > with lists and other 3rd-party services (like "send this article > to...."). > > Unfortunately, it seems like the discussion is bogged down in two > regards: > - the ietf-dmarc working group is charted to "enhance DMARC" - > dealing with its impacts is not really the focus > - folks want a general purpose solution > > Personally, I'd like to see a short-term solution to make our > lives easier, as list managers - sort of the way that NAT has been > dealing with IPv4 address exhaustion, while we wait for IPv6 to > happen. > > I've been thinking along the lines of an update to RFC2369 - the > 16-year-old document defines the List-* headers. Say by adding a > couple of headers along the lines of: > List-Original-Author: > List-Original-Reply-To: > List-Reply-To: > > Seems to me that this would: > 1. give us a standard way to find the original author (and for > HTML mail, to reply by clicking on a mailto: URL in the header) > 2. provide standardized information that could be used by MUAs for > identifying, and presenting reply options (maybe leading to "reply > to list" and "reply to author" buttons starting to show up on > toolbars) > 3. set the stage for adding some authentication mechanisms that > accomplish what DMARC is intended to do (e.g. by adding a few more > headers that cryptographically authenticate the new List- headers > and bind them to the message body) > > It strikes me that this might proceed rather quickly, if > incorporated into an RFC co-authored and submitted by folks from > the mailing list software community (i.e., the folks who'd write > the patches to Sympa, Mailman, ezmlm, etc) - particularly if some > running code were to be implemented as part of the process. (Can > you say, "rough consensus and running code?") > > Reactions? Anybody want to collaborate on a draft RFC for > submission through the independent submissions path? Any thoughts > on who needs to be involved from the Sympa community, and/or from > the other mailing list software communities? > > Miles Fidelman (a frustrated sympa administrator) > > > > > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From nobody Mon Oct 27 18:17:54 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 731D81A8822 for ; Mon, 27 Oct 2014 18:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5THbEKQnfAl for ; Mon, 27 Oct 2014 18:17:49 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5C65A1A87F1 for ; Mon, 27 Oct 2014 18:17:49 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PE92IEKQKW003G43@mauve.mrochek.com> for dmarc@ietf.org; Mon, 27 Oct 2014 18:12:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1414458768; bh=RhJZPwLf5wJ5J2MMlPOgtko7I8TaXTbj2efkOu8wZFE=; h=From:Cc:Date:Subject:In-reply-to:References:To; b=Ml+gPccjz3dXOWGKzSTcoO9Rv8l0riuUSH3CgEIQPw3jMXsP8r8sImA5IuBsl+TOk oSEgjJqkX+1uspq+y+eqB6MljHv45hXfaQj/7FcxcUC1OYjTzBI0MQPNpFhd0ULkeQ kCVcRMC00zO4Q6E8xohMkSbWAZmNcrM40/ifyqk0= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PE3G6YIHXS0028JO@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dmarc@ietf.org; Mon, 27 Oct 2014 18:12:44 -0700 (PDT) From: ned+dmarc@mrochek.com Message-id: <01PE92ICZF0O0028JO@mauve.mrochek.com> Date: Mon, 27 Oct 2014 17:47:16 -0700 (PDT) In-reply-to: "Your message dated Mon, 27 Oct 2014 20:45:32 -0400" <544EE72C.2080708@meetinghouse.net> References: <544EE72C.2080708@meetinghouse.net> To: Miles Fidelman Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/DfS3P6hnx9RiYbD7n4SuOGIHJjs Cc: "sympa-users@cru.fr" , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] thoughts re. DMARC impacts X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 01:17:51 -0000 > Folks, > Many of us just had to deal with the impacts of DMARC on our lists. > In the aftermath, I've been participating on the dmarc-ietf email list - > trying to discuss ways to "fix DMARC" to better coexist with lists and > other 3rd-party services (like "send this article to...."). > Unfortunately, it seems like the discussion is bogged down in two regards: > - the ietf-dmarc working group is charted to "enhance DMARC" - dealing > with its impacts is not really the focus Please reread the charter. This is not at all what it says. Among other things, the charter states that: The working group will specify mechanisms for reducing or eliminating the DMARC's effects on indirect mail flows, including deployed behaviors of many different intermediaries, such as mailing list managers, automated mailbox forwarding services, and MTAs that perform enhanced message handling that results in message modification. I don't see that as in any way in line with your assertion that the wg is not chartered to deal with the impact of DMARC. In fact it seems to be exactly the opposite. And in particular, nowhere in that paragraph is there any requirement that this must necessarily be done by "enhancing DMARC". > - folks want a general purpose solution Of course they do. Unfortunately, people's desires do not magic such a solution into existence. And if someone has described a viable and deployable general-purpose solution, I must have missed it. So we are left with consideration of various partial solutions and compromises. > Personally, I'd like to see a short-term solution to make our lives > easier, as list managers - sort of the way that NAT has been dealing > with IPv4 address exhaustion, while we wait for IPv6 to happen. > I've been thinking along the lines of an update to RFC2369 - the > 16-year-old document defines the List-* headers. Say by adding a couple > of headers along the lines of: > List-Original-Author: > List-Original-Reply-To: > List-Reply-To: > Seems to me that this would: > 1. give us a standard way to find the original author (and for HTML > mail, to reply by clicking on a mailto: URL in the header) > 2. provide standardized information that could be used by MUAs for > identifying, and presenting reply options (maybe leading to "reply to > list" and "reply to author" buttons starting to show up on toolbars) > 3. set the stage for adding some authentication mechanisms that > accomplish what DMARC is intended to do (e.g. by adding a few more > headers that cryptographically authenticate the new List- headers and > bind them to the message body) > It strikes me that this might proceed rather quickly, if incorporated > into an RFC co-authored and submitted by folks from the mailing list > software community (i.e., the folks who'd write the patches to Sympa, > Mailman, ezmlm, etc) - particularly if some running code were to be > implemented as part of the process. (Can you say, "rough consensus and > running code?") > Reactions? Anybody want to collaborate on a draft RFC for submission > through the independent submissions path? Any thoughts on who needs to > be involved from the Sympa community, and/or from the other mailing list > software communities? What in the charter makes you think such a draft would be in any way incompatible with being a product of this group? Indeed, this fits quite nicely into phase I, which is, you know, what we're supposed to be working on now. (As opposed to phase II, which is where we will start looking at possible changes to DMARC itself.) Of course the fact that this fits within our charter doesn't mean there's consensus on this particular approach. But to that end, if you want to get people on board, might I suggest that rather than in effect asking people to abandon the wg effort for something else, that you instead do what countless others have done before you, and start by writing a draft that describes your proposal in detail so participants can assess it? Ned From nobody Mon Oct 27 18:26:54 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 562C11A8839 for ; Mon, 27 Oct 2014 18:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.881 X-Spam-Level: X-Spam-Status: No, score=-0.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZccMRlWUDmg for ; Mon, 27 Oct 2014 18:26:45 -0700 (PDT) Received: from server1.neighborhoods.net (server1.neighborhoods.net [207.154.13.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1511A19E5 for ; Mon, 27 Oct 2014 18:26:45 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by server1.neighborhoods.net (Postfix) with ESMTP id 13A5CCC050 for ; Mon, 27 Oct 2014 21:26:45 -0400 (EDT) X-Virus-Scanned: by amavisd-new-2.6.2 (20081215) (Debian) at neighborhoods.net Received: from server1.neighborhoods.net ([127.0.0.1]) by localhost (server1.neighborhoods.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Rcqdd5S7OqTQ for ; Mon, 27 Oct 2014 21:26:36 -0400 (EDT) Received: from Miles-Fidelmans-MacBook-Pro.local (static-173-56-67-50.nycmny.fios.verizon.net [173.56.67.50]) by server1.neighborhoods.net (Postfix) with ESMTPSA id 13343CC04F for ; Mon, 27 Oct 2014 21:26:36 -0400 (EDT) Message-ID: <544EF0CB.8060407@meetinghouse.net> Date: Mon, 27 Oct 2014 21:26:35 -0400 From: Miles Fidelman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:33.0) Gecko/20100101 Firefox/33.0 SeaMonkey/2.30 MIME-Version: 1.0 CC: "dmarc@ietf.org" References: <544EE72C.2080708@meetinghouse.net> <01PE92ICZF0O0028JO@mauve.mrochek.com> In-Reply-To: <01PE92ICZF0O0028JO@mauve.mrochek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/tTvxJpx3daY9-gK1bMiq5uFl6ZM Subject: Re: [dmarc-ietf] thoughts re. DMARC impacts X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 01:26:47 -0000 See below.... Ned Freed wrote: >> Folks, > > > >> Many of us just had to deal with the impacts of DMARC on our lists. > >> In the aftermath, I've been participating on the dmarc-ietf email list - >> trying to discuss ways to "fix DMARC" to better coexist with lists and >> other 3rd-party services (like "send this article to...."). > >> Unfortunately, it seems like the discussion is bogged down in two >> regards: >> - the ietf-dmarc working group is charted to "enhance DMARC" - dealing >> with its impacts is not really the focus > > Please reread the charter. This is not at all what it says. > > Among other things, the charter states that: > > The working group will specify mechanisms for reducing or eliminating > the DMARC's effects on indirect mail flows, including deployed > behaviors of many different intermediaries, such as mailing list > managers, automated mailbox forwarding services, and MTAs that > perform enhanced message handling that results in message > modification. > I don't see that as in any way in line with your assertion that the wg > is not > chartered to deal with the impact of DMARC. In fact it seems to be > exactly the > opposite. And in particular, nowhere in that paragraph is there any > requirement > that this must necessarily be done by "enhancing DMARC". Ok... good to hear. I was inferring from the responses so far, and probably read the charter just a bit too quickly. > >> - folks want a general purpose solution > > Of course they do. Unfortunately, people's desires do not magic such a > solution > into existence. And if someone has described a viable and deployable > general-purpose solution, I must have missed it. So we are left with > consideration of various partial solutions and compromises. Agreed - hence my preference for dealing with low hanging fruit. > >> Personally, I'd like to see a short-term solution to make our lives >> easier, as list managers - sort of the way that NAT has been dealing >> with IPv4 address exhaustion, while we wait for IPv6 to happen. > >> I've been thinking along the lines of an update to RFC2369 - the >> 16-year-old document defines the List-* headers. Say by adding a couple >> of headers along the lines of: >> List-Original-Author: >> List-Original-Reply-To: >> List-Reply-To: > >> Seems to me that this would: >> 1. give us a standard way to find the original author (and for HTML >> mail, to reply by clicking on a mailto: URL in the header) >> 2. provide standardized information that could be used by MUAs for >> identifying, and presenting reply options (maybe leading to "reply to >> list" and "reply to author" buttons starting to show up on toolbars) >> 3. set the stage for adding some authentication mechanisms that >> accomplish what DMARC is intended to do (e.g. by adding a few more >> headers that cryptographically authenticate the new List- headers and >> bind them to the message body) > >> It strikes me that this might proceed rather quickly, if incorporated >> into an RFC co-authored and submitted by folks from the mailing list >> software community (i.e., the folks who'd write the patches to Sympa, >> Mailman, ezmlm, etc) - particularly if some running code were to be >> implemented as part of the process. (Can you say, "rough consensus and >> running code?") > >> Reactions? Anybody want to collaborate on a draft RFC for submission >> through the independent submissions path? Any thoughts on who needs to >> be involved from the Sympa community, and/or from the other mailing list >> software communities? > > What in the charter makes you think such a draft would be in any way > incompatible with being a product of this group? Indeed, this fits > quite nicely > into phase I, which is, you know, what we're supposed to be working on > now. (As > opposed to phase II, which is where we will start looking at possible > changes > to DMARC itself.) > > Of course the fact that this fits within our charter doesn't mean there's > consensus on this particular approach. But to that end, if you want to > get > people on board, might I suggest that rather than in effect asking > people to > abandon the wg effort for something else, that you instead do what > countless > others have done before you, and start by writing a draft that > describes your > proposal in detail so participants can assess it? Well... love to. Kind of why I posted the question to the sympa list - I'd like to see how the concept floats with users/developers of a specific list manager (the one I use, obviously), and the one that reacted quickest with a patch. I would still like to have some guidance as to the form and process - specifically since I'm essentially proposing to add a paragraph or two to an existing RFC. What would be the best way to frame that? Cheers, Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From nobody Mon Oct 27 22:22:34 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DAE81A1B2C for ; Mon, 27 Oct 2014 22:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.489 X-Spam-Level: **** X-Spam-Status: No, score=4.489 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FRT_PROFILE2=1.981, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NbBgkf53VDBe for ; Mon, 27 Oct 2014 22:22:30 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 6AEBB1A1B24 for ; Mon, 27 Oct 2014 22:22:29 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id 02BE81C39D2; Tue, 28 Oct 2014 14:22:29 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id E8CFB1A27CF; Tue, 28 Oct 2014 14:22:28 +0900 (JST) From: "Stephen J. Turnbull" To: Douglas Otis In-Reply-To: <2F6164AC-59A4-44CB-A499-4FA08E83DE9A@gmail.com> References: <544A681E.1000500@meetinghouse.net> <2F6164AC-59A4-44CB-A499-4FA08E83DE9A@gmail.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Tue, 28 Oct 2014 14:22:28 +0900 Message-ID: <87sii84vl7.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/TNEMfmArSV-jQJRqFWWaMwPOpTo Cc: "dmarc@ietf.org" , Miles Fidelman Subject: [dmarc-ietf] Ignoring Spam Folder Considered Harmful [was: Additional List-foo ...] X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 05:22:32 -0000 Douglas Otis writes: > Modifying From header fields destroys functionality and dangerously > expects users to "repair" the damage caused, such as responding to > messages in their spam folder Please stop using "user looks in spam folder" as an example.[1][2] Users *should* look in their spam folders, at least if they have well- managed spam filters. Well-managed spam filters provide spam folders not because they think users want to look at spam, but because they know that there *will* be false positives. The filter's goal is to keep that folder as empty as possible, but perfection is unachievable. For example, my car dealer's messages occasionally (but more than once!) ended up in the spam folder because they *are* spammy (one particularly egregious one got 13 stars when I ran it through SpamAssassin, although evidently Gmail didn't think it bad enough to discard even though it did put it in the spam folder), but they're not UCE by definition because I opted in to that list properly. Footnotes: [1] I consider this an example of the technical fallacy: "security problems can be solved with sufficiently advanced technology." I don't trust people who advocate it, however technically proficient they may be, to manage or design security systems. [2] It's specious here, anyway. Modifying "From" should make the message *less* likely to end up in the spambucket, since there will be a From-aligned, valid DKIM signature (at least in the case of a well-managed indirect mailer). The problem is that it's likely to make the user vulnerable to various forms of social engineering that emulate this kind of From-munging. From nobody Mon Oct 27 22:51:09 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9FAD1A1A60 for ; Mon, 27 Oct 2014 22:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nlpOSAdV1aQ3 for ; Mon, 27 Oct 2014 22:51:04 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id BDD641A19F5 for ; Mon, 27 Oct 2014 22:51:04 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id 1CEC51C3A44; Tue, 28 Oct 2014 14:51:04 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 0EBA31A27CF; Tue, 28 Oct 2014 14:51:04 +0900 (JST) From: "Stephen J. Turnbull" To: Miles Fidelman In-Reply-To: <544AD9F3.9080304@meetinghouse.net> References: <544A681E.1000500@meetinghouse.net> <544AD9F3.9080304@meetinghouse.net> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Tue, 28 Oct 2014 14:51:03 +0900 Message-ID: <87r3xs4u9k.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/mAWQeE2TqRc0jygOfZ1zSYxNb0o Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 05:51:06 -0000 Miles Fidelman writes: > Steve Atkins wrote: > > On Oct 24, 2014, at 10:54 AM, Miles Fidelman wrote: > >> 3. More important, perhaps, is that if we simply picked a name, > >> and standardized a "List-original-author:" header - it would > >> allow the SMALL NUMBER of mailing list software developers > >> (mailman, sympa, ezmlm, a few more) to support that header, > >> probably in the same code module where they already support > >> the existing RFC239 headers. I expect that within a week of > >> agreeing on a field name, all the major mailing list managers > >> would have patches written. Written, yes. Accepted, maybe. Mailman is unlikely to accept such a thing without a fight. See reasons 1-4 below. Other reasons have been mentioned, but these are the ones that get me hot under the collar. > >> Unless I'm missing something, there's no downside. 1. It is insufficiently general (doesn't appear to apply to non-list use cases) and therefore would induce unnecessary complexity or uneasiness among standards-conforming admins who would be queasy about using a List-* field for a non-list use case. 2. Unlike the RFC 2369 and 2919 fields, which add useful information to the message, without changing existing information, this field is useless unless From is munged, which is nonconforming behavior. 3. To make it conformant, RFC 5322 would need to be updated. > Well, my proposal is to be agnostic about the From: field - what it's > supposed to be is well defined, despite various mailing list packages > munging it in non-standard ways, to get list traffic past restrictive > DMARC sender alignment policies. At the moment, different list managers > are implementing various different From: re-writing options (e.g., From: > by way of ; rewriting to the list address, > etc.). I propose that we don't touch the From: field. Well, no, you can't really do that. See 2 and 3 above. > That leaves the list software free to use the Reply-To: field as > originally intended - something that can be set by list policy to either > the author or the list, as configured for the list in question. You misunderstand RFC 5322 and all of its predecessors. Use of Reply-To by discussion lists is non-conformant, although common. In case of announce lists DMARC should not be a problem (unless they suffer from a non-list-related indirect mail issue). I have a old proposal for a List-Reply-Preference header, which allows the list to specify whether it prefers the default reply function to go to List or Author (never made it to an IETF draft due to Antarctic response from MUA authors). Maybe I could dust that off (but it would go through apps-wg, I think -- in general most of the Reply-To related proposals here belong there, I would suppose). > > And there's a hope that that would lead to MUA developers making > > the List-original-author field available to users - to filter by, > > to use as a target to "reply to author", and to be visible to > > identify the original sender? > > Exactly! And to reduce the need to play with and overload the semantics > of the From: and Reply-To: fields. Uh-oh. 4. If this field were made visible to users in popular MUAs, they would surely learn to interpret it as a "Really-Truly-From" field, and thus it would become a vector for attacks. If not made visible, it's not clear to me what good it would be. Yes, you could give it precedence over the From field for Reply-To-Author, but that would be confusing to users, and possibly open to abuse. Note that previous proponents of Original-Author fields have maintained that the good thing about it would be that it would *not* be visible to users, and thus would not attract the attention of the folks using "p=reject". > Which still leaves this as an open question: > > > > > >> Which leads to the purely procedural question: What would be the > >> most straightforward process for writing and promulgating an RFC > >> that essentially updates RFC2369 by adding one section that > >> defines an additional header to the current list of List-* > >> headers? The first thing you need to do is realize that these proposals only make sense under the presumption that From will be munged. That is nonconformant to RFC 5322, and *that* is a nonexistence proof for "straightforward". From nobody Mon Oct 27 23:25:00 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2626A1A00FC for ; Mon, 27 Oct 2014 23:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llFlKInCGSSH for ; Mon, 27 Oct 2014 23:24:55 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C1D71A008A for ; Mon, 27 Oct 2014 23:24:55 -0700 (PDT) Received: from [192.168.1.100] (unknown [72.128.40.159]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 002E3C403F8; Tue, 28 Oct 2014 01:24:53 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1414477494; bh=swXwKjO7do8A3ddP76r09zoNpWeOGp+7ukvg0eCeylc=; h=In-Reply-To:References:Subject:From:Date:To:From; b=oMhoOflnWXduCGGaeMdttqL2EeWZA34rXOMKlQMzJbXwMKaVbdYlDR9AOhMr3ZWnY l15/9dTQLF8R2RPZL32xTd7iYg33JRRMgikYpcmbc5n1mOekeRTOPmzag8jc4CsRqw iU1+aLMFyhfBtxBr7qx1TpKuvzsvy+wr0uNmRkhU= User-Agent: K-9 Mail for Android In-Reply-To: <87r3xs4u9k.fsf@uwakimon.sk.tsukuba.ac.jp> References: <544A681E.1000500@meetinghouse.net> <544AD9F3.9080304@meetinghouse.net> <87r3xs4u9k.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Tue, 28 Oct 2014 01:24:52 -0500 To: "dmarc@ietf.org" Message-ID: <2A32DB76-5C0F-4CA5-8E42-3A70E510B2BC@kitterman.com> Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/WoCdTPTfx1DAYQKBeyNpC3Tvvtk Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 06:24:58 -0000 On October 28, 2014 12:51:03 AM CDT, "Stephen J. Turnbull" wrote: >Miles Fidelman writes: > > Steve Atkins wrote: >> > On Oct 24, 2014, at 10:54 AM, Miles Fidelman > wrote: > > > >> 3. More important, perhaps, is that if we simply picked a name, > > >> and standardized a "List-original-author:" header - it would > > >> allow the SMALL NUMBER of mailing list software developers > > >> (mailman, sympa, ezmlm, a few more) to support that header, > > >> probably in the same code module where they already support > > >> the existing RFC239 headers. I expect that within a week of > > >> agreeing on a field name, all the major mailing list managers > > >> would have patches written. > >Written, yes. Accepted, maybe. Mailman is unlikely to accept such a >thing without a fight. See reasons 1-4 below. Other reasons have >been mentioned, but these are the ones that get me hot under the >collar. > > > >> Unless I'm missing something, there's no downside. > >1. It is insufficiently general (doesn't appear to apply to non-list > use cases) and therefore would induce unnecessary complexity or > uneasiness among standards-conforming admins who would be queasy > about using a List-* field for a non-list use case. > >2. Unlike the RFC 2369 and 2919 fields, which add useful information > to the message, without changing existing information, this field > is useless unless From is munged, which is nonconforming behavior. > >3. To make it conformant, RFC 5322 would need to be updated. > >> Well, my proposal is to be agnostic about the From: field - what it's > >> supposed to be is well defined, despite various mailing list packages > >> munging it in non-standard ways, to get list traffic past restrictive > >> DMARC sender alignment policies. At the moment, different list >managers >> are implementing various different From: re-writing options (e.g., >From: > > by way of ; rewriting to the list address, > > etc.). I propose that we don't touch the From: field. > >Well, no, you can't really do that. See 2 and 3 above. > > > That leaves the list software free to use the Reply-To: field as >> originally intended - something that can be set by list policy to >either > > the author or the list, as configured for the list in question. > >You misunderstand RFC 5322 and all of its predecessors. Use of >Reply-To by discussion lists is non-conformant, although common. In >case of announce lists DMARC should not be a problem (unless they >suffer from a non-list-related indirect mail issue). > >I have a old proposal for a List-Reply-Preference header, which allows >the list to specify whether it prefers the default reply function to >go to List or Author (never made it to an IETF draft due to Antarctic >response from MUA authors). Maybe I could dust that off (but it would >go through apps-wg, I think -- in general most of the Reply-To related >proposals here belong there, I would suppose). > > > > And there's a hope that that would lead to MUA developers making > > > the List-original-author field available to users - to filter by, > > > to use as a target to "reply to author", and to be visible to > > > identify the original sender? > > >> Exactly! And to reduce the need to play with and overload the >semantics > > of the From: and Reply-To: fields. > >Uh-oh. > >4. If this field were made visible to users in popular MUAs, they > would surely learn to interpret it as a "Really-Truly-From" field, > and thus it would become a vector for attacks. If not made > visible, it's not clear to me what good it would be. Yes, you > could give it precedence over the From field for Reply-To-Author, > but that would be confusing to users, and possibly open to abuse. > >Note that previous proponents of Original-Author fields have >maintained that the good thing about it would be that it would *not* >be visible to users, and thus would not attract the attention of the >folks using "p=reject". > > > Which still leaves this as an open question: > > > > > > > > >> Which leads to the purely procedural question: What would be the > > >> most straightforward process for writing and promulgating an RFC > > >> that essentially updates RFC2369 by adding one section that > > >> defines an additional header to the current list of List-* > > >> headers? > >The first thing you need to do is realize that these proposals only >make sense under the presumption that From will be munged. That is >nonconformant to RFC 5322, and *that* is a nonexistence proof for >"straightforward". So because RFC 5322 the email I see in my inbox on a daily basis with a munged From is a figment of my imagination? Also, since Mailman already supports From munging, it seems odd to suggest related patches wouldn't be accepted because From munging is evil. I believe the Rubicon has been crossed. Scott K From nobody Tue Oct 28 01:12:19 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0B81A0385 for ; Tue, 28 Oct 2014 01:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.708 X-Spam-Level: * X-Spam-Status: No, score=1.708 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, GB_I_LETTER=-2, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_110=0.6, J_CHICKENPOX_16=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10pGgImsNWEK for ; Tue, 28 Oct 2014 01:11:25 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id C126A1A19F9 for ; Tue, 28 Oct 2014 01:11:24 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id 4C8361C3A39; Tue, 28 Oct 2014 17:11:23 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 3EC8A1A27CF; Tue, 28 Oct 2014 17:11:23 +0900 (JST) From: "Stephen J. Turnbull" To: Miles Fidelman In-Reply-To: <544EE12C.40503@meetinghouse.net> References: <544A681E.1000500@meetinghouse.net> <2F6164AC-59A4-44CB-A499-4FA08E83DE9A@gmail.com> <544EE12C.40503@meetinghouse.net> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Tue, 28 Oct 2014 17:11:23 +0900 Message-ID: <87h9yo4nro.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/pwUaAsJWqEgR508eZXjfM7MC7Kg Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 08:11:27 -0000 Miles Fidelman writes: > Douglas Otis wrote: > > On Oct 24, 2014, at 7:54 AM, Miles Fidelman wrote: > > The problem that needs to be addressed relates to all possible > > third-party related services, which includes but is not limited > > to use of discussion lists. There are many other equally > > legitimate examples of valid third-party messages (third-party > > defined as when the From and DKIM or SPF domains do not align). > > Seems to me that this is a case of the perfect being the enemy of > the good. I think most participants here agree with you (with all due respect to Douglas, who's done a ton of work on TPA-labels). Have you read the archives, going back way before the WG formation, even? All of these issues (including perfect vs. good :-) have been hashed repeatedly since April, and most all have a distinguished lineage (discussion of some of them have recently been discovered in previously uninterpretable portions of the Dead Sea Scrolls ;-). > What say we try to deal with three issues separately: > > 1. short-term standardization of measures that people are taking to deal > with the impact of DMARC on specific classes of breakage - in > particular, dealing with mailing list breakage Even though I'm a MLM developer, I object to that "particularization" for the same reasons others do: often there is a trivial or simple generalization that covers more use cases. Specifically, I see no point whatsover in a "List-" prefix for any of the headers proposed. The main advantage seems to be that it makes it look like a small, no-brainer change to existing practice for a particular use-case. But it's neither (as I've argued elsewhere). > Right now, the most pressing issue is that a number of large players > have imposed DMARC on the rest of the net. As a matter of policy, DMARC > expects receiving MTAs to impose a sender's policy - whereas the > traditional mechanism for dealing with authentication is for receiving > MTAs to make their own decisions based on multiple inputs. And they still do. Just not all of them. In fact, the DMARC document phrases these things in terms of "advice". (It doesn't use that word, but clearly "p=reject" is an abbreviation for "p=[we have a security problem so anything that's not From-aligned is surely inauthentic and probably malicious so without bothering your users you can and should peremptorily ]reject".) > And, in the process, the DMARC approach essentially tells > intermediate services to go screw. In practice, yes. However, from the point of view of the letter of the document, Yahoo! and AOL know very well that in their case failure of From alignment does *not* mean the message is inauthentic (at least not sufficiently reliably), and therefore they should not be using it as they do. I'm not sure what the AOL people are thinking, but pretty clearly the Yahoo! technical staff are aware of the problem and do not like the collateral damage associated with their "p=reject" policy. I personally believe they would be amenable to trying From-Domain-side mitigations that solve most of their problems. Eg, Levine's "DKIM Conditional Signatures", the Crocker-Kucherawy "Delegating DKIM Signing Authority", or Otis's "Third-Party Authorization Label": http://tools.ietf.org/html/draft-levine-dkim-conditional http://tools.ietf.org/html/draft-kucherawy-dkim-delegate http://tools.ietf.org/html/draft-otis-tpa-label It just won't happen until we have our ducks in a row, and some large scale experiments have been conducted. > What say we spend some of our efforts on dealing with narrow, and > tractable issues. Such as my proposal re. mailing lists, by a > straightforward extension to an existing practice (the List-* > headers). It's not straightforward. You may think it's straightforward, and you have every right to your opinion, but (as discussed elsewhere) a lot of people disagree, and that makes the politics of getting something into place anything but straightforward. It will also be difficult to get people to *stop* doing those things once there is a better fix. That is especially true if they discover convenient abuses of the new fields (like Reply-To munging). > >> Speaking as one who both is on a bunch of mailing lists, and who > >> hosts a bunch of mailing lists, the suggestion strikes me as > >> almost a no-brainer. It solves a very big problem, in a very > >> straightforward way. It doesn't solve *anything* until MUAs support it. Most MUAs currently "support" it only by providing an "original message" functionality which allows the cognoscenti to look it up themselves. This may or may not take as much time as it takes Yahoo! and AOL to adopt Author-Domain-side mitigations. > > Ensuring an origination header can be seen is better solved by > > making specific exceptions for valid use of From header field > > group syntax permitted by RFC6854 which amended RFC5322. > > Can you make a clear proposal? It's in the archives of this mailing list. > For the case of lists, the semantics and syntactic of how to use From: > and Reply-To: have never been quite clear, Oh, yes they have. Discussion lists that use Reply-To are simply nonconformant, and the costs and benefits of doing so have long been clear. People simply disagree on the values associated with it, and nobody has gone to the effort to (1) write a protocol for a field for list use (more generally, any Mediator's use), and (2) provide patches for the major open source MUAs to support them. > If you have a more general case solution - that doesn't require > cooperation of Yahoo et al, let's see it! The cooperation of Yahoo! is likely to be forthcoming (IMO YMMV of course), although it won't be 100% of what we'd like and it won't be tomorrow. > I'd argue that point. At this point, the community hasn't accepted > the DMARC approach to imposing sender authentication - rather, a > popular reaction has been to ignore DMARC policies. I suggest that > this is a situation that will continue. No. They do not ignore them, at least if you're talking about Gmail. Gmail only downgrades from p=reject to p=quarantine. Nor does DMARC itself *impose* sender policies (despite the names of the p= policy options). As described above, once one wades through all the technical verbiage, "p=reject" is *advice*, but (if the Author Domain is something like a bank) advice that no sane mailbox provider would care to ignore. So Gmail has *always* treated p=reject as p=quarantine (some discussion of this point from Gmail personnel is in the archives here), and it just *seems* as if they suddenly started ignoring p=reject during the April Debacle because whatever algorithm they use is sane vs. the intended use cases for DMARC p=reject. It's only when Yahoo! started using p=reject that it became clear that they're quite sane for that use case too. :-) From nobody Tue Oct 28 02:22:52 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE2091A1AB7 for ; Tue, 28 Oct 2014 02:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.009 X-Spam-Level: ** X-Spam-Status: No, score=2.009 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPRZSxnylS2j for ; Tue, 28 Oct 2014 02:22:07 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6451A1AA8 for ; Tue, 28 Oct 2014 02:22:06 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id D72FB1C3A17; Tue, 28 Oct 2014 18:22:04 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id CB0691A27CF; Tue, 28 Oct 2014 18:22:04 +0900 (JST) From: "Stephen J. Turnbull" To: Scott Kitterman In-Reply-To: <2A32DB76-5C0F-4CA5-8E42-3A70E510B2BC@kitterman.com> References: <544A681E.1000500@meetinghouse.net> <544AD9F3.9080304@meetinghouse.net> <87r3xs4u9k.fsf@uwakimon.sk.tsukuba.ac.jp> <2A32DB76-5C0F-4CA5-8E42-3A70E510B2BC@kitterman.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Tue, 28 Oct 2014 18:22:04 +0900 Message-ID: <87d29c4khv.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/7qRTLsU6HXvGG_0rk5KwH26r6Cc Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 09:22:09 -0000 Scott Kitterman writes: > >The first thing you need to do is realize that these proposals only > >make sense under the presumption that From will be munged. That is > >nonconformant to RFC 5322, and *that* is a nonexistence proof for > >"straightforward". > > So because RFC 5322 the email I see in my inbox on a daily basis > with a munged From is a figment of my imagination? What is a figment of your imagination is your interpretation of what I wrote, and you quoted. It was somewhat abbreviated, so let me expand. The fact that some agents do not conform to a standard is rarely considered a sufficient reason to amend the standard, much less so to build on the nonconformance without amending the standard. Such changes will be anything but straightforward, unless you make a deliberate effort to generate a "submarine" RFC without attracting attention from those of us who believe our reasons for disliking the idea are good ones. > Also, since Mailman already supports From munging, it seems odd to > suggest related patches wouldn't be accepted because From munging > is evil. Mailman supports From-munging for the same reasons that it supports Reply-To munging: so that it can - document that behavior demanded by users is non-conformant and not recommended, - document why that is so, - document the limitations and "gotchas" provided by the feature, and - where possible, provide features that limit the damage but are substantially more difficult to implement because they not only are flexible, but also need support from the list configurate routines. In the Reply-To case, Mailman provides options to *set* the Reply-To field to list, or to *add* the list's address to Reply-To. In the DMARC case, From-munging can be selectively performed only when the message's Author Domain publishes a "p=reject" policy), and again Reply-To handling has several options. Such more complicated features are rarely provided by the 3rd-party patches, which often become quite widely used. It is not clear to me that there will be any demand at all for such patches by Mailman sites. If and when there is, we'll think about it. As an abstract exercise, I will oppose standardization of an "original author" field, and it was considered likely when I was delegated to particpate here that most of the core developers of Mailman will agree with me (that's why they ain't here and I is). > I believe the Rubicon has been crossed. I appreciate your discussion. It's made me take a lot more care in my own thinking on the matter. But I think you're on the wrong continent. The Tigris has been crossed, but we can still avoid crossing the Euphrates, and at least for now, I believe we should go no farther. Specifically, ISTR you are one of the advocates of an "original author" header field who maintains that it's safe because MUAs *won't* display it, and therefore it does not pose the kind of "recommender spam" and phishing risks that the From field does. But here you are supporting two posters who suggest that display by the MUA is a desirable feature. It's definitely not straightforward when different proponents advance diametrically opposed features as important advantages of the proposal. Regards, Steve From nobody Tue Oct 28 12:22:52 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65D471ACCE3 for ; Tue, 28 Oct 2014 12:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.838 X-Spam-Level: X-Spam-Status: No, score=-97.838 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_16=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1JwypSZiMC2 for ; Tue, 28 Oct 2014 12:22:44 -0700 (PDT) Received: from news.winserver.com (mail.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8C58F1A8F4D for ; Tue, 28 Oct 2014 12:22:44 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=5122; t=1414524152; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=ADqr39glPgSoDKEW/v7//J/xme4=; b=kHTRW4PojhL0WTn8wb21 jSYSgU4x6TWzPtpGY0rtICOXG5QyOYJScAc6xvTkXvYj6v7TmsBlqgnZF9WpxKER aOwbR1p/2Br8+xhTI110Ue6wQ/jWsFK2Ab/Mxl8pNSfhFSINXIB76MjEJiHb2kxi QHEXf57DWs38rl9sobfSj/s= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 28 Oct 2014 14:22:32 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1119234622.85832.3888; Tue, 28 Oct 2014 14:22:31 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=5122; t=1414523735; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=mIOV/s+ hrnDd8v8JAYVRXEL7cczUhv+HcixOgTeRNYk=; b=s/AWa84eGN142F2XnvuWm/0 ORK8OEkbDdsDzEiPAzy1iZaeyeBukfVjMcN8qRFLxl48Peqi/+zjMyNXGnT75KgN 69HUzePm/1c1Tsah6Zgao2gXcCVJn7aG0Z9sJB1h+uYLmpfe4axS9SNzJdLu8UHx KdLczdyrz4MqqZKvLI9I= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 28 Oct 2014 15:15:35 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4006614985.9.3808; Tue, 28 Oct 2014 15:15:34 -0400 Message-ID: <544FECF6.70001@isdg.net> Date: Tue, 28 Oct 2014 15:22:30 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Brett McDowell , Dave Crocker References: <5436FE09.4050104@sonnection.nl> <20141010041209.2106.qmail@ary.lan> <01PDKQLQAPA200005K@mauve.mrochek.com> <01PDUPKE1KHQ00005L@mauve.mrochek.com> <54494348.4090306@isdg.net> <871tpyieot.fsf@uwakimon.sk.tsukuba.ac.jp> <544A43D4.5070903@isdg.net> <87tx2tgoby.fsf@uwakimon.sk.tsukuba.ac.jp> <544AFEFA.1060506@isdg.net> <036E3CA0799048928F761B1C43905335@fgsr.local> <544BD68B.6030905@dcrocker.net> <544EB20A.2050602@dcrocker.net> <67037945-4C30-43A9-9030-0A7A2A061C15@gmail.com> In-Reply-To: <67037945-4C30-43A9-9030-0A7A2A061C15@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/u48mya-zpjI-wQkL0rz5AfGRNYw Cc: dmarc , "J. Gomez" Subject: Re: [dmarc-ietf] wiki vs. list? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 19:22:47 -0000 On 10/27/2014 5:16 PM, Brett McDowell wrote: > I’m not sure what the relevance of this particular debate is, but in hopes of moving us forward, I offer another data point. > > Please remember that you can deploy DMARC and get exactly the desired result from your DMARC deployment, without deploying any DKIM infrastructure. Example: you can push a p=reject on a domain that never sends mail. You can push any p= value for a domain that is only “protected†by SPF records, even one that is in use, and get exactly the desired result. DKIM is of course required to achieve the desired result for most mail flows, but DKIM it is not in any way required for all successful deployments of DMARC. > This was always possible with all DKIM Policy Framework proposals since 2003 -- you can piggy back of the idea that receivers would be checking for specific exclusive operations. This is in fact, the highest benefit one can receive with any of the Domain Policy Protocols where the "expectation" bar has risen beyond the standard expectation and the highly abused legacy operation. > Given that fact, perhaps we can stop debating whether or not DMARC is a DKIM Policy Framework. But what was the point of that debate in the first place? Probably because there has been resistant to the idea of a "lookup." In addition, the term "Policy" has been swapped around with the idea of an operational "practice" in place. So its the practice|policy of a domain to expect mail to have certain attributes, i.e. be sign or not sign, no mail at all, or allow a 3rd party to sign, etcs. Whats lacking in DMARC are 3rd party policies and the point I wish to stress is that we are not going to resolve this issue until that is recognized. We had too much resistance by the 3rd party MLM market to allow the 1st party to dictate what is valid or not. See RFC5016 and how it makes this a MLM market protection, replace SSP with DMARC and we have: Section 5.3, item 10 10. DMARC MUST NOT provide a mechanism that impugns the existence of non-first party signatures in a message. A corollary of this requirement is that the protocol MUST NOT link practices of first party signers with the practices of third party signers. INFORMATIVE NOTE: the main thrust of this requirement is that practices should only be published for that which the publisher has control, and should not meddle in what is ultimately the local policy of the receiver. Refs: Deployment Consideration, Section 4.3. This corollary added at the last minute and ever since then, we had no SOLUTION to this issue. It destroyed SSP, ADSP and now it threatens DMARC. Only this time, by using radical rewrite concepts to bypass the DMARC security offered by 1st party. > If we all agreed that DMARC was a DKIM Policy Framework, what outcome would >that have brought us closer to? To accept the fact that DMARC lacks policies or certain practices that has long cause the conflict that currently exist. We are trying to see how to fit" in an authorized or allowed a 3rd party signer. The DMARC Policy Framework has no provision for this other than an allowance for a 3rd party extension to be added to it, see draft-kucherawy-dmarc-base, section 3.1.4.3 3.1.4.3. Alignment and Extension Technologies If DMARC is extended to include the use of other authentication mechanisms, the extensions will need to allow for domain identifier extraction so that alignment with the RFC5322.From domain can be verified. There is where the focus should be at. > I suspect there was a purpose for that argument that might still be relevant >to our work even though the argument doesn’t seem to be supported, but I’m > not seeing it yet. Thats unfortunate, because based on your marketing efforts (spams from agari regarding presentations you are making), you should be on top of these very important total mail integration concepts. These are ALL integrated ideas and you can't just isolate one from the other if there is expectation of a wide spread, across the board, adoption: RFC4405 SUBMITTER SMTP Service Extension RFC4406 Sender ID: Authenticating E-Mail RFC4407 Purported Responsible Address (PRA) RFC4408 Sender Policy Framework (SPF) RFC4686 Analysis of Threats Motivating DKIM RFC4870 DomainKeys RFC4871 DKIM (RFC5672.TXT, RFC6376.TXT) RFC5016 Requirements for a DKIM Signing Practices Protocol RFC5451 Message Header Field for Indicating Message Authentication Status RFC5518 Vouch By Reference RFC5585 DKIM Service Overview RFC5617 DKIM Author Domain Signing Practices (ADSP) RFC5863 DKIM Development, Deployment, and Operations RFC5965 An Extensible Format for Email Feedback Reports RFC6376 DomainKeys Identified Mail (DKIM) Signatures RFC6377 DomainKeys Identified Mail (DKIM) and Mailing Lists RFC6541 DomainKeys Identified Mail (DKIM) Authorized Third-Party Signatures In particular, I suggest a quick review of RFC4686, RFC5016 and RFC5585 to gain a high total system view appreciation of whats going on. Thanks -- HLS From nobody Tue Oct 28 12:27:08 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BAA01AC40D for ; Tue, 28 Oct 2014 12:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.698 X-Spam-Level: X-Spam-Status: No, score=0.698 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHk7aonGEnyB for ; Tue, 28 Oct 2014 12:27:03 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C8A61AC3FC for ; Tue, 28 Oct 2014 12:27:03 -0700 (PDT) Received: from scott-latitude-e6320.localnet (unknown [72.128.40.159]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 9A5E7C40078; Tue, 28 Oct 2014 14:27:02 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1414524422; bh=hy248ErDgZN/dAR+ka6zTvvXstIJjLLHI7a7l/W9K3Y=; h=From:To:Subject:Date:In-Reply-To:References:From; b=j6KHwxhb7gO8DVOvSBRLbX0aeL//iPLAqEosx7R0neHfOOa+6mhGYTYT6CRmtlmp6 bHJkHrHKtiHe8e2nASKdS4+dOSY/1dUBm7cCY2l3NouyYb92waW2ysU2zprCS9fRxQ 2kv4mhnEEUTic76xKjzlC969HC4UHXMtr4Ff3nHc= From: Scott Kitterman To: dmarc@ietf.org Date: Tue, 28 Oct 2014 15:27:01 -0400 Message-ID: <7262926.bSZJ7Csryx@scott-latitude-e6320> User-Agent: KMail/4.13.3 (Linux/3.13.0-37-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <87d29c4khv.fsf@uwakimon.sk.tsukuba.ac.jp> References: <544A681E.1000500@meetinghouse.net> <2A32DB76-5C0F-4CA5-8E42-3A70E510B2BC@kitterman.com> <87d29c4khv.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/t2EMHLEyg0mzD8q52T2l7-OYX_8 Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 19:27:06 -0000 On Tuesday, October 28, 2014 18:22:04 Stephen J. Turnbull wrote: > Scott Kitterman writes: > > >The first thing you need to do is realize that these proposals only > > >make sense under the presumption that From will be munged. That is > > >nonconformant to RFC 5322, and *that* is a nonexistence proof for > > >"straightforward". > > > > So because RFC 5322 the email I see in my inbox on a daily basis > > with a munged From is a figment of my imagination? > > What is a figment of your imagination is your interpretation of what I > wrote, and you quoted. > > It was somewhat abbreviated, so let me expand. The fact that some > agents do not conform to a standard is rarely considered a sufficient > reason to amend the standard, much less so to build on the > nonconformance without amending the standard. Such changes will be > anything but straightforward, unless you make a deliberate effort to > generate a "submarine" RFC without attracting attention from those of > us who believe our reasons for disliking the idea are good ones. > > > Also, since Mailman already supports From munging, it seems odd to > > suggest related patches wouldn't be accepted because From munging > > is evil. > > Mailman supports From-munging for the same reasons that it supports > Reply-To munging: so that it can > > - document that behavior demanded by users is non-conformant and not > recommended, > > - document why that is so, > > - document the limitations and "gotchas" provided by the feature, and > > - where possible, provide features that limit the damage but are > substantially more difficult to implement because they not only are > flexible, but also need support from the list configurate routines. > > In the Reply-To case, Mailman provides options to *set* the Reply-To > field to list, or to *add* the list's address to Reply-To. In the > DMARC case, From-munging can be selectively performed only when the > message's Author Domain publishes a "p=reject" policy), and again > Reply-To handling has several options. Such more complicated features > are rarely provided by the 3rd-party patches, which often become quite > widely used. > > It is not clear to me that there will be any demand at all for such > patches by Mailman sites. If and when there is, we'll think about it. > As an abstract exercise, I will oppose standardization of an "original > author" field, and it was considered likely when I was delegated to > particpate here that most of the core developers of Mailman will agree > with me (that's why they ain't here and I is). > > > I believe the Rubicon has been crossed. > > I appreciate your discussion. It's made me take a lot more care in my > own thinking on the matter. But I think you're on the wrong > continent. The Tigris has been crossed, but we can still avoid > crossing the Euphrates, and at least for now, I believe we should go > no farther. > > Specifically, ISTR you are one of the advocates of an "original > author" header field who maintains that it's safe because MUAs *won't* > display it, and therefore it does not pose the kind of "recommender > spam" and phishing risks that the From field does. But here you are > supporting two posters who suggest that display by the MUA is a > desirable feature. It's definitely not straightforward when different > proponents advance diametrically opposed features as important > advantages of the proposal. Thanks for the thoughtful reply. My personal want is very limited. When I click on "reply to author" in Kmail, I want it to go to the person that wrote the mail (Kmail also has reply to list, which is very useful for me). If there's no interest in standardizing, then I'll just make sure X-Original-Sender which is being used by multiple parties already is supported. I still think picking a common header field name to use is better than not, but meh. Scott K From nobody Tue Oct 28 12:47:25 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76C031ACD6A for ; Tue, 28 Oct 2014 12:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.912 X-Spam-Level: * X-Spam-Status: No, score=1.912 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ItBEL3_cdnq for ; Tue, 28 Oct 2014 12:47:21 -0700 (PDT) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA0691ACD7B for ; Tue, 28 Oct 2014 12:46:52 -0700 (PDT) Received: by mail-vc0-f179.google.com with SMTP id ij19so796643vcb.10 for ; Tue, 28 Oct 2014 12:46:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=mg6d0JD+UaEOv0+WZLJtcOYRJcjlNaw/0GnE6NkpnPk=; b=mVDY4ivP/hypNE3tHhZ7BDUgyhu/DylYFy4pJOku9xq1M5oincMvPiE31tRlk9nCzI jftmvv8OXJ/gjZOh1HymDjcv0HtHeR/nAi4ubaSUUML/ori1bG+CRR7LgVn1FrkpPuhg b15Lzb1DdJoWZBnVD+0O0/a3kSyvRPs3uu0zdIa0xAYl9JcmE1niOHuP5drti8AyuZtf CJOqZ1g5QJ2h/iFWktkbstTAoWAy4fEIKzJ2JkH5IHNs354oJssT0YrJ2JU74eBDZF8L CxKDeZ/JF1P9IyXeTrw77K9y2NxnFTVEuh8G7aRdMQLLvb9Bj3FocmZfzg9BCKPXNwsT IvOA== X-Received: by 10.52.189.106 with SMTP id gh10mr2884082vdc.33.1414525612017; Tue, 28 Oct 2014 12:46:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.226.136 with HTTP; Tue, 28 Oct 2014 12:46:31 -0700 (PDT) From: Todd Herr Date: Tue, 28 Oct 2014 15:46:31 -0400 Message-ID: To: dmarc@ietf.org Content-Type: multipart/alternative; boundary=001a1136be90a14fab050680e81e Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/OoHL8vQutI2f_E1TpMc4UAxWCB8 Subject: [dmarc-ietf] M3AAWG Contribution to Milestone 1 Work X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 19:47:22 -0000 --001a1136be90a14fab050680e81e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Greetings. My name is Todd Herr, and I work for Return Path. I'm writing to you today as a representative of M3AAWG. At M3AAWG's 31st Meeting in Belgium this past summer, some work began on a document that was an attempt to enumerate the most common use cases for parties impacted by a mailbox provider's publishing a p=3Dreject policy, as well as mitigation strategies for same. Between June and our most recent meeting last week in Boston, as our document started to take shape, it was pointed out that this working group was engaged in an effort that was quite similar to M3AAWG's. =E2=80=8BLast week in Boston, a meeting was held among interested parties, = and it was decided that M3AAWG should abandon our work as a separate product, and instead contribute what we have to Milestone 1. Along with this contribution of our work product will come at least one person (me) willing to further contribute time and effort to getting this work done. The document M3AAWG has worked on is still in a rough format, but should be visible and open to commenting to all who wish to do so at this location: =E2=80=8B DMARC Freemail Mitigation =E2=80=8B Thank you for reading, and I look forward to trying to contribute in meaningful ways to this group's efforts. --=20 Todd --001a1136be90a14fab050680e81e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Greetings.

= My name is Todd Herr, and I work for Return Path. I'm writing to you to= day as a representative of M3AAWG.

At M= 3AAWG's 31st Meeting in Belgium this past summer, some work began on a = document that was an attempt to enumerate the most common use cases for par= ties impacted by a mailbox provider's publishing a p=3Dreject policy, a= s well as mitigation strategies for same. Between June and our most recent = meeting last week in Boston, as our document started to take shape, it was = pointed out that this working group was engaged in an effort that was quite= similar to M3AAWG's.

=E2=80=8BLast = week in Boston, a meeting was held among interested parties, and it was dec= ided that M3AAWG should abandon our work as a separate product, and instead= contribute what we have to Milestone 1. Along with this contribution of ou= r work product will come at least one person (me) willing to further contri= bute time and effort to getting this work done.

The document M3AAWG has worked on is still in a rough format, but s= hould be visible and open to commenting to all who wish to do so at this lo= cation:

=E2=80=8B
=C2=A0DMARC Freemail Mitigation=E2=80=8B
Thank you for readi= ng, and I look forward to trying to contribute in meaningful ways to this g= roup's efforts.

--=C2=A0
Todd

--001a1136be90a14fab050680e81e-- From nobody Tue Oct 28 13:20:41 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76F131ACCEC for ; Tue, 28 Oct 2014 13:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.597 X-Spam-Level: X-Spam-Status: No, score=-0.597 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htejq4BKJJxm for ; Tue, 28 Oct 2014 13:20:34 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69E641ACEA0 for ; Tue, 28 Oct 2014 13:16:08 -0700 (PDT) Received: by mail-oi0-f47.google.com with SMTP id a3so565550oib.6 for ; Tue, 28 Oct 2014 13:16:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WoLsNSpA29vcWDZorLooNCGZpIUHSu5LjzKA8riwRlo=; b=NWWJY0eRLK+L1hJBrlfZseWdrU+XRFDzMXNAagf4FNu/So4F0ien/z7pVT8KCEArXG cS2wXz+S4tQ4IXQdhQpPOm+5enorMYQ/ecxPeyGufib5gv5i4jyyxe4UGiDMzHfH3T5h gUcPP4aiEfEyPoF9jkcmZgUHxHiYKpRWE0sqpXRiCXRLbpYRNHCUXs1kDdH3f+Oblx1W O0YyCHs05J6tT9RygjfReDwpc86zxUPEhEmV1xHii5o8Fxa/bVvUdcJ9j9tCQFpm8JTU w8yyD/6cU/5L1Ho+9tMpAq1KY3lhoSQiqMnYE8q6LyU4kH5h8GGqENMVgtDwajwebYdL 4RLA== MIME-Version: 1.0 X-Received: by 10.60.46.199 with SMTP id x7mr95252oem.86.1414527367924; Tue, 28 Oct 2014 13:16:07 -0700 (PDT) Received: by 10.76.129.48 with HTTP; Tue, 28 Oct 2014 13:16:07 -0700 (PDT) In-Reply-To: <544FECF6.70001@isdg.net> References: <5436FE09.4050104@sonnection.nl> <20141010041209.2106.qmail@ary.lan> <01PDKQLQAPA200005K@mauve.mrochek.com> <01PDUPKE1KHQ00005L@mauve.mrochek.com> <54494348.4090306@isdg.net> <871tpyieot.fsf@uwakimon.sk.tsukuba.ac.jp> <544A43D4.5070903@isdg.net> <87tx2tgoby.fsf@uwakimon.sk.tsukuba.ac.jp> <544AFEFA.1060506@isdg.net> <036E3CA0799048928F761B1C43905335@fgsr.local> <544BD68B.6030905@dcrocker.net> <544EB20A.2050602@dcrocker.net> <67037945-4C30-43A9-9030-0A7A2A061C15@gmail.com> <544FECF6.70001@isdg.net> Date: Tue, 28 Oct 2014 16:16:07 -0400 Message-ID: From: Brett McDowell To: Hector Santos Content-Type: multipart/alternative; boundary=089e0149bde64a53590506815161 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/hebqSN8pAGErXnNeHGGdfSYQkfc Cc: dmarc , Dave Crocker , "J. Gomez" Subject: Re: [dmarc-ietf] wiki vs. list? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 20:20:35 -0000 --089e0149bde64a53590506815161 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Oct 28, 2014 at 3:22 PM, Hector Santos wrote: > > > I suspect there was a purpose for that argument that might still be >> relevant >> to our work even though the argument doesn=E2=80=99t seem to be supporte= d, but >> > I=E2=80=99m not seeing it yet. > > Thats unfortunate, because based on your marketing efforts (spams from > agari regarding presentations you are making), you should be on top of > these very important total mail integration concepts. Hector, don't confuse your inability to put forward a coherent argument with my inability to understand these concepts. --089e0149bde64a53590506815161 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Oct 28, 2014 at 3:22 PM, Hector Santos <hsantos@isdg.net>= ; wrote:

I suspect there was a purpose for that argument that might still be relevan= t
to our work even though the argument doesn=E2=80=99t seem to be supported, = but
I=E2=80=99m not seeing it yet.

 Thats unfortunate, because based on your marketing efforts (spams from agar= i regarding presentations you are making), you should be on top of these ve= ry important total mail integration concepts. =C2=A0

<= /div>
Hector, don't confuse your inability to put forward a coheren= t argument with my inability to understand these concepts.

<= /div>
--089e0149bde64a53590506815161-- From nobody Tue Oct 28 13:32:46 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CFC21ACDDE for ; Tue, 28 Oct 2014 13:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.38 X-Spam-Level: X-Spam-Status: No, score=-98.38 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81ZA18jzVddM for ; Tue, 28 Oct 2014 13:32:42 -0700 (PDT) Received: from mail.catinthebox.net (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3092D1ACE61 for ; Tue, 28 Oct 2014 13:32:03 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1186; t=1414528322; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=LZc7sZSIfKuDavPCWCP4AAUt6pE=; b=ZIIIWC5wveRys3FGsyLV XAsT2pKD5m0IOExP6nzhc+qHudmzxVZUwHhleIHdyOBe5Hf6xvgkShSsRy+Osvsb MQHTVS82RXPkr9kXY5v51P0vnm792ESeEP4TCboxQ1lA2WY8LEVY+BVCXr3VWkN4 bpVBIF8TdKyU7mGAOUXIQXk= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 28 Oct 2014 15:32:02 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1123404950.85832.1284; Tue, 28 Oct 2014 15:32:01 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1186; t=1414527906; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=YadfN+r BTdf6gtBE8LXXICX9jRrDMykiR/VUZF/98lM=; b=ek51zWCfNGuzR1PWlXb6bs5 1I8lYhBfR+CztBWj1x8VvVkpoTSUPwdMWA7GkE6Q+3VpaSSKAdqwxvBEmjjSwJvX TiYjVx5Z5f2lcvnpJAOJ7KzMYZzah/Nl1OiJaFEUqdZt5c6aXndVjLTVxwqDKQNG W9Up60RTrv8Z0BVpaBJ8= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 28 Oct 2014 16:25:06 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4010785360.9.4748; Tue, 28 Oct 2014 16:25:04 -0400 Message-ID: <544FFD41.9030408@isdg.net> Date: Tue, 28 Oct 2014 16:32:01 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Brett McDowell References: <5436FE09.4050104@sonnection.nl> <20141010041209.2106.qmail@ary.lan> <01PDKQLQAPA200005K@mauve.mrochek.com> <01PDUPKE1KHQ00005L@mauve.mrochek.com> <54494348.4090306@isdg.net> <871tpyieot.fsf@uwakimon.sk.tsukuba.ac.jp> <544A43D4.5070903@isdg.net> <87tx2tgoby.fsf@uwakimon.sk.tsukuba.ac.jp> <544AFEFA.1060506@isdg.net> <036E3CA0799048928F761B1C43905335@fgsr.local> <544BD68B.6030905@dcrocker.net> <544EB20A.2050602@dcrocker.net> <67037945-4C30-43A9-9030-0A7A2A061C15@gmail.com> <544FECF6.70001@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/8iArZNbu720AFEbLwZOy_tPa-C0 Cc: dmarc , Dave Crocker , "J. Gomez" Subject: Re: [dmarc-ietf] wiki vs. list? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 20:32:44 -0000 On 10/28/2014 4:16 PM, Brett McDowell wrote: >> >>> Brett McDowell wrote: >>> I suspect there was a purpose for that argument that might still be >>> relevant to our work even though the argument doesn’t seem to be supported, >>> but I’m not seeing it yet. >> >> Hector Santos wrote: >> Thats unfortunate, because based on your marketing efforts (spams from >> agari regarding presentations you are making), you should be on top of >> these very important total mail integration concepts. > > Hector, don't confuse your inability to put forward a coherent argument > with my inability to understand these concepts. Thats it? Is that all you have, is to attack my integrity? I won't bother to issue an complaint to the WG chairs. I wasn't attacking you. You questioned the concept and reasons for the DKIM Policy framework discussions when in fact, DMARC is all about a policy layer for DKIM/SPF. I felt its unfortunate you are not seeing the problem. There is a 184 references towards the idea. There is a long time history and tons of R&D work. There is a problem regarding 3rd party signers. What else is there to understand? -- HLS From nobody Tue Oct 28 13:50:00 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5DCF1A8F43 for ; Tue, 28 Oct 2014 13:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iz90Ap_dV1pL for ; Tue, 28 Oct 2014 13:49:56 -0700 (PDT) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 668431A8F3F for ; Tue, 28 Oct 2014 13:49:56 -0700 (PDT) Received: from [10.0.1.4] (97-82-216-27.dhcp.hckr.nc.charter.com [97.82.216.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id B5D78CB46 for ; Tue, 28 Oct 2014 16:49:54 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Tim Draegen In-Reply-To: <544FFD41.9030408@isdg.net> Date: Tue, 28 Oct 2014 16:49:54 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <5436FE09.4050104@sonnection.nl> <20141010041209.2106.qmail@ary.lan> <01PDKQLQAPA200005K@mauve.mrochek.com> <01PDUPKE1KHQ00005L@mauve.mrochek.com> <54494348.4090306@isdg.net> <871tpyieot.fsf@uwakimon.sk.tsukuba.ac.jp> <544A43D4.5070903@isdg.net> <87tx2tgoby.fsf@uwakimon.sk.tsukuba.ac.jp> <544AFEFA.1060506@isdg.net> <036E3CA0799048928F761B1C43905335@fgsr.local> <544BD68B.6030905@dcrocker.net> <544EB20A.2050602@dcrocker.net> <67037945-4C30-43A9-9030-0A7A2A061C15@gmail.com> <544FECF6.70001@isdg.net> <544FFD41.9030408@isdg.net> To: dmarc X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/FaSiyPU4E9A49ZYy0BLeNo4c9u4 Subject: Re: [dmarc-ietf] wiki vs. list? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 20:49:58 -0000 Hello, please remember to keep this dialogue respectful. Feel free to review: http://trac.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneOneWiki ...as it forms the basis for meeting the WG's first milestone. 1/2 of this WG's Chair, =- Tim From nobody Tue Oct 28 13:58:09 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B400A1A8FD3 for ; Tue, 28 Oct 2014 13:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.302 X-Spam-Level: X-Spam-Status: No, score=-99.302 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7YrzC15poBF for ; Tue, 28 Oct 2014 13:58:04 -0700 (PDT) Received: from listserv.winserver.com (secure.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id E49561A8F4A for ; Tue, 28 Oct 2014 13:58:03 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2432; t=1414529873; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=nha0QI12L2QoguUTMVC6Ec9EXt8=; b=Zsa46CUZ7o3Zk9JBHebQ uj7ZEYzHYdveC0tf5gMpyPhdBAg8yIxX1uA3EhURxkIPopJZ99DuqJBHgmwCFYKo SzTP3/vhXP7sp2EVqOBffo3HYaDmUYhAFnZgYt8N7UEMMmmcVyQzh4c56ut979nN KETciWPjL2F9yk1tXDr9SW0= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 28 Oct 2014 15:57:53 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1124955288.85832.5412; Tue, 28 Oct 2014 15:57:52 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2432; t=1414529456; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=bimtKON psRVlZU4oMOxL6GODhunzRzQ/uC37W5KWBMA=; b=DUv/O/nOAvY71eQSJsKtJgU sfSHqj3/klbAs34JVBnejg9a99iyMJ/UjBl8Pr9qGQOg0A6QZh+5Soa6mB8GLs2b ukuQOp8dZ17y1WBMPfB3O0UNSbVFyPxLr/2qZtfBRlsLjFlGIehS8UWADaJauJCJ NU5O4vYZjy+pzCa2Cgic= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 28 Oct 2014 16:50:56 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4012336094.9.4832; Tue, 28 Oct 2014 16:50:55 -0400 Message-ID: <5450034F.3050703@isdg.net> Date: Tue, 28 Oct 2014 16:57:51 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Brett McDowell References: <5436FE09.4050104@sonnection.nl> <20141010041209.2106.qmail@ary.lan> <01PDKQLQAPA200005K@mauve.mrochek.com> <01PDUPKE1KHQ00005L@mauve.mrochek.com> <54494348.4090306@isdg.net> <871tpyieot.fsf@uwakimon.sk.tsukuba.ac.jp> <544A43D4.5070903@isdg.net> <87tx2tgoby.fsf@uwakimon.sk.tsukuba.ac.jp> <544AFEFA.1060506@isdg.net> <036E3CA0799048928F761B1C43905335@fgsr.local> <544BD68B.6030905@dcrocker.net> <544EB20A.2050602@dcrocker.net> <67037945-4C30-43A9-9030-0A7A2A061C15@gmail.com> <544FECF6.70001@isdg.net> <544FFD41.9030408@isdg.net> In-Reply-To: <544FFD41.9030408@isdg.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/7hnqGNXAJomVsR3pScajNjL9Qu4 Cc: dmarc , Dave Crocker , "J. Gomez" Subject: Re: [dmarc-ietf] wiki vs. list? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 20:58:07 -0000 Brett, my main point is that, if you, of all people, don't understand the problem, then we seriously are having a basic understanding of the long time conflict and its resolutions. You (speaking in general) either support a policy concept or you don't. Thats been the dilemma all these years. But you do understand policy, because you pointed out the idea that you don't need DKIM per se to use DMARC, i.e. you have a restrictive policy to handle legacy abused operations (where mail is not signed or there is no mail operation for a domain). These are not new ideas. They are 10 years old DKIM POLICY concepts. However, I find it hard to understand how the advocates of DMARC are not pushing for 3rd party solutions. Thats the odd thing about it. My apology to you if you felt offended by my comments. It wasn't intended. If the new DMARC advocates and DKIM Policy Marketing was as strong during SSP/ADSP, the original proof of concept with DKIM, we probably would of solved this problem long ago and MLM/MLS systems, including our own MLS product, would be better off without the radical rewriting hacks suggestions. -- HLS On 10/28/2014 4:32 PM, Hector Santos wrote: > On 10/28/2014 4:16 PM, Brett McDowell wrote: >>> >>>> Brett McDowell wrote: >>>> I suspect there was a purpose for that argument that might still be >>>> relevant to our work even though the argument doesn’t seem to be >>>> supported, >>>> but I’m not seeing it yet. >>> >>> Hector Santos wrote: >>> Thats unfortunate, because based on your marketing efforts (spams from >>> agari regarding presentations you are making), you should be on top of >>> these very important total mail integration concepts. >> >> Hector, don't confuse your inability to put forward a coherent argument >> with my inability to understand these concepts. > > Thats it? Is that all you have, is to attack my integrity? I won't > bother to issue an complaint to the WG chairs. I wasn't attacking > you. You questioned the concept and reasons for the DKIM Policy > framework discussions when in fact, DMARC is all about a policy layer > for DKIM/SPF. I felt its unfortunate you are not seeing the problem. > There is a 184 references towards the idea. There is a long time > history and tons of R&D work. There is a problem regarding 3rd party > signers. What else is there to understand? > -- HLS From nobody Tue Oct 28 13:58:30 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDD5F1A8FD3 for ; Tue, 28 Oct 2014 13:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.881 X-Spam-Level: X-Spam-Status: No, score=-0.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZFEcR8RqG2J for ; Tue, 28 Oct 2014 13:58:17 -0700 (PDT) Received: from server1.neighborhoods.net (server1.neighborhoods.net [207.154.13.48]) by ietfa.amsl.com (Postfix) with ESMTP id AC0411A8AEC for ; Tue, 28 Oct 2014 13:58:17 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by server1.neighborhoods.net (Postfix) with ESMTP id 85FAFCC100 for ; Tue, 28 Oct 2014 16:58:16 -0400 (EDT) X-Virus-Scanned: by amavisd-new-2.6.2 (20081215) (Debian) at neighborhoods.net Received: from server1.neighborhoods.net ([127.0.0.1]) by localhost (server1.neighborhoods.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id OCUR9pleg0kF for ; Tue, 28 Oct 2014 16:58:07 -0400 (EDT) Received: from [172.18.4.88] (unknown [69.27.252.130]) by server1.neighborhoods.net (Postfix) with ESMTPSA id AAA72CC083 for ; Tue, 28 Oct 2014 16:58:07 -0400 (EDT) Message-ID: <5450039B.5010504@meetinghouse.net> Date: Tue, 28 Oct 2014 16:59:07 -0400 From: Miles Fidelman User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 SeaMonkey/2.30 MIME-Version: 1.0 CC: dmarc References: <5436FE09.4050104@sonnection.nl> <20141010041209.2106.qmail@ary.lan> <01PDKQLQAPA200005K@mauve.mrochek.com> <01PDUPKE1KHQ00005L@mauve.mrochek.com> <54494348.4090306@isdg.net> <871tpyieot.fsf@uwakimon.sk.tsukuba.ac.jp> <544A43D4.5070903@isdg.net> <87tx2tgoby.fsf@uwakimon.sk.tsukuba.ac.jp> <544AFEFA.1060506@isdg.net> <036E3CA0799048928F761B1C43905335@fgsr.local> <544BD68B.6030905@dcrocker.net> <544EB20A.2050602@dcrocker.net> <67037945-4C30-43A9-9030-0A7A2A061C15@gmail.com> <544FECF6.70001@isdg.net> In-Reply-To: <544FECF6.70001@isdg.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/0S35d8Wk26LZe8KMKaZCWc4r-Vk Subject: Re: [dmarc-ietf] wiki vs. list? -- please update subject lines X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 20:58:21 -0000 Can we please start using meaningful subject lines. We're now discussing about 6 different topics under "wiki vs. list" - none of which have to do with "wiki vs. list." Miles Fidelman From nobody Tue Oct 28 14:30:51 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 676401AD04A for ; Tue, 28 Oct 2014 14:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nuHlJz6d3Zm9 for ; Tue, 28 Oct 2014 14:30:48 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F02B11AD04C for ; Tue, 28 Oct 2014 14:30:47 -0700 (PDT) Received: by mail-oi0-f44.google.com with SMTP id h136so1280466oig.17 for ; Tue, 28 Oct 2014 14:30:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iJLBwFembpMNb7WaBlLgw1L2ZDCxp6CzkW44Glpfcms=; b=eO/5ysk5Q3yI/icZhQFZ9EVr864tukeXjJGGng3CwCkJ2m0NO2lEq+BX8/+YnPHleB tDzOYtUGiw41Sci8K/n0I5hRoQmHiT10j+pi4ZT1AaTr4qK2KqyqHDisIf5RjAG79MUD lB0+1m4Uo2aLK7PJZhzUJqTb0e+ltk1J5UwRxUA0gwi6zmVLvx2XnbRvQr7H4+TVLSjV n6hFZA1TsFztzEnA1zXcyOUPLzF4Xt0pwT5qHqMUyIfcu3MF1mWUhsRTGnn31SLOsmAx frNQiYrQjmBktbSXblu/MSG6rBejMEuZq2pgPyoqj8m48/2qd3ywfTKfafpvMeCtNMtl /SvA== MIME-Version: 1.0 X-Received: by 10.60.45.206 with SMTP id p14mr4951377oem.38.1414531847188; Tue, 28 Oct 2014 14:30:47 -0700 (PDT) Received: by 10.76.129.48 with HTTP; Tue, 28 Oct 2014 14:30:47 -0700 (PDT) In-Reply-To: <5450034F.3050703@isdg.net> References: <5436FE09.4050104@sonnection.nl> <20141010041209.2106.qmail@ary.lan> <01PDKQLQAPA200005K@mauve.mrochek.com> <01PDUPKE1KHQ00005L@mauve.mrochek.com> <54494348.4090306@isdg.net> <871tpyieot.fsf@uwakimon.sk.tsukuba.ac.jp> <544A43D4.5070903@isdg.net> <87tx2tgoby.fsf@uwakimon.sk.tsukuba.ac.jp> <544AFEFA.1060506@isdg.net> <036E3CA0799048928F761B1C43905335@fgsr.local> <544BD68B.6030905@dcrocker.net> <544EB20A.2050602@dcrocker.net> <67037945-4C30-43A9-9030-0A7A2A061C15@gmail.com> <544FECF6.70001@isdg.net> <544FFD41.9030408@isdg.net> <5450034F.3050703@isdg.net> Date: Tue, 28 Oct 2014 17:30:47 -0400 Message-ID: From: Brett McDowell To: Hector Santos Content-Type: multipart/alternative; boundary=001a11c2019a4674820506825c81 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/J1m66qw6PMUFsV75sL0OOAqpnfY Cc: dmarc , Dave Crocker , "J. Gomez" Subject: Re: [dmarc-ietf] wiki vs. list? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 21:30:49 -0000 --001a11c2019a4674820506825c81 Content-Type: text/plain; charset=UTF-8 On Tue, Oct 28, 2014 at 4:57 PM, Hector Santos wrote: > My apology to you if you felt offended by my comments. It wasn't > intended. Thank you for saying so Hector. I appreciate it. > >>> Hector, don't confuse your inability to put forward a coherent argument >>> with my inability to understand these concepts. >>> >> >> Thats it? Is that all you have, is to attack my integrity? > > I apologize if my effort to defend my own integrity (and that of Agari) came across as an attack on yours. You are obviously extremely well versed in "the literature" of Internet mail. I didn't mean to imply you were incapable of making a coherent argument, just that you hadn't thus far and that I wasn't going to accept the implications of your comment aimed at Agari and myself. But it's all water under the bridge, as they say. FWIW, I actually think I now understand what you were trying to get at with the original argument about DMARC being a DKIM Policy Framework. We were simply talking past each other. So yes, I obviously support what DMARC does to make the inboxes of the world a safer place every day. So if you want to call that "a policy framework", I don't see the downside in agreeing with you. But let's get back to closing out Milestone 1, which is orthogonal to this discussion. --001a11c2019a4674820506825c81 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Oct 28, 2014 at 4:57 PM, Hector Santos <hsantos@isdg.net> wrote:


My apology to you if you felt offended by my comments.=C2=A0 It wasn't = intended. =C2=A0

Thank you for saying so He= ctor.=C2=A0 I appreciate it.
=C2=A0

Hector, don't confuse your inability to put forward a coherent argument=
with my inability to understand these concepts.


Thats it?=C2=A0 Is that all you have, is to attack my integrity?=C2=A0

I apologize if my effo= rt to defend my own integrity (and that of Agari) came across as an attack = on yours.=C2=A0 You are obviously extremely well versed in "the litera= ture" of Internet mail.=C2=A0 I didn't mean to imply you were inca= pable of making a coherent argument, just that you hadn't thus far and = that I wasn't going to accept the implications of your comment aimed at= Agari and myself.=C2=A0 But it's all water under the bridge, as they s= ay.

FWIW, I actually think I now understand what y= ou were trying to get at with the original argument about DMARC being a DKI= M Policy Framework.=C2=A0 We were simply talking past each other.=C2=A0 So = yes, I obviously support what DMARC does to make the inboxes of the world a= safer place every day.=C2=A0 So if you want to call that "a policy fr= amework", I don't see the downside in agreeing with you. =C2=A0

But let's get back to closing out Milestone 1, w= hich is orthogonal to this discussion.

=C2=A0
--001a11c2019a4674820506825c81-- From nobody Tue Oct 28 15:44:51 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 521BB1A0258 for ; Tue, 28 Oct 2014 15:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHdldz9X4_9K for ; Tue, 28 Oct 2014 15:44:46 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DFD91A0217 for ; Tue, 28 Oct 2014 15:44:31 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id a1so605270wgh.34 for ; Tue, 28 Oct 2014 15:44:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=0ekrc8AS6+ImWbmO602mfO/p6U09FJCYaMTQcj9WWRQ=; b=GTpAMi8q/aFYf1kNtJkbKkokIEco9fwTlBQ5/ZP9vRcPhbru10DHup5998FJI4R8W1 KYhJD4Rr0nLomnZfo5fjDZy2NTTkpIBhFv2rimZ6HNCgyu6mz8zi3LxUx6KgDUKxPaQR bTG2n+R0HByJ0z8l6ORFpKPHOsoISK6sEBPJERkFLoENBFUzAXpv4YHEAeZxDk23VNDT X+kMLSMgDwday64hVWtsEZPe33o8Px4wUSWAb1A+v6hBM8qZ53NNSj9T1+AeJCRgtXDz GNuhaZDyel8sijNyFC1CKWO+V8zH38FCjqz6PiAit1CHhSfz7/gTxgCXTsMKz0Dg94KF z/pQ== MIME-Version: 1.0 X-Received: by 10.180.9.65 with SMTP id x1mr8201436wia.30.1414536269886; Tue, 28 Oct 2014 15:44:29 -0700 (PDT) Received: by 10.27.76.134 with HTTP; Tue, 28 Oct 2014 15:44:29 -0700 (PDT) Date: Tue, 28 Oct 2014 15:44:29 -0700 Message-ID: From: "Murray S. Kucherawy" To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=001a11c245cae37c3c05068363b4 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/O3UI3TZsu7V4jA97clQwtxVcVfA Subject: [dmarc-ietf] draft-kucherawy-dmarc-base revision submitted X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 22:44:48 -0000 --001a11c245cae37c3c05068363b4 Content-Type: text/plain; charset=UTF-8 Colleagues, With apologies once again that it's taken so long, I have submitted the base draft again to the datatracker. It underwent what Eliot Lear calls a "haircut", which is to say I spent a good chunk of time rearranging the material, consolidating redundant sections, removing unnecessarily verbose or unimportant text. His sketch of a roadmap to doing so was very helpful indeed. There was only one technical change, and that was to remove all references to IODEF since that's an aspect of the reporting component that is completely unimplemented. In the hopes of keeping the spec simple, it's now gone. Since we're past the I-D deadline, the ISE or Pete will have to approve its addition to the datatracker, so it will magically appear at some point soon, and then move forward in the publication process. My thanks to all of you that took time to make haircut suggestions. Onward, -MSK --001a11c245cae37c3c05068363b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Colleagues,

With apo= logies once again that it's taken so long, I have submitted the base dr= aft again to the datatracker.=C2=A0 It underwent what Eliot Lear calls a &q= uot;haircut", which is to say I spent a good chunk of time rearranging= the material, consolidating redundant sections, removing unnecessarily ver= bose or unimportant text.=C2=A0 His sketch of a roadmap to doing so was ver= y helpful indeed.

There was only one technical change, and that was = to remove all references to IODEF since that's an aspect of the reporti= ng component that is completely unimplemented.=C2=A0 In the hopes of keepin= g the spec simple, it's now gone.

Since we're pa= st the I-D deadline, the ISE or Pete will have to approve its addition to t= he datatracker, so it will magically appear at some point soon, and then mo= ve forward in the publication process.

My thanks to all of you that = took time to make haircut suggestions.

Onward,
-MSK
--001a11c245cae37c3c05068363b4-- From nobody Tue Oct 28 16:09:44 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD8D1A1A24 for ; Tue, 28 Oct 2014 16:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pr0ubuPsQIAu for ; Tue, 28 Oct 2014 16:09:38 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3A441A1A6A for ; Tue, 28 Oct 2014 16:09:37 -0700 (PDT) Received: by mail-oi0-f49.google.com with SMTP id u20so1375518oif.8 for ; Tue, 28 Oct 2014 16:09:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mU2hSrMKEVsmAHrvkK/nUkfNCPks0ghvggfSgrMpn5s=; b=J5G9YxYMqMO/PdAWSA6S7L+y23RgYnDwp2cFKsPuL6M8lo15nU108qUgdkPZRnda3u jmFMEaxyleaxYGIZuRhvwwVI41UZU8pPkPTndQAbj+QyBZRohkV1w0Do0xamm6pF5u3F vnGwj5UImM35aMhtFaSq0F1gJJe3KzTaQf3vsdgwEplV+HWNRlkqDOJ3QClaCNwUyZb7 1rq5Syvh/0w8KDo9x/k6jQdxO1+xzK6UUq8K+IQl80qaEXEvb1g3Zk25ClMJYSyRSxX6 RXcppVA47C3Vb5CvNZb7ZJOTH51i6TSdO31CWqCpOnnSuubgE9lvWagvnB6Yu318DPkK 32tg== MIME-Version: 1.0 X-Received: by 10.202.75.202 with SMTP id y193mr5056371oia.56.1414537777334; Tue, 28 Oct 2014 16:09:37 -0700 (PDT) Received: by 10.76.129.48 with HTTP; Tue, 28 Oct 2014 16:09:37 -0700 (PDT) In-Reply-To: References: Date: Tue, 28 Oct 2014 19:09:37 -0400 Message-ID: From: Brett McDowell To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=001a11c17daebd50a3050683bd27 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/ARa-FRTTWUt8oE5dbTQ7doWzDIY Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base revision submitted X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 23:09:39 -0000 --001a11c17daebd50a3050683bd27 Content-Type: text/plain; charset=UTF-8 Thanks Murray. That was a really important step. You continue to carry the bulk of the email security standardization load on your shoulders, and it is greatly appreciated! Cheers, -Brett On Tue, Oct 28, 2014 at 6:44 PM, Murray S. Kucherawy wrote: > Colleagues, > > With apologies once again that it's taken so long, I have submitted the > base draft again to the datatracker. It underwent what Eliot Lear calls a > "haircut", which is to say I spent a good chunk of time rearranging the > material, consolidating redundant sections, removing unnecessarily verbose > or unimportant text. His sketch of a roadmap to doing so was very helpful > indeed. > > There was only one technical change, and that was to remove all references > to IODEF since that's an aspect of the reporting component that is > completely unimplemented. In the hopes of keeping the spec simple, it's > now gone. > > Since we're past the I-D deadline, the ISE or Pete will have to approve > its addition to the datatracker, so it will magically appear at some point > soon, and then move forward in the publication process. > > My thanks to all of you that took time to make haircut suggestions. > > Onward, > -MSK > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --001a11c17daebd50a3050683bd27 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Murray.=C2=A0 That was a really important step.=C2= =A0 You continue to carry the bulk of the email security standardization lo= ad on your shoulders, and it is greatly appreciated!

Che= ers,

-Brett
=
On Tue, Oct 28, 2014 at 6:44 PM, Murray S. K= ucherawy <superuser@gmail.com> wrote:
Colleagues,

=
With apologies once again that it's taken so long, I have submitt= ed the base draft again to the datatracker.=C2=A0 It underwent what Eliot L= ear calls a "haircut", which is to say I spent a good chunk of ti= me rearranging the material, consolidating redundant sections, removing unn= ecessarily verbose or unimportant text.=C2=A0 His sketch of a roadmap to do= ing so was very helpful indeed.

There was only one technical change,= and that was to remove all references to IODEF since that's an aspect = of the reporting component that is completely unimplemented.=C2=A0 In the h= opes of keeping the spec simple, it's now gone.

Sinc= e we're past the I-D deadline, the ISE or Pete will have to approve its= addition to the datatracker, so it will magically appear at some point soo= n, and then move forward in the publication process.

My thanks to al= l of you that took time to make haircut suggestions.

Onward,
-MSK

_______________________________________________
dmarc mailing list
dmarc@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dmarc


--001a11c17daebd50a3050683bd27-- From nobody Tue Oct 28 16:15:55 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 366B61A1B1C for ; Tue, 28 Oct 2014 16:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1StVmPMPO8yt for ; Tue, 28 Oct 2014 16:15:50 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79F4F1A1B12 for ; Tue, 28 Oct 2014 16:15:50 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id ex7so3146809wid.4 for ; Tue, 28 Oct 2014 16:15:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+dFshozcBlK+8N9Rm6QYvN1vruFi0jBOZclYwLK0RIk=; b=lLFlJq5evXoVcCBZjRsT3pAo4vNykFAExKWFxHNJhzZok49kFJDaBBPyPkr233LEfg NY1YJyu26kVCmtbBV+bgTtk5b1UOlbZYOL2RUhcDs5SN3/yWtLuvqx5ZpVSUq14wySJs HZqQu+F2YQBaoCSxaw11kWgaNBkmnBWNhR9ilhV2nV9kkDyW2W1J8x9C/j+gJt/Q8wgR 4/czSAZJpILHlXfSqhn8qRL13V4h/deOA49NYEEGiRjM0lqXDddMk3qk5p1rMck88dJl xLmciPV0AzhjItA6vt6PY+nhQt25IYd8VlWTaZdPAbmCmPHoOOHRxq11rbcTqivmr3jj XYTw== MIME-Version: 1.0 X-Received: by 10.180.91.49 with SMTP id cb17mr7854575wib.30.1414538149075; Tue, 28 Oct 2014 16:15:49 -0700 (PDT) Received: by 10.27.76.134 with HTTP; Tue, 28 Oct 2014 16:15:49 -0700 (PDT) In-Reply-To: References: Date: Tue, 28 Oct 2014 16:15:49 -0700 Message-ID: From: "Murray S. Kucherawy" To: Brett McDowell Content-Type: multipart/alternative; boundary=f46d043c7b2ae5a075050683d38d Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/NmyRIVTNYO-bhPoJPDcvqvd2MPw Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base revision submitted X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 23:15:53 -0000 --f46d043c7b2ae5a075050683d38d Content-Type: text/plain; charset=UTF-8 On Tue, Oct 28, 2014 at 4:09 PM, Brett McDowell wrote: > Thanks Murray. That was a really important step. You continue to carry > the bulk of the email security standardization load on your shoulders, and > it is greatly appreciated! > Hi Brett, Thanks for your support. I was going to say "I added a section that shows how we can finally solve the display name problem" just to troll you specifically, but then I thought better of it. :-) -MSK --f46d043c7b2ae5a075050683d38d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Oct 28, 2014 at 4:09 PM, Brett McDowell <b= rettmcdowell@gmail.com> wrote:
=
Thanks Murray.=C2=A0 That was a really important step.= =C2=A0 You continue to carry the bulk of the email security standardization= load on your shoulders, and it is greatly appreciated!

Hi Brett,

Thanks for your support.

I was goi= ng to say "I added a section that shows how we can finally solve the display na= me=20 problem" just to troll you specifically, but then I thought better of = it.=C2=A0=20 :-)

-MSK
--f46d043c7b2ae5a075050683d38d-- From nobody Tue Oct 28 17:25:41 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2D271A1B7E for ; Tue, 28 Oct 2014 17:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5RLmmjPRDJ93 for ; Tue, 28 Oct 2014 17:25:37 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2253E1A1A29 for ; Tue, 28 Oct 2014 17:25:37 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id kx10so1912119pab.6 for ; Tue, 28 Oct 2014 17:25:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:date:subject:to:message-id:mime-version; bh=eQ2MzYzielM8wYAxxLTygwKfp6zfvPGlqj/p7dGC6PY=; b=oqodIT2a9iYm84hbvc6SKF9Jb6LAryWK9EYDMDES1vSGxH+wqx1rs//GAT5FUXYn2y xc23p4v98yVhm0esovo9+sUb9gw4aIxadLSjdJJm4hF0cRjquxN1jGRlc8MMso8Qom53 rv6un4ODunel8X7Fo2L5OTNw5+UjOSm+Ot2znXH3F/LYT3OeQ5G2bp4EqORxPDeqbdFl Q1x45S+DovXI0X+1AAzpUL79rLpy5EAdADm8J0hPfB3kSeAIEIcS+4B072AigcAHeae9 pDE2FcSNFasYFEj+5R0UZzvcUfsnu45u02vHDNhbKiAst0RGaC8Bh0YhNR2WFacpHHEP 0mfA== X-Received: by 10.66.248.104 with SMTP id yl8mr7070401pac.2.1414542336691; Tue, 28 Oct 2014 17:25:36 -0700 (PDT) Received: from [192.168.2.225] (c-67-188-1-12.hsd1.ca.comcast.net. [67.188.1.12]) by mx.google.com with ESMTPSA id j11sm2651429pdk.76.2014.10.28.17.25.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 28 Oct 2014 17:25:36 -0700 (PDT) From: Douglas Otis Content-Type: multipart/alternative; boundary="Apple-Mail=_7B4D528D-7981-4AFF-A4E2-8E2BA27E69DA" Date: Tue, 28 Oct 2014 17:25:33 -0700 To: dmarc Message-Id: <82363627-795A-45F3-85F3-3A6F7A161F20@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/_qwuebtGI_cBy5LfSXtT9mBPL8Q Subject: [dmarc-ietf] DMARC: draft-crocker-dmarc-bcp-03 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 00:25:39 -0000 --Apple-Mail=_7B4D528D-7981-4AFF-A4E2-8E2BA27E69DA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear DMARC WG, The draft-crocker-dmarc-bcp-03 repeats a mistake made in RFC5863 Section = 5.4 which caused several large service providers to permit easy DKIM = =46rom spoofing. A problem one the authors of the DMARC base draft had = not realized affected their own large deployment until fairly recently. = This draft fails to highlight essential checks needed to augment = otherwise unreliable Authentication Results. The tests described in = section 10.1 of the DMARC base specification remains excluded from the = DKIM signature verification process. This means a subsequent message = process must include DMARC base section 10.1 checks entirely overlooked = yet again in this bcp. While the informational RFC7103, Advice for Safe = Handling of Malformed Messages offers informational advice, RFC5863 = describing DKIM deployment also makes the same mistake in its Section = 5.4 when suggesting DKIM can be used to avoid subsequent processing. = Section 2.1.2 Runtime DMARC processing - Receiver side makes the same = flawed recommendation as found in RFC5863 Section 5.4 which neglects a = flaw in the DKIM signature verification process affecting DKIM result = validity as required to properly enforce DMARC or to bypass additional = checks.=20 It seems the general view is that such checks must happen at a lower = level, although neither RFC5321 nor RFC6376 Section 8.15 made format = compliance an acceptance requirement. In the case of RFC5321, a = store-and-forward strategy would need to negotiate minor format changes = as occurred with RFC6854 for example. No harm would have occurred if = RFC6376 ensured valid signature results had valid formats and can be = implemented via software switch in OpenDKIM. This change was largely = overlooked in the DMARC base draft in until an overly vague mention in = 10.1 which ignores its use when handling international email addresses. = Group syntax still permits a single address, and could be used to safely = signal a non-compliant source which might be confirmed by other means, = for example. Once again, a need to evolve a format specification = remains overlooked. DMARC continues to lack any visible means for = making often needed exceptions, which remains a serious flaw unless it = can be overcome by a domain explicit exception strategy. =20 RFC5321 Section 3.3. Mail Transactions "When the RFC 822 format ([RFC 822], [RFC 5322]) is being used, the mail = data include the header fields such as those named Date, Subject, To, Cc, and From. Server SMTP systems SHOULD NOT reject messages based on perceived defects in the RFC 822 or MIME (RFC 2045) message header section or message body. In particular, they MUST NOT reject messages in which the numbers of Resent-header fields do not match or Resent-to appears without Resent-from and/or Resent-date." (The footnotes have been expanded to clarify a reference to RFC 822 = includes all versions up to and including RFC 5322) Minor notes: Section 3.3 makes a reference to .blah.com which is a Brazilian web site = merging social network messaging. This should be converted to = example.com. Section 7.3. Use and Reporting of Local Policy Overrides has receivers = reporting back to the DMARC domain why a policy assertion was ignored. = Since DMARC lacks any mechanism (say outside that of something like = TPA-Label) the DMARC domain is unable to benefit those issuing such = feedback, since they are still obliged to discover needed exceptions = from other sources. What is their motivation for offering override = feedback? Regards, Douglas Otis --Apple-Mail=_7B4D528D-7981-4AFF-A4E2-8E2BA27E69DA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 
Dear DMARC WG,
The draft-crocker-dmarc-bcp-03 =
repeats a mistake made in RFC5863 Section 5.4 which caused several large =
service providers to permit easy DKIM =46rom spoofing. A problem one the =
authors of the DMARC base draft had not realized affected their own =
large deployment until fairly recently. This draft fails to highlight =
essential checks needed to augment otherwise unreliable Authentication =
Results. The tests described in section 10.1 of the DMARC base =
specification remains excluded from the DKIM signature verification =
process. This means a subsequent message process must include DMARC base =
section 10.1 checks entirely overlooked yet again in this bcp. While the =
informational RFC7103, Advice for Safe Handling of Malformed Messages =
offers informational advice, RFC5863 describing DKIM deployment also =
makes the same mistake in its Section 5.4 when suggesting DKIM can be =
used to avoid subsequent processing.  Section 2.1.2 Runtime =
DMARC processing - Receiver side makes the same flawed recommendation as =
found in RFC5863 Section 5.4 which neglects a flaw in the =
DKIM signature verification process affecting DKIM result =
validity as required to properly enforce DMARC or to bypass additional =
checks. 

It seems the general view is =
that such checks must happen at a lower level, although =
neither RFC5321 nor RFC6376 Section 8.15 made format compliance an =
acceptance requirement.  In the case of RFC5321, a =
store-and-forward strategy would need to negotiate =
minor format changes as occurred with RFC6854 for example.  No harm =
would have occurred if RFC6376 ensured valid signature results had valid =
formats and can be implemented via software switch in OpenDKIM.   This =
change was largely overlooked in the DMARC base draft in until =
an overly vague mention in 10.1 which ignores its use when handling =
international email addresses.  Group syntax still permits a single =
address, and could be used to safely signal a non-compliant =
source which might be confirmed by other means, for example.  Once =
again, a need to evolve a format specification remains overlooked.  =
DMARC continues to lack any visible means for making often needed =
exceptions, which remains a serious flaw unless it can be overcome by a =
domain explicit exception strategy.  

RFC5321 =
Section 3.3. Mail Transactions
"When the RFC 822 format ([RFC =
822], [RFC 5322]) is being used, the mail data
 include the =
header fields such as those named Date, Subject, To, Cc,
 and =
From.  Server SMTP systems SHOULD NOT reject messages based =
on
 perceived defects in the RFC 822 or MIME (RFC 2045) =
message
 header section or message body.  In particular, they =
MUST NOT reject
 messages in which the numbers of =
Resent-header fields do not match or
 Resent-to appears =
without Resent-from and/or Resent-date."

(The =
footnotes have been expanded to clarify a reference to RFC 822 includes =
all
 versions up to and including RFC =
5322)

Minor =
notes:

Section 3.3 makes a reference to .blah.com which is a Brazilian web site =
merging social network messaging. This should be converted to example.com.

Sect=
ion 7.3.  Use and Reporting of Local Policy Overrides has receivers =
reporting back to the DMARC domain why a policy assertion was ignored.  =
Since DMARC lacks any mechanism (say outside that of something like =
TPA-Label) the DMARC domain is unable to benefit those issuing such =
feedback, since they are still obliged to discover needed exceptions =
from other sources. What is their motivation for offering override =
feedback?

Regards,
Douglas =
Otis


= --Apple-Mail=_7B4D528D-7981-4AFF-A4E2-8E2BA27E69DA-- From nobody Tue Oct 28 17:38:26 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B67971A1BAE for ; Tue, 28 Oct 2014 17:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5KlmXKliPnWG for ; Tue, 28 Oct 2014 17:38:11 -0700 (PDT) Received: from server1.neighborhoods.net (server1.neighborhoods.net [207.154.13.48]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF321A1BB3 for ; Tue, 28 Oct 2014 17:38:11 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by server1.neighborhoods.net (Postfix) with ESMTP id 864B6CC050 for ; Tue, 28 Oct 2014 20:38:10 -0400 (EDT) X-Virus-Scanned: by amavisd-new-2.6.2 (20081215) (Debian) at neighborhoods.net Received: from server1.neighborhoods.net ([127.0.0.1]) by localhost (server1.neighborhoods.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id zNLmJxrewqpB for ; Tue, 28 Oct 2014 20:38:05 -0400 (EDT) Received: from Miles-Fidelmans-MacBook-Pro.local (static-173-56-67-50.nycmny.fios.verizon.net [173.56.67.50]) by server1.neighborhoods.net (Postfix) with ESMTPSA id 790DECC047 for ; Tue, 28 Oct 2014 20:37:59 -0400 (EDT) Message-ID: <545036E7.7040201@meetinghouse.net> Date: Tue, 28 Oct 2014 20:37:59 -0400 From: Miles Fidelman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:33.0) Gecko/20100101 Firefox/33.0 SeaMonkey/2.30 MIME-Version: 1.0 To: dmarc@ietf.org References: <544A681E.1000500@meetinghouse.net> <2A32DB76-5C0F-4CA5-8E42-3A70E510B2BC@kitterman.com> <87d29c4khv.fsf@uwakimon.sk.tsukuba.ac.jp> <7262926.bSZJ7Csryx@scott-latitude-e6320> In-Reply-To: <7262926.bSZJ7Csryx@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/NX16wkus1_z_39sOhYm81TRemIE Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 00:38:20 -0000 Scott Kitterman wrote: > On Tuesday, October 28, 2014 18:22:04 Stephen J. Turnbull wrote: >> Scott Kitterman writes: >> > >The first thing you need to do is realize that these proposals only >> > >make sense under the presumption that From will be munged. That is >> > >nonconformant to RFC 5322, and *that* is a nonexistence proof for >> > >"straightforward". >> > >> > So because RFC 5322 the email I see in my inbox on a daily basis >> > with a munged From is a figment of my imagination? >> >> What is a figment of your imagination is your interpretation of what I >> wrote, and you quoted. >> >> It was somewhat abbreviated, so let me expand. The fact that some >> agents do not conform to a standard is rarely considered a sufficient >> reason to amend the standard, much less so to build on the >> nonconformance without amending the standard. Such changes will be >> anything but straightforward, unless you make a deliberate effort to >> generate a "submarine" RFC without attracting attention from those of >> us who believe our reasons for disliking the idea are good ones. >> >> > Also, since Mailman already supports From munging, it seems odd to >> > suggest related patches wouldn't be accepted because From munging >> > is evil. >> >> Mailman supports From-munging for the same reasons that it supports >> Reply-To munging: so that it can >> >> - document that behavior demanded by users is non-conformant and not >> recommended, >> >> - document why that is so, >> >> - document the limitations and "gotchas" provided by the feature, and >> >> - where possible, provide features that limit the damage but are >> substantially more difficult to implement because they not only are >> flexible, but also need support from the list configurate routines. >> >> In the Reply-To case, Mailman provides options to *set* the Reply-To >> field to list, or to *add* the list's address to Reply-To. In the >> DMARC case, From-munging can be selectively performed only when the >> message's Author Domain publishes a "p=reject" policy), and again >> Reply-To handling has several options. Such more complicated features >> are rarely provided by the 3rd-party patches, which often become quite >> widely used. >> >> It is not clear to me that there will be any demand at all for such >> patches by Mailman sites. If and when there is, we'll think about it. >> As an abstract exercise, I will oppose standardization of an "original >> author" field, and it was considered likely when I was delegated to >> particpate here that most of the core developers of Mailman will agree >> with me (that's why they ain't here and I is). >> >> > I believe the Rubicon has been crossed. >> >> I appreciate your discussion. It's made me take a lot more care in my >> own thinking on the matter. But I think you're on the wrong >> continent. The Tigris has been crossed, but we can still avoid >> crossing the Euphrates, and at least for now, I believe we should go >> no farther. >> >> Specifically, ISTR you are one of the advocates of an "original >> author" header field who maintains that it's safe because MUAs *won't* >> display it, and therefore it does not pose the kind of "recommender >> spam" and phishing risks that the From field does. But here you are >> supporting two posters who suggest that display by the MUA is a >> desirable feature. It's definitely not straightforward when different >> proponents advance diametrically opposed features as important >> advantages of the proposal. > Thanks for the thoughtful reply. > > My personal want is very limited. When I click on "reply to author" in Kmail, > I want it to go to the person that wrote the mail (Kmail also has reply to > list, which is very useful for me). If there's no interest in standardizing, > then I'll just make sure X-Original-Sender which is being used by multiple > parties already is supported. I still think picking a common header field name > to use is better than not, but meh. > > Scott K > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc Stephen - thanks for your comments - obviously it's not as straightforward as I might think. Then again, Scott makes a pretty good point. -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From nobody Tue Oct 28 17:39:39 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE2071A1BC5 for ; Tue, 28 Oct 2014 17:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.492 X-Spam-Level: X-Spam-Status: No, score=-0.492 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_FROM_12LTRDOM=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kpngld2XyABo for ; Tue, 28 Oct 2014 17:39:36 -0700 (PDT) Received: from server1.neighborhoods.net (server1.neighborhoods.net [207.154.13.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3671A1BC3 for ; Tue, 28 Oct 2014 17:39:36 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by server1.neighborhoods.net (Postfix) with ESMTP id DE7CCCC04B for ; Tue, 28 Oct 2014 20:39:35 -0400 (EDT) X-Virus-Scanned: by amavisd-new-2.6.2 (20081215) (Debian) at neighborhoods.net Received: from server1.neighborhoods.net ([127.0.0.1]) by localhost (server1.neighborhoods.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 8YS4F6OZhqYW for ; Tue, 28 Oct 2014 20:39:27 -0400 (EDT) Received: from Miles-Fidelmans-MacBook-Pro.local (static-173-56-67-50.nycmny.fios.verizon.net [173.56.67.50]) by server1.neighborhoods.net (Postfix) with ESMTPSA id 0E0AFCC047 for ; Tue, 28 Oct 2014 20:39:27 -0400 (EDT) Message-ID: <5450373E.1060601@meetinghouse.net> Date: Tue, 28 Oct 2014 20:39:26 -0400 From: Miles Fidelman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:33.0) Gecko/20100101 Firefox/33.0 SeaMonkey/2.30 MIME-Version: 1.0 To: "dmarc@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Ev6OLAXd_5tEKrZuBELDJduJlQM Subject: [dmarc-ietf] wiki and data tracker? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 00:39:38 -0000 Folks, Just to avoid confusion as to where to find stuff - might it make sense to put links to the wiki pages and documents in an easily found place (like, say the WG home page)? Miles -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From nobody Tue Oct 28 21:43:20 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A50AC1A6F49 for ; Tue, 28 Oct 2014 21:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.909 X-Spam-Level: *** X-Spam-Status: No, score=3.909 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_16=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFbFyF2uVW_o for ; Tue, 28 Oct 2014 21:43:15 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id A54701A6F5B for ; Tue, 28 Oct 2014 21:43:15 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id 3E6A31C394F; Wed, 29 Oct 2014 13:43:14 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 2FE021A27CF; Wed, 29 Oct 2014 13:43:14 +0900 (JST) From: "Stephen J. Turnbull" To: Hector Santos In-Reply-To: <5450034F.3050703@isdg.net> References: <5436FE09.4050104@sonnection.nl> <20141010041209.2106.qmail@ary.lan> <01PDKQLQAPA200005K@mauve.mrochek.com> <01PDUPKE1KHQ00005L@mauve.mrochek.com> <54494348.4090306@isdg.net> <871tpyieot.fsf@uwakimon.sk.tsukuba.ac.jp> <544A43D4.5070903@isdg.net> <87tx2tgoby.fsf@uwakimon.sk.tsukuba.ac.jp> <544AFEFA.1060506@isdg.net> <036E3CA0799048928F761B1C43905335@fgsr.local> <544BD68B.6030905@dcrocker.net> <544EB20A.2050602@dcrocker.net> <67037945-4C30-43A9-9030-0A7A2A061C15@gmail.com> <544FECF6.70001@isdg.net> <544FFD41.9030408@isdg.net> <5450034F.3050703@isdg.net> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 29 Oct 2014 13:43:14 +0900 Message-ID: <874mun4hb1.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/rDJ8pYKf9PB2dkTWjwXzbCtv6bs Cc: Brett McDowell , dmarc , Dave Crocker , "J. Gomez" Subject: Re: [dmarc-ietf] wiki vs. list? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 04:43:17 -0000 Hector Santos writes: > You (speaking in general) either support a policy concept or you > don't. Thats been the dilemma all these years. If "policy" means that destinations "must" or "should" (in the RFC 2119 sense) *do* what the Author Domain publishes as policy, both as an MLM developer and as a user of the Internet I can't support a "policy concept". Of course, this is what "policy" means in most everyday contexts, so it's easy to get confused. If "policy" means that Author Domains can publish information about their particular circumstances vis-a-vis various threats that exist, associated with recommendations (BCP) for disposition of messages that meet (or fail to meet) various criteria in those particular circumstances, along with discussion of how blindly following rules can hork the whole 'net, of course I'm all for it. > However, I find it hard to understand how the advocates of DMARC > are not pushing for 3rd party solutions. Thats the odd thing about > it. Most advocates of DMARC have no need for 3rd party solutions. They are concentrating on transactional, direct mailflows, and where they need indirect mailflows, it seems that they have little trouble establishing sister domains with appropriate DMARC policies for those exceptional mailflows. AFAIK even the "we know better than DMARC" services like Gmail *reject* when these domains publish "p=reject". The heavy DMARC users whose use of p=reject are causing problems for third parties aren't really experiencing much pain themselves, or at least the concentrated attacks in April were *much* more painful. A few users complain, but the services have plausible deniability and their users' hate for spam to protect them from mass revulsion, let alone revolution. I doubt they consider it their business to develop such solutions, especially since they say they are still under attack, and presumably are experiencing new forms of attack all the time. The third parties who *do* have an interest in "real" solutions didn't have time to develop one in April, let alone persuade the many DMARC participants to implement it. Most MLM users, for example, are quite nontechnical, and have little experience with the issues that the IETF has to grapple with in creating a viable *standard* solution. Nor do we trust, specifically, Yahoo! and AOL to adopt one if it existed. At least at Mailman we have a long history of users suffering from their arbitrary decisions and inflexible policies, and we don't believe that they will adopt a standard solution even if one were created. The Mailman community has little incentive and less optimism for pushing for standardized "third-party solutions". (Not to mention that IETF standardization processes are considered arcane and slow.) Note: Above in referring to "Mailman", I'm reporting the general opinion of the Mailman community. I am personally hopeful, after interacting with technical staff at Yahoo!, that Yahoo! will play along (but I'm sure it will take time). I don't have the same confidence about AOL (no similar interaction), but I suppose that they won't want to be odd man out if Yahoo! participates. (As for IETF standardization, I'm here, OK? :-) And I'm saying those things to the Mailman folks, too. But it's going to take time to convince them. > If the new DMARC advocates and DKIM Policy Marketing was as strong > during SSP/ADSP, the original proof of concept with DKIM, we > probably would of solved this problem long ago and MLM/MLS systems, > including our own MLS product, would be better off without the > radical rewriting hacks suggestions. They're not "suggestions". They're de facto BCP. You need to wrap your head around that fact. No, they're not good. In fact, they suck badly in my opinion, and as you know I've argued against suggestions like "List-Original-Author" that encourage and enable them. But they *are* in wide use and nobody has come up with a better idea we can use *now* -- they are indeed *best* *currently*. Denying that just confuses the heck out of the rest of us. Sincere regards, Steve From nobody Tue Oct 28 23:00:39 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10D971A036A for ; Tue, 28 Oct 2014 23:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llqdVOGL5sS2 for ; Tue, 28 Oct 2014 23:00:25 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 2A56E1A0377 for ; Tue, 28 Oct 2014 23:00:20 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id 72A251C39AA; Wed, 29 Oct 2014 15:00:19 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 678571A27CF; Wed, 29 Oct 2014 15:00:19 +0900 (JST) From: "Stephen J. Turnbull" To: Miles Fidelman In-Reply-To: <545036E7.7040201@meetinghouse.net> References: <544A681E.1000500@meetinghouse.net> <2A32DB76-5C0F-4CA5-8E42-3A70E510B2BC@kitterman.com> <87d29c4khv.fsf@uwakimon.sk.tsukuba.ac.jp> <7262926.bSZJ7Csryx@scott-latitude-e6320> <545036E7.7040201@meetinghouse.net> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 29 Oct 2014 15:00:19 +0900 Message-ID: <8738a74dqk.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/XrrGQaQORa1LScpSUsn5keMTmU8 Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Additional List-foo Header Field To Help Mitigate Mailing List Damage X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 06:00:27 -0000 Miles Fidelman writes: > > My personal want is very limited. When I click on "reply to > > author" in Kmail, I want it to go to the person that wrote the > > mail (Kmail also has reply to list, which is very useful for me). > > If there's no interest in standardizing, then I'll just make sure > > X-Original-Sender which is being used by multiple parties already > > is supported. I still think picking a common header field name > > to use is better than not, but meh. > > Stephen - thanks for your comments - obviously it's not as > straightforward as I might think. > > Then again, Scott makes a pretty good point. Yes, he does. It's very similar to the one I made to Hector just now about From-munging being a de facto BCP (best current practice). But I strongly believe that we should not make either be a de jure normative RFC. And I think it's best to leave these de facto BCPs informal, for private agreement among participating parties (that latter is very much IMHO YMMV, I understand that it will be annoyingly unreliable and tedious in Scott's use case). That's quite aside from the consideration that the IETF process will cough up a hairball on any proposal that involves "reinterpreting" the semantics of the From field. :-) Regards, Steve From nobody Tue Oct 28 23:14:29 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9AC01A036D for ; Tue, 28 Oct 2014 23:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z_r-CndFXRDy for ; Tue, 28 Oct 2014 23:14:22 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6124E1A0084 for ; Tue, 28 Oct 2014 23:14:22 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id q5so730990wiv.4 for ; Tue, 28 Oct 2014 23:14:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VrAyEetVE2cMzyATfC3mi67Wujavn8Y5fGypfgbdGuw=; b=opjjrvwMt1UWZb4usgOG9P85w+9F3r4ATqRVy4bzp56BmUDDsci7+RdeVT3XjhFIs3 4vDML7SA9JOUcxiFLxBDIXVJftJLiYmf1LTztu3aJF0kXVl7vg4//XZ9m+mMaRO8N8Br qD3rUguJe84uNy1FTIO/Nqg18sOmYyVmDAcoylsAp3UEaZOusNZDHpiDVPFYd+AGnwM3 hWb2Lccu5bbi5QgmiQpe7uxX7R2TEXJ3rmnl8Ti1LJNLyM5jU6Stg2vJhFXWGjUIR1KV niOWttsbtNOr7PPRRTPiCRdhtwYkR+qkpZVK2mSFeI4encwQn0bqr8al7M8ZkoaqQ150 jOGg== MIME-Version: 1.0 X-Received: by 10.194.3.2 with SMTP id 2mr9894860wjy.89.1414563260946; Tue, 28 Oct 2014 23:14:20 -0700 (PDT) Received: by 10.27.76.134 with HTTP; Tue, 28 Oct 2014 23:14:20 -0700 (PDT) In-Reply-To: <874mun4hb1.fsf@uwakimon.sk.tsukuba.ac.jp> References: <5436FE09.4050104@sonnection.nl> <20141010041209.2106.qmail@ary.lan> <01PDKQLQAPA200005K@mauve.mrochek.com> <01PDUPKE1KHQ00005L@mauve.mrochek.com> <54494348.4090306@isdg.net> <871tpyieot.fsf@uwakimon.sk.tsukuba.ac.jp> <544A43D4.5070903@isdg.net> <87tx2tgoby.fsf@uwakimon.sk.tsukuba.ac.jp> <544AFEFA.1060506@isdg.net> <036E3CA0799048928F761B1C43905335@fgsr.local> <544BD68B.6030905@dcrocker.net> <544EB20A.2050602@dcrocker.net> <67037945-4C30-43A9-9030-0A7A2A061C15@gmail.com> <544FECF6.70001@isdg.net> <544FFD41.9030408@isdg.net> <5450034F.3050703@isdg.net> <874mun4hb1.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Tue, 28 Oct 2014 23:14:20 -0700 Message-ID: From: "Murray S. Kucherawy" To: "Stephen J. Turnbull" Content-Type: multipart/alternative; boundary=047d7b343c18ae5e68050689ac83 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/5hKdn_a_Yvr5NV7bx-llsc5vVTo Cc: Brett McDowell , dmarc , Hector Santos , Dave Crocker , "J. Gomez" Subject: Re: [dmarc-ietf] wiki vs. list? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 06:14:26 -0000 --047d7b343c18ae5e68050689ac83 Content-Type: text/plain; charset=UTF-8 On Tue, Oct 28, 2014 at 9:43 PM, Stephen J. Turnbull wrote: > Hector Santos writes: > > > You (speaking in general) either support a policy concept or you > > don't. Thats been the dilemma all these years. > Stephen's summary of the state of things matches my understanding pretty much exactly. The "dilemma" has nothing to do with not supporting policy. It has everything to do with the fact that the policy mechanisms we've come up with so far don't work; they are too complicated, they're easily beaten, they don't scale to large ESP size, they only apply to some kinds of mail, they don't provide enough bang for the buck, or some combination of those. It's untrue that we never gave them a chance. ADSP and ATPS, for example, became RFCs and got released as part of commercial and open source products because we thought they might be worth trying out. For ATPS, there was absolutely no interest; for ADSP, people tried it and didn't like what they saw. If there were other things that were tried that actually stood a chance of working, I've yet to hear about them. As far as I'm concerned, the "policy concept" that will succeed is something that meets most or all of those requirements. But I would rather release email authentication protocols without a third-party capability, or even without a policy capability at all, than saddle it with some kind of broken extension that's got some or all of these flaws. That's what we did with DKIM, and in retrospect, it was certainly the right thing to do. Moreover, it'll take some pretty strong arguments, or actual data would be even better, to form consensus around such a thing. Hopefully we've now said enough on this thread about policy and third-party stuff, especially since it has nothing at all to do with reaching our first milestone. -MSK --047d7b343c18ae5e68050689ac83 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Oct 28, 2014 at 9:43 PM, Stephen J. Turnbull <st= ephen@xemacs.org> wrote:
Hector= Santos writes:

=C2=A0> You (speaking in general) either support a policy concept or you=
=C2=A0> don't.=C2=A0 Thats been the dilemma all these years.

Stephen's summary of the state of t= hings matches my understanding pretty much exactly.

The &= quot;dilemma" has nothing to do with not supporting policy.=C2=A0 It h= as everything to do with the fact that the policy mechanisms we've come= up with so far don't work; they are too complicated, they're easil= y beaten, they don't scale to large ESP size, they only apply to some k= inds of mail, they don't provide enough bang for the buck, or some comb= ination of those.

It's untrue that we never gave them= a chance.=C2=A0 ADSP and ATPS, for example, became RFCs and got released a= s part of commercial and open source products because we thought they might= be worth trying out.=C2=A0 For ATPS, there was absolutely no interest; for= ADSP, people tried it and didn't like what they saw.=C2=A0 If there we= re other things that were tried that actually stood a chance of working, I&= #39;ve yet to hear about them.

As far as I'm concerned, th= e "policy concept" that will succeed is something that meets most= or all of those requirements.=C2=A0 But I would rather release email authe= ntication protocols without a third-party capability, or even without a pol= icy capability at all, than saddle it with some kind of broken extension th= at's got some or all of these flaws.=C2=A0 That's what we did with = DKIM, and in retrospect, it was certainly the right thing to do.=C2=A0 More= over, it'll take some pretty strong arguments, or actual data would be = even better, to form consensus around such a thing.

Hopefully we've now said enough on this thr= ead about policy and third-party stuff, especially since it has nothing at = all to do with reaching our first milestone.

-MSK
--047d7b343c18ae5e68050689ac83-- From nobody Wed Oct 29 11:56:39 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0201A88A9 for ; Wed, 29 Oct 2014 11:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQzszDEqwmuY for ; Wed, 29 Oct 2014 11:56:30 -0700 (PDT) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD1FD1A88AD for ; Wed, 29 Oct 2014 11:56:30 -0700 (PDT) Received: by mail-ig0-f170.google.com with SMTP id h15so1755190igd.1 for ; Wed, 29 Oct 2014 11:56:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=zZvFCmFJJAJaa2h6TM3GFKew5wWcvkZAsuTgVlaQaBg=; b=NRF+g76+Vj2xIYbgLAPMM6RC7ONe1qlM6tlfc5/d84oRmwJ43CIBvZABY1olU1o+OG z1oAYIXiGL3eZjbiUhxgPdzTrkUHjPlDA00jboQoeqMD8Vh8RZtPfPA/wI27frha/D2H gHpU4DTtuOBiqZhtWcdSSu6En95+CmT//YlPrhO5pEoRU+zLAHPcefpoX8K2mD5z1bcY OqXRuh8dJC/IUMpIgUx5blKy/AKbXJU6pIdZ4JsJDD/oeCE+7k2kWVy/IImxxhEwobfN U4QpuEpi5MGSgpoq+Su9WyhhhuvP2i8L/gEqFzv10K249IkIXDQKrhfuN5OZbTJKplMa i4kw== X-Received: by 10.107.163.142 with SMTP id m136mr13741624ioe.32.1414608990115; Wed, 29 Oct 2014 11:56:30 -0700 (PDT) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id qa7sm1886449igb.1.2014.10.29.11.56.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 Oct 2014 11:56:29 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_9CE620BE-B2E4-4D84-8CD3-4B4648A5F4AE" From: Douglas Otis In-Reply-To: Date: Wed, 29 Oct 2014 11:56:29 -0700 Message-Id: <7A6AB270-089F-4E17-BC86-1A6E55F900FE@gmail.com> References: <5436FE09.4050104@sonnection.nl> <20141010041209.2106.qmail@ary.lan> <01PDKQLQAPA200005K@mauve.mrochek.com> <01PDUPKE1KHQ00005L@mauve.mrochek.com> <54494348.4090306@isdg.net> <871tpyieot.fsf@uwakimon.sk.tsukuba.ac.jp> <544A43D4.5070903@isdg.net> <87tx2tgoby.fsf@uwakimon.sk.tsukuba.ac.jp> <544AFEFA.1060506@isdg.net> <036E3CA0799048928F761B1C43905335@fgsr.local> <544BD68B.6030905@dcrocker.net> <544EB20A.2050602@dcrocker.net> <67037945-4C30-43A9-9030-0A7A2A061C15@gmail.com> <544FECF6.70001@isdg.net> <544FFD41.9030408@isdg.net> <5450034F.3050703@isdg.net> <874mun4hb1.fsf@uwakimon.sk.tsukuba.ac.jp> To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/LJ0jDfjVym1hgSped6lV7JzLZWc Cc: Douglas Otis , Brett McDowell , dmarc , Dave Crocker , "Stephen J. Turnbull" , Hector Santos , "J. Gomez" Subject: Re: [dmarc-ietf] wiki vs. list? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 18:56:37 -0000 --Apple-Mail=_9CE620BE-B2E4-4D84-8CD3-4B4648A5F4AE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 28, 2014, at 11:14 PM, Murray S. Kucherawy = wrote: > On Tue, Oct 28, 2014 at 9:43 PM, Stephen J. Turnbull = wrote: > Hector Santos writes: >=20 > > You (speaking in general) either support a policy concept or you > > don't. Thats been the dilemma all these years. >=20 > Stephen's summary of the state of things matches my understanding = pretty much exactly. >=20 > The "dilemma" has nothing to do with not supporting policy. It has = everything to do with the fact that the policy mechanisms we've come up = with so far don't work; they are too complicated, they're easily beaten, = they don't scale to large ESP size, they only apply to some kinds of = mail, they don't provide enough bang for the buck, or some combination = of those. >=20 > It's untrue that we never gave them a chance. ADSP and ATPS, for = example, became RFCs and got released as part of commercial and open = source products because we thought they might be worth trying out. For = ATPS, there was absolutely no interest; for ADSP, people tried it and = didn't like what they saw. If there were other things that were tried = that actually stood a chance of working, I've yet to hear about them. >=20 > As far as I'm concerned, the "policy concept" that will succeed is = something that meets most or all of those requirements. But I would = rather release email authentication protocols without a third-party = capability, or even without a policy capability at all, than saddle it = with some kind of broken extension that's got some or all of these = flaws. That's what we did with DKIM, and in retrospect, it was = certainly the right thing to do. Moreover, it'll take some pretty = strong arguments, or actual data would be even better, to form consensus = around such a thing. >=20 > Hopefully we've now said enough on this thread about policy and = third-party stuff, especially since it has nothing at all to do with = reaching our first milestone. Dear Murray, May I add a minor point, ATPS introduced optional authorization label = encodings signaled with a "special" unsupported third-party DKIM = signature. It seems IESG suggested there might be DoS concerns and that = adding signaling via a "special" third-party DKIM signature would be = less prone although this ignores additional namespace diversity that = could be created by DKIM selectors which might actually increase DoS = concerns. TPA-Label instead solved this by adding a simple flag in the = DMARC record. Another advantage claimed for ATPS was these "special" third-party = signatures permitted authorization labels to also be simple strings = rather than a deterministic hash. Unfortunately, this change induced by = IESG then required ALL third-party services introducing an unsupported = DKIM signature lacked any way to convey the authorization label encoding = schemes used by what is now called DMARC domains. Imagine the dilemma = this would cause those operating services such as mailing-lists being = forced to remain current of all unpublished practices employed by the = domains of their users. This added encoding option signaled using a = special DKIM signature prevented any reliant third-party signature = adoption, although it was ostensibly done to make this protocol easier = to implement by allowing the option of plain labels. This too can now = be signaled using the DMARC record directly. As such, it should not = have been surprising there was no interest in ATPS, nor, IMHO, should = there have been. That said, you should be commended for having taken = this scheme as far as you did. For all your hard work, I truly thank = you. Regards, Douglas Otis --Apple-Mail=_9CE620BE-B2E4-4D84-8CD3-4B4648A5F4AE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Oct 28, 2014, at 11:14 PM, Murray = S. Kucherawy <superuser@gmail.com> = wrote:

On Tue, Oct 28, 2014 at 9:43 PM, Stephen = J. Turnbull <stephen@xemacs.org> wrote:
Hector Santos writes:

 > You (speaking in general) either support a policy concept or = you
 > don't.  Thats been the dilemma all these = years.

Stephen's summary of = the state of things matches my understanding pretty much = exactly.

The "dilemma" has nothing to do with not = supporting policy.  It has everything to do with the fact that the = policy mechanisms we've come up with so far don't work; they are too = complicated, they're easily beaten, they don't scale to large ESP size, = they only apply to some kinds of mail, they don't provide enough bang = for the buck, or some combination of those.

It's = untrue that we never gave them a chance.  ADSP and ATPS, for = example, became RFCs and got released as part of commercial and open = source products because we thought they might be worth trying out.  = For ATPS, there was absolutely no interest; for ADSP, people tried it = and didn't like what they saw.  If there were other things that = were tried that actually stood a chance of working, I've yet to hear = about them.

As far as I'm concerned, the "policy concept" = that will succeed is something that meets most or all of those = requirements.  But I would rather release email authentication = protocols without a third-party capability, or even without a policy = capability at all, than saddle it with some kind of broken extension = that's got some or all of these flaws.  That's what we did with = DKIM, and in retrospect, it was certainly the right thing to do.  = Moreover, it'll take some pretty strong arguments, or actual data would = be even better, to form consensus around such a thing.

Hopefully we've now said enough on = this thread about policy and third-party stuff, especially since it has = nothing at all to do with reaching our first = milestone.

Dear = Murray,

May I add a minor point, ATPS = introduced optional authorization label encodings signaled with a = "special" unsupported third-party DKIM signature.  It seems IESG = suggested there might be DoS concerns and that adding signaling via a = "special" third-party DKIM signature would be less prone although this = ignores additional namespace diversity that could be created by DKIM = selectors which might actually increase DoS concerns. TPA-Label instead = solved this by adding a simple flag in the DMARC = record.

Another advantage claimed for ATPS was = these "special" third-party signatures permitted authorization labels to = also be simple strings rather than a deterministic hash. Unfortunately, = this change induced by IESG then required ALL third-party services = introducing an unsupported DKIM signature lacked any way to convey the = authorization label encoding schemes used by what is now called DMARC = domains.  Imagine the dilemma this would cause those operating = services such as mailing-lists being forced to remain current of all = unpublished practices employed by the domains of their users.   = This added encoding option signaled using a special DKIM signature = prevented any reliant third-party signature adoption, although it was = ostensibly done to make this protocol easier to implement by allowing = the option of plain labels.  This too can now be signaled using the = DMARC record directly.  As such, it should not have been surprising = there was no interest in ATPS, nor, IMHO, should there have been. =  That said, you should be commended for having taken this scheme as = far as you did.  For all your hard work, I truly thank = you.

Regards,
Douglas = Otis





= = --Apple-Mail=_9CE620BE-B2E4-4D84-8CD3-4B4648A5F4AE-- From nobody Wed Oct 29 12:16:08 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A218A1A8907 for ; Wed, 29 Oct 2014 12:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78DEBjRhPNct for ; Wed, 29 Oct 2014 12:16:03 -0700 (PDT) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CBA61A88CE for ; Wed, 29 Oct 2014 12:16:03 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id m15so2616479wgh.41 for ; Wed, 29 Oct 2014 12:16:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lka/Y2yGQGWPD0F71rIw2q+oocqeL5jXHwnJzRzyXgM=; b=mTvNOZbQa/I20YiLrscy8DfetOHOCPYnYha2Ouw3/rz5gF/B6ax8Kc7grLtDzGj5hN /FHbj+qQfaF6w1/HWn7ZFKzyk3o7IGnBZYYON/3auzpPA/Ri+ixYsrFHzkk295MDKWOp K8iesjphj+uvfdvfIJ/PxyxLzGF3ASnJ/P2sgO2L3sXpY6CFLq5LSyddhq8vmHXef2Ia qMFSUDGgWCnKBqz9V5ISb8zg/X66Xgh2pSUCvF6pNVKtnyyZdhzaPOsrl4ew6LoXezaT uOCPqISqOxEQnf/9A3sqSIMnBv/n2pb5vY7sesPpKu5Jpi8o97X082LdPYY4wrhl5sfo CWzw== MIME-Version: 1.0 X-Received: by 10.194.157.137 with SMTP id wm9mr15058795wjb.5.1414610161817; Wed, 29 Oct 2014 12:16:01 -0700 (PDT) Received: by 10.27.76.134 with HTTP; Wed, 29 Oct 2014 12:16:01 -0700 (PDT) In-Reply-To: <7A6AB270-089F-4E17-BC86-1A6E55F900FE@gmail.com> References: <5436FE09.4050104@sonnection.nl> <20141010041209.2106.qmail@ary.lan> <01PDKQLQAPA200005K@mauve.mrochek.com> <01PDUPKE1KHQ00005L@mauve.mrochek.com> <54494348.4090306@isdg.net> <871tpyieot.fsf@uwakimon.sk.tsukuba.ac.jp> <544A43D4.5070903@isdg.net> <87tx2tgoby.fsf@uwakimon.sk.tsukuba.ac.jp> <544AFEFA.1060506@isdg.net> <036E3CA0799048928F761B1C43905335@fgsr.local> <544BD68B.6030905@dcrocker.net> <544EB20A.2050602@dcrocker.net> <67037945-4C30-43A9-9030-0A7A2A061C15@gmail.com> <544FECF6.70001@isdg.net> <544FFD41.9030408@isdg.net> <5450034F.3050703@isdg.net> <874mun4hb1.fsf@uwakimon.sk.tsukuba.ac.jp> <7A6AB270-089F-4E17-BC86-1A6E55F900FE@gmail.com> Date: Wed, 29 Oct 2014 12:16:01 -0700 Message-ID: From: "Murray S. Kucherawy" To: Douglas Otis Content-Type: multipart/alternative; boundary=089e013c6b6830de8b0506949867 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/NQfVOpGDea4f-X2-Hwt9mdSKxyc Cc: dmarc Subject: Re: [dmarc-ietf] wiki vs. list? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 19:16:05 -0000 --089e013c6b6830de8b0506949867 Content-Type: text/plain; charset=UTF-8 On Wed, Oct 29, 2014 at 11:56 AM, Douglas Otis wrote: > May I add a minor point, ATPS introduced optional authorization label > encodings signaled with a "special" unsupported third-party DKIM > signature. > [...] > As such, it should not have been surprising there was no interest in ATPS, > nor, IMHO, should there have been. That said, you should be commended for > having taken this scheme as far as you did. For all your hard work, I > truly thank you. > I appreciate the recognition. As for the rest, you've made these claims before. I still don't buy it. If you were right, there would have been some feedback somewhere from the community (other than you, I mean) explaining why it was an unacceptable solution and perhaps making suggestions about improving it to make it more palatable. There has not been a single message of this nature since. Instead, I believe it's simply the case that nobody's looked at it. We published it as an Experimental RFC and made it available in open source for free, and announced its availability in a few key places (MAAWG, for example). According to our automated feedback, exactly two operators tried it (one of them me, the other a hobbyist). There has been no active response of any kind in almost three years. I take this to indicate that, prior to DMARC, third-party stuff in general has simply not been enough of a pain point for anyone to care. DMARC may be changing that perspective finally. It remains to be seen where consensus will take us, and again, whether the email community at large will be interested. -MSK --089e013c6b6830de8b0506949867 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Oct 29, 2014 at 11:56 AM, Douglas Otis <dou= g.mtview@gmail.com> wrote:
May I add a minor point, ATPS introduced = optional authorization label encodings signaled with a "special" = unsupported third-party DKIM signature.=C2=A0
[...]
As such, it= should not have been surprising there was no interest in ATPS, nor, IMHO, = should there have been.=C2=A0 That said, you should be commended for having= taken this scheme as far as you did.=C2=A0 For all your hard work, I truly= thank you.

I appreciate the re= cognition.

As for the rest, you've made these claims = before.=C2=A0 I still don't buy it.=C2=A0 If you were right, there woul= d have been some feedback somewhere from the community (other than you, I m= ean) explaining why it was an unacceptable solution and perhaps making sugg= estions about improving it to make it more palatable.=C2=A0 There has not b= een a single message of this nature since.

Instead, I believe it'= ;s simply the case that nobody's looked at it.=C2=A0 We published it as= an Experimental RFC and made it available in open source for free, and ann= ounced its availability in a few key places (MAAWG, for example).=C2=A0 Acc= ording to our automated feedback, exactly two operators tried it (one of th= em me, the other a hobbyist).=C2=A0 There has been no active response of an= y kind in almost three years.=C2=A0 I take this to indicate that, prior to = DMARC, third-party stuff in general has simply not been enough of a pain po= int for anyone to care.

DMARC may be changing that perspe= ctive finally.=C2=A0 It remains to be seen where consensus will take us, an= d again, whether the email community at large will be interested.

-MSK
--089e013c6b6830de8b0506949867-- From nobody Wed Oct 29 13:37:13 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6BCA1A8928 for ; Wed, 29 Oct 2014 13:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2DvPJUK231l for ; Wed, 29 Oct 2014 13:37:09 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 137051A88D7 for ; Wed, 29 Oct 2014 13:37:08 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id n12so2757316wgh.30 for ; Wed, 29 Oct 2014 13:37:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=SdM39ojdUNL2Bt7omaAqmcGSIPShhwcm9kWHaex1CDI=; b=OzLlL17rbZcb9ZH/3BCAf+pPZz6dJIQpHUAiG0C1aTobdwLnuAI5CEM3w7LQ8SG3vl TCAoKTMsQk4ivdq/XBHdjd+hjeAjtkd0MDN8uaKFt60f8oQM5I+A3jlVvg/AXzuzNnVW 9dy6KYmhZgRZB8Urxkq8mZ3jr7mHaoq6Apq3Q6vBZ4rZhs27VGCjgQRJxxU6W9mZ8Y71 g0LVtH5YQtIDvRjkTYSe7pxdeptwEn9R/vnT0in6FH9SNK3xZmalgfDOxNq2j23QzLHw FaYVIJb8Gt9gDXylmQOPPvi2r8S0z57gk4aqkbnkDuCwAsliXreSR5hRJl+ApV5OPb5W K/Ow== MIME-Version: 1.0 X-Received: by 10.194.91.176 with SMTP id cf16mr15095832wjb.60.1414615027662; Wed, 29 Oct 2014 13:37:07 -0700 (PDT) Received: by 10.27.76.134 with HTTP; Wed, 29 Oct 2014 13:37:07 -0700 (PDT) In-Reply-To: References: Date: Wed, 29 Oct 2014 13:37:07 -0700 Message-ID: From: "Murray S. Kucherawy" To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=047d7bfcef2637c6c6050695ba26 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/KPLpd-4XojzUu06JVmXxRZJHuyA Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base revision submitted X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 20:37:11 -0000 --047d7bfcef2637c6c6050695ba26 Content-Type: text/plain; charset=UTF-8 On Tue, Oct 28, 2014 at 3:44 PM, Murray S. Kucherawy wrote: > Since we're past the I-D deadline, the ISE or Pete will have to approve > its addition to the datatracker, so it will magically appear at some point > soon, and then move forward in the publication process. > It's now available in the datatracker: https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/ -MSK --047d7bfcef2637c6c6050695ba26 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Oct 28, 2014 at 3:44 PM, Murray S. Kucherawy <s= uperuser@gmail.com> wrote:
Since we're past the I-D deadline, the ISE or = Pete will have to approve its addition to the datatracker, so it will magic= ally appear at some point soon, and then move forward in the publication pr= ocess.

-MSK
--047d7bfcef2637c6c6050695ba26-- From nobody Wed Oct 29 15:57:13 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54F151AC7E7 for ; Wed, 29 Oct 2014 15:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.301 X-Spam-Level: X-Spam-Status: No, score=-99.301 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6BvXf58_6fi for ; Wed, 29 Oct 2014 15:57:01 -0700 (PDT) Received: from secure.winserver.com (groups.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 9A52D1ACCED for ; Wed, 29 Oct 2014 15:56:57 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4540; t=1414623415; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=ZmnW7bW42REv1RlMA5cMI7GdXFw=; b=wccYGQNTa0d7sFjtPF7K WgJsBvwAnaGl6Kz5d87LewrpAr49lnoLne/lWJcDkUZ0VMwBu9sakTQIAQJGhJOI /NqLlwR00Y0un5qrMbrGAFWidGzJN1MzzdwAsa32Pz46ZTQaCAX68bDPSBw7l7Ah vJbTS+kuRZXZafDQYkfIp+I= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 29 Oct 2014 17:56:55 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1218496638.419.3108; Wed, 29 Oct 2014 17:56:54 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4540; t=1414622995; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=6jhBFgL tNl3mx/TEmOVgggxjTUcfmhyOywLErtrAYb8=; b=Pfo+04oIyS8Fb2ZRygpg46B YPMM3JvhpzKfFtzrUI3TrSI0e5TNLiO2CmucqaGivZo40WdQ5CaHcX8de49Y+AJr txPpR4Q2Bcb7iuA5JHm1lEMR0jq/d0m205ryhWQKDtrToApVNlBq99A6zOBe9Yby 9wiYviAZUdHh3igaPUuI= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 29 Oct 2014 18:49:55 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4105874985.9.7792; Wed, 29 Oct 2014 18:49:54 -0400 Message-ID: <545170B6.1020609@isdg.net> Date: Wed, 29 Oct 2014 18:56:54 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" , Douglas Otis References: <5436FE09.4050104@sonnection.nl> <01PDKQLQAPA200005K@mauve.mrochek.com> <01PDUPKE1KHQ00005L@mauve.mrochek.com> <54494348.4090306@isdg.net> <871tpyieot.fsf@uwakimon.sk.tsukuba.ac.jp> <544A43D4.5070903@isdg.net> <87tx2tgoby.fsf@uwakimon.sk.tsukuba.ac.jp> <544AFEFA.1060506@isdg.net> <036E3CA0799048928F761B1C43905335@fgsr.local> <544BD68B.6030905@dcrocker.net> <544EB20A.2050602@dcrocker.net> <67037945-4C30-43A9-9030-0A7A2A061C15@gmail.com> <544FECF6.70001@isdg.net> <544FFD41.9030408@isdg.net> <5450034F.3050703@isdg.net> <874mun4hb1.fsf@uwakimon.sk.tsukuba.ac.jp> <7A6AB270-089F-4E17-BC86-1A6E55F900FE@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/6h6Sx5MuDR81gSNh2m16Rrx8MHg Cc: dmarc Subject: Re: [dmarc-ietf] wiki vs. list? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 22:57:09 -0000 On 10/29/2014 3:16 PM, Murray S. Kucherawy wrote: > On Wed, Oct 29, 2014 at 11:56 AM, Douglas Otis > wrote: > >> May I add a minor point, ATPS introduced optional authorization label >> encodings signaled with a "special" unsupported third-party DKIM >> signature. >> [...] >> As such, it should not have been surprising there was no interest in ATPS, >> nor, IMHO, should there have been. That said, you should be commended for >> having taken this scheme as far as you did. For all your hard work, I >> truly thank you. >> > > I appreciate the recognition. > > As for the rest, you've made these claims before. I still don't buy it. > If you were right, there would have been some feedback somewhere from the > community (other than you, I mean) explaining why it was an unacceptable > solution and perhaps making suggestions about improving it to make it more > palatable. There has not been a single message of this nature since. This is not a fair assessment, especially among this group. > Instead, I believe it's simply the case that nobody's looked at it. We > published it as an Experimental RFC and made it available in open source > for free, and announced its availability in a few key places (MAAWG, for > example). According to our automated feedback, exactly two operators tried > it (one of them me, the other a hobbyist). You always forget our commercial product and the few thousands of its operators, and also the interest I recorded and shown via the ADSP/ATPS wizards. All that is never repeated nor acknowledged by you. > There has been no active > response of any kind in almost three years. I take this to indicate that, > prior to DMARC, third-party stuff in general has simply not been enough of > a pain point for anyone to care. This is a contradiction. DMARC is policy. You choose to limit it based on the ADSP rough experiences we had regarding 3rd party in a TRUST ONLY group and you learned not to add it. You admitted as much. You did do ATPS because of the interest in the DKIM-WG but you also said it was not a GOOD IDEA following the doctrine of a few others so no one followed you. You can't do that. Levine did the same with ADSP and it also had a hard time. DMARC would had also had a hard time if introduced in DKIM-WG. It was the same thing and problems as ADSP. ADSP was pushed out to be replaced for DMARC. That doesn't make sense -- to say ADSP was a failed experienced/experiment and DMARC is not? Whats the difference? You got to champion what you produce. It doesn't work any other way. You championed DMARC. You took the same technology and added reporting to it, something that was pushed back during SSP/ADSP. DSAP offered a little reporting. People, ADMINS, like reporting. So that was the entry point to what we have. But its the same problem was ADSP. Nothing was solved with DMARC. > DMARC may be changing that perspective finally. It remains to be seen > where consensus will take us, and again, whether the email community at > large will be interested. DMARC, like ADSP is a contradiction in proper total mail integration. They were both half-baked, incomplete solutions and anyone can see it was going to be a problem from the git-go. That is why it has been a thorn on a side for a long time. Its not a matter of not wanting 3rd party solutions, it needs to be PART of the PROTOCOL to complete or fill all holes in it. In other word, you didn't give anyone to chance to adjust to it because you failed to believe in it. If you don't see it, I can understand it. But people did it and in this group, a different set of folks from the DMARC arena, it hards to understand why they don't want the DMARC thorn removed by provided 3rd party OPTIONS. Make it optional at least. You don't even want to do that. Its odd to write something that you don't believe in. Others see that and won't give it a chance. I understand you also had pressure from the trust groups to not support it. But from a product standpoint, you have to provide the OPTIONS to do offer this. You don't even want to do that. I still don't buy the arguments against it because it is the BEST solution we have available and definitely the most simplistic of everything being proposed especially the rewriting hacks, which for sure is not going to be widely acceptable and also borders on ethical engineering and intentional damages. It could be appealed material for sure. -- HLS From nobody Wed Oct 29 16:20:45 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5901ACD01 for ; Wed, 29 Oct 2014 16:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.137 X-Spam-Level: X-Spam-Status: No, score=-101.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWqeOfsDOyOx for ; Wed, 29 Oct 2014 16:20:37 -0700 (PDT) Received: from secure.winserver.com (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1941ACCFB for ; Wed, 29 Oct 2014 16:20:37 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2181; t=1414624836; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=GRFIiLdvN698E6AmQ9wYhdW5nek=; b=OEzsxrdgEu4Gl1EeKNPp M9H7BBNxga0HUPiDWDG4XgOiBjekTRCvryhmB0HGK+D4yoMPsymHYUX5u6EsAyJG 7wGg5wfQzZYTYW9aR+5ddKp0GVevHfFCWICuScKkml+slbjkpFZVVJ5GcNgGJeAp 0xWiqZrr6ewBMtrQKEegox4= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 29 Oct 2014 18:20:36 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1219916809.419.3176; Wed, 29 Oct 2014 18:20:34 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2181; t=1414624417; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=gp/i8Fl kWl/JtGlzP8qvcaEzFEFPOwYIBCiq8RK4MkU=; b=VmSH/yJnx+LzA6XGMhOJV/1 o7hmSVx2OIlLVoc8VwLbFh9Xbrj5GK53gDKdjAfOYaO2yFmadGbgwiX64FW67ZiI sHp7iwUYhlYxEeDqs1onDnKsj1sV/TDYV/VdvBqEA14rxpdME7Qio99lX8yYK+Tr ZyPQiiznbDWcTNE9oKqk= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 29 Oct 2014 19:13:37 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4107296454.9.3184; Wed, 29 Oct 2014 19:13:35 -0400 Message-ID: <54517643.80105@isdg.net> Date: Wed, 29 Oct 2014 19:20:35 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Miles Fidelman References: <5436FE09.4050104@sonnection.nl> <20141010041209.2106.qmail@ary.lan> <01PDKQLQAPA200005K@mauve.mrochek.com> <01PDUPKE1KHQ00005L@mauve.mrochek.com> <54494348.4090306@isdg.net> <871tpyieot.fsf@uwakimon.sk.tsukuba.ac.jp> <544A43D4.5070903@isdg.net> <87tx2tgoby.fsf@uwakimon.sk.tsukuba.ac.jp> <544AFEFA.1060506@isdg.net> <036E3CA0799048928F761B1C43905335@fgsr.local> <544BD68B.6030905@dcrocker.net> <544EB20A.2050602@dcrocker.net> <67037945-4C30-43A9-9030-0A7A2A061C15@gmail.com> <544FECF6.70001@isdg.net> <5450039B.5010504@meetinghouse.net> In-Reply-To: <5450039B.5010504@meetinghouse.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/A-w2fihOaACk3NxYDfbzvP8k2PQ Cc: dmarc Subject: Re: [dmarc-ietf] wiki vs. list? -- please update subject lines X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 23:20:39 -0000 On 10/28/2014 4:59 PM, Miles Fidelman wrote: > Can we please start using meaningful subject lines. We're now > discussing about 6 different topics under "wiki vs. list" - none of > which have to do with "wiki vs. list." > > Miles Fidelman When you generalize the problem for any "indirect flow" or "list system" it was long understood and documented in RFC5016 by defining two terms, first party and third party signatures. https://tools.ietf.org/html/rfc5016#section-2 o First Party Signature: a first party signature is a valid signature where the signing identity (the d= tag or the more specific identity i= tag) matches the first party address. "Matches" in this context is defined in [RFC4871]. o Third Party Signature: a third party signature is a valid signature that does not qualify as a first party signature. Note that a DKIM third party signature is not required to correspond to a header field address such as the contents of Sender or List-Id, etc. In other words, when it comes to "INDIRECT FLOWS" at the end of day, we are talking about software detecting the difference between two identities: From: user@author-domain DKIM-Signature: d=signer-domain where the author-domain identity (ADID) either matches or is different from the signer domain identity (SDID). In other words, INDIRECT FLOWS are 3rd party signers: ADID != SDID The solution is to make the AUTHORIZED ASSOCIATION between the ADID and SDID. It really doesn't matter what "indirect flow" is out there, at the end of the day, its about the two parameters not matching and that is what the SOFTWARE will see. The question is what do we teach the SOFTWARE to do about it. This GROUP wants to MUNGE the ADID the bypass the DMARC security. I say that is a TERRIBLE IDEA but I understand how some are very passionate about DMARC interfering in some of their users participation in their operations. If they are going to rewrite, then at the very least we MUST make 3rd party protocol options and algorithms available as well to ALL implementators as part of the DMARC protocol to complete the total picture. -- HLS From nobody Wed Oct 29 19:32:47 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE461ACFE3 for ; Wed, 29 Oct 2014 19:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.918 X-Spam-Level: X-Spam-Status: No, score=-0.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.994, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vt3trYbdDUCX for ; Wed, 29 Oct 2014 19:32:44 -0700 (PDT) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9341ACFDD for ; Wed, 29 Oct 2014 19:32:43 -0700 (PDT) Received: from [10.0.1.4] (97-82-216-27.dhcp.hckr.nc.charter.com [97.82.216.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id 5778DCB46 for ; Wed, 29 Oct 2014 22:32:42 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Tim Draegen In-Reply-To: <54517643.80105@isdg.net> Date: Wed, 29 Oct 2014 22:32:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <891E5CFA-68D8-4A0C-B615-484A3FDE3A57@eudaemon.net> References: <5436FE09.4050104@sonnection.nl> <20141010041209.2106.qmail@ary.lan> <01PDKQLQAPA200005K@mauve.mrochek.com> <01PDUPKE1KHQ00005L@mauve.mrochek.com> <54494348.4090306@isdg.net> <871tpyieot.fsf@uwakimon.sk.tsukuba.ac.jp> <544A43D4.5070903@isdg.net> <87tx2tgoby.fsf@uwakimon.sk.tsukuba.ac.jp> <544AFEFA.1060506@isdg.net> <036E3CA0799048928F761B1C43905335@fgsr.local> <544BD68B.6030905@dcrocker.net> <544EB20A.2050602@dcrocker.net> <67037945-4C30-43A9-9030-0A7A2A061C15@gmail.com> <544FECF6.70001@isdg.net> <5450039B.5010504@meetinghouse.net> <54517643.80105@isdg.net> To: dmarc X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/CsmZWfHmS7rrRgyX1VGkwdLLs_0 Subject: [dmarc-ietf] End of thread! was: Re: wiki vs. list? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 02:32:45 -0000 > On Oct 29, 2014, at 7:20 PM, Hector Santos wrote: >=20 > If they are going to rewrite, then at the very least we MUST make 3rd = party protocol options and algorithms available as well to ALL = implementators as part of the DMARC protocol to complete the total = picture. Hi Hector, this thread is no longer productive to the work that this = working group needs to immediately accomplish. What you're referring to = is more properly part of a latter phase/milestone, but first the WG = needs to finish compiling the actual list of "indirect email flows". The WG is focused now on compiling this list to avoid issues that arise = when the problem space is too narrowly defined. Unfortunately this = means you need to wait for the WG to catch up to you. To make sure the = WG isn't delayed, I'm asking for reviews of the current work: http://trac.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneOneWiki Anything else right now is simply a distraction. 1/2 of the WG Chair, =3D- Tim From nobody Wed Oct 29 21:03:20 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 530691AD005 for ; Wed, 29 Oct 2014 21:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.508 X-Spam-Level: ** X-Spam-Status: No, score=2.508 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYaHgzgQvBgY for ; Wed, 29 Oct 2014 21:03:15 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6071ACF1D for ; Wed, 29 Oct 2014 21:03:14 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id 2DBC81C3B39; Thu, 30 Oct 2014 13:03:13 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 217A21A27CF; Thu, 30 Oct 2014 13:03:13 +0900 (JST) From: "Stephen J. Turnbull" To: Hector Santos In-Reply-To: <54517643.80105@isdg.net> References: <5436FE09.4050104@sonnection.nl> <20141010041209.2106.qmail@ary.lan> <01PDKQLQAPA200005K@mauve.mrochek.com> <01PDUPKE1KHQ00005L@mauve.mrochek.com> <54494348.4090306@isdg.net> <871tpyieot.fsf@uwakimon.sk.tsukuba.ac.jp> <544A43D4.5070903@isdg.net> <87tx2tgoby.fsf@uwakimon.sk.tsukuba.ac.jp> <544AFEFA.1060506@isdg.net> <036E3CA0799048928F761B1C43905335@fgsr.local> <544BD68B.6030905@dcrocker.net> <544EB20A.2050602@dcrocker.net> <67037945-4C30-43A9-9030-0A7A2A061C15@gmail.com> <544FECF6.70001@isdg.net> <5450039B.5010504@meetinghouse.net> <54517643.80105@isdg.net> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Thu, 30 Oct 2014 13:03:13 +0900 Message-ID: <87oasu2ohq.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/OGFnaTmXy3d0H6SeIHgGxIQD4kk Cc: dmarc , Miles Fidelman Subject: Re: [dmarc-ietf] wiki vs. list? -- please update subject lines X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 04:03:18 -0000 Hector Santos writes: > The solution [to the third-party problem] is to make the AUTHORIZED > ASSOCIATION between the ADID and SDID. This is a *first* party solution, and I have seen no evidence that Yahoo! and AOL are going to buy in to TPA-labels-style authorized associations. In fact, I am pretty sure that AOL *will refuse*, because over the past few years they have been chasing out and then firing exactly the staff who would be responsible for authorizing the associations. > This GROUP wants to MUNGE the ADID the bypass the DMARC security. Please stop that. It does not *want* to do any such thing. It simply acknowledges that it is *already* current practice. (I dropped the "best" just for you!) > If they are going to rewrite, then at the very least we MUST make 3rd > party protocol options and algorithms available as well to ALL > implementators as part of the DMARC protocol to complete the total > picture. We can't make them available to "all". Those options, as you and Doug advocate them (that is, requiring "policy lookup"), are available only to first parties. This is the stumbling block that forces indirect mail operators to consider ADID-munging (From-munging). Are you willing to support the Levine or Crocker-Kucherawy proposals for delegation to explicit addressees? Steve From nobody Wed Oct 29 21:49:58 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739A91AD00A for ; Wed, 29 Oct 2014 21:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.018 X-Spam-Level: X-Spam-Status: No, score=-1.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, PLING_QUERY=0.994, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wT8R_5zYk4-V for ; Wed, 29 Oct 2014 21:49:55 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id ECB121AD008 for ; Wed, 29 Oct 2014 21:49:54 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PEC2I240SW003U7K@mauve.mrochek.com> for dmarc@ietf.org; Wed, 29 Oct 2014 21:44:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1414644294; bh=M0jBilv2VkCesHcn9u7AdjbrPV/wcQnoUUsuJMmnw4U=; h=From:Cc:Date:Subject:In-reply-to:References:To; b=HNMZIASsiYyCdaC+vQ+bRIGFj8OL012UTe3NID6UPAGLxuf5LXbnHHzulr28NHiH3 Bq+p4rh9eHMKPSTOSaB5CZ63BqqkU7set0Vs+C+LnKlL3CR1WXwPHO86AGNiUVZ/6x kkugXmWyXvoji4KOqDI6WZdwsrkhFb6jFIz6lYIs= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PE3G6YIHXS0028JO@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dmarc@ietf.org; Wed, 29 Oct 2014 21:44:50 -0700 (PDT) From: ned+dmarc@mrochek.com Message-id: <01PEC2I0P5V80028JO@mauve.mrochek.com> Date: Wed, 29 Oct 2014 21:44:37 -0700 (PDT) In-reply-to: "Your message dated Wed, 29 Oct 2014 22:32:42 -0400" <891E5CFA-68D8-4A0C-B615-484A3FDE3A57@eudaemon.net> References: <5436FE09.4050104@sonnection.nl> <20141010041209.2106.qmail@ary.lan> <01PDKQLQAPA200005K@mauve.mrochek.com> <01PDUPKE1KHQ00005L@mauve.mrochek.com> <54494348.4090306@isdg.net> <871tpyieot.fsf@uwakimon.sk.tsukuba.ac.jp> <544A43D4.5070903@isdg.net> <87tx2tgoby.fsf@uwakimon.sk.tsukuba.ac.jp> <544AFEFA.1060506@isdg.net> <036E3CA0799048928F761B1C43905335@fgsr.local> <544BD68B.6030905@dcrocker.net> <544EB20A.2050602@dcrocker.net> <67037945-4C30-43A9-9030-0A7A2A061C15@gmail.com> <544FECF6.70001@isdg.net> <5450039B.5010504@meetinghouse.net> <54517643.80105@isdg.net> <891E5CFA-68D8-4A0C-B615-484A3FDE3A57@eudaemon.net> To: Tim Draegen Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/8c1zF5XFYa-7vUfy3975TiUZdJA Cc: dmarc Subject: Re: [dmarc-ietf] End of thread! was: Re: wiki vs. list? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 04:49:56 -0000 > > On Oct 29, 2014, at 7:20 PM, Hector Santos wrote: > > > > If they are going to rewrite, then at the very least we MUST make 3rd party protocol options and algorithms available as well to ALL implementators as part of the DMARC protocol to complete the total picture. > Hi Hector, this thread is no longer productive to the work that this working group needs to immediately accomplish. What you're referring to is more properly part of a latter phase/milestone, but first the WG needs to finish compiling the actual list of "indirect email flows". > The WG is focused now on compiling this list to avoid issues that arise when the problem space is too narrowly defined. Unfortunately this means you need to wait for the WG to catch up to you. To make sure the WG isn't delayed, I'm asking for reviews of the current work: > http://trac.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneOneWiki > Anything else right now is simply a distraction. > 1/2 of the WG Chair, +1 from the other 1/2. Ned From nobody Wed Oct 29 23:00:22 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3885B1AD01A for ; Wed, 29 Oct 2014 23:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQ2QyVn7ILcA for ; Wed, 29 Oct 2014 23:00:18 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 632941AD017 for ; Wed, 29 Oct 2014 23:00:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4874; q=dns/txt; s=iport; t=1414648818; x=1415858418; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=DkUmNcF+0GhFzB46rQGs9b+V/VbYK7kQp7uvQe0rcGc=; b=DsIxGzFWHmgN+HaghZAl9KLadyiWZzBr9Uu3cURGT8NL2EuSVTGfK0EN sjajsSBUn5KO3x04oUsD18bF6AuLG44jnkDhSHXBxO4Lo6Ai5Y+/uR0hP OudXjvlZFZR4cieAMl6WyKQF2GGZhDEknWKbBKmLvIwfTUb9gnB9nkmS5 0=; X-Files: signature.asc : 486 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0EAPnSUVStJssW/2dsb2JhbABcg2JYznEBCYdNAoE0AQEBAQF9hAMBAQQBAQEgSwoRCwQUCRYIAwICCQMCAQIBDwYfEQYBDAYCAQGIKAMSDbJ7jjgNhjgBAQEBAQEBAQEBAQEBAQEBAQEBFQSOVoJBgneBVAEEhGKPPYFQaIRBQYIRh2+HaIZog3k8L4JLAQEB X-IronPort-AV: E=Sophos;i="5.07,284,1413244800"; d="asc'?scan'208,217";a="225786670" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 30 Oct 2014 06:00:16 +0000 Received: from [10.61.73.199] (ams3-vpn-dhcp2503.cisco.com [10.61.73.199]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s9U60FAe015883; Thu, 30 Oct 2014 06:00:16 GMT Message-ID: <5451D3EF.4060900@cisco.com> Date: Thu, 30 Oct 2014 07:00:15 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" , "dmarc@ietf.org" References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bF1KnJ4pUjxONKQEkfV9vNtbIOGOJwa38" Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Dx4E7oPPXzqZPldPO-RP5Vbj3IA Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base revision submitted X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 06:00:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bF1KnJ4pUjxONKQEkfV9vNtbIOGOJwa38 Content-Type: multipart/alternative; boundary="------------050601070307070801030305" This is a multi-part message in MIME format. --------------050601070307070801030305 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Murray, You've clearly put a lot of work into updating this document, and there are a substantial number of changes. That means it deserves this group's serious attention. You've given me my homework assignment, I can say... Eliot On 10/29/14, 9:37 PM, Murray S. Kucherawy wrote: > On Tue, Oct 28, 2014 at 3:44 PM, Murray S. Kucherawy > > wrote: > > Since we're past the I-D deadline, the ISE or Pete will have to > approve its addition to the datatracker, so it will magically > appear at some point soon, and then move forward in the > publication process. > > > It's now available in the datatracker: > https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/ > > -MSK > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc --------------050601070307070801030305 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Murray,

You've clearly put a lot of work into updating this document, and there are a substantial number of changes.=C2=A0 That means it deserv= es this group's serious attention.=C2=A0 You've given me my homework assignment, I can say...

Eliot

On 10/29/14, 9:37 PM, Murray S. Kucherawy wrote:
On Tue, Oct 28, 2014 at 3:44 PM, Murray S. Kucherawy <superus= er@gmail.com> wrote:
Since we're past the I-D deadline, the ISE or Pete will have to approve its addition to the datatracker, so it will magically appear at some point soon, and then move forward in the publication process.

-MSK 


_______________________________________________
dmarc mailing list
dmar=
c@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

--------------050601070307070801030305-- --bF1KnJ4pUjxONKQEkfV9vNtbIOGOJwa38 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQEcBAEBAgAGBQJUUdPvAAoJEIe2a0bZ0nozQUQH/32hGbgMt7CmKiKAWy2aWdF5 tg9lxytvY9CDfjL5bmqVA2iofRCXLVofEk/gLXeqxa3iSzip5GZIgTFZz+e2SZqY MSuAK5QS2VJGjFniIQoiV3n0al/8E/ZkVNz1oqZPLM5qm8twdLIgAolrTAul2CLp rNXoLMQT8pUhCBYii8ZwiNCr019GhCuB4iuvjdUne9LkeA1hdbCpxV2n+Ix/SqjK 2PRg0W3f8+3Q6exl9nkaoDnIpXKfpyS3xfLTs/aAXOZeh/wP37UxEwRjTxMF19qc O4Rcb5unsl5q6oGN/+mM1IroMikY00Ni57OO/IRf3iqy3NCejZBw/CEAlR5y5jg= =ZdCw -----END PGP SIGNATURE----- --bF1KnJ4pUjxONKQEkfV9vNtbIOGOJwa38-- From nobody Thu Oct 30 15:00:37 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 826641A8840 for ; Thu, 30 Oct 2014 15:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHGI65XmCrLo for ; Thu, 30 Oct 2014 15:00:33 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92C671A8849 for ; Thu, 30 Oct 2014 15:00:33 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id tp5so79549ieb.22 for ; Thu, 30 Oct 2014 15:00:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=F9gbpzmuG6r9p/7zZ3gkf9eLB1rgUsmJfoMwauucros=; b=GElQeXu68BPWbxDoycFCXTefqOwZCJschqEXZ4NbX8BeQa3YPjkCmPojL8aBhicH7z S8mFv0Do8+nEIYJZL+fuCVfmsOyvCcgvude5MBmXjw1+uc7hPc2zVzuB4M1Ef9YwU/GA Aabp9sPGpEcKOXnbpndnYufAofseuTTKuS6Oj+EVFAIs0M2tc/X9EESO5IjXHDxHecD3 fti6OaXhtmtXJSKIy+Ba1RFhFU/kGkxe/kj4Sx/9G1Xw+T625+r01hrXzUdY7+7+SSRV xRiQgk5HYu47ndqFdTcH3xFMe8KgmQmJqL/NQjxr+UdulTwyl8yNtsRrBj4lKHw3soI7 vdxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=F9gbpzmuG6r9p/7zZ3gkf9eLB1rgUsmJfoMwauucros=; b=HM7zoi/NbhMJS9IkdXe0BUGXC842iQ33BEQpHZdQyLL5A2gDoJuP657kCLaIhFjUC0 mxh5ViLfFGQ4bvW6w5YCHeN+sEJ+1/0IDZZ1JGq1fCDaCwaaKKhYr/TaqG6u/usGmknC ZAqgFH/vwHcywsWcryujhK27/ifnyqboXPDkmExlia2LORk2B21MuIgLWxg9Nt3OoZq0 Gct5/60FuAfSTZCfvKz7eMeAOUmXwtWSqeQY3uVSKoy19loqZJwULaqPNxgj4Nv87uvc 8cCNUKVlrxNNPNaAnhoP0IPlBXbJbg/npbB/p/y6laSEaCJd9WJpV1OsH71B/pT/jaRa gGMQ== X-Gm-Message-State: ALoCoQktnAdzcHTGjtRoWc4TnlZ30gzCcZj6tzkHxE+plIjZq0zSkv26tRgeH8JNc0AcQr38iGOa MIME-Version: 1.0 X-Received: by 10.107.9.2 with SMTP id j2mr5597459ioi.82.1414706433040; Thu, 30 Oct 2014 15:00:33 -0700 (PDT) Received: by 10.64.62.78 with HTTP; Thu, 30 Oct 2014 15:00:32 -0700 (PDT) In-Reply-To: <87oasu2ohq.fsf@uwakimon.sk.tsukuba.ac.jp> References: <5436FE09.4050104@sonnection.nl> <20141010041209.2106.qmail@ary.lan> <01PDKQLQAPA200005K@mauve.mrochek.com> <01PDUPKE1KHQ00005L@mauve.mrochek.com> <54494348.4090306@isdg.net> <871tpyieot.fsf@uwakimon.sk.tsukuba.ac.jp> <544A43D4.5070903@isdg.net> <87tx2tgoby.fsf@uwakimon.sk.tsukuba.ac.jp> <544AFEFA.1060506@isdg.net> <036E3CA0799048928F761B1C43905335@fgsr.local> <544BD68B.6030905@dcrocker.net> <544EB20A.2050602@dcrocker.net> <67037945-4C30-43A9-9030-0A7A2A061C15@gmail.com> <544FECF6.70001@isdg.net> <5450039B.5010504@meetinghouse.net> <54517643.80105@isdg.net> <87oasu2ohq.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Thu, 30 Oct 2014 15:00:32 -0700 Message-ID: From: Brandon Long To: "Stephen J. Turnbull" Content-Type: multipart/alternative; boundary=001a113f9bfa6746330506ab0266 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/B7jsn1zzkOkVLgrLXAzOsuciULQ Cc: dmarc , Hector Santos , Miles Fidelman Subject: Re: [dmarc-ietf] wiki vs. list? -- please update subject lines X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 22:00:35 -0000 --001a113f9bfa6746330506ab0266 Content-Type: text/plain; charset=UTF-8 On Wed, Oct 29, 2014 at 9:03 PM, Stephen J. Turnbull wrote: > Hector Santos writes: > > > The solution [to the third-party problem] is to make the AUTHORIZED > > ASSOCIATION between the ADID and SDID. > > This is a *first* party solution, and I have seen no evidence that > Yahoo! and AOL are going to buy in to TPA-labels-style authorized > associations. In fact, I am pretty sure that AOL *will refuse*, > because over the past few years they have been chasing out and then > firing exactly the staff who would be responsible for authorizing the > associations. > I'm not happy with the idea because I have >400M users, and I'm not even sure how I would validate any given service to gain enough trust to allow it to send for any one of those users. And there are always going to be some services that we haven't seen before or won't make the trust bar (you're running a mailing list on your linux virtual server for your N friends? That's nice, not going to meet the bar or the bar is useless). Speaking for an enterprise use case, we have relaying, expanding SPF or passing out a specific dkim key to handle those senders, but at the very least, a business domain is at least a restricted set of users with likely a similar trust domain and policies and such. And now I'm not sure if I'm responding to a thread that was officially closed by the wg or not, so my apologies if that's the case. Brandon --001a113f9bfa6746330506ab0266 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Oct 29, 2014 at 9:03 PM, Stephen J. Turnbull = <stephen@xemacs.= org> wrote:
Hector Santos w= rites:

=C2=A0> The solution [to the third-party problem] is to make the AUTHORI= ZED
=C2=A0> ASSOCIATION between the ADID and SDID.

This is a *first* party solution, and I have seen no evidence that Yahoo! and AOL are going to buy in to TPA-labels-style authorized
associations.=C2=A0 In fact, I am pretty sure that AOL *will refuse*,
because over the past few years they have been chasing out and then
firing exactly the staff who would be responsible for authorizing the
associations.

I'm not happy with th= e idea because I have >400M users, and I'm not even sure how I would= validate any given service to gain enough trust to allow it to send for an= y one of those users.=C2=A0 And there are always going to be some services = that we haven't seen before or won't make the trust bar (you're= running a mailing list on your linux virtual server for your N friends?=C2= =A0 That's nice, not going to meet the bar or the bar is useless).

Speaking for an enterprise use case, we have relaying,= expanding SPF or passing out a specific dkim key to handle those senders, = but at the very least, a business domain is at least a restricted set of us= ers with likely a similar trust domain and policies and such.
And now I'm not sure if I'm responding to a thread that= was officially closed by the wg or not, so my apologies if that's the = case.

Brandon
--001a113f9bfa6746330506ab0266-- From nobody Thu Oct 30 17:47:54 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE561A8A20 for ; Thu, 30 Oct 2014 17:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKRsdCraY5L1 for ; Thu, 30 Oct 2014 17:47:51 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 265981A8A1F for ; Thu, 30 Oct 2014 17:47:51 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id tp5so305658ieb.15 for ; Thu, 30 Oct 2014 17:47:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3ChOeJDsZq0TLnSVkSeORFeVIFavRMwBdgdy5isD45Y=; b=lgFvHpGPDcMUPU3dWtuRD3VDSqZ0JMFrC6CbMOiy1+dmz5FugnpodiZDjJFbbItD0/ uAewdEO7fkQRpHqFNo7DCMi+IV+wVKdtC0vljDaqNpF/4fH7CGaQ570dBrNAsX5nPy45 WJiC8w0WXDGZLxjS2SrFpzQdZ0fEVP1Tr78kxWow0Dn2j7uTi+0i6CVETNz3BXktlOJh fGYTpI5R/FnghML4JBuQIkP3gnx/kwIAu1NUO1eiFAsFayFowexvauPiYquQHrU26foe bCWvXHhprylRV5967EbfiFZDUYP6uqeZbGqqfZQdamF5iZ2rU6mVGsV6hMk3i22Zm/C4 gwpw== X-Received: by 10.51.15.132 with SMTP id fo4mr341437igd.36.1414716470452; Thu, 30 Oct 2014 17:47:50 -0700 (PDT) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id v133sm4447407ioe.18.2014.10.30.17.47.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 Oct 2014 17:47:49 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=us-ascii From: Douglas Otis In-Reply-To: Date: Thu, 30 Oct 2014 17:47:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5436FE09.4050104@sonnection.nl> <20141010041209.2106.qmail@ary.lan> <01PDKQLQAPA200005K@mauve.mrochek.com> <01PDUPKE1KHQ00005L@mauve.mrochek.com> <54494348.4090306@isdg.net> <871tpyieot.fsf@uwakimon.sk.tsukuba.ac.jp> <544A43D4.5070903@isdg.net> <87tx2tgoby.fsf@uwakimon.sk.tsukuba.ac.jp> <544AFEFA.1060506@isdg.net> <036E3CA0799048928F761B1C43905335@fgsr.local> <544BD68B.6030905@dcrocker.net> <544EB20A.2050602@dcrocker.net> <67037945-4C30-43A9-9030-0A7A2A061C15@gmail.com> <544FECF6.70001@isdg.net> <5450039B.5010504@meetinghouse.net> <54517643.80105@isdg.net> <87oasu2ohq.fsf@uwakimon.sk.tsukuba.ac.jp> To: Brandon Long X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/FJX7ihv-JauqSHs90YIrXLQ2l54 Cc: "Stephen J. Turnbull" , dmarc , Hector Santos , Douglas Otis , Miles Fidelman Subject: Re: [dmarc-ietf] wiki vs. list? -- please update subject lines X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 00:47:53 -0000 On Oct 30, 2014, at 3:00 PM, Brandon Long wrote: > On Wed, Oct 29, 2014 at 9:03 PM, Stephen J. Turnbull = wrote: > Hector Santos writes: >=20 > > The solution [to the third-party problem] is to make the AUTHORIZED > > ASSOCIATION between the ADID and SDID. >=20 > This is a *first* party solution, and I have seen no evidence that > Yahoo! and AOL are going to buy in to TPA-labels-style authorized > associations. In fact, I am pretty sure that AOL *will refuse*, > because over the past few years they have been chasing out and then > firing exactly the staff who would be responsible for authorizing the > associations. >=20 > I'm not happy with the idea because I have >400M users, and I'm not = even sure how I would validate any given service to gain enough trust to = allow it to send for any one of those users. And there are always going = to be some services that we haven't seen before or won't make the trust = bar (you're running a mailing list on your linux virtual server for your = N friends? That's nice, not going to meet the bar or the bar is = useless). >=20 > Speaking for an enterprise use case, we have relaying, expanding SPF = or passing out a specific dkim key to handle those senders, but at the = very least, a business domain is at least a restricted set of users with = likely a similar trust domain and policies and such. >=20 > And now I'm not sure if I'm responding to a thread that was officially = closed by the wg or not, so my apologies if that's the case. Dear Brandon, As the DMARC introduction states, it determines authorized identifiers. = The draft unfortunately also muddles authorization with authentication. = We have been seeing an increasing level of spoofing that leverages = weaknesses in SPF and even DKIM. Preventing authorized messages from = being placed into spam folders must not be seen as claiming to have = "authenticated" a message's originating domain. Neither DKIM nor SPF = really does this. It is misleading to oversell the function of DMARC, = SPF, and DKIM. In addition, having a growing amount of legitimate email = placed into spam folders also carries comparable risks as this too = lowers the bar in what a user is more likely to open.=20 A DMARC domain can determine legitimate third-party services by = comparing outbound message domains against their DMARC feedback. = Offering receivers domain specific third-party feedback will increase = protections (raising the bar) as well as allowing DMARC restrictive = policies to be applied in more environments. The DMARC domain could even = proactively vet these domains. Why give a malicious domain grist for = their phishing mill? Regards, Douglas Otis= From nobody Fri Oct 31 15:37:36 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 172FD1A70FF for ; Fri, 31 Oct 2014 15:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.398 X-Spam-Level: * X-Spam-Status: No, score=1.398 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_16=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01pDJ0cNadlr for ; Fri, 31 Oct 2014 15:37:31 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C77BD1A7031 for ; Fri, 31 Oct 2014 15:37:30 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.298.1; Fri, 31 Oct 2014 23:37:28 +0100 Message-ID: <3154FB1A540749FBA374F7F4DB9CEEB5@fgsr.local> From: "J. Gomez" To: Date: Fri, 31 Oct 2014 23:39:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/5xE8W4C1l7hPG1GrTjJnxyAz1bY Subject: [dmarc-ietf] Extending DMARC: managing failure cases: plus ultra X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 22:37:33 -0000 (First: yes, I know this is not in Milestone 1 Roadmap, but I just dump = it here do that I myself don't forget about it. Please delete from your = Inbox at first symptom of annoyance; thank you.) Proposal: to extend DMARC to further handle failure cases when Sender's = policy is p=3Dreject and the Receiver is receiving a non-aligned email = as per DMARC. The proposal consists of two parts: 1) A new tag for the DMARC record in DNS. The tag could be named "ama" = ("ask-me-anything"), and its possible values could be an int (N) from = value 0 up to 65535, the default being "ama=3D0" when the "ama" tag is = omitted (note: "ama=3D0" would equal to "do not ask the Sender = anything"). 2) A new protocol, bi-directional and XML-based and carried over HTTPS, = by which Receiver would query Sender if the first N (or any number < N) = lines of a DMARC-failed received email are to be considered "legit use" = of the Sender's "domain email policy", and by which (the purported) = Sender would answer the query with whether that particular email (of = which the first N, or less than N, lines he has been made aware of) is = legit, not legit, or doubtful. (Note: this XML transaction should happen = in semi-realtime while the original SMTP transaction for the queried = email is still pending closure.) To further refine: How to avoid the (purported) Sender's XML "ama" = service being DDoS-ed by evil actors? How to make it so that the = Receiver does not accidentally disclose to a fake Sender the = confidential content of received emails? Perhaps the ama-XML-query = should only happen (and should only be accepted by the [purported] = Sender) when the received email has a From-header signed by an = (additional) valid DKIM signature? So there, that. Regards, J.Gomez From nobody Fri Oct 31 15:47:53 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 665831A82E2 for ; Fri, 31 Oct 2014 15:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tw2WoHDqA3UE for ; Fri, 31 Oct 2014 15:47:49 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A40D21A7021 for ; Fri, 31 Oct 2014 15:47:49 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s9VMljga014770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 31 Oct 2014 15:47:49 -0700 Message-ID: <5454118B.9030706@dcrocker.net> Date: Fri, 31 Oct 2014 15:47:39 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "J. Gomez" , dmarc@ietf.org References: <3154FB1A540749FBA374F7F4DB9CEEB5@fgsr.local> In-Reply-To: <3154FB1A540749FBA374F7F4DB9CEEB5@fgsr.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Fri, 31 Oct 2014 15:47:49 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Hu2vNp8MglsZHHHaBN10sU4jPxM Subject: Re: [dmarc-ietf] Extending DMARC: managing failure cases: plus ultra X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 22:47:51 -0000 On 10/31/2014 3:39 PM, J. Gomez wrote: > I just dump it here do that I myself don't forget about it. I tend to like such aide-memoire postings to the list -- as long as we don't get distracted -- but I think we also want to encourage placing them into the wiki. As I recall, it has separate sections for each milestone. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Oct 31 15:59:12 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7514D1A038F for ; Fri, 31 Oct 2014 15:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JcHXNpMuWJQG for ; Fri, 31 Oct 2014 15:58:59 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFA981A8700 for ; Fri, 31 Oct 2014 15:58:58 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.298.1; Fri, 31 Oct 2014 23:58:57 +0100 Message-ID: From: "J. Gomez" To: References: <3154FB1A540749FBA374F7F4DB9CEEB5@fgsr.local> <5454118B.9030706@dcrocker.net> Date: Sat, 1 Nov 2014 00:01:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/K6abJEt8pWdrI-jl1T__bQjWS0A Subject: Re: [dmarc-ietf] Extending DMARC: managing failure cases: plus ultra X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 22:59:03 -0000 On Friday, October 31, 2014 11:47 PM [GMT+1=3DCET], Dave Crocker wrote: > On 10/31/2014 3:39 PM, J. Gomez wrote: > > I just dump it here do that I myself don't forget about it. >=20 >=20 > I tend to like such aide-memoire postings to the list -- as long as we > don't get distracted -- but I think we also want to encourage placing > them into the wiki. As I recall, it has separate sections for each > milestone. I don't want to pollute the wiki with wild and inmature ideas of mine. = This list is a much better place to get shitty ideas smacked down real = fast. :) Regards, J.Gomez From nobody Fri Oct 31 16:10:38 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6C281A1A20 for ; Fri, 31 Oct 2014 16:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.2 X-Spam-Level: X-Spam-Status: No, score=-6.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FqxcHCbJYRNY for ; Fri, 31 Oct 2014 16:10:26 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 591591A038F for ; Fri, 31 Oct 2014 16:10:25 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s9VNAL9U015070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 31 Oct 2014 16:10:24 -0700 Message-ID: <545416D7.6050601@dcrocker.net> Date: Fri, 31 Oct 2014 16:10:15 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "J. Gomez" , dmarc@ietf.org References: <3154FB1A540749FBA374F7F4DB9CEEB5@fgsr.local> <5454118B.9030706@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Fri, 31 Oct 2014 16:10:25 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/1Fugb6K8Ql9ZebNA5R7kfAAyJMM Subject: Re: [dmarc-ietf] Extending DMARC: managing failure cases: plus ultra X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 23:10:36 -0000 On 10/31/2014 4:01 PM, J. Gomez wrote: > I don't want to pollute the wiki with wild and inmature ideas of mine. This list is a much better place to get shitty ideas smacked down real fast. :) I would indulge the in invitation to repartee, but the whole point is not to distract the list. Simple view: When a topic is being discussed, the list is the best place to expose a new idea -- no matter which orifice it exudes from -- for discussion. But when it is off-topic, the wiki is the best place to record it for later reference. Anyhow, just my opinion. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Oct 31 16:20:58 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 597AF1A870D for ; Fri, 31 Oct 2014 16:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_INVITATION=-2, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-bRKeMVvr-Q for ; Fri, 31 Oct 2014 16:20:54 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AE901A8706 for ; Fri, 31 Oct 2014 16:20:54 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.298.1; Sat, 1 Nov 2014 00:20:52 +0100 Message-ID: <77A68748FE874021852B4D8FF12AFD17@fgsr.local> From: "J. Gomez" To: References: <3154FB1A540749FBA374F7F4DB9CEEB5@fgsr.local> <5454118B.9030706@dcrocker.net> <545416D7.6050601@dcrocker.net> Date: Sat, 1 Nov 2014 00:22:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/ojUyEzOlFSB9hKkhZRo441yP5_w Subject: Re: [dmarc-ietf] Extending DMARC: managing failure cases: plus ultra X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 23:20:56 -0000 On Saturday, November 01, 2014 12:10 AM [GMT+1=3DCET], Dave Crocker = wrote: > On 10/31/2014 4:01 PM, J. Gomez wrote: > > I don't want to pollute the wiki with wild and inmature ideas of > > mine. This list is a much better place to get shitty ideas smacked > > down real fast. :) =20 >=20 >=20 > I would indulge the in invitation to repartee, but the whole point is > not to distract the list. Well, this is just a thread in the list, it could be ignored/killed by = those disliking it. But I would love to hear your criticism of the ama-XML query service for = DMARC failure cases... I mean, if the idea deserves a rapid death, lets proceed and get done = with it. Regards, J.Gomez From nobody Fri Oct 31 16:45:40 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24EE81A873E for ; Fri, 31 Oct 2014 16:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNmTjxjmr2Tv for ; Fri, 31 Oct 2014 16:45:35 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1CCA1A86FE for ; Fri, 31 Oct 2014 16:45:34 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id at20so2298044iec.17 for ; Fri, 31 Oct 2014 16:45:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=QlLXSt/qKvVzICrLopcsPXiVWKyJ/1GHdw//wqa5dy0=; b=iAyN3SQFNqsYgaKCpBnci/a2AUjQxhOzU389m1kTQ+4iLnAEpxUBpBMWUe5L/UbnLO Dc0LxGlLgFYmbvhZyua5mB5QVSqqHha/ZrOq3Q50EW6YjWYBWjovwGCNOLybu6K6OK37 Y1jbXvWJSCK874+T9GIk95XaIwCGXaTv5XhNaciiowBXXvJC+/FcEhDklMCIgqdjwaL2 dXVxrBAqneYGVwAc1pkKR8WK27Cuc1SpuY3EiGrL/yo9euYw79UckA3/PP0n8U9Tpep2 WTK6MdT3i6IHcr3/Yr3eEb4oPjL5nVMFfsa9odTlSYfbZhYeyBsH8JDkW0aiegMKe/Z9 sUiw== X-Received: by 10.42.110.195 with SMTP id r3mr27057714icp.12.1414799134411; Fri, 31 Oct 2014 16:45:34 -0700 (PDT) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id w8sm148587igl.13.2014.10.31.16.45.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 Oct 2014 16:45:33 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_46ED469E-EFBD-404F-8554-D073E516F31F" From: Douglas Otis In-Reply-To: Date: Fri, 31 Oct 2014 16:45:34 -0700 Message-Id: References: To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/AW8ullSb1XoNhrCUD2evIiVxJyQ Cc: "dmarc@ietf.org" , Douglas Otis Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 23:45:38 -0000 --Apple-Mail=_46ED469E-EFBD-404F-8554-D073E516F31F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/ Dear Murray, Nice work as this is a great improvement. The introduction properly states the function of DKIM or SPF is to = detect and block unauthorized email. Neither DKIM nor SPF determines: 1) valid RFC5322 structure 2) intended message recipient 3) sending domain 4) =46rom header field content 5) Subject header field content As such, using the terms authenticates and authentication should not be = used when referring to DKIM or SPF results. Nothing is being = authenticated. The real function is verification of an authorization. = It is dangerously misleading to overstate DMARC/SPF/DKIM mechanisms, = especially since DMARC permits the weakest mechanism to be a basis for = acceptance. Leave the name of the document as is, in the hopes future mechanisms = will enable an ability to actually authenticate domains. Perhaps by = using tokens similar to ApplePay or LoopPay.=20 Section 2, Was: However, there has been no single widely accepted or publicly available mechanism to communicate domain-specific message authentication policies, or to request reporting of authentication and disposition of received mail. Should be: However, there has been no single widely accepted or publicly available mechanism to communicate domain-specific message verification policies, or to request reporting of verification and disposition of received mail. Was: As a result, senders who have implemented email authentication have had difficulty determining how effective their authentication is, and use of authentication failures to filter mail has not been a success Should be: As a result, senders implementing email authorization schemes have had difficulty determining how effective their authorization is, and use of authorization failures to filter mail has not been a success. Section 2.2 Was: o authentication of entities other than domains, since DMARC is built upon SPF and DKIM which authenticate domains; and Should be: o authorizations of entities other than domains, since DMARC is built upon SPF and DKIM which authorizes domains; and=20 Section 3: Was: Authenticated Identifiers: Domain-level identifiers that are established using authentication technologies are referred to as "Authenticated Identifiers". See Section 3.1.1 for details about the supported mechanisms. Should be: Authorized Identifiers: Domain-level identifiers that are established using authorization technologies are referred to as "Authorized Identifiers". See Section 3.1.1 for details about the supported mechanisms. Was: 3.1.1. Authentication Mechanisms Should be: 3.1.1. Authorization Mechanisms Was: o [SPF], which authenticates the domain found in an [SMTP] MAIL command when it is the authorized domain. Should be: o [SPF], which authorizes the domain found in an [SMTP] MAIL command. Section 3.1.4 Was: Each of the underlying authentication technologies Should be: Each of the underlying authorization technologies Was: 3.1.4.2. SPF-authenticated Identifiers Should be: 3.1.4.2. SPF-authorized Identifiers Section 5 Was: A Domain Owner may find that although its messages pass a particular authentication scheme's checks, it wishes not to have Mail Receivers =20 Should be; A Domain Owner may find that although its messages pass a particular authorization scheme's checks, it wishes not to have Mail Receivers =20 Although DMARC requires subsequent format checks of the =46rom header = field, it does not do this with the Subject line which often permits = injectable clickable URLs. As was done with the DKIM deployment RFCs, the same has been done for = DMARC. It seems neither DKIM nor DMARC follow the path of least = astonishment. If history is any sort of predictor, DMARC will be gamed whenever = receivers follow the path of least resistance and trust the = Authentication results contained within messages. It seems unfortunate that Internet Identified Mail was not adopted = because it passed the public key within the message which was seen as = causing too much message overhead. Now, rather than correcting the DKIM = validation process, domains are now expected to list all the headers = used twice in each and every message. As such, it seems IIM would now = have been the better choice. It is very dangerous to over sell the function of SPF and DKIM. Both of = these mechanisms are experiencing increased exploitation in highly = critical areas. It is unfortunate it took until May of 2014 for a major = provider to finally acknowledge the nature of these exploits, although = they had been explained much earlier in appeals and magazine articles. Unless DKIM is repaired, both the DKIM Deployment and DMARC BCPs drafts = are sorely lacking much needed guidance. Guidance many are likely to = find astonishing.=20 Regards, Douglas Otis --Apple-Mail=_46ED469E-EFBD-404F-8554-D073E516F31F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii http= s://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/

<= br>
Dear Murray,

Nice work as this is = a great improvement.

The introduction properly = states the function of DKIM or SPF is to detect and block unauthorized = email.

Neither DKIM nor SPF = determines:
1) valid RFC5322 structure
2) =
intended message recipient
3) sending domain
4) =46rom=
 header field content
5) Subject header field =
content

As such, using the terms =
authenticates and authentication should not be used when =
referring to DKIM or SPF results.  Nothing is being authenticated.  The =
real function is verification of an authorization.  It is =
dangerously misleading to overstate DMARC/SPF/DKIM mechanisms, =
especially since DMARC permits the weakest mechanism to be a basis for =
acceptance.
Leave the name of the document as is, in the = hopes future mechanisms will enable an ability to actually authenticate = domains.  Perhaps by using tokens similar to ApplePay or = LoopPay. 

Section = 2,

Was:
  =  However, there has been
   no single widely = accepted or publicly available mechanism to
  =  communicate domain-specific message authentication policies, or = to
   request reporting of authentication and = disposition of received = mail.

Should = be:
   However, there has = been
   no single widely accepted or publicly = available mechanism to
   communicate = domain-specific message verification policies, or to
  =  request reporting of verification and disposition of received = mail.

Was:
  =  As a result, senders who have implemented email authentication = have
   had difficulty determining how effective = their authentication is, and
   use of = authentication failures to filter mail has not been a = success

Should = be:
   As a result, senders implementing = email authorization schemes have
   had difficulty = determining how effective their authorization is, and
  =  use of authorization failures to filter mail has not been a = success.

Section = 2.2
 Was:
 o  authentication of entities other than =
domains, since DMARC is
    built upon SPF and DKIM which =
authenticate domains; and
Should =
be:
o authorizations of = entities other than domains, since DMARC is
   built upon = SPF and DKIM which authorizes domains; = and 

Section 3:
Was:
      =
Authenticated Identifiers:  Domain-level identifiers that =
are
      established using authentication =
technologies are referred to as
      =
"Authenticated Identifiers".  See Section 3.1.1 for =
details about
      the supported =
mechanisms.
Should be:
      Authorized Identifiers:  Domain-level =
identifiers that are
      established using =
authorization technologies are referred to as
      =
"Authorized Identifiers".  See Section 3.1.1 for details =
about
      the supported =
mechanisms.
Was:
3.1.1. =
 Authentication Mechanisms
Should be:
3.1.1.  Authorization =
Mechanisms

Was:
o =
 [SPF], which authenticates the domain found in an [SMTP] =
MAIL
      command when it is the authorized =
domain.

Should be:
o =
 [SPF], which authorizes the domain found in an [SMTP] =
MAIL
      =
command.

Section =
3.1.4
Was:
Each of the =
underlying authentication technologies
Should =
be:
Each of the underlying =
authorization technologies
Was:
3.1.4.2.  SPF-authenticated Identifiers
Should =
be:

3.1.4.2.  SPF-authorized =
Identifiers
Section =
5

Was:
   A Domain Owner may find that although its messages =
pass a particular
   authentication scheme's checks, it wishes not to have Mail Receivers
 
Should be;
   A Domain =
Owner may find that although its messages pass a particular
   authorization scheme's checks, it wishes not to have Mail Receivers
 
Although DMARC requires subsequent =
format checks of the =46rom header field, it does not do this with the =
Subject line which often permits injectable clickable URLs.
As was done with the DKIM deployment RFCs, the same =
has been done for DMARC. It seems neither DKIM nor DMARC follow the path =
of least astonishment.
If history is any =
sort of predictor, DMARC will be gamed whenever receivers follow the =
path of least resistance and trust the Authentication results =
contained within messages.
It seems =
unfortunate that Internet Identified Mail was not adopted because it =
passed the public key within the message which was seen as causing too =
much message overhead.  Now, rather than correcting the DKIM validation =
process, domains are now expected to list all the headers used twice in =
each and every message.  As such, it seems IIM would now have been the =
better choice.
It is very dangerous to over =
sell the function of SPF and DKIM.  Both of these mechanisms are =
experiencing increased exploitation in highly critical areas.  It is =
unfortunate it took until May of 2014 for a major provider to finally =
acknowledge the nature of these exploits, although they had been =
explained much earlier in appeals and magazine articles.
Unless DKIM is repaired, both the DKIM Deployment and =
DMARC BCPs drafts are sorely lacking much needed guidance.  Guidance =
many are likely to find astonishing. 
Regards,
Douglas Otis



= --Apple-Mail=_46ED469E-EFBD-404F-8554-D073E516F31F--