Colleagues,

draft-kuchera= wy-dmarc-base is nearing IESG conflict review, and it's been pointed ou= t that a review from back in April has not been properly attended to.

Could I get the WG (forgive me, co-chairs!) to comment on this so t= hat I can see what changes might be appropriate here?=C2=A0 Having this res= olved before the telechat in the first week of January would be truly delig= htful.

Note that some amount of this may have already been add= ressed (it was about -04; -08 is current, and at least the ABNF issue Jim r= aises will be handled in -09), so please at least check -08 when considerin= g your responses.

The posting: http://www.ietf.org/mail-archive/we= b/dmarc/current/msg00764.html

Thank you!

-MSK
--f46d04426c2cdfa312050a98696c-- From nobody Fri Dec 19 14:30: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 6FF901ACE23 for ; Fri, 19 Dec 2014 14:30:35 -0800 (PST) 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 525eB7Pkxbnf for ; Fri, 19 Dec 2014 14:30:32 -0800 (PST) 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 63E931ACE27 for ; Fri, 19 Dec 2014 14:30:27 -0800 (PST) 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 sBJMUJSH030228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 19 Dec 2014 14:30:22 -0800 Message-ID: <5494A6F5.5020906@dcrocker.net> Date: Fri, 19 Dec 2014 14:30:13 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: jim fenton References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Fri, 19 Dec 2014 14:30:23 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/HeR5n09K75zTSUo3283pajKShLU Cc: "dmarc@ietf.org" , "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 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, 19 Dec 2014 22:30:35 -0000 On 12/19/2014 1:30 PM, Murray S. Kucherawy wrote: > Could I get the WG (forgive me, co-chairs!) to comment Some of Jim's note are about writing style, precision, specific terminology usage, points of nuance, or requests for clarification. I'll leave clarification to Murry, and I'll assume that Murray and/or the RFC Editor will deal with such niceties. The niceties matter, but don't group require discussion, IMO. So my feedback is limited to points I consider substantive or even possibly controversial: Meta-concern: Since Jim cited paragraph numbers rather than explicitly quoting text, I've no idea whether I'm looking at the correct text. In fact, I've started to fear that his par numbering is zero based... Substative Meta-concern: It's important to distinguish between comments that make sense to pursue in an effort at further development -- that is, the new working group -- versus ones that clarify the existing spec or identify significant failures in it. > The posting: > http://www.ietf.org/mail-archive/web/dmarc/current/msg00764.html > From: Jim Fenton > To: "dmarc at ietf.org" > Date: Wed, 16 Apr 2014 12:11:45 -0700 ... > Bullet 10: Again, DMARC doesn't do authentication, even for domains; it > relies on other authentication mechanisms. I originally thought this, too, but in fact DMARC does do authentication: DMARC asserts authenticity of the rfc5322.From field domain name. That's a distinct semantic increment over anything SPF or DKIM do on their own. > 3.1.2 General Concepts ... > Paragraph 3 doesn't quite capture the sense of alignment properly, > especially for SPF. A message that is authorized by SPF might have an > unaligned envelope-from address, so the validity of SPF for such > messages is moot. I think this is par. 2 in the -08 draft and that text looks fine to me. If someone thinks the text needs changing, they need to offer candidate text. > 3.2 Organizational Domain > > I remain very concerned about this algorithm since I have been > previously told very specifically not to do this by the DNS folks. I'm > also concerned about the inconsistency (interoperability impact) that > could result from different operators using different public suffix lists. Everyone is concerned about it. But it's the best that is currently available. > 4. Policy > > Paragraph 4 basically says, if you don't want a particular > authentication scheme to be considered by DMARC, don't use it at all. > For a domain that is using SPF and DMARC (for example), this could be an > impediment to their deployment of DKIM because they could not test with > it without having it immediately affect recipients' message handling. > One possibility would be to ignore DKIM if the testing (t=y) flag is > set, although a campaign would be needed to get the many domains > currently using t=y to turn it off. Another possibility would be to have > a setting in DMARC to ignore a specific authentication method entirely. The first possibility isn't viabile, for the reason cited. The second possibility might be worth pursuing in the DMARC working group, rather than in a document that captures existing DMARC practice. There are, of course, other possibilities, such as not having DMARC pursue operational nuance that makes the spec more complex, trying to handle special cases. That is, if a site isn't ready to use DMARC, it shouldn't. > 5. DMARC policy record > > Paragraph 2: Again, "matches perfectly with the DNS" is an inaccurate > characterization. If the query requirement matched perfectly with the > DNS, DNS would have a way to determine the Administrative Domain without > resorting to suffix lists and such. Just strike the sentence; this isn't > relevant here anyway. -08 doesn't have this language. > 7.1 Verifying External Destinations > > Paragraph 3: "verification steps SHOULD be taken" These steps are to > protect another domain from attack. It needs to be a MUST. 6.1 in -08. Given the problems with the search for org domain, a SHOULD is as far as is practical here. I'd suggest noting that that's a reason this can't be a MUST. > 8. Policy Discovery ... 5.6.3 in -08 > Second-to-last paragraph: "If the RFC5322.From domain does not exist in > the DNS" is basically changing what RFC5321/5322 allow. This isn't the > place to be making fundamental changes to the behavior of email. It isn't meant to be. -08 text says: "If the RFC5322.From domain does not exist in the DNS, Mail Receivers SHOULD direct the receiving SMTP server to reject the message. The choice of mechanism for such rejection and the implications of those choices are discussed in Section 9.3." I suggest removing it. Although a common anti-abuse mechanism, it's out of scope for DMARC. > 9. Domain Owner Actions 5.5 in -08 > Last paragraph doesn't seem like it fits. Suggest it be removed. While I could imagine a better place for it in the doc, having a /terse/ pointer like this to some authentication pedagogy seems useful to me, in an authentication-related spec... > 10.1 Extract author domain 6.6.1 in -08 > "Such messages SHOULD be rejected": looks like it's been removed. > 11.1 Discovery 6.2.1 in -08 > Mail Receivers can also discover reporting requests from the > Organizational Domain. That should be mentioned here. But I'm a little > confused why we have another Discovery section at all. The text's use of the word 'corresponds' handles the mapping to org domain, IMO. > 11.2.1 Email > > The whole thing about filenames needs to go away. Since it's only a > SHOULD requirement, the Report Receiver needs to be able to handle > reports that don't follow this format as well as those that do. "SHOULD" is a very strong normative statement. Note that it permits non-conformance only in the presence of singular knowledge by the non-conforming party. Filename labeling is generally considered useful. Why wouldn't it be useful here? > I also > wonder if some operating systems have trouble with filenames containing > the "!" character. If they are, they already need to be able to resolve the issue. > 14.1 Data Exposure Considerations > > Last paragraph: what's an "unexpected Mail Receiver"? > > The privacy consideration here, which isn't obvious from the wording, is > that users may currently use forwarding in a way that prevents the > sender from determining the ultimate delivery address. DMARC has the > potential to break that. This might be important in the case of a user > that is trying to distance themselves from a stalker. How is that a DMARC-specific 'exposure' consideration? > 14.2 Report Recipients > > Some potential exists for report recipients to perform traffic analysis: > to obtain metadata about the receiver's traffic. In addition to > verifying compliance with policies, receivers need to consider that > before sending reports to a third party. +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Dec 19 14:34: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 387DE1A854D for ; Fri, 19 Dec 2014 14:34:33 -0800 (PST) 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 dlzuB84yCrJm for ; Fri, 19 Dec 2014 14:34:31 -0800 (PST) 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 22AD61ACE41 for ; Fri, 19 Dec 2014 14:34:31 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id bs8so3317804wib.4 for ; Fri, 19 Dec 2014 14:34:30 -0800 (PST) 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=lspYawh88pvSJut8KhU0e95n4sPGQD7HjGvG4DViWLc=; b=lJ2HCDsf4xTlCUNhqiHnS9wjLAA7HP4ekoHpsH0bZj5l2SPkbqNz5jHaNoQ4RT2uga p9hk9arbsRXqY/Zudmh79mMEcxtCZ+SroIT7WNm2OhjOucUURsnwsTJcALbfL4H8uRBm OYx+V6fK9hhxsOc/xwoDTAY0zxN7yxBchOfnQuv/J6n+thb6oshe5vAgyPi9lF3OOBm7 guqzOVgLy/xXebqQOTx3A/r+xbWQ9RITOP2hYw+tJdK+1FepLh078cWzN4S1GSEed0qV ucHtwswLZ40UtbttC2mB1TyufKUhijzwdeO6mQrmiDJkPlu0NzNkHlQGwjZDYdXog1Ib kv8w== MIME-Version: 1.0 X-Received: by 10.180.85.33 with SMTP id e1mr9619322wiz.61.1419028469967; Fri, 19 Dec 2014 14:34:29 -0800 (PST) Received: by 10.27.8.74 with HTTP; Fri, 19 Dec 2014 14:34:29 -0800 (PST) In-Reply-To: <5494A6F5.5020906@dcrocker.net> References: <5494A6F5.5020906@dcrocker.net> Date: Fri, 19 Dec 2014 14:34:29 -0800 Message-ID: From: "Murray S. Kucherawy" To: Dave Crocker Content-Type: multipart/alternative; boundary=f46d04428074e0f42f050a994f56 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/8NF1SpPvtpzOfD-Klg9UiTQ6ZoM Cc: jim fenton , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 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, 19 Dec 2014 22:34:33 -0000 --f46d04428074e0f42f050a994f56 Content-Type: text/plain; charset=UTF-8 On Fri, Dec 19, 2014 at 2:30 PM, Dave Crocker wrote: > Meta-concern: Since Jim cited paragraph numbers rather than explicitly > quoting text, I've no idea whether I'm looking at the correct text. In > fact, I've started to fear that his par numbering is zero based... > The document has been reorganized since his original comments, so this was an issue for me as well. Thanks for your comments. There was a separate feedback comment that was purely typos/nits which I'll handle myself and not foist on the WG unless I really get stuck; dealing with this substantive stuff was my greatest worry. -MSK --f46d04428074e0f42f050a994f56 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Dec 19, 2014 at 2:30 PM, Dave Crocker <dhc@dcrocke= r.net> wrote:

Meta-concern:=C2=A0 Since Jim cited pa= ragraph numbers rather than explicitly
quoting text, I've no idea whether I'm looking at the correct text.= =C2=A0 In
fact, I've started to fear that his par numbering is zero based...
<= /blockquote>

The document has been reorganized since his= original comments, so this was an issue for me as well.

= Thanks for your comments.=C2=A0 There was a separate feedback comment that = was purely typos/nits which I'll handle myself and not foist on the WG = unless I really get stuck; dealing with this substantive stuff was my great= est worry.

-MSK

--f46d04428074e0f42f050a994f56-- From nobody Sat Dec 20 23:19: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 AFBE81A0195 for ; Sat, 20 Dec 2014 23:19:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.689 X-Spam-Level: X-Spam-Status: No, score=0.689 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, 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 urRtQ90pt8k0 for ; Sat, 20 Dec 2014 23:19:09 -0800 (PST) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C823B1A0196 for ; Sat, 20 Dec 2014 23:19:08 -0800 (PST) Received: from [IPv6:2001:470:1f05:bfe:35c5:65a4:405f:3c65] ([IPv6:2001:470:1f05:bfe:35c5:65a4:405f:3c65]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.3/8.14.3/Debian-9.4) with ESMTP id sBL7IvBT010055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 20 Dec 2014 23:18:59 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1419146340; bh=eai+Hj+DXEOE5XOY/7nLmtL19cOU8ANwRwZzvg5LjZs=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=BiOsvGpdjS1nJfbsoVz6ayYd1qcwDgA0bjE7o7pq4/YpSyQSq9WET+pwWTnBN34dQ C2jII7k8Jt2jWLoe+i/IkhjyN4kAjbtx0xqSUIx6z34AHoWBfmDOB2Ggipgox7dNvC DsH717qQGd44nRx/K9uX7zw66Va0uV8dAhtFsNrk= Message-ID: <54967461.2070702@bluepopcorn.net> Date: Sat, 20 Dec 2014 23:18:57 -0800 From: Jim Fenton User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <5494A6F5.5020906@dcrocker.net> In-Reply-To: <5494A6F5.5020906@dcrocker.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/U3ubIDikpTK6LnYVMoxLv1tii6A Cc: "dmarc@ietf.org" , "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 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, 21 Dec 2014 07:19:12 -0000 Hi, Dave - On 12/19/2014 02:30 PM, Dave Crocker wrote: [2.4 Out of Scope] >> Bullet 10: Again, DMARC doesn't do authentication, even for domains; i= t >> relies on other authentication mechanisms. > I originally thought this, too, but in fact DMARC does do authenticatio= n: > > DMARC asserts authenticity of the rfc5322.From field domain name. > That's a distinct semantic increment over anything SPF or DKIM do on > their own. What it does is different enough from SPF and DKIM that I think it's overloading the term "authentication" to use it again here. It doesn't contribute to a clear understanding. It looks at the results of SPF and DKIM, which operate at the domain level, so this bullet isn't really necessary. > > > >> 3.1.2 General Concepts > ... >> Paragraph 3 doesn't quite capture the sense of alignment properly, >> especially for SPF. A message that is authorized by SPF might have an >> unaligned envelope-from address, so the validity of SPF for such >> messages is moot. > I think this is par. 2 in the -08 draft and that text looks fine to me.= Yes, paragraph 2. My point is that a the last sentence seems to say that if a message arrives from a server authorized by SPF, it will not be affected by DMARC policies. > > If someone thinks the text needs changing, they need to offer candidate= > text. DMARC's filtering function is based on whether SPF or DKIM can provide an authenticated, aligned identifier for the message under consideration. Messages that purport to be from a Domain Owner's domain and arrive from servers that are not authorized by that domain's SPF and do not contain an appropriate DKIM signature can be affected by DMARC policies. [I think the additional "that domain's" will do it.] > > > >> 3.2 Organizational Domain >> >> I remain very concerned about this algorithm since I have been >> previously told very specifically not to do this by the DNS folks. I'm= >> also concerned about the inconsistency (interoperability impact) that >> could result from different operators using different public suffix li= sts. > Everyone is concerned about it. But it's the best that is currently > available. > > >> 4. Policy >> >> Paragraph 4 basically says, if you don't want a particular >> authentication scheme to be considered by DMARC, don't use it at all. >> For a domain that is using SPF and DMARC (for example), this could be = an >> impediment to their deployment of DKIM because they could not test wit= h >> it without having it immediately affect recipients' message handling. >> One possibility would be to ignore DKIM if the testing (t=3Dy) flag is= >> set, although a campaign would be needed to get the many domains >> currently using t=3Dy to turn it off. Another possibility would be to = have >> a setting in DMARC to ignore a specific authentication method entirely= =2E > The first possibility isn't viabile, for the reason cited. The second > possibility might be worth pursuing in the DMARC working group, rather > than in a document that captures existing DMARC practice. > > There are, of course, other possibilities, such as not having DMARC > pursue operational nuance that makes the spec more complex, trying to > handle special cases. That is, if a site isn't ready to use DMARC, it > shouldn't. The point is that use of DMARC may come first, and makes SPF and DKIM more brittle. Domains that have deployed DMARC may want to deploy both SPF and DKIM (having already deployed one or the other), but it would be better if they didn't have to turn off DMARC to do so. Agree that this is a bit of a corner case. > > >> 5. DMARC policy record >> >> Paragraph 2: Again, "matches perfectly with the DNS" is an inaccurate >> characterization. If the query requirement matched perfectly with the >> DNS, DNS would have a way to determine the Administrative Domain witho= ut >> resorting to suffix lists and such. Just strike the sentence; this isn= 't >> relevant here anyway. > -08 doesn't have this language. Now section 5.1, paragraph 2. Honestly, this reads like marketing fluff that doesn't belong in a specification like this. > > > >> 7.1 Verifying External Destinations >> >> Paragraph 3: "verification steps SHOULD be taken" These steps are to >> protect another domain from attack. It needs to be a MUST. > 6.1 in -08. > > Given the problems with the search for org domain, a SHOULD is as far a= s > is practical here. > > I'd suggest noting that that's a reason this can't be a MUST. This is already predicated on having discovered the DMARC policy, so the org domain search is irrelevant. If this is only a SHOULD, under what circumstances might a Mail Receiver follow a different procedure, or not do this at all? This reporting procedure is one of the core aspects of DMARC; if someone is doing something different, I would think that the specification would want to say that it's not DMARC any more. > > > >> 8. Policy Discovery > ... > > 5.6.3 in -08 > > >> Second-to-last paragraph: "If the RFC5322.From domain does not exist i= n >> the DNS" is basically changing what RFC5321/5322 allow. This isn't the= >> place to be making fundamental changes to the behavior of email. > It isn't meant to be. > > -08 text says: > > "If the RFC5322.From domain does not exist in the DNS, Mail > Receivers > SHOULD direct the receiving SMTP server to reject the message. The > choice of mechanism for such rejection and the implications of those= > choices are discussed in Section 9.3." > > I suggest removing it. Although a common anti-abuse mechanism, it's ou= t > of scope for DMARC. +1 > > >> 9. Domain Owner Actions > 5.5 in -08 > >> Last paragraph doesn't seem like it fits. Suggest it be removed. > While I could imagine a better place for it in the doc, having a /terse= / > pointer like this to some authentication pedagogy seems useful to me, i= n > an authentication-related spec... The paragraph I was referencing (having to do with "mailto" URIs) is not in -08. > > >> 10.1 Extract author domain > 6.6.1 in -08 5.6.1, actually > >> "Such messages SHOULD be rejected":=20 > looks like it's been removed. Yes, it has. > > >> 11.1 Discovery > 6.2.1 in -08 > >> Mail Receivers can also discover reporting requests from the >> Organizational Domain. That should be mentioned here. But I'm a little= >> confused why we have another Discovery section at all. > The text's use of the word 'corresponds' handles the mapping to org > domain, IMO. This is more of a comment about document organization. The previous sections have been talking about things that follow discovery of the policy record, and now when talking about aggregate reports there's another section about discovery. Why here; isn't this a little redundant?= > > >> 11.2.1 Email >> >> The whole thing about filenames needs to go away. Since it's only a >> SHOULD requirement, the Report Receiver needs to be able to handle >> reports that don't follow this format as well as those that do.=20 > "SHOULD" is a very strong normative statement. Note that it permits > non-conformance only in the presence of singular knowledge by the > non-conforming party. > > Filename labeling is generally considered useful. Why wouldn't it be > useful here? SHOULD isn't strong enough for the Report Receiver to depend on. There are other ways to get the information that is encoded into the filename. If the spec wants to suggest, "here's a nice file name format that you MAY want to use", that's fine. But SHOULD is both too weak if the recipient can't depend on it and too strong if it's merely advice. > > >> I also >> wonder if some operating systems have trouble with filenames containin= g >> the "!" character.=20 > If they are, they already need to be able to resolve the issue. I suppose. Seems like there might be other choices that would be less likely to cause an issue, but I suspect that ship has sailed already. > > >> 14.1 Data Exposure Considerations Now section 8.1 >> >> Last paragraph: what's an "unexpected Mail Receiver"? That's now paragraph 5, and I now think it's clear enough. >> >> The privacy consideration here, which isn't obvious from the wording, = is >> that users may currently use forwarding in a way that prevents the >> sender from determining the ultimate delivery address. DMARC has the >> potential to break that. This might be important in the case of a user= >> that is trying to distance themselves from a stalker. > How is that a DMARC-specific 'exposure' consideration? Because it's the retrieval (or search for) the DMARC record might reveals that. But on rereading this, paragraph 4 addresses this sufficiently. New issue: Paragraph 3 refers to "Both report types" but since iodef was removed, it should just say "The AFRF report type". > > >> 14.2 Report Recipients >> >> Some potential exists for report recipients to perform traffic analysi= s: >> to obtain metadata about the receiver's traffic. In addition to >> verifying compliance with policies, receivers need to consider that >> before sending reports to a third party. > +1 -Jim From nobody Sun Dec 21 07:38: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 CF3B81A1A95 for ; Sun, 21 Dec 2014 07:38:11 -0800 (PST) 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 SUJDVwD_ygQw for ; Sun, 21 Dec 2014 07:38:09 -0800 (PST) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id D99F81A1A92 for ; Sun, 21 Dec 2014 07:38:08 -0800 (PST) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 097481C38CB; Mon, 22 Dec 2014 00:38:07 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id D216D1A2CFC; Mon, 22 Dec 2014 00:38:06 +0900 (JST) From: "Stephen J. Turnbull" To: Jim Fenton In-Reply-To: <54967461.2070702@bluepopcorn.net> References: <5494A6F5.5020906@dcrocker.net> <54967461.2070702@bluepopcorn.net> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Mon, 22 Dec 2014 00:38:06 +0900 Message-ID: <874mspnhcx.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/GTW5q3djrJHOQz9Z3duiKXR_icc Cc: "dmarc@ietf.org" , "Murray S. Kucherawy" , dcrocker@bbiw.net Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 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, 21 Dec 2014 15:38:13 -0000 Jim Fenton writes: > Hi, Dave - > > On 12/19/2014 02:30 PM, Dave Crocker wrote: > > [2.4 Out of Scope] > >> Bullet 10: Again, DMARC doesn't do authentication, even for domains; it > >> relies on other authentication mechanisms. > > I originally thought this, too, but in fact DMARC does do authentication: > > > > DMARC asserts authenticity of the rfc5322.From field domain name. > > That's a distinct semantic increment over anything SPF or DKIM do on > > their own. > > What it does is different enough from SPF and DKIM that I think it's > overloading the term "authentication" to use it again here. It doesn't > contribute to a clear understanding. It looks at the results of SPF and > DKIM, which operate at the domain level, so this bullet isn't really > necessary. It's important to be precise about these concepts. As I read RFC 4949, Dave is correct. It's true that most of the heavy lifting was done by SPF or DKIM, and in that sense DMARC is very different. Nevertheless, it's the fact that DMARC authenticates the domain of the address in From that makes it useful. And problematic: it is that claim of authentication that justifies use of "p=reject". It had better be in the document. From nobody Sun Dec 21 08:23: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 20A421A1B63 for ; Sun, 21 Dec 2014 08:23:17 -0800 (PST) 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 dDwDG0vnFB10 for ; Sun, 21 Dec 2014 08:23:14 -0800 (PST) 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 354331A1B5F for ; Sun, 21 Dec 2014 08:23:13 -0800 (PST) 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 sBLGN5CT006565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 21 Dec 2014 08:23:09 -0800 Message-ID: <5496F3E0.7040205@dcrocker.net> Date: Sun, 21 Dec 2014 08:22:56 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Jim Fenton References: <5494A6F5.5020906@dcrocker.net> <54967461.2070702@bluepopcorn.net> In-Reply-To: <54967461.2070702@bluepopcorn.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Sun, 21 Dec 2014 08:23:09 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/E_4Amd8eFX5VtiUKk06_kn9TXvg Cc: "dmarc@ietf.org" , "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 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: Sun, 21 Dec 2014 16:23:17 -0000 On 12/20/2014 11:18 PM, Jim Fenton wrote: >> DMARC asserts authenticity of the rfc5322.From field domain name. >> That's a distinct semantic increment over anything SPF or DKIM do on >> their own. > > What it does is different enough from SPF and DKIM that I think it's > overloading the term "authentication" to use it again here. Jim, It's not 'overloading' anything. Authentication is a term of art. It's meaning is well-established. For example: Internet Security Glossary, Version 2 https://tools.ietf.org/html/rfc4949 $ authentication (I) The process of verifying a claim that a system entity or system resource has a certain attribute value. There are many authentication mechanisms. The issue is not whether DMARC's authentication is 'different from' SPF or DKIM. The issue is whether it is authenticating something. It is. The fact that SPF and DKIM are in the mix is not relevant to the question of whether DMARC is authenticating something. It is authenticating the domain name in the rfc5322.From field. Neither SPF nor DKIM make any assertions about the validity of the domain name in the rfc5322.From field. > It doesn't > contribute to a clear understanding. It looks at the results of SPF and > DKIM, which operate at the domain level, so this bullet isn't really > necessary. The results of SPF and DKIM say nothing about the rfc5322.From field. The assertion of validity for the domain name in that field is a bit of value-add that is specific to DMARC. Value-add of that sort is classically called authentication. >>> 3.1.2 General Concepts >> ... >>> Paragraph 3 doesn't quite capture the sense of alignment properly, >>> especially for SPF. A message that is authorized by SPF might have an >>> unaligned envelope-from address, so the validity of SPF for such >>> messages is moot. >> I think this is par. 2 in the -08 draft and that text looks fine to me. > > Yes, paragraph 2. My point is that a the last sentence seems to say that > if a message arrives from a server authorized by SPF, it will not be > affected by DMARC policies. ... >> If someone thinks the text needs changing, they need to offer candidate >> text. > > DMARC's filtering function is based on whether SPF or DKIM can provide > an authenticated, aligned identifier for the message under > consideration. Messages that purport to be from a Domain Owner's domain > and arrive from servers that are not authorized by that domain's SPF and > do not contain an appropriate DKIM signature can be affected by DMARC > policies. I don't read that existing last sentence the way you do. However on reflection, I think the first sentence can be improved and would prefer some wording changes for the paragraph, too. Perhaps: DMARC's filtering function is based on whether the rfc5322.From field domain is aligned with (matches) an authenticated domain name from SPF or DKIM. When a message has a published DMARC policy associated with the domain name in the RFC5322.From field, and that domain is not validated through SPF or DKIM, the disposition of that message can be affected by the DMARC policy. >>> 4. Policy >>> >>> Paragraph 4 basically says, ... >> There are, of course, other possibilities, such as not having DMARC >> pursue operational nuance that makes the spec more complex, trying to >> handle special cases. That is, if a site isn't ready to use DMARC, it >> shouldn't. > > The point is that use of DMARC may come first, and makes SPF and DKIM > more brittle. Domains that have deployed DMARC may want to deploy both > SPF and DKIM (having already deployed one or the other), but it would be > better if they didn't have to turn off DMARC to do so. It does not 'make SPF and DKIM more brittle'. It does not affect their operation at all. As for DMARC 'coming first', I don't understand that. DMARC can't operate without an existing SPF and/or DKIM infrastructure. At any rate, as for your 'it would be better' assertion, it well might be true. But responding to that concern can't happen in isolation. To deal with it appears to impose more overall complexity. And systems complexity creates its own base of errors that we would then have to deal with. >>> 5. DMARC policy record >>> >>> Paragraph 2: Again, "matches perfectly with the DNS" is an inaccurate >>> characterization. If the query requirement matched perfectly with the >>> DNS, DNS would have a way to determine the Administrative Domain without >>> resorting to suffix lists and such. Just strike the sentence; this isn't >>> relevant here anyway. >> -08 doesn't have this language. > > Now section 5.1, paragraph 2. Honestly, this reads like marketing fluff > that doesn't belong in a specification like this. 'Perfectly' and 'considerable' do tend to add a bit of marketing tone. I think that dropping those two words moves the entire paragraph into the realm of offering a simple and common justification for use of the DNS, presumably instead of inventing a new query mechanism. People often do not understand the benefit of re-using an existing mechanism rather than defining a new one, especially when the mechanism involves a deployment and operation of a global infrastructure. (cf, DKIM vs. IIM...) >>> 7.1 Verifying External Destinations >>> >>> Paragraph 3: "verification steps SHOULD be taken" These steps are to >>> protect another domain from attack. It needs to be a MUST. >> 6.1 in -08. >> >> Given the problems with the search for org domain, a SHOULD is as far as >> is practical here. >> >> I'd suggest noting that that's a reason this can't be a MUST. > > This is already predicated on having discovered the DMARC policy, so the > org domain search is irrelevant. > > If this is only a SHOULD, under what circumstances might a Mail Receiver > follow a different procedure, or not do this at all? When the receiver has some basis for knowing that it's ok to deviate from this portion of the specification. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Dec 22 07:44: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 BDD2F1A1A9A for ; Mon, 22 Dec 2014 07:44:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.103 X-Spam-Level: X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 pea7LKn_esLZ for ; Mon, 22 Dec 2014 07:44:05 -0800 (PST) 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 B81B51A1A69 for ; Mon, 22 Dec 2014 07:44:05 -0800 (PST) Received: from kitterman-optiplex-9020m.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 CFA84C40103 for ; Mon, 22 Dec 2014 09:44:04 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1419263044; bh=J1K9N7cpxNLXuyFPbNWr9xCcKcROPMu4hoeUFS+yq9g=; h=From:To:Subject:Date:In-Reply-To:References:From; b=utlXTskm8jGcQb/WDwSLq1DiCYmJuJmQJ87e/Ti52ctsxP5MP+Wlx83NNmGsd7DRO neWHXExLpPBMbV1nRgHMr9hv+rV2xh+F2WGHsBgtRDYPv3FxRO4h/fxQU+BCwMKLTG ZjKkaTS0Gy2T7SSHWPMUIshbM7Dz7Y55M0Spk24c= From: Scott Kitterman To: dmarc@ietf.org Date: Mon, 22 Dec 2014 10:44:04 -0500 Message-ID: <6858606.AfKicQ9CJZ@kitterman-optiplex-9020m> User-Agent: KMail/4.13.3 (Linux/3.13.0-37-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Yp3bStKMED6bZT9MgAXIsZvJjQU Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 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, 22 Dec 2014 15:44:07 -0000 On Friday, December 19, 2014 01:30:10 PM Murray S. Kucherawy wrote: > Colleagues, > > draft-kucherawy-dmarc-base is nearing IESG conflict review, and it's been > pointed out that a review from back in April has not been properly attended > to. > > Could I get the WG (forgive me, co-chairs!) to comment on this so that I > can see what changes might be appropriate here? Having this resolved > before the telechat in the first week of January would be truly delightful. > > Note that some amount of this may have already been addressed (it was about > -04; -08 is current, and at least the ABNF issue Jim raises will be handled > in -09), so please at least check -08 when considering your responses. > > The posting: > http://www.ietf.org/mail-archive/web/dmarc/current/msg00764.html There was a recent thread on postfix-users about DMARC rejections when there are DNS errors that caused me to review -08 to see what it says on the matter. At the end of section 5.6.2, it says: Handling of messages for which SPF and/or DKIM evaluation encounters a DNS error is left to the discretion of the Mail Receiver. Further discussion is available in Section 5.6.3. My reading of 5.6.3 though is that it only discusses DNS errors in the context of failing to retrieve the DMARC record. Any discussion about handling DNS errors for SPF/DKIM seems to be missing. Scott K From nobody Mon Dec 22 10:40: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 298B31A1BF6 for ; Mon, 22 Dec 2014 10:40:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 JaVa0HEqBG4j for ; Mon, 22 Dec 2014 10:40:39 -0800 (PST) Received: from mx-out-1.zmailcloud.com (01.zmailcloud.com [192.198.85.104]) by ietfa.amsl.com (Postfix) with ESMTP id 294321A1BEC for ; Mon, 22 Dec 2014 10:40:39 -0800 (PST) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id A9DD5564BCD; Mon, 22 Dec 2014 12:40:38 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 8B9086027C; Mon, 22 Dec 2014 12:40:38 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d_FMckSk6sOH; Mon, 22 Dec 2014 12:40:38 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 52D3F60153; Mon, 22 Dec 2014 12:40:38 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-2.01.com 52D3F60153 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1419273638; bh=gA2QqOHyslKz4uq72EulAIjeufRaC1f0at8MZLCfgcM=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=HquhZQna435pvZIQ0H5znrafDbjNb8KW5e5DlZB4kyDScH2C6h3kktsnmXce1mcxO c3Iwlrx8B8guEUfy5gr/u4dgnQ2F7zE2P63fAu5BIih9PyHn5sxHYIhfVh4yLrNgf5 mvy8WiEjtPmst3zouWSh6HESzqkFWrd3eZs+gzQs= Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 397B06027C; Mon, 22 Dec 2014 12:40:38 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id SfnT-nu6TWY1; Mon, 22 Dec 2014 12:40:38 -0600 (CST) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-2.01.com (Postfix) with ESMTP id 16EB760153; Mon, 22 Dec 2014 12:40:38 -0600 (CST) Date: Mon, 22 Dec 2014 12:40:36 -0600 (CST) From: Franck Martin To: Scott Kitterman Message-ID: <951030635.14870.1419273636075.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <6858606.AfKicQ9CJZ@kitterman-optiplex-9020m> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.1.101.178] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF34 (Mac)/8.0.5_GA_5839) Thread-Topic: Jim Fenton's review of -04 Thread-Index: lKz/DnmO+LZ66y3FBTCHGM3YMETSyw== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/s9G5dDUpfAYgDLaXyOHWoP5Wr3o Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 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, 22 Dec 2014 18:40:41 -0000 ----- Original Message ----- > From: "Scott Kitterman" > To: dmarc@ietf.org > Sent: Monday, December 22, 2014 7:44:04 AM > Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 >=20 > On Friday, December 19, 2014 01:30:10 PM Murray S. Kucherawy wrote: > > Colleagues, > >=20 > > draft-kucherawy-dmarc-base is nearing IESG conflict review, and it's be= en > > pointed out that a review from back in April has not been properly atte= nded > > to. > >=20 > > Could I get the WG (forgive me, co-chairs!) to comment on this so that = I > > can see what changes might be appropriate here? Having this resolved > > before the telechat in the first week of January would be truly delight= ful. > >=20 > > Note that some amount of this may have already been addressed (it was a= bout > > -04; -08 is current, and at least the ABNF issue Jim raises will be han= dled > > in -09), so please at least check -08 when considering your responses. > >=20 > > The posting: > > http://www.ietf.org/mail-archive/web/dmarc/current/msg00764.html >=20 > There was a recent thread on postfix-users about DMARC rejections when th= ere > are DNS errors that caused me to review -08 to see what it says on the > matter. >=20 > At the end of section 5.6.2, it says: >=20 > Handling of messages for which SPF and/or DKIM evaluation encounters > a DNS error is left to the discretion of the Mail Receiver. Further > discussion is available in Section 5.6.3. >=20 > My reading of 5.6.3 though is that it only discusses DNS errors in the > context > of failing to retrieve the DMARC record. Any discussion about handling D= NS > errors for SPF/DKIM seems to be missing. I had a few issues with a large sender, which had their TXT record overload= ed (not uncommon, this is where google analytics and other wants to prove w= ho you are). Combined with a low TTL, it would happen rarely, but frequentl= y enough that an SPF could not be assessed and DMARC would fail. The fallba= ck mechanism in bind is slow when you have edns issues. 1) I wished that SPF record location would have been _spf. 2) may be here the recommendation, is that with DMARC it is best to tempfai= l an email if you can=E2=80=99t get an SPF result due to DNS (same with DKI= M), rather than carry on and pass the result to higher policy layers. From nobody Mon Dec 22 11:02: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 86C741A6D3F for ; Mon, 22 Dec 2014 11:02:32 -0800 (PST) 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 akSnmLNC1Q6b for ; Mon, 22 Dec 2014 11:02:30 -0800 (PST) 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 409831A3BA3 for ; Mon, 22 Dec 2014 11:02:30 -0800 (PST) Received: from kitterman-optiplex-9020m.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 749FAC40103 for ; Mon, 22 Dec 2014 13:02:28 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1419274948; bh=Z+O8YKSCJUHZTT+uvAvUnXedw0rxF5IKVcpV0q24rMg=; h=From:To:Subject:Date:In-Reply-To:References:From; b=j661/EtvVx2z8rQkUMP72Z87GJBJNlDTqP+0+WL4tXq3KcZ0ClatlJnVE/+LXhzCU MjmjYpSxHrSVyO7GTxQtMCCi2YdS89K51iKVgMnjcpmx+dZqUZaRmRvb9w37ep8X8R zHKkAXjeZs0dvl5HK/RyhQq0VLxvpo79xrJSJrqM= From: Scott Kitterman To: dmarc@ietf.org Date: Mon, 22 Dec 2014 14:02:28 -0500 Message-ID: <4068953.ZrKghXMp7t@kitterman-optiplex-9020m> User-Agent: KMail/4.13.3 (Linux/3.13.0-37-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <951030635.14870.1419273636075.JavaMail.zimbra@peachymango.org> References:

<951030635.14870.1419273636075.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/1p0mrxMWQ3On43YLn_T43w_bs-w Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 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, 22 Dec 2014 19:02:32 -0000 On Monday, December 22, 2014 12:40:36 PM Franck Martin wrote: > ----- Original Message ----- >=20 > > From: "Scott Kitterman" > > To: dmarc@ietf.org > > Sent: Monday, December 22, 2014 7:44:04 AM > > Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 > >=20 > > On Friday, December 19, 2014 01:30:10 PM Murray S. Kucherawy wrote:= > > > Colleagues, > > >=20 > > > draft-kucherawy-dmarc-base is nearing IESG conflict review, and i= t's > > > been > > > pointed out that a review from back in April has not been properl= y > > > attended > > > to. > > >=20 > > > Could I get the WG (forgive me, co-chairs!) to comment on this so= that I > > > can see what changes might be appropriate here? Having this reso= lved > > > before the telechat in the first week of January would be truly > > > delightful. > > >=20 > > > Note that some amount of this may have already been addressed (it= was > > > about > > > -04; -08 is current, and at least the ABNF issue Jim raises will = be > > > handled > > > in -09), so please at least check -08 when considering your respo= nses. > > >=20 > > > The posting: > > > http://www.ietf.org/mail-archive/web/dmarc/current/msg00764.html > >=20 > > There was a recent thread on postfix-users about DMARC rejections w= hen > > there are DNS errors that caused me to review -08 to see what it sa= ys on > > the matter. > >=20 > > At the end of section 5.6.2, it says: > > Handling of messages for which SPF and/or DKIM evaluation encoun= ters > > a DNS error is left to the discretion of the Mail Receiver. Fur= ther > > discussion is available in Section 5.6.3. > >=20 > > My reading of 5.6.3 though is that it only discusses DNS errors in = the > > context > > of failing to retrieve the DMARC record. Any discussion about hand= ling > > DNS > > errors for SPF/DKIM seems to be missing. >=20 > I had a few issues with a large sender, which had their TXT record > overloaded (not uncommon, this is where google analytics and other wa= nts to > prove who you are). Combined with a low TTL, it would happen rarely, = but > frequently enough that an SPF could not be assessed and DMARC would f= ail. > The fallback mechanism in bind is slow when you have edns issues. >=20 > 1) I wished that SPF record location would have been _spf. > 2) may be here the recommendation, is that with DMARC it is best to t= empfail > an email if you can=E2=80=99t get an SPF result due to DNS (same with= DKIM), rather > than carry on and pass the result to higher policy layers. The underscore location was considered at the time, but in 2004 we beli= eved=20 that it would have created a significant barrier to deployment since ma= ny=20 tools/service provider control panels at the time didn't allow it. It = would=20 certainly be better now, but as with type SPF, there's no transition=20= mechanism. If we were going to transition SPF records anywhere, it wou= ld have=20 been better to do it to the new RR type. Both SPF and DKIM do have a temporary error state, so it's certainly po= ssible=20 to include this. I think it's totally up to the receiver if they choos= e to=20 defer (45X) or choose not to use DMARC in case of a temporary error in = one of=20 the underlying protocols (i.e. SPF or DKIM) making it impossible to mak= e a=20 complete DMARC evaluation. Perhaps 5.6.3 needs something like "SHOULD NOT act on DMARC policy if a= =20 temporary error in SPF or DKIM processing prevents a full evaluation." Scott K From nobody Mon Dec 22 11:11: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 233DB1A1EF2 for ; Mon, 22 Dec 2014 11:11:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 fdMqeIk3V9Ul for ; Mon, 22 Dec 2014 11:11:30 -0800 (PST) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id EA18D1A6F2B for ; Mon, 22 Dec 2014 11:11:15 -0800 (PST) Received: from mx14.mailtransaction.com (mx11.mailtransaction.com [88.198.59.230]) by mx20.mailtransaction.com (Postfix) with ESMTP id 3k5qz63QNjz1L8cr; Mon, 22 Dec 2014 20:11:14 +0100 (CET) Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx14.mailtransaction.com (Postfix) with ESMTP id 3k5qz61tvHz5MhcJ; Mon, 22 Dec 2014 20:11:14 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id 46FE9123488; Mon, 22 Dec 2014 20:11:18 +0100 (CET) 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 Xx4nnPkqGzBH; Mon, 22 Dec 2014 20:11:12 +0100 (CET) Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id ADAF6123482; Mon, 22 Dec 2014 20:11:12 +0100 (CET) Message-ID: <54986CCC.70200@sonnection.nl> Date: Mon, 22 Dec 2014 20:11:08 +0100 From: "Rolf E. Sonneveld" Organization: Sonnection B.V. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Scott Kitterman , dmarc@ietf.org References:

<951030635.14870.1419273636075.JavaMail.zimbra@peachymango.org> <4068953.ZrKghXMp7t@kitterman-optiplex-9020m> In-Reply-To: <4068953.ZrKghXMp7t@kitterman-optiplex-9020m> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1419275474; bh=rFk1FUcHLMR0ET2WHkaQcSGbgfSL6mb41sX3f2QZqFI=; h=Message-ID:Date:From:To:Subject:From; b=Z5mCgy61/0hY7MK+TL6uAldnQqU0L6pctAVOakPmPvcxo4kHDUxvGMMKcCLKfxfnY mayQVnrJdTqoLPFyHspX3Tw8NKmjPJ17fI9vdLdqlOx6OSpNFahcYr/Ztm6wYEFQSZ UAcBjyzhpWPJ2lytYrp0hi7+D6Y5f56SxrHwBK2M= DKIM-Filter: OpenDKIM Filter v2.8.2 mx20.mailtransaction.com 3k5qz63QNjz1L8cr Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/GX1EoKOHsgRADtVmLOH2Zshm6e4 Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 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, 22 Dec 2014 19:11:34 -0000 On 12/22/2014 08:02 PM, Scott Kitterman wrote: > On Monday, December 22, 2014 12:40:36 PM Franck Martin wrote: >> ----- Original Message ----- >> >>> From: "Scott Kitterman" >>> To: dmarc@ietf.org >>> Sent: Monday, December 22, 2014 7:44:04 AM >>> Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 >>> >>> On Friday, December 19, 2014 01:30:10 PM Murray S. Kucherawy wrote: >>>> Colleagues, >>>> >>>> draft-kucherawy-dmarc-base is nearing IESG conflict review, and it's >>>> been >>>> pointed out that a review from back in April has not been properly >>>> attended >>>> to. >>>> >>>> Could I get the WG (forgive me, co-chairs!) to comment on this so th= at I >>>> can see what changes might be appropriate here? Having this resolve= d >>>> before the telechat in the first week of January would be truly >>>> delightful. >>>> >>>> Note that some amount of this may have already been addressed (it wa= s >>>> about >>>> -04; -08 is current, and at least the ABNF issue Jim raises will be >>>> handled >>>> in -09), so please at least check -08 when considering your response= s. >>>> >>>> The posting: >>>> http://www.ietf.org/mail-archive/web/dmarc/current/msg00764.html >>> There was a recent thread on postfix-users about DMARC rejections whe= n >>> there are DNS errors that caused me to review -08 to see what it says= on >>> the matter. >>> >>> At the end of section 5.6.2, it says: >>> Handling of messages for which SPF and/or DKIM evaluation encount= ers >>> a DNS error is left to the discretion of the Mail Receiver. Furt= her >>> discussion is available in Section 5.6.3. >>> >>> My reading of 5.6.3 though is that it only discusses DNS errors in th= e >>> context >>> of failing to retrieve the DMARC record. Any discussion about handli= ng >>> DNS >>> errors for SPF/DKIM seems to be missing. >> I had a few issues with a large sender, which had their TXT record >> overloaded (not uncommon, this is where google analytics and other wan= ts to >> prove who you are). Combined with a low TTL, it would happen rarely, b= ut >> frequently enough that an SPF could not be assessed and DMARC would fa= il. >> The fallback mechanism in bind is slow when you have edns issues. >> >> 1) I wished that SPF record location would have been _spf. >> 2) may be here the recommendation, is that with DMARC it is best to te= mpfail >> an email if you can=E2=80=99t get an SPF result due to DNS (same with = DKIM), rather >> than carry on and pass the result to higher policy layers. > The underscore location was considered at the time, but in 2004 we beli= eved > that it would have created a significant barrier to deployment since ma= ny > tools/service provider control panels at the time didn't allow it. It = would > certainly be better now, but as with type SPF, there's no transition > mechanism. If we were going to transition SPF records anywhere, it wou= ld have > been better to do it to the new RR type. > > Both SPF and DKIM do have a temporary error state, so it's certainly po= ssible > to include this. I think it's totally up to the receiver if they choos= e to > defer (45X) or choose not to use DMARC in case of a temporary error in = one of > the underlying protocols (i.e. SPF or DKIM) making it impossible to mak= e a > complete DMARC evaluation. > > Perhaps 5.6.3 needs something like "SHOULD NOT act on DMARC policy if a > temporary error in SPF or DKIM processing prevents a full evaluation." +1 /rolf From nobody Mon Dec 22 11:16: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 41CE71A6EF3 for ; Mon, 22 Dec 2014 11:16:19 -0800 (PST) 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 8Q8nFpPj0TL1 for ; Mon, 22 Dec 2014 11:16:17 -0800 (PST) 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 DC0F31A6EEC for ; Mon, 22 Dec 2014 11:16:16 -0800 (PST) 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 sBMJGCdl012939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 22 Dec 2014 11:16:15 -0800 Message-ID: <54986DF1.9060807@dcrocker.net> Date: Mon, 22 Dec 2014 11:16:01 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: R.E.Sonneveld@sonnection.nl, Scott Kitterman References:

<951030635.14870.1419273636075.JavaMail.zimbra@peachymango.org> <4068953.ZrKghXMp7t@kitterman-optiplex-9020m> <54986CCC.70200@sonnection.nl> In-Reply-To: <54986CCC.70200@sonnection.nl> 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]); Mon, 22 Dec 2014 11:16:16 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/One8k00s1AIAbev4VTua88OqBHU Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 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, 22 Dec 2014 19:16:19 -0000 On 12/22/2014 11:11 AM, Rolf E. Sonneveld wrote: >> >> Perhaps 5.6.3 needs something like "SHOULD NOT act on DMARC policy if a >> temporary error in SPF or DKIM processing prevents a full evaluation." > > +1 We need to be careful about how this is phrased. I specifically suspect that the above suggested wording is a bad idea, or worse, probably wrong. DMARC /requires/ prior validation of the author From domain via a lower-level mechanism. SPF and DKIM are defined for now. If neither of them validates the domain, then DMARC fails. There is no 'should' about it. It fails. Failing means that the polices are not applied. As in MUST NOT be applied. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Dec 22 11:39: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 338B81AC3D5 for ; Mon, 22 Dec 2014 11:39:33 -0800 (PST) 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 teVmyLaCPpjs for ; Mon, 22 Dec 2014 11:39:30 -0800 (PST) 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 53F5C1AC3C8 for ; Mon, 22 Dec 2014 11:39:30 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id x13so7462110wgg.5 for ; Mon, 22 Dec 2014 11:39:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=BQ5thOAWzrRWFpZ5Id32mxvdRcmQfUiZVaoDSIBz84g=; b=E6G1j5J/QoixM5Y7v/AAv6qzHnKAn4l/U5KDMeQ502M2ouDK8oVTRDh/UCUNu6T+Pw IGz9Y4/hyN8fD9LQauieDcQ8od8jNB7HLLQvpEpCKLHCq/LfN6YKH87kqhQIBaqrbEti XVZ6aitXmSits/VGXbFubHOoEm5KR4gXp01Y8= 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:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=BQ5thOAWzrRWFpZ5Id32mxvdRcmQfUiZVaoDSIBz84g=; b=Cny7K5nLnem9usN/HqpB1pcPUyHg+QZBf1rzJkswqwPmxLxGNtqWvhU+HN8plikK9j 8V84D4QZPQeYX4z08WGPsPBWdQ22wgHdbga738ez8qWZWNJ9FuWmBhBy5JP3lbGn6joK WVov5N5d7vbh2ZOUg/z50mH02NV+Au1z00ZM6+E81GVwP3Hr7lKnGHr5R8Yyt4Ah1t4b sgmyfG/8JAmUCo5G2CP071iCcF4IsorQ17HI+z/oTjs0UG2W7gd4Dq/y2znndrjIKei2 L9cgci+CjJ444GVjEuomgKuggsVGM7bo7mlFWaIMgBkoR4zoRrgXTSkv3fRbn8PZV693 +0Fw== X-Gm-Message-State: ALoCoQmkC7PdRMHQLndrBzMHlzO2+bzMLF3PKiqKv0x8s4wgRTlvOwME6H0Qac19YmRmylXUQANk MIME-Version: 1.0 X-Received: by 10.194.109.6 with SMTP id ho6mr45095433wjb.93.1419277169008; Mon, 22 Dec 2014 11:39:29 -0800 (PST) Sender: kurta@drkurt.com Received: by 10.194.41.161 with HTTP; Mon, 22 Dec 2014 11:39:28 -0800 (PST) In-Reply-To: <54986DF1.9060807@dcrocker.net> References:

<951030635.14870.1419273636075.JavaMail.zimbra@peachymango.org> <4068953.ZrKghXMp7t@kitterman-optiplex-9020m> <54986CCC.70200@sonnection.nl> <54986DF1.9060807@dcrocker.net> Date: Mon, 22 Dec 2014 11:39:28 -0800 X-Google-Sender-Auth: 0gPmoQIvpqE_Pa2hFsnRD4DBaIY Message-ID: From: Kurt Andersen To: Dave Crocker , "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=047d7bf10b507f37f1050ad3374a Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/xMmbCJlbxSbVvDtNsFJVQjJqAVA Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 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, 22 Dec 2014 19:39:33 -0000 --047d7bf10b507f37f1050ad3374a Content-Type: text/plain; charset=UTF-8 On Mon, Dec 22, 2014 at 11:16 AM, Dave Crocker wrote: > On 12/22/2014 11:11 AM, Rolf E. Sonneveld wrote: > >> > >> Perhaps 5.6.3 needs something like "SHOULD NOT act on DMARC policy if a > >> temporary error in SPF or DKIM processing prevents a full evaluation." > > > > +1 > > We need to be careful about how this is phrased. I specifically suspect > that the above suggested wording is a bad idea, or worse, probably wrong. > > DMARC /requires/ prior validation of the author From domain via a > lower-level mechanism. SPF and DKIM are defined for now. If neither of > them validates the domain, then DMARC fails. > > There is no 'should' about it. It fails. > > Failing means that the polices are not applied. As in MUST NOT be applied. DMARC is built on a positive assertion model. To say that a failure means that no policy is applied is contrary to the model. The policy is explicitly *applied* if neither SPF nor DMARC validates the aligned domain. I disagree with the "not act. . .[if not] full evaluation" - if SPF tempfails, but DKIM passes, that is sufficient for a DMARC pass and I don't see any reason to force the DMARC evaluation to some other value. If SPF tempfails and DKIM is missing or fails, then treating the outcome as "unknown" seems reasonable If SPF or DKIM come up with a temp error, that could be an attack vector to bypass DMARC enforcement, but if receivers simply tempfail such mail, it seems consistent to me with the handling of any other error that is expected to be transient in nature. If it really is an attack of some sort, the mail will eventually time out on the sender's machine. I'm not sure that adding this detail prior to the WG's work output would be prudent or in keeping with the intent of the current "stake in the sand" spec. --Kurt --047d7bf10b507f37f1050ad3374a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Dec 22, 2014 at 11:16 AM, Dave Crocker <dhc@dcro= cker.net> wrote:

On 12/22/2014 11:11 AM, Rolf E. Sonneveld wrote:
>>
>> Perhaps 5.6.3 needs something like "SHOULD NOT act on DMARC p= olicy if a
>> temporary error in SPF or DKIM processing prevents a full evaluati= on."
>
> +1

We need to be careful about how this is phrased.=C2=A0 I specificall= y suspect
that the above suggested wording is a bad idea, or worse, probably wrong.
DMARC /requires/ prior validation of the author From domain via a
lower-level mechanism.=C2=A0 SPF and DKIM are defined for now.=C2=A0 If nei= ther of
them validates the domain, then DMARC fails.

There is no 'should' about it.=C2=A0 It fails.

Failing means that the polices are not applied.=C2=A0 As in MUST NOT be app= lied.

DMARC is built on a positive assertio= n model. To say that a failure means that no policy is applied is contrary = to the model. The policy is explicitly *applied* if neither SPF nor DMARC v= alidates the aligned domain.

I disagree with the "n= ot act. . .[if not] full evaluation" - if SPF tempfails, but DKIM pass= es, that is sufficient for a DMARC pass and I don't see any reason to f= orce the DMARC evaluation to some other value. If SPF tempfails and DKIM is= missing or fails, then treating the outcome as "unknown" seems r= easonable

If SPF or DKIM come up with a temp error, that = could be an attack vector to bypass DMARC enforcement, but if receivers sim= ply tempfail such mail, it seems consistent to me with the handling of any = other error that is expected to be transient in nature. If it really is an = attack of some sort, the mail will eventually time out on the sender's = machine.

I'm not sure that adding this detail prior to the WG= 9;s work output would be prudent or in keeping with the intent of the curre= nt "stake in the sand" spec.

--Kurt

--047d7bf10b507f37f1050ad3374a-- From nobody Mon Dec 22 11:47: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 9BEA21A6EE0 for ; Mon, 22 Dec 2014 11:47:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 1Xjfr_3aV3LQ for ; Mon, 22 Dec 2014 11:47:19 -0800 (PST) Received: from mx10.mailtransaction.com (mx10.mailtransaction.com [88.198.59.241]) by ietfa.amsl.com (Postfix) with ESMTP id 3204A1A6F80 for ; Mon, 22 Dec 2014 11:47:19 -0800 (PST) Received: from mx24.mailtransaction.com (mx21.mailtransaction.com [78.46.16.236]) by mx10.mailtransaction.com (Postfix) with ESMTP id 3k5rmj4VJzz5MhcJ; Mon, 22 Dec 2014 20:47:17 +0100 (CET) Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx24.mailtransaction.com (Postfix) with ESMTP id 3k5rmj31mWz1L8cr; Mon, 22 Dec 2014 20:47:17 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id 637F8123488; Mon, 22 Dec 2014 20:47:21 +0100 (CET) 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 SMMlfFssDdgx; Mon, 22 Dec 2014 20:47:16 +0100 (CET) Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id DB250123482; Mon, 22 Dec 2014 20:47:15 +0100 (CET) Message-ID: <5498753F.9090300@sonnection.nl> Date: Mon, 22 Dec 2014 20:47:11 +0100 From: "Rolf E. Sonneveld" Organization: Sonnection B.V. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: dcrocker@bbiw.net, Scott Kitterman References:

<951030635.14870.1419273636075.JavaMail.zimbra@peachymango.org> <4068953.ZrKghXMp7t@kitterman-optiplex-9020m> <54986CCC.70200@sonnection.nl> <54986DF1.9060807@dcrocker.net> In-Reply-To: <54986DF1.9060807@dcrocker.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1419277637; bh=/o3Cz2/OA1/QymeFflB7wAJS1gjcp4Z1AZanslpXXXk=; h=Message-ID:Date:From:To:Subject:From; b=F+mJUeBrilceuHAw/Xnt3gXnHcAVIISmDD0MMCcu4YaoE3XS9UmGj5WH44HMzOya+ FHs/oc+rtwmifhEARXiO0xgTcQxB7I+kfLfa4vEYGOWl2liSvXNiRWNbNQMUkjGTBr EWZepB/OoNMHYCJ6Ww6F6TmQXcRkqK6Ahn2d2EFY= DKIM-Filter: OpenDKIM Filter v2.8.2 mx10.mailtransaction.com 3k5rmj4VJzz5MhcJ Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/UsxqwLFWv2at36x5vVxukte_vQ4 Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 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, 22 Dec 2014 19:47:21 -0000 On 12/22/2014 08:16 PM, Dave Crocker wrote: > On 12/22/2014 11:11 AM, Rolf E. Sonneveld wrote: >>> Perhaps 5.6.3 needs something like "SHOULD NOT act on DMARC policy if a >>> temporary error in SPF or DKIM processing prevents a full evaluation." >> +1 > > We need to be careful about how this is phrased. I specifically suspect > that the above suggested wording is a bad idea, or worse, probably wrong. > > DMARC /requires/ prior validation of the author From domain via a > lower-level mechanism. SPF and DKIM are defined for now. If neither of > them validates the domain, then DMARC fails. What do you mean with 'validates'?: a) confirm that the domain exists and that the required information for the lower-level mechanism(s) could successfully be determined? b) 'authenticates' c) something else? Assuming you mean a) (or something that is close to it), then the problem here is: what if SPF cannot be 'validated' while DKIM can, and vice versa? > > There is no 'should' about it. It fails. > > Failing means that the polices are not applied. As in MUST NOT be applied. This seems to me to be contradictory of the way the word 'fails' is used in http://tools.ietf.org/id/draft-kucherawy-dmarc-base-08.txt. For example: how should I interpret these last two lines, when comparing this with what is being said about 'fails' in the context of 'p=quarantine' and 'p=reject': > quarantine: The Domain Owner wishes to have email that fails the > DMARC mechanism check to be treated by Mail Receivers as > suspicious. Depending on the capabilities of the Mail > Receiver, this can mean "place into spam folder", "scrutinize > with additional intensity", and/or "flag as suspicious". and > reject: The Domain Owner wishes for Mail Receivers to reject > email that fails the DMARC mechanism check. Rejection SHOULD > occur during the SMTP transaction. See Section 9.3 for some > discussion of SMTP rejection methods and their implications. Please read http://tools.ietf.org/id/draft-kucherawy-dmarc-base-08.txt again and mark every occurrence of he word 'fail' or 'fails'. Often it is used in the context of DKIM and SPF checks, sometimes in the context of DMARC mechanisms etc. I'm confused. /rolf From nobody Mon Dec 22 11:53: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 703C41A6FF6 for ; Mon, 22 Dec 2014 11:53:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 b1XFxxIUGyqm for ; Mon, 22 Dec 2014 11:53:32 -0800 (PST) Received: from mx-out-1.zmailcloud.com (01.zmailcloud.com [192.198.85.104]) by ietfa.amsl.com (Postfix) with ESMTP id 171B41A6FED for ; Mon, 22 Dec 2014 11:53:31 -0800 (PST) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 9BA38564BAC; Mon, 22 Dec 2014 13:53:30 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 92DBC6028C; Mon, 22 Dec 2014 13:53:30 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EgOwKaJM-fhY; Mon, 22 Dec 2014 13:53:30 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 66EC66028D; Mon, 22 Dec 2014 13:53:30 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-2.01.com 66EC66028D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1419278010; bh=qsJKiEA+eo4IRJQEhLj0K2O+Nkrb4wEGLv4wUogXzhA=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=Ufntz/cxNYeD0F+/tk7VFD/OQTHDrHyi1jf6dgp5CoYfXuMAC/as08eJp5HO5kag2 XOSqkQgx9Dt0ygu8vM9MiLyTvsLV42xLxxmEZJGsVtBSsuaB1cXkgmu7Yz/AeIhfk+ tV8zWCnwxgmbREWQaT7xluyloBhxOcAcGrh6q10Y= Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 5019B6028C; Mon, 22 Dec 2014 13:53:30 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id h7sW7_2SRaOe; Mon, 22 Dec 2014 13:53:30 -0600 (CST) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-2.01.com (Postfix) with ESMTP id 2DA0860288; Mon, 22 Dec 2014 13:53:30 -0600 (CST) Date: Mon, 22 Dec 2014 13:53:30 -0600 (CST) From: Franck Martin To: dcrocker@bbiw.net Message-ID: <1219737888.17066.1419278010000.JavaMail.zimbra@peachymango.org> In-Reply-To: References:

<951030635.14870.1419273636075.JavaMail.zimbra@peachymango.org> <4068953.ZrKghXMp7t@kitterman-optiplex-9020m> <54986CCC.70200@sonnection.nl> <54986DF1.9060807@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]); Mon, 22 Dec 2014 12:27:27 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/auyf50tgL9UuxDpeAgdaS1tQoqY Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 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, 22 Dec 2014 20:27:29 -0000 On 12/22/2014 11:39 AM, Kurt Andersen wrote: > Failing means that the polices are not applied. As in MUST NOT be > applied. > > > DMARC is built on a positive assertion model. To say that a failure > means that no policy is applied is contrary to the model. The policy is > explicitly *applied* if neither SPF nor DMARC validates the aligned domain oops. sorry. right. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Dec 23 21:45: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 2DE751ACCDF for ; Tue, 23 Dec 2014 21:45:45 -0800 (PST) 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 V4hFqhkYh1JJ for ; Tue, 23 Dec 2014 21:45:41 -0800 (PST) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD7451ACC82 for ; Tue, 23 Dec 2014 21:45:40 -0800 (PST) Received: by mail-wg0-f51.google.com with SMTP id x12so10512276wgg.38 for ; Tue, 23 Dec 2014 21:45:39 -0800 (PST) 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=rJqurFZe6PtxBUl2yTZs5GQ9y8m0tX26o45Tlp34rxc=; b=ZzA6V+BoCU3ZyJZPWluBRazjniiYR1BwDr0Ubx27SBtVcLs7oby0H52GjtdyPtXfnJ xpWgesblKITMHPeZKYUBnD3Z9Ks7SLQXyVezsv2nVzeUEu3yaFDJ7P5KNPVTnmFZSFvl S2imXp1YDer7S50kxQEK3Ydt1sSzGUaqbEx67GtuhDg/rIvh2hHGWsFjuU8FkEK9+eIq bjEvBbBgRMwFjId6Xl5rx+vcw0HTQuoke+UhNJQ848XrlXJKd310tHD6SgnlqLDJZzWZ o/6hRbIRafAevcYAKkMv362qmINpz3nTFwShAZr53YeEUgzA6M5wSyA7HgB3VH82IA9h 94Rg== MIME-Version: 1.0 X-Received: by 10.180.218.39 with SMTP id pd7mr48868659wic.21.1419399939168; Tue, 23 Dec 2014 21:45:39 -0800 (PST) Received: by 10.27.204.198 with HTTP; Tue, 23 Dec 2014 21:45:39 -0800 (PST) In-Reply-To: <5463ECBD.9030703@sonnection.nl> References: <5463ECBD.9030703@sonnection.nl> Date: Wed, 24 Dec 2014 00:45:39 -0500 Message-ID: From: "Murray S. Kucherawy" To: "" Content-Type: multipart/alternative; boundary=001a1134cd582b1f31050aefcde0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/nOJUOrOtOkFKpYtXDZ391XA_U2w Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base updated (-06) 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, 24 Dec 2014 05:45:45 -0000 --001a1134cd582b1f31050aefcde0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Rolf, getting back to your review (thanks for the nudge): On Wed, Nov 12, 2014 at 6:26 PM, Rolf E. Sonneveld < R.E.Sonneveld@sonnection.nl> wrote: > > > Abstract: > > This lack of cohesion has several effects: receivers have difficulty > providing feedback to senders about authentication, senders therefore hav= e > difficulty evaluating their authentication deployments, and as a result > neither is able to make effective use of existing authentication technolo= gy. > > > This focuses on the reporting function of DMARC, leaving out the policy > part of it. > > Suggested text: > > This lack of cohesion has several effects: senders have difficulty > providing information about their use of an authentication policy and > receivers have difficulty determining a disposition preferred by senders. > Vice versa, mail receivers have difficulty providing feedback to senders > about authentication, senders therefore have difficulty evaluating their > authentication deployments, and as a result neither is able to make > effective use of existing authentication technology. > > The Abstract appears to have been rewritten since you reviewed it, so a straight text swap won't work anymore. The new text focuses on what's being provided, not what was missing. Do you want to take another run at it? > Introduction: > > [...] mail receivers have tried to protect senders [...] > > > Suggested: > > [...] mail receivers have tried to protect senders and their own > users/customers [...] > > This text no longer appears in the draft. > Starting with "DMARC allows domain owners and receivers to collaborate > by", the terms 'domain owners', 'receivers', 'senders' and 'SMTP > receivers', 'Mail Receivers', 'mail receivers' are used throughout the > document. I'd suggest to add a definition of the term ' Mail Senders' to > the introduction part of chapter 3 and then use only the terms as defined > in 3., throughout the document. Suggested text for the term Mail Sender: > > > - Mail Sender: the sender of mail with a domain for which the Domain > Owner may have published a DKIM public key and/or an SPF authenticatio= n > record and/or a DMARC policy; > > > (although we may want to not mention DKIM or SPF here). > It looks like that got cleared up; -08 has no reference to "Mail Sender". > 2.2 Out of Scope > > Add: > > o cousin domain attacks > Covered in Section 2.4 of -08. > 3.1.2 Key Concepts > > Last sentence: add a reference to this 'other referenced material'. > Good idea; added. > 3.1.3 Flow diagram > > The box titled 'User Mailbox' could give the impression that there's only > one choice for delivery. However, quarantining can be done without delive= ry > to a mailbox. I'd suggest to label this box 'rMDA'. > That's already done in -08. > The part within parentheses of step 6: > > 6. Recipient transport service conducts SPF and DKIM authentication > checks by passing the necessary data to their respective modules, each of > which require queries to the Author Domain=E2=80=99s DNS data (when ident= ifiers are > aligned; see below). > > > might indicate that SPF and DKIM authentication checks need not be > performed when identifiers are not aligned. However, for sake of reportin= g, > SPF and DKIM authentication checks will in general always be done, or am = I > missing something? > I can envision a DMARC implementation that skips SPF or DKIM checks if the corresponding identifiers are not aligned, because they won't be interesting to DMARC in that case. > 3.1.4.1 DKIM-authenticated Identifiers > > remove (or change) the 'Cousin Domain' example: it doesn't hold when a ba= d > actor is signing the mail with d=3Dcousindomain and > RFC5322.From=3Dlocalpart@cousindomain > It's not there in -08. > 4 Use of RFC5322.From > > Last bullet (The DMARC mechanism ...). It seems the other bullets provide > reasons why RFC5322.From is chosen while the last one does not. It looks = to > me as a circular reasoning. > It's not there in -08. > 5.2 DMARC URIs > > It is not clear from the text what the report originator must do when the > report payload exceeds the maximum size as indicated by the record. Shoul= d > it not send anything, should it split up reports, should it notify the > requester that there was a report exceeding the maximum size? > Section 6.2.2 in both versions explains what to do here. > 5.3 General Record Format > > adkim and aspf do not provide a list of all possible options (like is don= e > for fo and p). Of course it is pretty obvious that for 'strict' the 's' > must be used, but it's not clear from the text. > They're there in -08. > Next, the P: and pct: tags: they show that (in hindsight) the policy part > and the reporting part of DMARC might have been better off, when they wer= e > defined in different specs. Now we need to complicate the text to say tha= t > the policy tag p: is required, but not for third-party reporting records. > And for pct, that it "MUST NOT be applied to the DMARC-generated reports"= . > Well, I believe this has been discussed before, no need to redo this > discussion. > > I'd suggest to synchronize the short description of the tags in 5.3 with > the descriptions of the tags in the table of 10.4 (now different > terminology is used here and there, for example Requested Mail Receiver > policy (5.3) and Requested handling policy (10.4). Suggested text in 5.3 > becomes then: > [...] > Section 5.3 is meant to be verbose descriptions of each of the tags, while Section 10.4 is a set of short, terse descriptions with references to the places where the details can be found. We could add section numbers to the references found in 10.4 if you think that would be helpful. > Further suggestion for the table in 10.4: reverse the order of 'p' and > 'pct' as 'p' is first discussed in the text of 5.3, before 'pct'. > I see what you're after here, but as it is they're in alphabetical order, like a dictionary, and I think that makes for easier referencing. > Suggestion for 'ri': remove the normative language (MUST and SHOULD) as > that might ask for a 'compliancy' section. Instead, move these suggested > values to the BCP document. > Well there is a normative component there, which is to say that anyone has to be able to produce at least daily reports. I think we have to at least say that. We (the IETF) seem to shy away from doing minimum compliance sections these days. > 5.6.2. Determine Handling Policy > > Bullet 6 in combination with the introduction text might give the > impression that the receiver MUST always follow the policy as published b= y > the Domain Owner. Suggestion to replace the text: > > 6. Apply policy. Emails that fail the DMARC mechanism check are disposed > of in accordance with the discovered DMARC policy of the Domain Owner. Se= e > Section 5.3 > > with: > > 6. Apply policy. Emails that fail the DMARC mechanism SHOULD be disposed > of in accordance with the discovered DMARC policy of the Domain Owner. Se= e > Section 5.3 > > Section 5 itself already has the equivalent of that SHOULD, followed by a "MAY deviate" based on local policy. > 5.6.3. Policy Discovery. > > This paragraph states that: > > If the RFC5322.From domain does not exist in the DNS, Mail Receivers > SHOULD direct the receiving SMTP server to reject the message. The choice > of mechanism for such rejection and the implications of those choices are > discussed in Section 9.3. > > Although this might be common practice (either by default MTA settings, o= r > by configuration parameters set by many mail operators), I believe this > informational RFC about DMARC cannot use normative language here to decri= be > what must be done with mail with a domain that is not present in DNS. > This has been brought up before. I think consensus has landed on the idea that this is an acceptable thing to say because it applies only to operators that are choosing to be DMARC participants. Moreover, the SHOULD ultimately enables you to make the choice for yourself if you think bouncing mail from non-existent domains would be destructive. And this is what DMARC operators have been doing for a while now, so I'll also fall back to noting that this specific effort is documenting current practice. If the working group wants to make a different statement, it can crack this topic open if and when it starts work on a version of DMARC along the Standards Track. 5.7 Last sentence: > > Mail Receivers SHOULD also implement reporting instructions of DMARC in > place of any extensions to SPF or DKIM that might enable such reporting. > > Not sure what this means. But it seems to me DMARC cannot claim priority > over other options/extensions in other IETF protocols. > This is another spot where the SHOULD gives the operator the choice to do both if it wishes. I can't remember off the top of my head what the use case is here, but essentially the absence of a request for DKIM or SPF reporting (as developed by the MARF working group some time ago) should not preclude DMARC reporting, nor should their presence interfere with DMARC reporting. -MSK --001a1134cd582b1f31050aefcde0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Rolf, getting back to your review (thanks for the nudge= ):

On Wed, Nov 12, 2014 at 6:26 PM, Rolf E. Sonneveld <R.= E.Sonneveld@sonnection.nl> wrote:

=20 =20 =20

Abstract:

This lack of cohesion has several effects: receivers have difficulty providing feedback to senders about authentication, senders therefore have difficulty evaluating their authentication deployments, and as a result neither is able to make effective use of existing authentication technology.

This focuses on the reporting function of DMARC, leaving out the policy part of it.

Suggested text:

This lack of cohesion has several effects: senders have difficulty providing information about their use of an authentication policy and receivers have difficulty determining a disposition preferred by senders. Vice versa, mail receivers have difficulty providing feedback to senders about authentication, senders therefore have difficulty evaluating their authentication deployments, and as a result neither is able to make effective use of existing authentication technology.

The Abstract appears to have been rewritten since = you reviewed it, so a straight text swap won't work anymore.=C2=A0 The = new text focuses on what's being provided, not what was missing.=C2=A0 = Do you want to take another run at it?
=C2=A0

Introduction:

[...] mail receivers have tried to protect senders [...]

Suggested:

[...] mail receivers have tried to protect senders and their own users/customers [...]
This text no longer appears in the draft.
=C2=A0

Starting with "DMARC allows domain owners and receivers to collaborate by", the terms 'domain owners', 'receivers= ', 'senders' and 'SMTP receivers', 'Mail Receivers', 'mail recei= vers' are used throughout the document. I'd suggest to add a definition of the ter= m ' Mail Senders' to the introduction part of chapter 3 and then = use only the terms as defined in 3., throughout the document. Suggested text for the term Mail Sender:

Mail Sender: the sender of mail with a domain for which the Domain Owner may have published a DKIM public key and/or an SPF authentication record and/or a DMARC policy;

(although we may want to not mention DKIM or SPF here).

It looks like that got cleared up; -08 has no re= ference to "Mail Sender".
=C2=A0
2.2 Out of Scope
=20
Add:

o=C2=A0=C2=A0=C2=A0 cousin domain attacks
=
Covered in Section 2.4 of -08.
=C2=A0

3.1.2 Key Concepts

Last sentence: add a reference to this 'other referenced material'.
Good idea; added.

3.1.3 Flow diagram

The box titled 'User Mailbox' could give the impression that there's only one choice for delivery. However, quarantining can b= e done without delivery to a mailbox. I'd suggest to label this box 'rMDA'.
That's already don= e in -08.
=C2=A0

The part within parentheses of step 6:

=C2=A06. Recipient transport service conducts= SPF and DKIM authentication checks by passing the necessary data to their respective modules, each of which require queries to the Author Domain=E2=80=99s DNS data (when identifiers are aligned; see below).

might indicate that SPF and DKIM authentication checks need not be performed when identifiers are not aligned. However, for sake of reporting, SPF and DKIM authentication checks will in general always be done, or am I missing something?

I can envision a DMARC implementation that skips SPF or DKIM checks = if the corresponding identifiers are not aligned, because they won't be= interesting to DMARC in that case.

3.1.4.1 DKIM-authenticated Identifiers

remove (or change) the 'Cousin Domain' example: it doesn'= ;t hold when a bad actor is signing the mail with d=3Dcousindomain and RFC5322.From=3Dlocalpart@cousindomain
=
It's not there in -08.
=C2=A0

4 Use of RFC5322.From

Last bullet (The DMARC mechanism ...). It seems the other bullets provide reasons why RFC5322.From is chosen while the last one does not. It looks to me as a circular reasoning.
It's not there in -08.
=C2=A0

5.2 DMARC URIs

It is not clear from the text what the report originator must do when the report payload exceeds the maximum size as indicated by the record. Should it not send anything, should it split up reports, should it notify the requester that there was a report exceeding the maximum size?

=
Section 6.2.2 in both versions explains what to do here.
=C2=A0
=

5.3 General Record Format

adkim and aspf do not provide a list of all possible options (like is done for fo and p). Of course it is pretty obvious that for 'strict' the 's' must be used, but it's not c= lear from the text.
They're there in -08.

Next, the P: and pct: tags: they show that (in hindsight) the policy part and the reporting part of DMARC might have been better off, when they were defined in different specs. Now we need to complicate the text to say that the policy tag p: is required, but not for third-party reporting records. And for pct, that it "MUS= T NOT be applied to the DMARC-generated reports". Well, I believe this has been discussed before, no need to redo this discussion.
=20
I'd suggest to synchronize the short description of the tags in 5.3 with the descriptions of the tags in the table of 10.4 (now different terminology is used here and there, for example Requested Mail Receiver policy (5.3) and Requested handling policy (10.4). Suggested text in 5.3 becomes then:
[...]
Section 5.3 is meant to be verbose descriptions of each of = the tags, while Section 10.4 is a set of short, terse descriptions with ref= erences to the places where the details can be found.=C2=A0 We could add se= ction numbers to the references found in 10.4 if you think that would be he= lpful.

Further suggestion for the table in 10.4: reverse the order of 'p' and 'pct' as 'p' is first discussed in th= e text of 5.3, before 'pct'.

I see what y= ou're after here, but as it is they're in alphabetical order, like = a dictionary, and I think that makes for easier referencing.
=20
Suggestion for 'ri': remove the normative language (MUST and SHOULD) as that might ask for a 'compliancy'=C2=A0 section. I= nstead, move these suggested values to the BCP document.
Well there is a normative component there, which is to say that = anyone has to be able to produce at least daily reports.=C2=A0 I think we h= ave to at least say that.=C2=A0 We (the IETF) seem to shy away from doing m= inimum compliance sections these days.

5.6.2. Determine Handling Policy

Bullet 6 in combination with the introduction text might give the impression that the receiver MUST always follow the policy as published by the Domain Owner. Suggestion to replace the text:

6. Apply policy. Emails that fail the DMARC mechanism check are disposed of in accordance with the discovered DMARC policy of the Domain Owner. See Section 5.3

with:

6. Apply policy. Emails that fail the DMARC mechanism SHOULD be disposed of in accordance with the discovered DMARC policy of the Domain Owner. See Section 5.3
Section 5 itself already has the equivalent of that SHOULD, fol= lowed by a "MAY deviate" based on local policy.

5.6.3. Policy Discovery.

This paragraph states that:

If the RFC5322.From domain does not exist in the DNS, Mail Receivers SHOULD direct the receiving SMTP server to reject the message. The choice of mechanism for such rejection and the implications of those choices are discussed in Section 9.3.

Although this might be common practice (either by default MTA settings, or by configuration parameters set by many mail operators), I believe this informational RFC about DMARC cannot use normative language here to decribe what must be done with mail with a domain that is not present in DNS.
<= div>This has been brought up before.=C2=A0 I think consensus has landed on = the idea that this is an acceptable thing to say because it applies only to= operators that are choosing to be DMARC participants.=C2=A0 Moreover, the = SHOULD ultimately enables you to make the choice for yourself if you think = bouncing mail from non-existent domains would be destructive.=C2=A0 And thi= s is what DMARC operators have been doing for a while now, so I'll also= fall back to noting that this specific effort is documenting current pract= ice.=C2=A0 If the working group wants to make a different statement, it can= crack this topic open if and when it starts work on a version of DMARC alo= ng the Standards Track.

5.7 Last sentence:

Mail Receivers SHOULD also implement reporting instructions of DMARC in place of any extensions to SPF or DKIM that might enable such reporting.

Not sure what this means. But it seems to me DMARC cannot claim priority over other options/extensions in other IETF protocols.
This is another spot where the SHOULD gives the o= perator the choice to do both if it wishes.=C2=A0 I can't remember off = the top of my head what the use case is here, but essentially the absence o= f a request for DKIM or SPF reporting (as developed by the MARF working gro= up some time ago) should not preclude DMARC reporting, nor should their pre= sence interfere with DMARC reporting.
=C2=A0
-MSK<= br>

--001a1134cd582b1f31050aefcde0-- From nobody Tue Dec 23 21:49: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 75E571ACD20 for ; Tue, 23 Dec 2014 21:49:07 -0800 (PST) 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 PenA8bCgN6H7 for ; Tue, 23 Dec 2014 21:49:06 -0800 (PST) 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 0CEC21ACC82 for ; Tue, 23 Dec 2014 21:49:06 -0800 (PST) Received: by mail-wg0-f47.google.com with SMTP id n12so10499273wgh.6 for ; Tue, 23 Dec 2014 21:49:04 -0800 (PST) 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=ETpeuGzcPCK+ikqMr3YT/DtcAVfU1uvYl5VtUbqRDKM=; b=GNPCOEoNvzfamcuN7kws7nlL3Lb/g2Fba5JSOmDoEo2EGCXYLmWG7Jb2BXmcktifOC dexeMcbEpN4ojdJns/aaXGeFP09R7DH5ME4DE7UMgpmxt/zHFNEvw4YjgX/Rfssi7Pz1 Hn+Vkf6BxVAKw1jzlR9WG9nQZHhQ04NzkC32UDa04idsTYBatfsTOTSA/NnhmGiUsLoA 9LSKc0QMZW8t+uv4nzgYz6UYFC/Oo9aeB/yWcmg+BjojmQtN7Phk5RZx2aH0MYCWcwaq cRa8wFMzhNXkcNn5CXMsNrI6czNzHrqFEHLTO9q1YtJZO4xKJCbDCc9o6mFAnjMu9q9h o4DQ== MIME-Version: 1.0 X-Received: by 10.194.200.234 with SMTP id jv10mr60275876wjc.110.1419400144906; Tue, 23 Dec 2014 21:49:04 -0800 (PST) Received: by 10.27.204.198 with HTTP; Tue, 23 Dec 2014 21:49:04 -0800 (PST) In-Reply-To: <7243484.JQFTys4I1u@kitterman-optiplex-9020m> References: <54986CCC.70200@sonnection.nl> <54986DF1.9060807@dcrocker.net> <7243484.JQFTys4I1u@kitterman-optiplex-9020m> Date: Wed, 24 Dec 2014 00:49:04 -0500 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=047d7bb70bb26e7189050aefd910 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/3e7qm08fRNjNINZ8ZxpltDfym_o Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DMARC and TEMP errors was: Re: Jim Fenton's review of -04 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, 24 Dec 2014 05:49:07 -0000 --047d7bb70bb26e7189050aefd910 Content-Type: text/plain; charset=UTF-8 On Mon, Dec 22, 2014 at 3:18 PM, Scott Kitterman wrote: > > As I read -08 what to do in that case is undefined. There's a dangling > pointer > to 5.6.3. It's dangling because nothing in that section addresses the > question of how to handle DKIM/SPF temporary errors. > > 5.6.3's final paragraph makes it clear that the action taken is at the discretion of the mail receiver, and gives two examples of non-destructive ways to handle that case. Do we need to say more than that? -MSK --047d7bb70bb26e7189050aefd910 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Dec 22, 2014 at 3:18 PM, Scott Kitterman <skli= st@kitterman.com> wrote:

As I read -08 what to do in that case is undefined.=C2=A0 There's a dan= gling pointer
to 5.6.3.=C2=A0 It's dangling because nothing in that section addresses= the
question of how to handle DKIM/SPF temporary errors.

5.6.3's final paragraph makes it c= lear that the action taken is at the discretion of the mail receiver, and g= ives two examples of non-destructive ways to handle that case.=C2=A0 Do we = need to say more than that?

-MSK

--047d7bb70bb26e7189050aefd910-- From nobody Tue Dec 23 22:12: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 B060D1ACD07 for ; Tue, 23 Dec 2014 22:12:04 -0800 (PST) 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 dnGHy1thuO7V for ; Tue, 23 Dec 2014 22:11:57 -0800 (PST) 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 D08921ACD26 for ; Tue, 23 Dec 2014 22:11:56 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id x13so10614983wgg.5 for ; Tue, 23 Dec 2014 22:11:55 -0800 (PST) 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=HuY+p/zzkYZ03KXkE13nDkE7N33RSsYSej/AqsL4vlA=; b=xPtOuOmMgA6s60fEaNAyyBa3yV0aqvwIFjj0XudLYc7BPnYKQcJTznIFtMqWlvuN3x RE9bYPrIaPwlBBJk+vXu755z7YHWTB/U8IQ5bplHtbEHiTKM/liW/EcXxQKk+c69SLTk O33HA50AdHelSWIdDW94v3eoVSlT3ILQVSUyHS37mTLh2Idqi/VkAS/mO9gGuCqjzvKZ DguVr8k2Zn4KEuKoAcpYbxyMoZoS7lGqFxGrq+KRixzQVf2G1IoLtdaxDzKWcTMNInJ3 hP9tz/fJVTfW8y04W8l3Ih9nQWyJIZsTxs0RhFYUQ6FqVxHueBSRZyQqqanCQWxW+E75 NBEw== MIME-Version: 1.0 X-Received: by 10.194.62.76 with SMTP id w12mr60172026wjr.5.1419401515573; Tue, 23 Dec 2014 22:11:55 -0800 (PST) Received: by 10.27.204.198 with HTTP; Tue, 23 Dec 2014 22:11:55 -0800 (PST) In-Reply-To: <5494A6F5.5020906@dcrocker.net> References: <5494A6F5.5020906@dcrocker.net> Date: Wed, 24 Dec 2014 01:11:55 -0500 Message-ID: From: "Murray S. Kucherawy" To: Dave Crocker Content-Type: multipart/alternative; boundary=047d7ba977a421288e050af02b30 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/8mM7ksQn4mO_tZMoUOcXINMN3a8 Cc: jim fenton , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 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, 24 Dec 2014 06:12:05 -0000 --047d7ba977a421288e050af02b30 Content-Type: text/plain; charset=UTF-8 On Fri, Dec 19, 2014 at 5:30 PM, Dave Crocker wrote: > > 3.2 Organizational Domain > > > > I remain very concerned about this algorithm since I have been > > previously told very specifically not to do this by the DNS folks. I'm > > also concerned about the inconsistency (interoperability impact) that > > could result from different operators using different public suffix > lists. > > Everyone is concerned about it. But it's the best that is currently > available. > +1, and furthermore, -08's Section 3.2 and Appendix A.6 both admit the current method is flawed and DMARC operators should switch to something better as soon as such a thing becomes available. I don't know what more can be said at this point. > > 4. Policy > > > > Paragraph 4 basically says, if you don't want a particular > > authentication scheme to be considered by DMARC, don't use it at all. > > For a domain that is using SPF and DMARC (for example), this could be an > > impediment to their deployment of DKIM because they could not test with > > it without having it immediately affect recipients' message handling. > > One possibility would be to ignore DKIM if the testing (t=y) flag is > > set, although a campaign would be needed to get the many domains > > currently using t=y to turn it off. Another possibility would be to have > > a setting in DMARC to ignore a specific authentication method entirely. > > The first possibility isn't viabile, for the reason cited. The second > possibility might be worth pursuing in the DMARC working group, rather > than in a document that captures existing DMARC practice. > > There are, of course, other possibilities, such as not having DMARC > pursue operational nuance that makes the spec more complex, trying to > handle special cases. That is, if a site isn't ready to use DMARC, it > shouldn't. > The "pct" tag was also provided to address the concern that the impact of enabling DMARC is uncertain. > > 7.1 Verifying External Destinations > > > > Paragraph 3: "verification steps SHOULD be taken" These steps are to > > protect another domain from attack. It needs to be a MUST. > > 6.1 in -08. > > Given the problems with the search for org domain, a SHOULD is as far as > is practical here. > > I'd suggest noting that that's a reason this can't be a MUST. > I think it's SHOULD because at the time it was written, the verification process was untested. It's in production now (OpenDMARC implements it), so I agree that a MUST is appropriate. > > 8. Policy Discovery > ... > > 5.6.3 in -08 > > > > Second-to-last paragraph: "If the RFC5322.From domain does not exist in > > the DNS" is basically changing what RFC5321/5322 allow. This isn't the > > place to be making fundamental changes to the behavior of email. > > It isn't meant to be. > > -08 text says: > > "If the RFC5322.From domain does not exist in the DNS, Mail > Receivers > SHOULD direct the receiving SMTP server to reject the message. The > choice of mechanism for such rejection and the implications of those > choices are discussed in Section 9.3." > > I suggest removing it. Although a common anti-abuse mechanism, it's out > of scope for DMARC. > I disagree. DMARC operators all seem to apply this practice, so it's correct to say that if you play this game, you reject mail from non-existent domains. Essentially in this way DMARC is a profile of RFC5321/RFC5322, which is perfectly acceptable. We are not updating those standards here, merely profiling them. > > 9. Domain Owner Actions > > 5.5 in -08 > > > Last paragraph doesn't seem like it fits. Suggest it be removed. > > While I could imagine a better place for it in the doc, having a /terse/ > pointer like this to some authentication pedagogy seems useful to me, in > an authentication-related spec... > +1. > > 11.1 Discovery > 6.2.1 in -08 > > > Mail Receivers can also discover reporting requests from the > > Organizational Domain. That should be mentioned here. But I'm a little > > confused why we have another Discovery section at all. > > The text's use of the word 'corresponds' handles the mapping to org > domain, IMO. > +1, and there isn't a second Discovery section anymore; there was a Great Consolidation at around the -05 version. > > 11.2.1 Email > > > > The whole thing about filenames needs to go away. Since it's only a > > SHOULD requirement, the Report Receiver needs to be able to handle > > reports that don't follow this format as well as those that do. > > "SHOULD" is a very strong normative statement. Note that it permits > non-conformance only in the presence of singular knowledge by the > non-conforming party. > > Filename labeling is generally considered useful. Why wouldn't it be > useful here? > +1, not to mention again that this is current practice among DMARC operators and doesn't seem to be an issue so far. > > 14.1 Data Exposure Considerations > > > > Last paragraph: what's an "unexpected Mail Receiver"? > Reworded. > > The privacy consideration here, which isn't obvious from the wording, is > > that users may currently use forwarding in a way that prevents the > > sender from determining the ultimate delivery address. DMARC has the > > potential to break that. This might be important in the case of a user > > that is trying to distance themselves from a stalker. > > How is that a DMARC-specific 'exposure' consideration? > DMARC creates the exposure. If A sends mail to B which forwards to C and then to D, D can send reports back to A, revealing the forwarding relationship from C to D. Reworded to accommodate. > > 14.2 Report Recipients > > > > Some potential exists for report recipients to perform traffic analysis: > > to obtain metadata about the receiver's traffic. In addition to > > verifying compliance with policies, receivers need to consider that > > before sending reports to a third party. > > +1 > Added. -MSK --047d7ba977a421288e050af02b30 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Dec 19, 2014 at 5:30 PM, Dave Crocker <dhc@dcrocke= r.net> wrote:

> 3.2 Organizational Domain
>
> I remain very concerned about this algorithm since I have been
> previously told very specifically not to do this by the DNS folks. I&#= 39;m
> also concerned about the inconsistency (interoperability impact) that<= br> > could result from different operators using different public suffix li= sts.

Everyone is concerned about it.=C2=A0 But it's the best that is current= ly
available.

+1, and furthermore, -08'= ;s Section 3.2 and Appendix A.6 both admit the current method is flawed and= DMARC operators should switch to something better as soon as such a thing = becomes available.=C2=A0 I don't know what more can be said at this poi= nt.
=C2=A0

> 4. Policy
>
> Paragraph 4 basically says, if you don't want a particular
> authentication scheme to be considered by DMARC, don't use it at a= ll.
> For a domain that is using SPF and DMARC (for example), this could be = an
> impediment to their deployment of DKIM because they could not test wit= h
> it without having it immediately affect recipients' message handli= ng.
> One possibility would be to ignore DKIM if the testing (t=3Dy) flag is=
> set, although a campaign would be needed to get the many domains
> currently using t=3Dy to turn it off. Another possibility would be to = have
> a setting in DMARC to ignore a specific authentication method entirely= .

The first possibility isn't viabile, for the reason cited.=C2=A0 The se= cond
possibility might be worth pursuing in the DMARC working group, rather
than in a document that captures existing DMARC practice.

There are, of course, other possibilities, such as not having DMARC
pursue operational nuance that makes the spec more complex, trying to
handle special cases.=C2=A0 That is, if a site isn't ready to use DMARC= , it
shouldn't.

The "pct" tag = was also provided to address the concern that the impact of enabling DMARC = is uncertain.
=C2=A0

> 7.1 Verifying External Destinations
>
> Paragraph 3: "verification steps SHOULD be taken" These step= s are to
> protect another domain from attack. It needs to be a MUST.

6.1 in -08.

Given the problems with the search for org domain, a SHOULD is as far as is practical here.

I'd suggest noting that that's a reason this can't be a MUST.

I think it's SHOULD because at the t= ime it was written, the verification process was untested.=C2=A0 It's i= n production now (OpenDMARC implements it), so I agree that a MUST is appro= priate.
=C2=A0

> 8. Policy Discovery
...

5.6.3 in -08

> Second-to-last paragraph: "If the RFC5322.From domain does not ex= ist in
> the DNS" is basically changing what RFC5321/5322 allow. This isn&= #39;t the
> place to be making fundamental changes to the behavior of email.

It isn't meant to be.

-08 text says:

=C2=A0 =C2=A0 =C2=A0"If the RFC5322.From domain does not exist in the = DNS, Mail
=C2=A0 =C2=A0Receivers
=C2=A0 =C2=A0SHOULD direct the receiving SMTP server to reject the message.= =C2=A0 The
=C2=A0 =C2=A0choice of mechanism for such rejection and the implications of= those
=C2=A0 =C2=A0choices are discussed in Section 9.3."

I suggest removing it.=C2=A0 Although a common anti-abuse mechanism, it'= ;s out
of scope for DMARC.

I disagree.=C2=A0 D= MARC operators all seem to apply this practice, so it's correct to say = that if you play this game, you reject mail from non-existent domains.=C2= =A0 Essentially in this way DMARC is a profile of RFC5321/RFC5322, which is= perfectly acceptable.=C2=A0 We are not updating those standards here, mere= ly profiling them.
=C2=A0

> 9. Domain Owner Actions

5.5 in -08

> Last paragraph doesn't seem like it fits. Suggest it be removed.
While I could imagine a better place for it in the doc, having a /terse/ pointer like this to some authentication pedagogy seems useful to me, in an authentication-related spec...

+1.
=C2=A0

> 11.1 Discovery
6.2.1 in -08

> Mail Receivers can also discover reporting requests from the
> Organizational Domain. That should be mentioned here. But I'm a li= ttle
> confused why we have another Discovery section at all.

The text's use of the word 'corresponds' handles the mapping to= org
domain, IMO.

+1, and there isn't a = second Discovery section anymore; there was a Great Consolidation at around= the -05 version.
=C2=A0

> 11.2.1 Email
>
> The whole thing about filenames needs to go away. Since it's only = a
> SHOULD requirement, the Report Receiver needs to be able to handle
> reports that don't follow this format as well as those that do.
"SHOULD" is a very strong normative statement. Note that it permi= ts
non-conformance only in the presence of singular knowledge by the
non-conforming party.

Filename labeling is generally considered useful.=C2=A0 Why wouldn't it= be
useful here?

+1, not to mention again t= hat this is current practice among DMARC operators and doesn't seem to = be an issue so far.

=C2=A0

> 14.1 Data Exposure Considerations
>
> Last paragraph: what's an "unexpected Mail Receiver"?

Reworded.
=C2=A0

> The privacy consideration here, which isn't obvious from the wordi= ng, is
> that users may currently use forwarding in a way that prevents the
> sender from determining the ultimate delivery address. DMARC has the > potential to break that. This might be important in the case of a user=
> that is trying to distance themselves from a stalker.

How is that a DMARC-specific 'exposure' consideration?

DMARC creates the exposure.=C2=A0 If A sends mail t= o B which forwards to C and then to D, D can send reports back to A, reveal= ing the forwarding relationship from C to D.

Reworded to = accommodate.
=C2=A0
> 14.2 Report Recipients
>
> Some potential exists for report recipients to perform traffic analysi= s:
> to obtain metadata about the receiver's traffic. In addition to > verifying compliance with policies, receivers need to consider that > before sending reports to a third party.

+1

Added.

-MSK

--047d7ba977a421288e050af02b30-- From nobody Tue Dec 23 22:26: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 5DA9F1ACD28 for ; Tue, 23 Dec 2014 22:26:01 -0800 (PST) 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 RuNtBs2tH8Kx for ; Tue, 23 Dec 2014 22:25:59 -0800 (PST) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c: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 9DACD1ACD05 for ; Tue, 23 Dec 2014 22:25:58 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id n3so12736383wiv.17 for ; Tue, 23 Dec 2014 22:25:57 -0800 (PST) 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=eHZagfUfpbT/OUXw5FKnM1Sn5X0Ykbl08/3eIHvZfhM=; b=Y5EWeIO1RpNV566yJPyPDw6diXcJtkg23FNiemLipXY0qce4KDJC3TovXvrb1RQsBE cHF/3hH0pj5qcVghVUec22/Bp56PH0blS6HTNeahuSuADbCORkxNZ/kWNVAT3J5oO7Od ldS+/WUHX1dHOvyTcmygGX5r9FdaupvNIfzlwfQz+kw6e3quBzEDWxp6wsMhoXf/8naC DOGmsSr1Dg156UWMlsdPKkbUFizk48xu/uQiSROI4DcLulIBOH96SclIKd95XX646g8n pLXfOuBdkVupqvdgWoI2AR9cUBCeHpLQhdgo0iTFrCjeDf/5va89Llbw0YEgw3TjTzci 0Ukw== MIME-Version: 1.0 X-Received: by 10.194.200.234 with SMTP id jv10mr60534058wjc.110.1419402357320; Tue, 23 Dec 2014 22:25:57 -0800 (PST) Received: by 10.27.204.198 with HTTP; Tue, 23 Dec 2014 22:25:57 -0800 (PST) In-Reply-To: <54967461.2070702@bluepopcorn.net> References: <5494A6F5.5020906@dcrocker.net> <54967461.2070702@bluepopcorn.net> Date: Wed, 24 Dec 2014 01:25:57 -0500 Message-ID: From: "Murray S. Kucherawy" To: Jim Fenton Content-Type: multipart/alternative; boundary=047d7bb70bb24d3239050af05df5 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/L7kMazZIcZE-EF44R52mwGuYf5M Cc: "dmarc@ietf.org" , Dave Crocker Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 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, 24 Dec 2014 06:26:01 -0000 --047d7bb70bb24d3239050af05df5 Content-Type: text/plain; charset=UTF-8 For the stuff not already answered in my last reply to Dave: On Sun, Dec 21, 2014 at 2:18 AM, Jim Fenton wrote: > [2.4 Out of Scope] > >> Bullet 10: Again, DMARC doesn't do authentication, even for domains; it > >> relies on other authentication mechanisms. > > I originally thought this, too, but in fact DMARC does do authentication: > > > > DMARC asserts authenticity of the rfc5322.From field domain name. > > That's a distinct semantic increment over anything SPF or DKIM do on > > their own. > > What it does is different enough from SPF and DKIM that I think it's > overloading the term "authentication" to use it again here. It doesn't > contribute to a clear understanding. It looks at the results of SPF and > DKIM, which operate at the domain level, so this bullet isn't really > necessary. > Doesn't RFC5322.From also operate at the domain level in our context? DMARC's filtering function is based on whether SPF or DKIM can provide > an authenticated, aligned identifier for the message under > consideration. Messages that purport to be from a Domain Owner's domain > and arrive from servers that are not authorized by that domain's SPF and > do not contain an appropriate DKIM signature can be affected by DMARC > policies. > > [I think the additional "that domain's" will do it.] > Added. > >> 5. DMARC policy record > >> > >> Paragraph 2: Again, "matches perfectly with the DNS" is an inaccurate > >> characterization. If the query requirement matched perfectly with the > >> DNS, DNS would have a way to determine the Administrative Domain without > >> resorting to suffix lists and such. Just strike the sentence; this isn't > >> relevant here anyway. > > -08 doesn't have this language. > > Now section 5.1, paragraph 2. Honestly, this reads like marketing fluff > that doesn't belong in a specification like this. > I don't have any trouble removing it. I think it was added to ward off anyone that might claim "You shouldn't be using the DNS for this." > >> 11.1 Discovery > > 6.2.1 in -08 > > > >> Mail Receivers can also discover reporting requests from the > >> Organizational Domain. That should be mentioned here. But I'm a little > >> confused why we have another Discovery section at all. > > The text's use of the word 'corresponds' handles the mapping to org > > domain, IMO. > > This is more of a comment about document organization. The previous > sections have been talking about things that follow discovery of the > policy record, and now when talking about aggregate reports there's > another section about discovery. Why here; isn't this a little redundant? > It's mainly to say that there isn't a specific discovery process for aggregate report details; it's already done. This might be a legacy from ancient versions where there was a separate process. I'll tidy it up by merging it into the previous subsection. > SHOULD isn't strong enough for the Report Receiver to depend on. There > are other ways to get the information that is encoded into the filename. > Like what? > If the spec wants to suggest, "here's a nice file name format that you > MAY want to use", that's fine. But SHOULD is both too weak if the > recipient can't depend on it and too strong if it's merely advice. > I'm not so sure. If we're going to go with MAY, then we also need some kind of signal that the filename used does conform to the proposed encoding, or else there might be some attempt to extract report parameters that simply aren't there. > >> The privacy consideration here, which isn't obvious from the wording, is > >> that users may currently use forwarding in a way that prevents the > >> sender from determining the ultimate delivery address. DMARC has the > >> potential to break that. This might be important in the case of a user > >> that is trying to distance themselves from a stalker. > > How is that a DMARC-specific 'exposure' consideration? > > Because it's the retrieval (or search for) the DMARC record might > reveals that. But on rereading this, paragraph 4 addresses this > sufficiently. > > New issue: Paragraph 3 refers to "Both report types" but since iodef was > removed, it should just say "The AFRF report type". > That refers to the aggregate and detailed reports ("rua" and "ruf"), not IODEF and AFRF. -MSK --047d7bb70bb24d3239050af05df5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

For the stuff not already answered in my last reply to Dav= e:

On Sun, Dec 21, 2014 at 2:18 AM, Jim Fenton <fenton@bl= uepopcorn.net> wrote:

[2.4 Out of Scope]
>> Bullet 10: Again, DMARC doesn't do authentica= tion, even for domains; it
>> relies on other authentication mechanisms.
> I originally thought this, too, but in fact DMARC does do authenticati= on:
>
>=C2=A0 =C2=A0 =C2=A0 DMARC asserts authenticity of the rfc5322.From fie= ld domain name.
> That's a distinct semantic increment over anything SPF or DKIM do = on
> their own.

What it does is different enough from SPF and DKIM that I think it&#= 39;s
overloading the term "authentication" to use it again here. It do= esn't
contribute to a clear understanding. It looks at the results of SPF and
DKIM, which operate at the domain level, so this bullet isn't really necessary.

Doesn't RFC5322.From also ope= rate at the domain level in our context?

DMARC's filtering function is based on whether SPF or DKIM can p= rovide
an authenticated, aligned identifier for the message under
consideration. Messages that purport to be from a Domain Owner's domain=
and arrive from servers that are not authorized by that domain's SPF an= d
do not contain an appropriate DKIM signature can be affected by DMARC
policies.

[I think the additional "that domain's" will do it.]

Added.
=C2=A0
>> 5. DMARC policy record
>>
>> Paragraph 2: Again, "matches perfectly with the DNS" is = an inaccurate
>> characterization. If the query requirement matched perfectly with = the
>> DNS, DNS would have a way to determine the Administrative Domain w= ithout
>> resorting to suffix lists and such. Just strike the sentence; this= isn't
>> relevant here anyway.
> -08 doesn't have this language.

Now section 5.1, paragraph 2. Honestly, this reads like marketing fl= uff
that doesn't belong in a specification like this.
=
I don't have any trouble removing it.=C2=A0 I think it w= as added to ward off anyone that might claim "You shouldn't be usi= ng the DNS for this."
=C2=A0
>> 11.1 Discovery
> 6.2.1 in -08
>
>> Mail Receivers can also discover reporting requests from the
>> Organizational Domain. That should be mentioned here. But I'm = a little
>> confused why we have another Discovery section at all.
> The text's use of the word 'corresponds' handles the mappi= ng to org
> domain, IMO.

This is more of a comment about document organization. The previous<= br> sections have been talking about things that follow discovery of the
policy record, and now when talking about aggregate reports there's
another section about discovery. Why here; isn't this a little redundan= t?

It's mainly to say that there is= n't a specific discovery process for aggregate report details; it's= already done.=C2=A0 This might be a legacy from ancient versions where the= re was a separate process.=C2=A0 I'll tidy it up by merging it into the= previous subsection.
=C2=A0
SHOULD isn't strong enough for the Report Receiver to depend on. There<= br> are other ways to get the information that is encoded into the filename.

Like what?
=C2=A0
If the spec wants to suggest, "here's a nice file name format that= you
MAY want to use", that's fine. But SHOULD is both too weak if the<= br> recipient can't depend on it and too strong if it's merely advice.<= br>

I'm not so sure.=C2=A0 If we're= going to go with MAY, then we also need some kind of signal that the filen= ame used does conform to the proposed encoding, or else there might be some= attempt to extract report parameters that simply aren't there.

=C2=A0

>> The privacy consideration here, which isn't o= bvious from the wording, is
>> that users may currently use forwarding in a way that prevents the=
>> sender from determining the ultimate delivery address. DMARC has t= he
>> potential to break that. This might be important in the case of a = user
>> that is trying to distance themselves from a stalker.
> How is that a DMARC-specific 'exposure' consideration?

Because it's the retrieval (or search for) the DMARC record migh= t
reveals that. But on rereading this, paragraph 4 addresses this
sufficiently.

New issue: Paragraph 3 refers to "Both report types" but since io= def was
removed, it should just say "The AFRF report type".

That refers to the aggregate and detailed reports (&= quot;rua" and "ruf"), not IODEF and AFRF.

= -MSK

--047d7bb70bb24d3239050af05df5-- From nobody Tue Dec 23 22:32: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 610571ACD36 for ; Tue, 23 Dec 2014 22:32:47 -0800 (PST) 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 77lTZmqjvwv6 for ; Tue, 23 Dec 2014 22:32:45 -0800 (PST) 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 91AB21ACD31 for ; Tue, 23 Dec 2014 22:32:45 -0800 (PST) Received: by mail-wg0-f43.google.com with SMTP id l18so10701110wgh.16 for ; Tue, 23 Dec 2014 22:32:44 -0800 (PST) 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=mJiAqnotDbYLLEi7Oq7X4IZdga7intd7JBig144syUg=; b=AisI+oWhZNK8i04/rMhtOuPcgjMGl02+31Ry/k7blOKJwyymzIzsqjPmQZT91ScLsy V1qnGpEBJyMvxhmvh15e4/xE82kMnn+22pYObLdi5wruW3m+ei0RC39WrA8WyEYyr8B+ 9RybGVLtUsdUKRhErEJ88AL1BBda0GGJdojkxWuwrbZ2YFDE8kM4iJCV4IA4e/8dd5HG EetLa31+0yiBH0+lfEliZhsyjLZAut0JC2qcfU1g4GKfWjq3tEK3DX2Bv5//PpHZMu1e 3asTCY8im6pM33WS+Vn14v3wyATKTnrhoJOZO1BPAIHcIszKn5eEiL8okXE1rodlXui+ 3BjA== MIME-Version: 1.0 X-Received: by 10.180.91.36 with SMTP id cb4mr47864415wib.30.1419402764372; Tue, 23 Dec 2014 22:32:44 -0800 (PST) Received: by 10.27.204.198 with HTTP; Tue, 23 Dec 2014 22:32:44 -0800 (PST) In-Reply-To: <6858606.AfKicQ9CJZ@kitterman-optiplex-9020m> References: <6858606.AfKicQ9CJZ@kitterman-optiplex-9020m> Date: Wed, 24 Dec 2014 01:32:44 -0500 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=f46d043d6711905133050af075b3 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/QXU2qtEZkyOW9XxX-ohLOC6CJ0U Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 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, 24 Dec 2014 06:32:47 -0000 --f46d043d6711905133050af075b3 Content-Type: text/plain; charset=UTF-8 On Mon, Dec 22, 2014 at 10:44 AM, Scott Kitterman wrote: > There was a recent thread on postfix-users about DMARC rejections when > there > are DNS errors that caused me to review -08 to see what it says on the > matter. > > At the end of section 5.6.2, it says: > > Handling of messages for which SPF and/or DKIM evaluation encounters > a DNS error is left to the discretion of the Mail Receiver. Further > discussion is available in Section 5.6.3. > > My reading of 5.6.3 though is that it only discusses DNS errors in the > context > of failing to retrieve the DMARC record. Any discussion about handling DNS > errors for SPF/DKIM seems to be missing. > Yes, DMARC punts on what to do when SPF or DKIM encounter transient failures. I imagine that's because those modules would arrange to temp-fail a message that has that problem. I suppose my experience is that messages don't even get to the point of DMARC evaluation when that happens, because the message has already been temp-failed. If you think about DKIM and SPF as being part of a layer below DMARC, then I'm not sure it's wise of us to be making any kind of normative statement about what to do when the lower layers fail. What do you suggest? -MSK --f46d043d6711905133050af075b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Dec 22, 2014 at 10:44 AM, Scott Kitterman <skl= ist@kitterman.com> wrote:

There was a recent thr= ead on postfix-users about DMARC rejections when there
are DNS errors that caused me to review -08 to see what it says on the matt= er.

At the end of section 5.6.2, it says:

=C2=A0 =C2=A0Handling of messages for which SPF and/or DKIM evaluation enco= unters
=C2=A0 =C2=A0a DNS error is left to the discretion of the Mail Receiver.=C2= =A0 Further
=C2=A0 =C2=A0discussion is available in Section 5.6.3.

My reading of 5.6.3 though is that it only discusses DNS errors in the cont= ext
of failing to retrieve the DMARC record.=C2=A0 Any discussion about handlin= g DNS
errors for SPF/DKIM seems to be missing.

Yes, DMARC punts on what to do when SPF or DKIM encounter transient failu= res.=C2=A0 I imagine that's because those modules would arrange to temp= -fail a message that has that problem.=C2=A0 I suppose my experience is tha= t messages don't even get to the point of DMARC evaluation when that ha= ppens, because the message has already been temp-failed.

= If you think about DKIM and SPF as being part of a layer below DMARC, then = I'm not sure it's wise of us to be making any kind of normative sta= tement about what to do when the lower layers fail.

What do you sugg= est?

-MSK

--f46d043d6711905133050af075b3-- From nobody Tue Dec 23 23:02: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 7ED101ACD2B for ; Tue, 23 Dec 2014 23:02:46 -0800 (PST) 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 6H4jmoSHF6DV for ; Tue, 23 Dec 2014 23:02:41 -0800 (PST) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c: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 06A611ACCE6 for ; Tue, 23 Dec 2014 23:02:40 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id bs8so14963589wib.1 for ; Tue, 23 Dec 2014 23:02:39 -0800 (PST) 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=QEwid3tuXXdft7LtPcWaco6jnpeZJsRwXf616RiSThM=; b=irmzd3njNPTyiZzFyQ/K9MLN4VEDXE0v7x3mFIR85jtvmifjJ9UPaWH5EVkcnI2B/t YbL4H3XVvW01vjkIRL4p410VXDlVRH9dDhgAGRmcVHWv72HTHzlFFqcXu5pvcHlWuRGy zwfVqnPSiIhq8x/mpLw9HlReRR4Xgoo3ps1sKfo6MCW1nHvtTyCmnh8+66k85FpmyJ4c SQESnYAeE5bHMmMa7/H/aZCz1456MPXevqSmD4jYzXpyXEh1+3aATeNy9mzPiA4hquCm 4+wRwRKx8KPiWHOYBzVfnrOWt2EVMGo3qLw/+FZ/2sXlqyZXeKK1lZJ3timNaTEO88VD ZQKg== MIME-Version: 1.0 X-Received: by 10.194.62.76 with SMTP id w12mr60541662wjr.5.1419404559642; Tue, 23 Dec 2014 23:02:39 -0800 (PST) Received: by 10.27.204.198 with HTTP; Tue, 23 Dec 2014 23:02:39 -0800 (PST) In-Reply-To: <534ED5F1.3010001@bluepopcorn.net> References: <534ED5F1.3010001@bluepopcorn.net> Date: Wed, 24 Dec 2014 02:02:39 -0500 Message-ID: From: "Murray S. Kucherawy" To: Jim Fenton Content-Type: multipart/alternative; boundary=047d7ba977a491f940050af0e02d Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/6DFOSHGuDoZieZm9GY_UlHT_wWY Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Review of draft-kucherawy-dmarc-base-04 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, 24 Dec 2014 07:02:46 -0000 --047d7ba977a491f940050af0e02d Content-Type: text/plain; charset=UTF-8 Covering the stuff Dave didn't cover: On Wed, Apr 16, 2014 at 3:11 PM, Jim Fenton wrote: > Top of page 6: "The receiver reports to the domain owner..." The > receiver actually sends reports to a report receiver designated by the > domain owner. > Fixed. > 2.4 Out of Scope > > I still find the double negatives to be confusing, e.g., "DMARC will not > make a distinction...". It's the making of a distinction that's out of > scope, not the not making a distinction (forgive my own double negative, > please!). > That text is apparently gone. > Bullet 10: Again, DMARC doesn't do authentication, even for domains; it > relies on other authentication mechanisms. > > 3. Terminology and Definitions > > Domain Owner: This definition refers to the domain owner as being the > registrant of a DNS domain. But as used elsewhere in the spec, it can > also be a delegate of that registrant that is given control over a > subdomain. The document frequently refers to a domain owner publishing a > DMARC record, so it's worth clarifying who has that capability. > > Report Receiver: "reports about the messages claiming to be from a third > party" We're talking about the reports here, not the messages > themselves, so I would suggest "reports from a third party about their > messages". > Fixed and fixed. > 3.1.2 General Concepts > > Paragraph 2: "provide feedback to the Domain Owner". Should this say a > Report Receiver designated by the Domain Owner, or is that too much > information at this point? > Fixed. > Paragraph 3 doesn't quite capture the sense of alignment properly, > especially for SPF. A message that is authorized by SPF might have an > unaligned envelope-from address, so the validity of SPF for such > messages is moot. > This appears to have been rewritten already. > 3.1.3 Flow Diagram > > Item 1: "Author constructs" and "Author also configures" -> "Domain > Owner constructs" and "Domain Owner also configures" (I missed this last > time) > > Item 7: 'e.g., a "pass" or "fail"' Are there other results? If not, > remove the e.g. > Fixed and fixed. > 3.1.4 Identifier Alignment > > Paragraph 5: Although this document makes it clear that "strict" and > "relaxed" are different from their usage in DKIM, I'm still having > trouble with those words. "strict" means that only this specific domain > is affected; "relaxed" means that this domain and its subdomains are > affected. So "relaxed" is really more strict in that it enforces more. > I find the terms to be confusing, and would recommend something that > more directly describes whether the policy applies to subdomains. > Since we're documenting deployed infrastructure here, it's way too late to be renaming these. > 3.1.4.1 DKIM-authenticated identifiers > > Paragraph 4: Include section reference (3.2) to public suffix lists > since the section describing it has moved after this text. > Added. > 5.2 General Record Format > > fo: A colon-separated list of options is supported, but 0 and 1 conflict > with each other so that either needs to be prohibited or it needs to > define which wins. > Previously addressed (Scott Kitterman brought it up). > fo:d: "a signature": In the case of a message with multiple DKIM > signatures, does that mean if any signature failed evaluation, a message > is sent? Is a separate message sent for each failed signature? > Clarified. > p:quarantine: What does "suspicious" mean? It sounds like it means > something other than "place into spam folder" and "scrutinize with > additional intensity" > Clarified. > pct: "DMARC-generated reports...must be sent and received unhindered". > How does one identity a DMARC-generated report to make sure it's > unhindered, especially if a bad actor tries to make their messages look > like reports? > The syntax of a DMARC report is defined elsewhere in the document. Shouldn't it be easy to identify one? > 5.3 Formal Definition > > dmarc-rfmt: Should allow a colon-separated list as described in 5.2. > Fixed. > 7.2 Aggregate Reports > > The list of what SHOULD be in the reports seems like it belongs in the > definitions of the report formats themselves. > The report formats, defined in MARF RFCs, present the syntax you would use to report those values if you have them. For DMARC, we're saying that all of those are a SHOULD. > 7.3 Failure reports > > Paragraphs 1 and 2 conflict -- it looks like a change to include [IODEF] > in the text was incompletely applied. > Cleaned up. > 7.3.1 Reporting Format Update > > "Operators implementing this specification also implement": Is that a > SHOULD or MUST before "also implement"? > It's an implied MUST. We're being trained lately that use of RFC2119 words is not always mandatory. In essence, this is saying "If you're a DMARC site, this is what you do." 7.4 Utility of Failure Reports > > Paragraph 1: "detects an authentication failure" -> "detects a DMARC > failure" (since authentication can succeed but DMARC fail because of > alignment) > Fixed (new location). > Paragraph 2 is not relevant to utility of failure reports and probably > belongs in 7.3.1. > It's all been rearranged, and the new layout seems better. > 8. Policy Discovery > > Step 3: This implicitly says that policy directly applied to a subdomain > takes precedence over that published by an Organizational Domain. That's > fine, but it should be stated more clearly elsewhere. As I said before, > it would be helpful to have something earlier in the specification that > talks about the ability to publish a policy either directly on a > subdomain or on an Organizational Domain. > Isn't this clear from the definition of "sp:" in 5.3 (of -08)? > Also, note that subdomain policies are necessarily strict (don't apply > to subdomains of the subdomain) because they won't be discovered using > this algorithm. It should say that somewhere do operators don't try to > apply DMARC to subtrees of their organizational domain. > I'm a little confused by your example. If I put a "p" and an "sp" tag at " example.com", then "p" applies to example.com and "sp" applies to *. example.com. That seems clear from 5.3. Are you suggesting saying that there's no way to do policy hierarchies? 10.1 Extract author domain > > "Such messages SHOULD be rejected": Agree where forbidden by RFC5322, > but a single RFC5322.From containing multiple entities is explicitly > valid. Again, this isn't the place to be making fundamental changes to > the behavior of email. > This has already been cleaned up. > 11.2.3 Error Reports > > Last paragraph: If this is published as an independent submission RFC, > there will be no opportunity to add something here. > What might one want to add? 14.4 Secure Protocols > > This seems like it belongs more in Security Consideration than here. > OK. 15.5 Identifier Alignment Considerations > > "DKIM signing practices" -> "DKIM selector records" > Fixed. > Note that actors that can gain control of SPF records or selectors can > probably publish a DMARC record for the subdomain as well, which will > take precedence over the record at the Organizational Domain. > > Last paragraph: What does "strict" have to do with this? > If you set "strict" on example.com, you remove any ability for someone that's compromised foo.example.com from generating mail that will pass DMARC. > 17.3 DNS Security > > Might want to make a distinction between DNSSEC publication and > resolution. Publication is relevant to Domain Owners, and third-party > Report Receivers. DNSSEC-aware resolution is relevant to Mail Receivers > and Report Receivers. > Done. -MSK --047d7ba977a491f940050af0e02d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Covering the stuff Dave didn't cover:

On Wed, Apr 16, 2014 at 3= :11 PM, Jim Fenton <fenton@bluepopcorn.net> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">Top of page 6: "The receiver reports to = the domain owner..."=C2=A0 The
receiver actually sends reports to a report receiver designated by the
domain owner.

Fixed.
=C2=A0

2.4 Out of Scope

I still find the double negatives to be confusing, e.g., "DMARC will n= ot
make a distinction...".=C2=A0 It's the making of a distinction tha= t's out of
scope, not the not making a distinction (forgive my own double negative, please!).

That text is apparently gone.=
=C2=A0

Bullet 10: Again, DMARC doesn't do authentication, even for domains; it=
relies on other authentication mechanisms.

3. Terminology and Definitions

Domain Owner: This definition refers to the domain owner as being the
registrant of a DNS domain. But as used elsewhere in the spec, it can
also be a delegate of that registrant that is given control over a
subdomain. The document frequently refers to a domain owner publishing a DMARC record, so it's worth clarifying who has that capability.

Report Receiver: "reports about the messages claiming to be from a thi= rd
party"=C2=A0 We're talking about the reports here, not the message= s
themselves, so I would suggest "reports from a third party about their=
messages".

Fixed and fixed.
=C2= =A0

3.1.2 General Concepts

Paragraph 2: "provide feedback to the Domain Owner". Should this = say a
Report Receiver designated by the Domain Owner, or is that too much
information at this point?

Fixed.
= =C2=A0

Paragraph 3 doesn't quite capture the sense of alignment properly,
especially for SPF. A message that is authorized by SPF might have an
unaligned envelope-from address, so the validity of SPF for such
messages is moot.

This appears to have = been rewritten already.
=C2=A0

3.1.3 Flow Diagram

Item 1: "Author constructs" and "Author also configures"= ; -> "Domain
Owner constructs" and "Domain Owner also configures" (I miss= ed this last
time)

Item 7: 'e.g., a "pass" or "fail"'=C2=A0 Are th= ere other results? If not,
remove the e.g.

Fixed and fixed.
=C2= =A0

3.1.4 Identifier Alignment

Paragraph 5: Although this document makes it clear that "strict" = and
"relaxed" are different from their usage in DKIM, I'm still h= aving
trouble with those words.=C2=A0 "strict" means that only this spe= cific domain
is affected; "relaxed" means that this domain and its subdomains = are
affected.=C2=A0 So "relaxed" is really more strict in that it enf= orces more.
I find the terms to be confusing, and would recommend something that
more directly describes whether the policy applies to subdomains.

Since we're documenting deployed infrastruct= ure here, it's way too late to be renaming these.
=C2=A0
3.1.4.1 DKIM-authenticated identifiers

Paragraph 4: Include section reference (3.2) to public suffix lists
since the section describing it has moved after this text.

Added.
=C2=A0

fo:d: "a signature": In the case of a message with multiple DKIM<= br> signatures, does that mean if any signature failed evaluation, a message is sent? Is a separate message sent for each failed signature?

Clarified.
=C2=A0
p:quarantine: What does "suspicious" mean? It sounds like it mean= s
something other than "place into spam folder" and "scrutiniz= e with
additional intensity"

Clarified.=C2=A0
pct: "DMARC-generated reports...must be sent and received unhindered&q= uot;.
How does one identity a DMARC-generated report to make sure it's
unhindered, especially if a bad actor tries to make their messages look
like reports?

The syntax of a DMARC rep= ort is defined elsewhere in the document.=C2=A0 Shouldn't it be easy to= identify one?

=C2=A0
5.3 Formal Definition

dmarc-rfmt: Should allow a colon-separated list as described in 5.2.

Fixed.
=C2=A0
7.2 Aggregate Reports

The list of what SHOULD be in the reports seems like it belongs in the
definitions of the report formats themselves.

The report formats, defined in MARF RFCs, present the syntax you wou= ld use to report those values if you have them.=C2=A0 For DMARC, we're = saying that all of those are a SHOULD.
=C2=A0
7.3 Failure reports

Paragraphs 1 and 2 conflict -- it looks like a change to include [IODEF] in the text was incompletely applied.

C= leaned up.
=C2=A0
7.3.1 Reporting Format Update

"Operators implementing this specification also implement": Is th= at a
SHOULD or MUST before "also implement"?

=
It's an implied MUST.=C2=A0 We're being trained lately t= hat use of RFC2119 words is not always mandatory.=C2=A0 In essence, this is= saying "If you're a DMARC site, this is what you do."
7.4 Utility of Failure Reports

Paragraph 1: "detects an authentication failure" -> "dete= cts a DMARC
failure" (since authentication can succeed but DMARC fail because of alignment)

Fixed (new location).
=C2= =A0
Paragraph 2 is not relevant to utility of failure reports and probably
belongs in 7.3.1.

It's all been rea= rranged, and the new layout seems better.
=C2=A0
8. Policy Discovery

Step 3: This implicitly says that policy directly applied to a subdomain takes precedence over that published by an Organizational Domain. That'= s
fine, but it should be stated more clearly elsewhere. As I said before,
it would be helpful to have something earlier in the specification that
talks about the ability to publish a policy either directly on a
subdomain or on an Organizational Domain.

Isn't this clear from the definition of "sp:" in 5.3 (of -= 08)?
=C2=A0
Also, note that subdomain policies are necessarily strict (don't apply<= br> to subdomains of the subdomain) because they won't be discovered using<= br> this algorithm. It should say that somewhere do operators don't try to<= br> apply DMARC to subtrees of their organizational domain.

I'm a little confused by your example.=C2=A0 If I put = a "p" and an "sp" tag at "example.com", then "p" applies to example.com and "sp" applies to *.example.com.=C2=A0 That seems clear from 5.3.=C2=A0= Are you suggesting saying that there's no way to do policy hierarchies= ?

10.1 Extract author domain

"Such messages SHOULD be rejected": Agree where forbidden by RFC5= 322,
but a single RFC5322.From containing multiple entities is explicitly
valid. Again, this isn't the place to be making fundamental changes to<= br> the behavior of email.

This has already= been cleaned up.
=C2=A0

11.2.3 Error Reports

Last paragraph: If this is published as an independent submission RFC,
there will be no opportunity to add something here.

What might one want to add?

14.4 Secure Protocols

This seems like it belongs more in Security Consideration than here.

OK.

15.5 Identifier Alignment Considerations

"DKIM signing practices" -> "DKIM selector records"<= br>

Fixed.
=C2=A0
Note that actors that can gain control of SPF records or selectors can
probably publish a DMARC record for the subdomain as well, which will
take precedence over the record at the Organizational Domain.

Last paragraph: What does "strict" have to do with this?

If you set "strict" on example.com, you remove any ability for someone that&#= 39;s compromised foo.example.com fro= m generating mail that will pass DMARC.
=C2=A0
17.3 DNS Security

Might want to make a distinction between DNSSEC publication and
resolution. Publication is relevant to Domain Owners, and third-party
Report Receivers. DNSSEC-aware resolution is relevant to Mail Receivers
and Report Receivers.

Done.

-MSK=

--047d7ba977a491f940050af0e02d-- From nobody Tue Dec 23 23:13: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 1183A1ACD3B for ; Tue, 23 Dec 2014 23:13:29 -0800 (PST) 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, 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 lWV0fw0vNXhU for ; Tue, 23 Dec 2014 23:13:27 -0800 (PST) Received: from mx-out-1.zmailcloud.com (01.zmailcloud.com [192.198.85.104]) by ietfa.amsl.com (Postfix) with ESMTP id 0769D1ACCE7 for ; Tue, 23 Dec 2014 23:13:27 -0800 (PST) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 90E0D564EEB; Wed, 24 Dec 2014 01:13:26 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 87FEB60203; Wed, 24 Dec 2014 01:13:26 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEj8wBokf8CI; Wed, 24 Dec 2014 01:13:26 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 3124C601D0; Wed, 24 Dec 2014 01:13:26 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-2.01.com 3124C601D0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1419405206; bh=yBfY4Sd+ohlSaK7OnX9LRrdKDLid3hvGLxXphwzkdx8=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; b=VrSfyK7pGs6zp2OPraZbbE7lv5ZxpyFOQ0Il64dZubXy07HHyCFy0Y8hbbYTHZFJp G3gQMmZBbBZdz1Z6EzNjBcgUIMPpyT1K4WqRzg7gFVA+REPfwt/o4y5mZqDIyFnGJC FH92WNYPpH5rtArQ2dRBaXnaYJeqhwD64yUW7qTg= Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 0AAB360203; Wed, 24 Dec 2014 01:13:26 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 0K5D7C0UGDhP; Wed, 24 Dec 2014 01:13:25 -0600 (CST) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-2.01.com (Postfix) with ESMTP id D1E9D601D0; Wed, 24 Dec 2014 01:13:25 -0600 (CST) Date: Wed, 24 Dec 2014 01:13:24 -0600 (CST) From: Franck Martin To: "Murray S. Kucherawy" Message-ID: <1712480034.45611.1419405204864.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <6858606.AfKicQ9CJZ@kitterman-optiplex-9020m>

MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_45610_69099402.1419405204863" X-Originating-IP: [10.1.101.178] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF34 (Mac)/8.0.5_GA_5839) Thread-Topic: Jim Fenton's review of -04 Thread-Index: he8fT5yENeaigtP84xG2geyz4DTpoQ== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/ukaxWJOrS9e16NhB6iEOao4MZ5w Cc: dmarc@ietf.org, Scott Kitterman Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 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, 24 Dec 2014 07:13:29 -0000 ------=_Part_45610_69099402.1419405204863 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit ----- Original Message ----- > From: "Murray S. Kucherawy" > To: "Scott Kitterman" > Cc: dmarc@ietf.org > Sent: Tuesday, December 23, 2014 10:32:44 PM > Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 > On Mon, Dec 22, 2014 at 10:44 AM, Scott Kitterman < sklist@kitterman.com > > wrote: > > There was a recent thread on postfix-users about DMARC rejections when > > there > > > are DNS errors that caused me to review -08 to see what it says on the > > matter. > > > At the end of section 5.6.2, it says: > > > Handling of messages for which SPF and/or DKIM evaluation encounters > > > a DNS error is left to the discretion of the Mail Receiver. Further > > > discussion is available in Section 5.6.3. > > > My reading of 5.6.3 though is that it only discusses DNS errors in the > > context > > > of failing to retrieve the DMARC record. Any discussion about handling DNS > > > errors for SPF/DKIM seems to be missing. > > Yes, DMARC punts on what to do when SPF or DKIM encounter transient failures. > I imagine that's because those modules would arrange to temp-fail a message > that has that problem. I suppose my experience is that messages don't even > get to the point of DMARC evaluation when that happens, because the message > has already been temp-failed. As SPF (and DKIM) can report a message with the status tempfail, it means the message is not necessarily tempfail (bounced). > If you think about DKIM and SPF as being part of a layer below DMARC, then > I'm not sure it's wise of us to be making any kind of normative statement > about what to do when the lower layers fail. > What do you suggest? I think we should recommend something here, not sure if it needs to be normative. We do say to ignore the SPF policy when p!=none, though I think we can be normative on the lower layers. I see 2 options here: 1)tempfail the message is either SPF and DKIM have a tempfail status 2)tempfail the message if both SPF and DKIM have a tempfail status 1) is my preferred and is aggressive, therefore not sure people will like it. I'll settle for 2) As explained in another post, I'm worried I can run a DNS attack (or just a self inflicted DNS bad config) and get DMARC to reject emails it should have accepted (has the DMARC policy in cache, but cannot assert SPF and DKIM). ------=_Part_45610_69099402.1419405204863 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

From: "Murray S. Kucherawy" <superuser@= gmail.com>
To: "Scott Kitterman" <sklist@kitterman.com><= br>Cc: dmarc@ietf.org
Sent: Tuesday, December 23, 2014 10:= 32:44 PM
Subject: Re: [dmarc-ietf] Jim Fenton's review of -04
=

On Mon, Dec 22, 2014 at 10:44 AM, Scott Kit= terman <sklist@kitterman.com> wrote:
There w= as a recent thread on postfix-users about DMARC rejections when there
are DNS errors that caused me to review -08 to see what it says on the matt= er.

At the end of section 5.6.2, it says:

Handling of messages for which SPF and/or DKIM evaluation enco= unters
a DNS error is left to the discretion of the Mail Receiver.&nb= sp; Further
discussion is available in Section 5.6.3.

My reading of 5.6.3 though is that it only discusses DNS errors in the cont= ext
of failing to retrieve the DMARC record. Any discussion about handlin= g DNS
errors for SPF/DKIM seems to be missing.

Yes, DMARC punts on what to do when SPF or DKIM encounter transient failu= res. I imagine that's because those modules would arrange to temp-fai= l a message that has that problem. I suppose my experience is that me= ssages don't even get to the point of DMARC evaluation when that happens, b= ecause the message has already been temp-failed.

As SPF (and DKIM) can report a message with the status t= empfail, it means the message is not necessarily tempfail (bounced).

If you think about DKIM and SPF as being part of a layer belo= w DMARC, then I'm not sure it's wise of us to be making any kind of normati= ve statement about what to do when the lower layers fail.

What do you suggest?

I think we should recommend something here, not sure if it needs to = be normative. We do say to ignore the SPF policy when p!=3Dnone, though I t= hink we can be normative on the lower layers. I see 2 options here:
1)tempfail the message is either SPF and DKIM have a tempfail status=
2)tempfail the message if both SPF and DKIM have a tempfail = status

1) is my preferred and is aggressive, t= herefore not sure people will like it. I'll settle for 2)
As explained in another post, I'm worried I can run a DNS attac= k (or just a self inflicted DNS bad config) and get DMARC to reject emails = it should have accepted (has the DMARC policy in cache, but cannot assert S= PF and DKIM).

------=_Part_45610_69099402.1419405204863-- From nobody Tue Dec 23 23:20: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 9EFBD1ACD4A for ; Tue, 23 Dec 2014 23:20:33 -0800 (PST) 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 Yf2POmuMOEbg for ; Tue, 23 Dec 2014 23:20:32 -0800 (PST) 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 DA1321ACD45 for ; Tue, 23 Dec 2014 23:20:31 -0800 (PST) Received: by mail-wg0-f52.google.com with SMTP id x12so10727635wgg.39 for ; Tue, 23 Dec 2014 23:20:30 -0800 (PST) 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=UYdCpsMrVdE3jpCk/ftKxVFO+k+/S91oNuN/kDbMjuE=; b=aqK6WEJXXtVzXkYl/1pQtVwXGyDhV228FNpNqhRSZ+/m8SX3w2EPjmAu7gffFDfJmJ Ghwhs9z8JtQxjlyYO+qBf0w6x7MBFXDbG7s7GYFO0R5qwbFsfAAx0zrzrFp9Ouie1thE GHb4cCbcP80dUKE5r0vZGPTuodfu163DFpDDECvQjNVCll3mHdHPiJBlHEC5H4Zjj4bi F4meERXoasjczUcklyQdNr3tpEB+q4y4bgysOsPftKCn1zmfDDy7DKkjXMEsM66mNh3P kMUVqenRr2euW5tWjaToKNswvnlSe5IMnJnF7PWsrwSUDCn3U/Cw+pbg3FGsPNX8VpRK rKdw== MIME-Version: 1.0 X-Received: by 10.180.85.33 with SMTP id e1mr48331009wiz.61.1419405630593; Tue, 23 Dec 2014 23:20:30 -0800 (PST) Received: by 10.27.204.198 with HTTP; Tue, 23 Dec 2014 23:20:30 -0800 (PST) In-Reply-To: <1712480034.45611.1419405204864.JavaMail.zimbra@peachymango.org> References: <6858606.AfKicQ9CJZ@kitterman-optiplex-9020m> <1712480034.45611.1419405204864.JavaMail.zimbra@peachymango.org> Date: Wed, 24 Dec 2014 02:20:30 -0500 Message-ID: From: "Murray S. Kucherawy" To: Franck Martin Content-Type: multipart/alternative; boundary=f46d04428074675e7e050af120b4 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/bLdzN07CVtap2WGhMNlmwOgyJx0 Cc: "dmarc@ietf.org" , Scott Kitterman Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 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, 24 Dec 2014 07:20:33 -0000 --f46d04428074675e7e050af120b4 Content-Type: text/plain; charset=UTF-8 On Wed, Dec 24, 2014 at 2:13 AM, Franck Martin wrote: > I think we should recommend something here, not sure if it needs to be > normative. We do say to ignore the SPF policy when p!=none, though I think > we can be normative on the lower layers. I see 2 options here: > 1)tempfail the message is either SPF and DKIM have a tempfail status > 2)tempfail the message if both SPF and DKIM have a tempfail status > > 1) is my preferred and is aggressive, therefore not sure people will like > it. I'll settle for 2) > > As explained in another post, I'm worried I can run a DNS attack (or just > a self inflicted DNS bad config) and get DMARC to reject emails it should > have accepted (has the DMARC policy in cache, but cannot assert SPF and > DKIM). > > I think it's reasonably clear from 5.6.3 that the "fail open" choice is possibly dangerous, as is anything that fails open. But more importantly, I'm also worried about making a normative decision now about something we deliberately haven't specified up to this point for whatever reason. We are supposed to be documenting current practice with this effort, not establishing something new. Might this something best left for the standards track WG effort? -MSK --f46d04428074675e7e050af120b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Dec 24, 2014 at 2:13 AM, Franck Martin <fr= anck@peachymango.org> wrote:
I think we should recommend something here, not sure if = it needs to be normative. We do say to ignore the SPF policy when p!=3Dnone= , though I think we can be normative on the lower layers. I see 2 options h= ere:
1)tempfail the message is either SPF and DKIM have a tem= pfail status
2)tempfail the message if both SPF and DKIM have= a tempfail status

1) is my preferred and is a= ggressive, therefore not sure people will like it. I'll settle for 2)

As explained in another post, I'm worried I= can run a DNS attack (or just a self inflicted DNS bad config) and get DMA= RC to reject emails it should have accepted (has the DMARC policy in cache,= but cannot assert SPF and DKIM).

I think it's reasona= bly clear from 5.6.3 that the "fail open" choice is possibly dang= erous, as is anything that fails open.

But more importantly, I'm also worried about making a normative dec= ision now about something we deliberately haven't specified up to this = point for whatever reason.=C2=A0 We are supposed to be documenting current = practice with this effort, not establishing something new.

Might thi= s something best left for the standards track WG effort?

-MSK
--f46d04428074675e7e050af120b4-- From nobody Tue Dec 23 23:40:42 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 396891ACD30 for ; Tue, 23 Dec 2014 23:40:41 -0800 (PST) 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, 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 SvW4qz5_hzI7 for ; Tue, 23 Dec 2014 23:40:39 -0800 (PST) Received: from mx-out-1.zmailcloud.com (01.zmailcloud.com [192.198.85.104]) by ietfa.amsl.com (Postfix) with ESMTP id 018F41ACD4E for ; Tue, 23 Dec 2014 23:40:39 -0800 (PST) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 9D0F8564EFD; Wed, 24 Dec 2014 01:40:38 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 89E5160236; Wed, 24 Dec 2014 01:40:38 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rNdm6eE3_xU3; Wed, 24 Dec 2014 01:40:38 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 5C48660266; Wed, 24 Dec 2014 01:40:38 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-2.01.com 5C48660266 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1419406838; bh=fYJ075OQiC+0cggfGNP6oru8FEWJ7+VAjxB8IgVpvXI=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; b=Q2cfdJvoo+EoyhDsJJvxAf3jNYZ7cwwkbyvqWfe3eJfAGBGVlpSd5EsUaCXuQMr6E slkw9QTnfeDc160pgqZpL8EdinOUYY+Ma7OOhGj4DLA2glQFu6W/MNbfMNoeOo63MX /IGvYBNXnaSUKdtKHm0hayUaVLWKsh+ZnYZN+fwY= Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 3A8556024C; Wed, 24 Dec 2014 01:40:38 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id a6AzgL3RYYLO; Wed, 24 Dec 2014 01:40:38 -0600 (CST) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-2.01.com (Postfix) with ESMTP id 143EB60236; Wed, 24 Dec 2014 01:40:38 -0600 (CST) Date: Wed, 24 Dec 2014 01:40:37 -0600 (CST) From: Franck Martin To: "Murray S. Kucherawy" Message-ID: <1194394943.45680.1419406837913.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <6858606.AfKicQ9CJZ@kitterman-optiplex-9020m> <1712480034.45611.1419405204864.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_45679_832768806.1419406837912" X-Originating-IP: [10.1.101.179] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF34 (Mac)/8.0.5_GA_5839) Thread-Topic: Jim Fenton's review of -04 Thread-Index: fV1/F0XxOZJ6Rfv92LwGvDwdJpKRzQ== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/N8FWmcSWZUEuOzErshbF6-cWko4 Cc: dmarc@ietf.org, Scott Kitterman Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 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, 24 Dec 2014 07:40:41 -0000 ------=_Part_45679_832768806.1419406837912 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit ----- Original Message ----- > From: "Murray S. Kucherawy" > To: "Franck Martin" > Cc: dmarc@ietf.org, "Scott Kitterman" > Sent: Tuesday, December 23, 2014 11:20:30 PM > Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 > On Wed, Dec 24, 2014 at 2:13 AM, Franck Martin < franck@peachymango.org > > wrote: > > I think we should recommend something here, not sure if it needs to be > > normative. We do say to ignore the SPF policy when p!=none, though I think > > we can be normative on the lower layers. I see 2 options here: > > > 1)tempfail the message is either SPF and DKIM have a tempfail status > > > 2)tempfail the message if both SPF and DKIM have a tempfail status > > > 1) is my preferred and is aggressive, therefore not sure people will like > > it. > > I'll settle for 2) > > > As explained in another post, I'm worried I can run a DNS attack (or just a > > self inflicted DNS bad config) and get DMARC to reject emails it should > > have > > accepted (has the DMARC policy in cache, but cannot assert SPF and DKIM). > > I think it's reasonably clear from 5.6.3 that the "fail open" choice is > possibly dangerous, as is anything that fails open. > But more importantly, I'm also worried about making a normative decision now > about something we deliberately haven't specified up to this point for > whatever reason. We are supposed to be documenting current practice with > this effort, not establishing something new. > Might this something best left for the standards track WG effort? Fair enough, but curious about standard practice. For instance what openDMARC do? and others? I think DMARC got us to be "stricter" and less "lenient" with email. ------=_Part_45679_832768806.1419406837912 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
From: "Murray S. Kucherawy" <superuser@= gmail.com>
To: "Franck Martin" <franck@peachymango.org><= br>Cc: dmarc@ietf.org, "Scott Kitterman" <sklist@kitterman.com>= ;
Sent: Tuesday, December 23, 2014 11:20:30 PM
Subject: Re: [dmarc-ietf] Jim Fenton's review of -04

On Wed, Dec 24, 2014 at 2:13 AM, Franck Martin <<= a href=3D"mailto:franck@peachymango.org" target=3D"_blank">franck@peachyman= go.org> wrote:
I think we should r= ecommend something here, not sure if it needs to be normative. We do say to= ignore the SPF policy when p!=3Dnone, though I think we can be normative o= n the lower layers. I see 2 options here:
1)tempfail the mess= age is either SPF and DKIM have a tempfail status
2)tempfail = the message if both SPF and DKIM have a tempfail status

<= /div>
1) is my preferred and is aggressive, therefore not sure people w= ill like it. I'll settle for 2)

As explained i= n another post, I'm worried I can run a DNS attack (or just a self inflicte= d DNS bad config) and get DMARC to reject emails it should have accepted (h= as the DMARC policy in cache, but cannot assert SPF and DKIM).

I think it's reasonably clear from 5.6.3 that the "fail open" choice i= s possibly dangerous, as is anything that fails open.

But more importantly, I'm also worried about = making a normative decision now about something we deliberately haven't spe= cified up to this point for whatever reason. We are supposed to be do= cumenting current practice with this effort, not establishing something new= .

Might this something best left for the standards track = WG effort?

Fair enough, but= curious about standard practice. For instance what openDMARC do? and other= s?

I think DMARC got us to be "stricter" and l= ess "lenient" with email.

------=_Part_45679_832768806.1419406837912-- From nobody Tue Dec 23 23:46: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 87C291ACD52 for ; Tue, 23 Dec 2014 23:46:09 -0800 (PST) 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 y685IoAONivG for ; Tue, 23 Dec 2014 23:46:07 -0800 (PST) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 401261ACD50 for ; Tue, 23 Dec 2014 23:46:07 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id h11so12810093wiw.7 for ; Tue, 23 Dec 2014 23:46:06 -0800 (PST) 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=j8Ttck6vOCWGcvoKVpNaVyt61yXu+rsIrDvh1t5g7F8=; b=a2vkfywLUZPrJLP92suRE7Y3ailaJ9VTlDbMvX0h8qUuKItiju/ORbdzQt1c/HP7B/ FFy0QJJ1gEHK+OMMIWd4pyYf9uivBU3fhvw6TinjmY90JyoyeXzGH2u+xYdfncPv2h7z PCuRj1h3nmIHT7JXz09ERRw1EWccINduWDwOP6iWWjZPzPAtqSIT4Uv6IHvmC1CuFv1m 2hdlTM8jPs1bEDSvipn26fyjTVBGhsQxXtWzzvMf9fawhatoPqd1CxmDrRxJSarnY83B WJ1k5xh6EfGzbH2wkLpf6XGcr3iNDDfiw+aT1xdW4cESV1Nm9SrlPXVi+RJ/Jyv8n4Ee OEPg== MIME-Version: 1.0 X-Received: by 10.181.13.242 with SMTP id fb18mr49052320wid.1.1419407166048; Tue, 23 Dec 2014 23:46:06 -0800 (PST) Received: by 10.27.204.198 with HTTP; Tue, 23 Dec 2014 23:46:05 -0800 (PST) Date: Wed, 24 Dec 2014 02:46:05 -0500 Message-ID: From: "Murray S. Kucherawy" To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=f46d043c05c4ec9134050af17b51 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/qsPrSwsWA7U0g32AbM3s8uS0nC4 Subject: [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: Wed, 24 Dec 2014 07:46:09 -0000 --f46d043c05c4ec9134050af17b51 Content-Type: text/plain; charset=UTF-8 Colleagues, I'm now completely caught up (as far as I can tell) on addressing feedback about the DMARC base draft that's going through the ISE process. As before, I'm resisting changes that add or change anything normative. I'm going only for things that clarify text, increase the accurate reflection of current practice, or help us to avoid IESG conflict review issues. Please let me know if I've missed anything that fits in one of those categories. Otherwise, -09 will go up soon including all of the changes that seem to fit within those boundaries. The planned diff to -08, which will become -09, is here: http://www.blackops.org/~msk/dmarc/diff.html Anything outside of those is open fodder for future working group discussion of a standards track version. -MSK --f46d043c05c4ec9134050af17b51 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Colleagues,

I'm now completely c= aught up (as far as I can tell) on addressing feedback about the DMARC base= draft that's going through the ISE process.

As before, I'm = resisting changes that add or change anything normative.=C2=A0 I'm goin= g only for things that clarify text, increase the accurate reflection of cu= rrent practice, or help us to avoid IESG conflict review issues.=C2=A0 Plea= se let me know if I've missed anything that fits in one of those catego= ries.=C2=A0 Otherwise, -09 will go up soon including all of the changes tha= t seem to fit within those boundaries.

The planned diff t= o -08, which will become -09, is here:
http://www.blackops.org/~msk/dmarc/diff.html

Anything outside of those is open fodder for future workin= g group discussion of a standards track version.

-MSK
--f46d043c05c4ec9134050af17b51-- From nobody Tue Dec 23 23:55: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 CB8221ACD53 for ; Tue, 23 Dec 2014 23:55:03 -0800 (PST) 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 cZ08BeciEDOP for ; Tue, 23 Dec 2014 23:55:01 -0800 (PST) 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 BCAB81ACD50 for ; Tue, 23 Dec 2014 23:55:00 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id bs8so12912410wib.10 for ; Tue, 23 Dec 2014 23:54:59 -0800 (PST) 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=H4GVWF39t/fgC4P6hYrvTkmma/vsoGf89EZ6riVjbqk=; b=EsLwpgM6HaE2iWhfLCDY+qF4KCiGBUsOpioxqHi4IoJSOsw7GFeFAkUVwhNTYegWs/ siySmAgdCbWWi/C/8NH7HikMXrG2DdyW7EjnqDJNbxpBkJ564Wn6vE5wbMZJEE9uCe45 vuXyF22VqXGJTWyW/fevbj7LwO8lZ95rcT7YnN6IJJpBrTN+5pB7HIB8cy2X8NOIWpJP ejMxIzydsMBL+HZ8+DyyUqWUzpIYNEZPDFG88xVY9Cryc6T/DEM6a2WbEvknpqlVHB2z kxM2EAeH3J3G5/I4D4VDIL8O4GqLwxHnibTCgsRt5VA2Zj9DErOn2ZS+ORISu1IDA9ex 6PrQ== MIME-Version: 1.0 X-Received: by 10.194.200.234 with SMTP id jv10mr61187260wjc.110.1419407699572; Tue, 23 Dec 2014 23:54:59 -0800 (PST) Received: by 10.27.204.198 with HTTP; Tue, 23 Dec 2014 23:54:59 -0800 (PST) In-Reply-To: <1194394943.45680.1419406837913.JavaMail.zimbra@peachymango.org> References: <6858606.AfKicQ9CJZ@kitterman-optiplex-9020m> <1712480034.45611.1419405204864.JavaMail.zimbra@peachymango.org> <1194394943.45680.1419406837913.JavaMail.zimbra@peachymango.org> Date: Wed, 24 Dec 2014 02:54:59 -0500 Message-ID: From: "Murray S. Kucherawy" To: Franck Martin Content-Type: multipart/alternative; boundary=047d7bb70bb2b97d5c050af19b36 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/OeBdG4qVKureOTYYBS8xg-Q5kKU Cc: "dmarc@ietf.org" , Scott Kitterman Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 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, 24 Dec 2014 07:55:04 -0000 --047d7bb70bb2b97d5c050af19b36 Content-Type: text/plain; charset=UTF-8 On Wed, Dec 24, 2014 at 2:40 AM, Franck Martin wrote: > ------------------------------ > > *From: *"Murray S. Kucherawy" > *To: *"Franck Martin" > *Cc: *dmarc@ietf.org, "Scott Kitterman" > *Sent: *Tuesday, December 23, 2014 11:20:30 PM > *Subject: *Re: [dmarc-ietf] Jim Fenton's review of -04 > > On Wed, Dec 24, 2014 at 2:13 AM, Franck Martin > wrote: > >> I think we should recommend something here, not sure if it needs to be >> normative. We do say to ignore the SPF policy when p!=none, though I think >> we can be normative on the lower layers. I see 2 options here: >> 1)tempfail the message is either SPF and DKIM have a tempfail status >> 2)tempfail the message if both SPF and DKIM have a tempfail status >> >> 1) is my preferred and is aggressive, therefore not sure people will like >> it. I'll settle for 2) >> >> As explained in another post, I'm worried I can run a DNS attack (or just >> a self inflicted DNS bad config) and get DMARC to reject emails it should >> have accepted (has the DMARC policy in cache, but cannot assert SPF and >> DKIM). >> >> > I think it's reasonably clear from 5.6.3 that the "fail open" choice is > possibly dangerous, as is anything that fails open. > > But more importantly, I'm also worried about making a normative decision > now about something we deliberately haven't specified up to this point for > whatever reason. We are supposed to be documenting current practice with > this effort, not establishing something new. > > Might this something best left for the standards track WG effort? > > Fair enough, but curious about standard practice. For instance what > openDMARC do? and others? > > I think DMARC got us to be "stricter" and less "lenient" with email. > > OpenDMARC gets the message only after OpenDKIM is done with it, so if OpenDKIM temp-fails, OpenDMARC never even sees it. Thus, the case we're concerned about here can't ever happen. -MSK --047d7bb70bb2b97d5c050af19b36 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Dec 24, 2014 at 2:40 AM, Franck Martin <fr= anck@peachymango.org> wrote:

From: "Murray S. Kucherawy" <superuser@gmail.com>
To: <= /b>"Franck Martin" <franck@peachymango.org>
Cc: dmarc@ietf.org, "Scott Kit= terman" <= sklist@kitterman.com>
Sent: Tuesday, December 23, 2014 11:= 20:30 PM
Subject: Re: [dmarc-ietf] Jim Fenton= 9;s review of -04

On Wed, Dec 24, 2014 at 2:13 AM, Franck Martin &= lt;franck@peach= ymango.org> wrote:
I think we shou= ld recommend something here, not sure if it needs to be normative. We do sa= y to ignore the SPF policy when p!=3Dnone, though I think we can be normati= ve on the lower layers. I see 2 options here:
1)tempfail the = message is either SPF and DKIM have a tempfail status
2)tempf= ail the message if both SPF and DKIM have a tempfail status
<= br>
1) is my preferred and is aggressive, therefore not sure peop= le will like it. I'll settle for 2)

As exp= lained in another post, I'm worried I can run a DNS attack (or just a s= elf inflicted DNS bad config) and get DMARC to reject emails it should have= accepted (has the DMARC policy in cache, but cannot assert SPF and DKIM).<= br>

I think it's reasonably clear from 5.6.3 that the &quo= t;fail open" choice is possibly dangerous, as is anything that fails o= pen.

But more importantl= y, I'm also worried about making a normative decision now about somethi= ng we deliberately haven't specified up to this point for whatever reas= on.=C2=A0 We are supposed to be documenting current practice with this effo= rt, not establishing something new.

Might this something = best left for the standards track WG effort?

=
Fair enough, but curious about standard pract= ice. For instance what openDMARC do? and others?

I think DMARC got us to be "stricter" and less "lenient&q= uot; with email.

OpenDMARC gets the message only after Ope= nDKIM is done with it, so if OpenDKIM temp-fails, OpenDMARC never even sees= it.=C2=A0 Thus, the case we're concerned about here can't ever hap= pen.

-MSK

--047d7bb70bb2b97d5c050af19b36-- From nobody Wed Dec 24 00:55: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 5C1B41ACDA7 for ; Wed, 24 Dec 2014 00:55:54 -0800 (PST) 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 vZyuafaYaFpT for ; Wed, 24 Dec 2014 00:55:52 -0800 (PST) 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 D31D61A1A1F for ; Wed, 24 Dec 2014 00:55:52 -0800 (PST) Received: from [10.176.126.24] (100.sub-70-198-192.myvzw.com [70.198.192.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 59CDDC40103; Wed, 24 Dec 2014 02:55:51 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1419411351; bh=BDDQ98rXEaHKOiTX/D4LNVMmMFWRf3bPCv0rckpJXuE=; h=In-Reply-To:References:Subject:From:Date:To:From; b=iCBab0tfmlg8Uh7tGUveqrV8/NzJJFqq/S4WJeIYxE4disNAavAqo/R7ZSBHB1Qed CX5Wrk1uktPa3rD0dxZ4cCIZAbrfh5cwZ4vf33Q1QxVyGlRSXiLjJ+gDAbDrS8cOsc 3ckkPt2W9vA5Oc77CN6aEBSk7vdKik55T08Bk9Tk= User-Agent: K-9 Mail for Android In-Reply-To: References: <54986CCC.70200@sonnection.nl> <54986DF1.9060807@dcrocker.net> <7243484.JQFTys4I1u@kitterman-optiplex-9020m> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Wed, 24 Dec 2014 03:50:27 -0500 To: "dmarc@ietf.org" Message-ID: <5B5E1BA1-1F6B-444B-A034-08ADA178D589@kitterman.com> Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/0hNFeHcGIkDENLcQm5yhAHwlfE4 Subject: Re: [dmarc-ietf] DMARC and TEMP errors was: Re: Jim Fenton's review of -04 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, 24 Dec 2014 08:55:54 -0000 On December 24, 2014 12:49:04 AM EST, "Murray S. Kucherawy" wrote: >On Mon, Dec 22, 2014 at 3:18 PM, Scott Kitterman >wrote: > >> >> As I read -08 what to do in that case is undefined. There's a >dangling >> pointer >> to 5.6.3. It's dangling because nothing in that section addresses >the >> question of how to handle DKIM/SPF temporary errors. >> >> >5.6.3's final paragraph makes it clear that the action taken is at the >discretion of the mail receiver, and gives two examples of >non-destructive >ways to handle that case. Do we need to say more than that? > >-MSK No. That's specifically about DNS errors related to DMARC record retrieval. My issue is what to after successfully retrieving the DMARC record if one of SPF/DKIM doesn't pass and align (DMARC fail) and the other of SPF/DKIM returns a DNS error. 5.6.2 appears to me to promise that is explained in 5.6.3 and it's not. Personally, I think rejecting mail based on temporary DNS errors is something the draft should discourage. Scott K From nobody Wed Dec 24 01:06: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 DD7DE1AD008 for ; Wed, 24 Dec 2014 01:06:25 -0800 (PST) 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 s7H1lIPQ6Qfz for ; Wed, 24 Dec 2014 01:06:23 -0800 (PST) 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 D84F31A6F47 for ; Wed, 24 Dec 2014 01:06:23 -0800 (PST) Received: from [10.176.126.24] (100.sub-70-198-192.myvzw.com [70.198.192.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 9E19FC40103; Wed, 24 Dec 2014 03:06:21 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1419411982; bh=2Yv+wzfmOXzvBM97qUa3BdkfX1HiIt0f5sXcuB6syQ8=; h=In-Reply-To:References:Subject:From:Date:To:From; b=MzPnzI7Avr71EhmXhIMOgKcPVN2wEgJecIzTwLx+biNIofOL31I0Y26GNblEi2kQ0 MbM+/Dv6fH3wQwEOD4mJAIKgBLi1bh/YRZOLpPzOeGox7J5ywBhPWks5phPMGyhfq5 dAzd2oNFvePBQJVcHCeAUiit3QmywFe7NUttSqss= User-Agent: K-9 Mail for Android In-Reply-To: References: <6858606.AfKicQ9CJZ@kitterman-optiplex-9020m> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Wed, 24 Dec 2014 04:04:51 -0500 To: "dmarc@ietf.org" Message-ID: <43288BDA-4BDD-4A18-A6DD-232BCFFDEB43@kitterman.com> Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/G6sulMe5sDJoayVNWlKoFrBxW98 Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 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, 24 Dec 2014 09:06:26 -0000 On December 24, 2014 1:32:44 AM EST, "Murray S. Kucherawy" wrote: >On Mon, Dec 22, 2014 at 10:44 AM, Scott Kitterman > >wrote: > >> There was a recent thread on postfix-users about DMARC rejections >when >> there >> are DNS errors that caused me to review -08 to see what it says on >the >> matter. >> >> At the end of section 5.6.2, it says: >> >> Handling of messages for which SPF and/or DKIM evaluation >encounters >> a DNS error is left to the discretion of the Mail Receiver. >Further >> discussion is available in Section 5.6.3. >> >> My reading of 5.6.3 though is that it only discusses DNS errors in >the >> context >> of failing to retrieve the DMARC record. Any discussion about >handling DNS >> errors for SPF/DKIM seems to be missing. >> > >Yes, DMARC punts on what to do when SPF or DKIM encounter transient >failures. I imagine that's because those modules would arrange to >temp-fail a message that has that problem. I suppose my experience is >that >messages don't even get to the point of DMARC evaluation when that >happens, >because the message has already been temp-failed. > >If you think about DKIM and SPF as being part of a layer below DMARC, >then >I'm not sure it's wise of us to be making any kind of normative >statement >about what to do when the lower layers fail. > >What do you suggest? > >-MSK The draft strongly encourages DMARC implementers to ignore SPF policy, so I don't think assuming messages will be deferred due only due to SPF or DKIM results indicating a temporary DNS error is appropriate. I think that in the case of a temporary DNS error in one of the lower level protocols, insufficient inputs are available to conclude a message has failed DMARC tests. Receivers can either ignore DMARC for this message due to incomplete evaluation or they can defer the message in the hope that the temporary error will be resolved when the message is retried. Receivers MUST NOT apply DMARC policy and reject or quarantine because the DMARC evaluation is incomplete. Scott K From nobody Wed Dec 24 01:11:42 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 539F61AD008 for ; Wed, 24 Dec 2014 01:11:38 -0800 (PST) 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 NvMG1Kw-t05o for ; Wed, 24 Dec 2014 01:11:36 -0800 (PST) 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 967B21AD005 for ; Wed, 24 Dec 2014 01:11:36 -0800 (PST) Received: from [10.176.126.24] (100.sub-70-198-192.myvzw.com [70.198.192.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 5F0C7C40103; Wed, 24 Dec 2014 03:11:35 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1419412295; bh=TRG+JxEa3qYMvqd5UNmarmexCs0dxr8cqSDsM776oXA=; h=In-Reply-To:References:Subject:From:Date:To:From; b=HD1d36PUeE3rHSclrNUnrC/V341/f6+9FU4erg/CzLDseTIDbfhpn3e+JBTRnJi1Y zfAXOF0OM7ajkhTzdKjOWaenaIv/98vP+pceeCYLSPeYyOFWgwAcWKrOhy7ZCJ//VX l3BTGliF9Ni8diFQuKEsRzmou471yRqSmp0iVreU= User-Agent: K-9 Mail for Android In-Reply-To: References: <6858606.AfKicQ9CJZ@kitterman-optiplex-9020m> <1712480034.45611.1419405204864.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Wed, 24 Dec 2014 04:09:49 -0500 To: "dmarc@ietf.org" Message-ID: <62849448-BFA5-49C0-A2B6-7A4B5CC34F2C@kitterman.com> Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/AedZuRRr6Rl9o0tjbnpYUFlc2Ck Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 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, 24 Dec 2014 09:11:38 -0000 On December 24, 2014 2:20:30 AM EST, "Murray S. Kucherawy" wrote: >On Wed, Dec 24, 2014 at 2:13 AM, Franck Martin >wrote: > >> I think we should recommend something here, not sure if it needs to >be >> normative. We do say to ignore the SPF policy when p!=none, though I >think >> we can be normative on the lower layers. I see 2 options here: >> 1)tempfail the message is either SPF and DKIM have a tempfail status >> 2)tempfail the message if both SPF and DKIM have a tempfail status >> >> 1) is my preferred and is aggressive, therefore not sure people will >like >> it. I'll settle for 2) >> >> As explained in another post, I'm worried I can run a DNS attack (or >just >> a self inflicted DNS bad config) and get DMARC to reject emails it >should >> have accepted (has the DMARC policy in cache, but cannot assert SPF >and >> DKIM). >> >> >I think it's reasonably clear from 5.6.3 that the "fail open" choice is >possibly dangerous, as is anything that fails open. > >But more importantly, I'm also worried about making a normative >decision >now about something we deliberately haven't specified up to this point >for >whatever reason. We are supposed to be documenting current practice >with >this effort, not establishing something new. > >Might this something best left for the standards track WG effort? 5.6.2 promises 5.6.3 addresses the question and it doesn't. At the very least, 5.6.2 should be fixed not to over promise what 5.6.3 will provide. I do think it's better to answer it now. I'm not sure when or if the WG will address missing chunks of protocol definition. The charter pretty well assumes there aren't any. Scott K From nobody Wed Dec 24 07:23: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 A11E41A8A7F for ; Wed, 24 Dec 2014 07:23:02 -0800 (PST) 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 U_bm0DtMzWvh for ; Wed, 24 Dec 2014 07:23:01 -0800 (PST) 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 2399D1A8A7A for ; Wed, 24 Dec 2014 07:23:01 -0800 (PST) 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 sBOFMtU5009704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 24 Dec 2014 07:22:59 -0800 Message-ID: <549ADA41.40005@dcrocker.net> Date: Wed, 24 Dec 2014 07:22:41 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <5494A6F5.5020906@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 24 Dec 2014 07:22:59 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Ev7c-2G8x73qnINRiTwX13wI5cE Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 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, 24 Dec 2014 15:23:02 -0000 On 12/23/2014 10:11 PM, Murray S. Kucherawy wrote: > -08 text says: > > "If the RFC5322.From domain does not exist in the DNS, Mail > Receivers > SHOULD direct the receiving SMTP server to reject the message. The > choice of mechanism for such rejection and the implications of those > choices are discussed in Section 9.3." > > I suggest removing it. Although a common anti-abuse mechanism, it's out > of scope for DMARC. > > > I disagree. DMARC operators all seem to apply this practice, so it's > correct to say that if you play this game, you reject mail from > non-existent domains. Essentially in this way DMARC is a profile of > RFC5321/RFC5322, which is perfectly acceptable. We are not updating > those standards here, merely profiling them. The fact that its use happens to correlate with DMARC use is a distraction. For example, there are plenty of operators who use apply this check but do not use DMARC. If the test is documented in a specification, it should be in /one/ specification. Putting it into the DMARC spec means it has to be documented somewhere else, for the folk who don't use DMARC. Broadly, there are all sorts of things that DMARC operators commonly do, but that are not appropriate to document in the DMARC specification. DMARC concerns the domain name in the From: field and finding that it has a DMARC record associated with it. If there is no record associated with the domain name, then it is not participating in DMARC. There are other places to document other, common anti-abuse practices. The check for an MX is completely out of scope for the DMARC spec. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Dec 24 07:43: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 405CC1A8A86 for ; Wed, 24 Dec 2014 07:43:43 -0800 (PST) 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 K-IURcTM2gc0 for ; Wed, 24 Dec 2014 07:43:41 -0800 (PST) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90AE01A8A85 for ; Wed, 24 Dec 2014 07:43:41 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id y19so11498656wgg.21 for ; Wed, 24 Dec 2014 07:43:40 -0800 (PST) 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=izxEKZ+YX8ebxf3ew40wEhjN5SELsZIEjxe+kO10UeI=; b=WLti+kVHJDVbtIDW/Sz9Q6I1L99dvf4/qF6OPCqpVcWEzYNKOuzjwBhOF8BkW/wiJg L5j4WO9DWguHtPDS/C/LKEf7VRgEUiY1E7/XZB1F4XLoQhnKwFNt0z8tMWnVkv6NghG1 91R9NLTiQHgYSDDGKqL4VI3MclRakLVp/82hQNrWtg7kG45JJVysTp2TfppdESvcPKci LBAfOcEfjZC8woWGS93H7u6kMCv90WvTHa8mK9rDPkCVWzp6IgEXxpcVuvQOiCIgu/1u Y8ceYz719X4B+9EhiDoFNXp8q663NY3dehZACpBNYZ11ODBF86LL02/omTzemfgQ7Raw Q5EA== MIME-Version: 1.0 X-Received: by 10.194.86.135 with SMTP id p7mr64369059wjz.89.1419435820245; Wed, 24 Dec 2014 07:43:40 -0800 (PST) Received: by 10.27.204.198 with HTTP; Wed, 24 Dec 2014 07:43:40 -0800 (PST) In-Reply-To: <62849448-BFA5-49C0-A2B6-7A4B5CC34F2C@kitterman.com> References: <6858606.AfKicQ9CJZ@kitterman-optiplex-9020m> <1712480034.45611.1419405204864.JavaMail.zimbra@peachymango.org> <62849448-BFA5-49C0-A2B6-7A4B5CC34F2C@kitterman.com> Date: Wed, 24 Dec 2014 10:43:40 -0500 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=089e0102e498d8e800050af827fe Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Zp5g7kGGVu5qpR3VcPlGbz1exZU Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 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, 24 Dec 2014 15:43:43 -0000 --089e0102e498d8e800050af827fe Content-Type: text/plain; charset=UTF-8 On Wed, Dec 24, 2014 at 4:09 AM, Scott Kitterman wrote: > 5.6.2 promises 5.6.3 addresses the question and it doesn't. At the very > least, 5.6.2 should be fixed not to over promise what 5.6.3 will provide. > I'm not clear why you say "it doesn't". 5.6.3 describes two options for handling a message when the query for the DMARC policy fails due to transient DNS errors. Is your issue that it doesn't prescribe one specific action? I also don't understand why you say the reference is dangling. 5.6.2 says that transient DNS errors for SPF and DKIM can occur and says the handling for that case is left to receiver discretion, but also points out that what 5.6.3 says can also be applied when that happens. -MSK --089e0102e498d8e800050af827fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Dec 24, 2014 at 4:09 AM, Scott Kitterman <skli= st@kitterman.com> wrote:
<= div class=3D"h5">5.6.2 promises 5.6.3 addresses the question and it doesn&#= 39;t. At the very least, 5.6.2 should be fixed not to over promise what 5.6= .3 will provide.

I'm no= t clear why you say "it doesn't".=C2=A0 5.6.3 describes two o= ptions for handling a message when the query for the DMARC policy fails due= to transient DNS errors.=C2=A0 Is your issue that it doesn't prescribe= one specific action?

I also don't understand why you= say the reference is dangling.=C2=A0 5.6.2 says that transient DNS errors = for SPF and DKIM can occur and says the handling for that case is left to r= eceiver discretion, but also points out that what 5.6.3 says can also be ap= plied when that happens.

-MSK

--089e0102e498d8e800050af827fe-- From nobody Wed Dec 24 07:46: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 5072D1A8A8B for ; Wed, 24 Dec 2014 07:46:46 -0800 (PST) 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 FO-yvg6I8Iyc for ; Wed, 24 Dec 2014 07:46:44 -0800 (PST) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E6261A8A89 for ; Wed, 24 Dec 2014 07:46:44 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id h11so13843233wiw.9 for ; Wed, 24 Dec 2014 07:46:43 -0800 (PST) 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=wux9cdS80EAMoiL4on6wwh6KXdTnfta3zVqACRzuo2Q=; b=JUeifnhGuShkxhD8+JMnNQoj+OlpoatlCJ7jfMyqyPs05s5hGozWQm6FtBEsxh0tDC USyT+JvLue+ePe3UROjabY93uYfvpLn6W+zRB7gSKCtMFVxvKsUmyDf3WIlt31MNEZxW /wZg1atIIbNKPehWh9HV5yTisp/Sda9WbRKJyZ4MMxx4sXsvNUgQvFXDUUfcOvYTLlw2 rfYtk2VIIYZvJFExckoq7CretCcm/c6e7PV6L3nKCmKmu4fq7VleiaS/CURw1vzR9A+6 ukgFvPbSZRsq99n/2eU1M3+wy1qyL65MLaKgMdEgeVFzIg76rAwK6lbrbKylQuJZWDCr RxyA== MIME-Version: 1.0 X-Received: by 10.180.218.39 with SMTP id pd7mr53182851wic.21.1419436003047; Wed, 24 Dec 2014 07:46:43 -0800 (PST) Received: by 10.27.204.198 with HTTP; Wed, 24 Dec 2014 07:46:42 -0800 (PST) In-Reply-To: <43288BDA-4BDD-4A18-A6DD-232BCFFDEB43@kitterman.com> References: <6858606.AfKicQ9CJZ@kitterman-optiplex-9020m> <43288BDA-4BDD-4A18-A6DD-232BCFFDEB43@kitterman.com> Date: Wed, 24 Dec 2014 10:46:42 -0500 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=001a1134cd58be40e1050af83209 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/xxOWuBZW3GxkebtiKiM3vaJVzk4 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 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, 24 Dec 2014 15:46:46 -0000 --001a1134cd58be40e1050af83209 Content-Type: text/plain; charset=UTF-8 On Wed, Dec 24, 2014 at 4:04 AM, Scott Kitterman wrote: > The draft strongly encourages DMARC implementers to ignore SPF policy, so > I don't think assuming messages will be deferred due only due to SPF or > DKIM results indicating a temporary DNS error is appropriate. > If there's a transient DNS error getting the SPF policy, then there's no SPF policy to be ignored. That's quite a different situation. > I think that in the case of a temporary DNS error in one of the lower > level protocols, insufficient inputs are available to conclude a message > has failed DMARC tests. > I agree. > Receivers can either ignore DMARC for this message due to incomplete > evaluation or they can defer the message in the hope that the temporary > error will be resolved when the message is retried. Receivers MUST NOT > apply DMARC policy and reject or quarantine because the DMARC evaluation is > incomplete. > Can you provide specific changes, with section numbers, that you'd like to see applied to resolve this? -MSK --001a1134cd58be40e1050af83209 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Dec 24, 2014 at 4:04 AM, Scott Kitterman <skli= st@kitterman.com> wrote:
The draft strongly enco= urages DMARC implementers to ignore SPF policy, so I don't think assumi= ng messages will be deferred due only due to SPF or DKIM results indicating= a temporary DNS error is appropriate.

= If there's a transient DNS error getting the SPF policy, then there'= ;s no SPF policy to be ignored.=C2=A0 That's quite a different situatio= n.
=C2=A0
I think that in the case of a temporary DNS error in one of the lower level= protocols, insufficient inputs are available to conclude a message has fai= led DMARC tests.

I agree.
=C2=A0
=
Receivers can either ignore DMARC for this message due to incomplete evalua= tion or they can defer the message in the hope that the temporary error wil= l be resolved when the message is retried.=C2=A0 Receivers MUST NOT apply D= MARC policy and reject or quarantine because the DMARC evaluation is incomp= lete.

Can you provide specific changes,= with section numbers, that you'd like to see applied to resolve this?<= br>
-MSK
--001a1134cd58be40e1050af83209-- From nobody Wed Dec 24 07:50:24 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 347881A8A82 for ; Wed, 24 Dec 2014 07:50:22 -0800 (PST) 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 vXXJdqELdHCg for ; Wed, 24 Dec 2014 07:50:18 -0800 (PST) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0939A1A8A83 for ; Wed, 24 Dec 2014 07:50:18 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id h11so13799336wiw.7 for ; Wed, 24 Dec 2014 07:50:16 -0800 (PST) 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=MQGO9jNY60A4NlTXia0p40OeHK6uS31OSH0d7T7AGvg=; b=FK0cqxlz0xujyMtvqDCLEPGD7oOcaL/cGeAEBcCmuON3AQ8cX+3N8+ga9tPOpdVh6s lnqq276QsMT9ZK+ufehjw1jWygumE9cvmhWGkAmcSOUvO7O6IULzcjguc08mu5AEpo6Q Xlx0OicICJlKmdW43WLB2Beund1FnRAmX8S+jensEXYKhu0hDO5gb4IURMnxp+KkF8Qd MCmzKCHVpCHwYc0Lcwi9pDb2UwFsluXKNpeSMvwiVZQLyxlZp3g0i4yhkVNow3z6Npfn rqOfYX+lIxMwWdDnjL3S6llMYhwhoDWvudBhSmMeQjuueDWVjcjvRDZISAXu6didESrJ 2XCA== MIME-Version: 1.0 X-Received: by 10.194.86.135 with SMTP id p7mr64419392wjz.89.1419436216862; Wed, 24 Dec 2014 07:50:16 -0800 (PST) Received: by 10.27.204.198 with HTTP; Wed, 24 Dec 2014 07:50:16 -0800 (PST) In-Reply-To: <549ADA41.40005@dcrocker.net> References: <5494A6F5.5020906@dcrocker.net> <549ADA41.40005@dcrocker.net> Date: Wed, 24 Dec 2014 10:50:16 -0500 Message-ID: From: "Murray S. Kucherawy" To: Dave Crocker Content-Type: multipart/alternative; boundary=089e0102e4987ccdd6050af83f0e Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Tqc088YS430ixgscChrG8f3WaVs Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 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, 24 Dec 2014 15:50:22 -0000 --089e0102e4987ccdd6050af83f0e Content-Type: text/plain; charset=UTF-8 On Wed, Dec 24, 2014 at 10:22 AM, Dave Crocker wrote: > > I disagree. DMARC operators all seem to apply this practice, so it's > > correct to say that if you play this game, you reject mail from > > non-existent domains. Essentially in this way DMARC is a profile of > > RFC5321/RFC5322, which is perfectly acceptable. We are not updating > > those standards here, merely profiling them. > > The fact that its use happens to correlate with DMARC use is a > distraction. For example, there are plenty of operators who use apply > this check but do not use DMARC. If the test is documented in a > specification, it should be in /one/ specification. Putting it into the > DMARC spec means it has to be documented somewhere else, for the folk > who don't use DMARC. > This paragraph appears in the DMARC spec because the operators participating all agreed that it should be part-and-parcel of this operating profile of email. It's not as happenstance as this sounds so far; the very thrust of DMARC is to make the From: content believable, and permitting a nonexistent domain name to make it to the inbox contradicts that goal. -MSK --089e0102e4987ccdd6050af83f0e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Dec 24, 2014 at 10:22 AM, Dave Crocker <dhc@dcro= cker.net> wrote:
> I disagre= e.=C2=A0 DMARC operators all seem to apply this practice, so it's
> correct to say that if you play this game, you reject mail from
> non-existent domains.=C2=A0 Essentially in this way DMARC is a profile= of
> RFC5321/RFC5322, which is perfectly acceptable.=C2=A0 We are not updat= ing
> those standards here, merely profiling them.

The fact that its use happens to correlate with DMARC use is a
distraction.=C2=A0 For example, there are plenty of operators who use apply=
this check but do not use DMARC.=C2=A0 If the test is documented in a
specification, it should be in /one/ specification.=C2=A0 Putting it into t= he
DMARC spec means it has to be documented somewhere else, for the folk
who don't use DMARC.

This paragraph= appears in the DMARC spec because the operators participating all agreed t= hat it should be part-and-parcel of this operating profile of email.=C2=A0 = It's not as happenstance as this sounds so far; the very thrust of DMAR= C is to make the From: content believable, and permitting a nonexistent dom= ain name to make it to the inbox contradicts that goal.

-= MSK

--089e0102e4987ccdd6050af83f0e-- From nobody Wed Dec 24 08:17: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 23E0F1A8A89 for ; Wed, 24 Dec 2014 08:17:20 -0800 (PST) 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, 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 Vr__vzWQDPlF for ; Wed, 24 Dec 2014 08:17:18 -0800 (PST) Received: from mx-out-1.zmailcloud.com (01.zmailcloud.com [192.198.85.104]) by ietfa.amsl.com (Postfix) with ESMTP id 64C441A8A8B for ; Wed, 24 Dec 2014 08:17:18 -0800 (PST) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id ED4235647DD; Wed, 24 Dec 2014 10:17:17 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id B0694A033B; Wed, 24 Dec 2014 10:17:17 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JGJxgLXxBP-D; Wed, 24 Dec 2014 10:17:17 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id D3A80A0372; Wed, 24 Dec 2014 10:17:14 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com D3A80A0372 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1419437835; bh=7nFFd0/LRlh53nSdXIBu1FptjrT329e9Px2cUKMiWFA=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; b=Hk3qsqTgx6sQ2P96LIfgXazIMNKRoJwyo70C5n5QC8AOkByVym7ZQmvC6wYveLLP9 JaJ8amVW0U0hBF+21nVe2YTtucrruVtR4idG+SCDyq68NBiLMqY1ZiSCdz7Ml2YxYy CIF7k4Y0mPiqpdp/TzyIgxUK/344kabsBoaTGdks= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id BAE21A0357; Wed, 24 Dec 2014 10:17:14 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id tnDiYPkZvuTL; Wed, 24 Dec 2014 10:17:14 -0600 (CST) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id 7A420A033B; Wed, 24 Dec 2014 10:17:14 -0600 (CST) Date: Wed, 24 Dec 2014 10:17:14 -0600 (CST) From: Franck Martin To: "Murray S. Kucherawy" Message-ID: <1994741083.49384.1419437834266.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <5494A6F5.5020906@dcrocker.net> <549ADA41.40005@dcrocker.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_49383_1687107832.1419437834265" X-Originating-IP: [10.1.101.178] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF34 (Mac)/8.0.5_GA_5839) Thread-Topic: Jim Fenton's review of -04 Thread-Index: 7tYurEOlobJp0aNi5n7mbJ8euGn2yA== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/holHbWWDaStOXgcn3jEqKE96l9M Cc: dmarc@ietf.org, Dave Crocker Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 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, 24 Dec 2014 16:17:20 -0000 ------=_Part_49383_1687107832.1419437834265 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit ----- Original Message ----- > From: "Murray S. Kucherawy" > To: "Dave Crocker" > Cc: dmarc@ietf.org > Sent: Wednesday, December 24, 2014 7:50:16 AM > Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 > On Wed, Dec 24, 2014 at 10:22 AM, Dave Crocker < dhc@dcrocker.net > wrote: > > > I disagree. DMARC operators all seem to apply this practice, so it's > > > > correct to say that if you play this game, you reject mail from > > > > non-existent domains. Essentially in this way DMARC is a profile of > > > > RFC5321/RFC5322, which is perfectly acceptable. We are not updating > > > > those standards here, merely profiling them. > > > The fact that its use happens to correlate with DMARC use is a > > > distraction. For example, there are plenty of operators who use apply > > > this check but do not use DMARC. If the test is documented in a > > > specification, it should be in /one/ specification. Putting it into the > > > DMARC spec means it has to be documented somewhere else, for the folk > > > who don't use DMARC. > > This paragraph appears in the DMARC spec because the operators participating > all agreed that it should be part-and-parcel of this operating profile of > email. It's not as happenstance as this sounds so far; the very thrust of > DMARC is to make the From: content believable, and permitting a nonexistent > domain name to make it to the inbox contradicts that goal. All of this I feel strongly is part of "security considerations", even if they may be not in that chapter. What is the use of doing DMARC, if you allow weak input and vulnerabilities? ------=_Part_49383_1687107832.1419437834265 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
From: "Murray S. Kucherawy" <superuser@= gmail.com>
To: "Dave Crocker" <dcrocker@bbiw.net>
= Cc: dmarc@ietf.org
Sent: Wednesday, December 24, 2014 7:50:16= AM
Subject: Re: [dmarc-ietf] Jim Fenton's review of -04
=
On Wed, Dec 24, 2014 at 10:22 AM, Dave Crocker <= span dir=3D"ltr"><= dhc@dcrocker.net> wrote:
> I= disagree. DMARC operators all seem to apply this practice, so it's > correct to say that if you play this game, you reject mail from
> non-existent domains. Essentially in this way DMARC is a profile= of
> RFC5321/RFC5322, which is perfectly acceptable. We are not updat= ing
> those standards here, merely profiling them.

The fact that its use happens to correlate with DMARC use is a
distraction. For example, there are plenty of operators who use apply=
this check but do not use DMARC. If the test is documented in a
specification, it should be in /one/ specification. Putting it into t= he
DMARC spec means it has to be documented somewhere else, for the folk
who don't use DMARC.

This paragraph app= ears in the DMARC spec because the operators participating all agreed that = it should be part-and-parcel of this operating profile of email. It's= not as happenstance as this sounds so far; the very thrust of DMARC is to = make the From: content believable, and permitting a nonexistent domain name= to make it to the inbox contradicts that goal.

All of this I feel strongly is part of "se= curity considerations", even if they may be not in that chapter. What is th= e use of doing DMARC, if you allow weak input and vulnerabilities?
------=_Part_49383_1687107832.1419437834265-- From nobody Wed Dec 24 08:21: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 D6B971A8A89 for ; Wed, 24 Dec 2014 08:21:45 -0800 (PST) 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, 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 s5N61m84oWkm for ; Wed, 24 Dec 2014 08:21:44 -0800 (PST) Received: from mx-out-1.zmailcloud.com (01.zmailcloud.com [192.198.85.104]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB401A8A80 for ; Wed, 24 Dec 2014 08:21:44 -0800 (PST) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 036D156492B; Wed, 24 Dec 2014 10:21:44 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id E7538A033B; Wed, 24 Dec 2014 10:21:43 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D_TBEVDgXb15; Wed, 24 Dec 2014 10:21:43 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id BACB3A0377; Wed, 24 Dec 2014 10:21:43 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com BACB3A0377 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1419438103; bh=f9OKMTBd+7OFC7mPis4GRn8FlVXaIn8FLMEkynvVtsU=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; b=iA+7BtjDzLtTB0weDFUGN1pPyCVy59ZIH/1h5wsOdNDuINyNmK2nDQi127D6A0tj2 WuZi4lSeV+R3MfXEs6EWOzsEfTyRGGfemQmO8NHsIuWxhXV+AzZUbf8OUva9qWSgTi D8LfbqA1vdV3pxJ9ZjemA1l7WdQsBHudC2EroTmY= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id A66CEA0357; Wed, 24 Dec 2014 10:21:43 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id SBXk7jGtCS1v; Wed, 24 Dec 2014 10:21:43 -0600 (CST) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id 8BC59A033B; Wed, 24 Dec 2014 10:21:43 -0600 (CST) Date: Wed, 24 Dec 2014 10:21:43 -0600 (CST) From: Franck Martin To: "Murray S. Kucherawy" Message-ID: <222921455.49494.1419438103510.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <6858606.AfKicQ9CJZ@kitterman-optiplex-9020m> <43288BDA-4BDD-4A18-A6DD-232BCFFDEB43@kitterman.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_49493_609874598.1419438103510" X-Originating-IP: [10.1.101.178] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF34 (Mac)/8.0.5_GA_5839) Thread-Topic: Jim Fenton's review of -04 Thread-Index: ZzR+7p977dZWIE2axivaCBriBLN84w== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/UGzrr8qlxiZ5OG59IDIjcdAUdZ4 Cc: dmarc@ietf.org, Scott Kitterman Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 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, 24 Dec 2014 16:21:46 -0000 ------=_Part_49493_609874598.1419438103510 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit ----- Original Message ----- > From: "Murray S. Kucherawy" > To: "Scott Kitterman" > Cc: dmarc@ietf.org > Sent: Wednesday, December 24, 2014 7:46:42 AM > Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 > On Wed, Dec 24, 2014 at 4:04 AM, Scott Kitterman < sklist@kitterman.com > > wrote: > > The draft strongly encourages DMARC implementers to ignore SPF policy, so I > > don't think assuming messages will be deferred due only due to SPF or DKIM > > results indicating a temporary DNS error is appropriate. > > If there's a transient DNS error getting the SPF policy, then there's no SPF > policy to be ignored. That's quite a different situation. > > I think that in the case of a temporary DNS error in one of the lower level > > protocols, insufficient inputs are available to conclude a message has > > failed DMARC tests. > > I agree. > > Receivers can either ignore DMARC for this message due to incomplete > > evaluation or they can defer the message in the hope that the temporary > > error will be resolved when the message is retried. Receivers MUST NOT > > apply > > DMARC policy and reject or quarantine because the DMARC evaluation is > > incomplete. > I would prefer this phrasing Receivers can either ignore DMARC for this message due to incomplete evaluation or they can defer the message in the hope that the temporary error will be resolved when the message is retried. Defer seems preferable for security reasons. Receivers MUST NOT apply DMARC policy and reject or quarantine because the DMARC evaluation is incomplete. ------=_Part_49493_609874598.1419438103510 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

From: "Murray S. Kucherawy= " <superuser@gmail.com>
To: "Scott Kitterman" <sklist@ki= tterman.com>
Cc: dmarc@ietf.org
Sent: Wednesday, Dec= ember 24, 2014 7:46:42 AM
Subject: Re: [dmarc-ietf] Jim Fenton's = review of -04

On Wed, Dec 24, 2014 at 4:= 04 AM, Scott Kitterman <sklist@kitterman.com> wrote:
<= div class=3D"gmail_extra">
The draft strongly encourages DMARC implementers to ignore SPF pol= icy, so I don't think assuming messages will be deferred due only due to SP= F or DKIM results indicating a temporary DNS error is appropriate.

If there's a transient DNS error getting the SP= F policy, then there's no SPF policy to be ignored. That's quite a di= fferent situation.

I think that in the case of a temporary DNS error in one of the lower level= protocols, insufficient inputs are available to conclude a message has fai= led DMARC tests.

I agree.

=
Receivers can either ignore DMARC for this message due to incomplete evalua= tion or they can defer the message in the hope that the temporary error wil= l be resolved when the message is retried. Receivers MUST NOT apply D= MARC policy and reject or quarantine because the DMARC evaluation is incomp= lete.

I woul= d prefer this phrasing

Receivers can either ig= nore DMARC for this message due to incomplete evaluation or they can defer = the message in the hope that the temporary error will be resolved when the = message is retried. Defer seems preferable for security reasons. Rece= ivers MUST NOT apply DMARC policy and reject or quarantine because the DMAR= C evaluation is incomplete.

------=_Part_49493_609874598.1419438103510-- From nobody Wed Dec 24 08:24: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 68C901A8A80 for ; Wed, 24 Dec 2014 08:24:14 -0800 (PST) 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 rZnKjcYjYDW5 for ; Wed, 24 Dec 2014 08:24:13 -0800 (PST) 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 42CF11A8A8F for ; Wed, 24 Dec 2014 08:24:13 -0800 (PST) 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 sBOGO7sP010578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 24 Dec 2014 08:24:11 -0800 Message-ID: <549AE89A.9070203@dcrocker.net> Date: Wed, 24 Dec 2014 08:23:54 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <5494A6F5.5020906@dcrocker.net> <549ADA41.40005@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 24 Dec 2014 08:24:11 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/_xDfm7DWQQP57rkqdDWKVBnZm8U Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 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, 24 Dec 2014 16:24:14 -0000 On 12/24/2014 7:50 AM, Murray S. Kucherawy wrote: > This paragraph appears in the DMARC spec because the operators > participating all agreed that it should be part-and-parcel of this > operating profile of email. It's not as happenstance as this sounds so > far; the very thrust of DMARC is to make the From: content believable, > and permitting a nonexistent domain name to make it to the inbox > contradicts that goal. The goal, as you state it, is at the level of seeking world peace. It is very laudable and and very, very broad. It covers vastly more than the scope of DMARC. DMARC is a specific bit of technology working towards that broader goal. That something happens to fall within this very broad scope does not automatically justify documenting it within the much narrower scope of a detailed specification, unless it is part of that specification's technology. The MX record check has no /technical/ relationship to the /technical/ details of DMARC. Please note that I'm not commenting on the efficacy of the record check, but on the need to document it in a place that makes sense for the full range of its implementers. There are, and will continue to be, plenty of operators using that check but not DMARC. That simple fact provides a very pragmatic reason for moving its specification into some document outside of DMARC. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Dec 24 08:43: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 E82641A8A8F for ; Wed, 24 Dec 2014 08:43:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.978 X-Spam-Level: X-Spam-Status: No, score=-3.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, 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 fbKdEjHE7FQT for ; Wed, 24 Dec 2014 08:43:49 -0800 (PST) Received: from esv4-mav04.corp.linkedin.com (esv4-mav04.corp.linkedin.com [69.28.149.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDF771A1A15 for ; Wed, 24 Dec 2014 08:43:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1419439429; x=1450975429; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=JBtVGvVce7+Rbj46qnj/rBAf4ue8ZbsrkM+jVoYhrOI=; b=YmjdF7qxyuDh/ksMhuGlmerjhR8dm1IaWgbixnc+EpoGDUtC377T5k+Y 7xKcrhw1dvxB6Hf28etbuKJsAQqkwwKduTm0oQ8HxyHD5hMadDk5BS1kw gEh9y4WCWz02SVYGQWPBzRcNG/Wk0/EP0GPVBRz1Q4rmUSTCBwq4bWHzU s=; X-IronPort-AV: E=Sophos;i="5.07,638,1413270000"; d="scan'208";a="166732136" Received: from esv4-exctest.linkedin.biz (172.18.46.60) by ESV4-HT01.linkedin.biz (172.18.46.235) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 24 Dec 2014 08:43:49 -0800 Received: from ESV4-MB03.linkedin.biz ([fe80::1caa:1422:7ef8:5ceb]) by esv4-exctest.linkedin.biz ([::1]) with mapi id 14.03.0195.001; Wed, 24 Dec 2014 08:43:48 -0800 From: Kurt Andersen To: Franck Martin , "Murray S. Kucherawy" Thread-Topic: [dmarc-ietf] Jim Fenton's review of -04 Thread-Index: AQHQH5jKs8GbclOMlEWOwe0m4egu/A== Date: Wed, 24 Dec 2014 16:43:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.253] Content-Type: text/plain; charset="us-ascii" Content-ID: <6C3BBF488B3CC44DB4A6F31C6A4EA087@linkedin.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/pkW56mia28AIXBRYGLsZ95Ibw98 Cc: "dmarc@ietf.org" , Scott Kitterman Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 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, 24 Dec 2014 16:43:52 -0000 On 2014-12-24, 08:21 , "Franck Martin" wrote: > > From: "Murray S. Kucherawy" > To: "Scott Kitterman" > Cc: dmarc@ietf.org > Sent: Wednesday, December 24, 2014 7:46:42 AM > Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 > > > On Wed, Dec 24, 2014 at 4:04 AM, Scott Kitterman > wrote: > > > > > The draft strongly encourages DMARC implementers to ignore SPF >policy,=20 > > > so I don't think assuming messages will be deferred due only due to >SPF=20 > > > or DKIM results indicating a temporary DNS error is appropriate. > > > > > > If there's a transient DNS error getting the SPF policy, then there's >no=20 > > SPF policy to be ignored. That's quite a different situation. > > > > > > > I think that in the case of a temporary DNS error in one of the >lower=20 > > > level protocols, insufficient inputs are available to conclude a >message=20 > > > has failed DMARC tests. > > > > > > I agree. > > > > > > Receivers can either ignore DMARC for this message due to incomplete >evaluation=20 > > or they can defer the message in the hope that the temporary error >will be=20 > > resolved when the message is retried. Receivers MUST NOT apply DMARC >policy=20 > > and reject or quarantine because the DMARC evaluation is incomplete. > > I would prefer this phrasing > > Receivers can either ignore DMARC for this message due to incomplete >evaluation=20 > or they can defer the message in the hope that the temporary error will >be=20 > resolved when the message is retried. Defer seems preferable for >security reasons.=20 > Receivers MUST NOT apply DMARC policy and reject or quarantine because >the DMARC=20 > evaluation is incomplete. I think that it might be worth suggesting that such transient errors could be=20 reasonably reported since this does constitute an avenue for some sort of flooding=20 attack or flaw in their DNS infrastructure (consider, for example a partially broken DNSSEC implementation). By reporting incidents, it can alert the operators to the problem. --Kurt Andersen From nobody Wed Dec 24 08:50: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 C3CB11A19E3 for ; Wed, 24 Dec 2014 08:50:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.378 X-Spam-Level: X-Spam-Status: No, score=-3.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_14=0.6, 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 MQua0uSk8c5W for ; Wed, 24 Dec 2014 08:50:33 -0800 (PST) Received: from esv4-mav04.corp.linkedin.com (esv4-mav04.corp.linkedin.com [69.28.149.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B8F21A066C for ; Wed, 24 Dec 2014 08:50:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1419439833; x=1450975833; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=CKX9Ww1bckN+TVszeuvOZli3WGY+RIukxREFwixzFqM=; b=N2klMBRKC1GJG5eakJYTxBRpYXhgW59VjMxeledZPolwodW//TeYzLfe KlqwvqWsVKRRmrKF549YrMTfwdaBvfeeTVk00TeigxCm9kpEuMtUU1N8T nXN8nuOyTkRnZSDT19SHm4Cb97s+Tn3iiupwNobMkZMsfx0roNEMVIs6m I=; X-IronPort-AV: E=Sophos;i="5.07,638,1413270000"; d="scan'208";a="166732953" Received: from esv4-exctest.linkedin.biz (172.18.46.60) by esv4-cas01.linkedin.biz (172.18.46.140) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 24 Dec 2014 08:50:32 -0800 Received: from ESV4-MB03.linkedin.biz ([fe80::1caa:1422:7ef8:5ceb]) by esv4-exctest.linkedin.biz ([::1]) with mapi id 14.03.0195.001; Wed, 24 Dec 2014 08:50:32 -0800 From: Kurt Andersen To: "dcrocker@bbiw.net" , "Murray S. Kucherawy" Thread-Topic: [dmarc-ietf] Jim Fenton's review of -04 Thread-Index: AQHQG9MAs8GbclOMlEWOwe0m4egu/JyYBSyAgAbKUoCAAJnigP//kmyA Date: Wed, 24 Dec 2014 16:50:32 +0000 Message-ID: References: <5494A6F5.5020906@dcrocker.net> <549ADA41.40005@dcrocker.net> In-Reply-To: <549ADA41.40005@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.253] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/2hWrZEtJem6JqNFGS_l1jsjxH_s Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 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, 24 Dec 2014 16:50:35 -0000 On 2014-12-24, 07:22 , "Dave Crocker" wrote: >DMARC concerns the domain name in the From: field and finding that it >has a DMARC record associated with it. If there is no record associated >with the domain name, then it is not participating in DMARC. > >There are other places to document other, common anti-abuse practices. I agree with this position. M3AAWG is actually about to publish a recommendation to deal with protecting parked domains which includes something like this, although it is separate from DMARC itself and can't address the issue of a truly NXDOMAIN condition. =20 I think that we have to leave NXDOMAIN handling to the discretion of receivers. --Kurt From nobody Wed Dec 24 09:14: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 4B8B01A07BD for ; Wed, 24 Dec 2014 09:14:31 -0800 (PST) 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 gsExRnTelxSO for ; Wed, 24 Dec 2014 09:14:29 -0800 (PST) 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 918E91A0095 for ; Wed, 24 Dec 2014 09:14:29 -0800 (PST) Received: from scott-latitude-e6320.localnet (unknown [76.92.231.124]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 9BD62C400D1; Wed, 24 Dec 2014 11:14:28 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1419441268; bh=7cAVURzthPyBvFGqsvLw3Df224Ma9yE8NbigU8AkfEI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=px623N8gIr4e0naBTQDtWGLdPyNqTR7J+Ut2/t/n0qoUPqAjrxE8/h4SN39rR1/Tm BlOZOB68JS84owrwQZ5PM76vHVu3u89Vq+zudiY9LQvLnMvqS253K+FXHCxzepBPD3 5KKQ+LYwo93pT9EhmUD32UObaufyTFW9OPDKxDHI= From: Scott Kitterman To: dmarc@ietf.org Date: Wed, 24 Dec 2014 12:14:27 -0500 Message-ID: <4165890.y5RTokQk0d@scott-latitude-e6320> User-Agent: KMail/4.13.3 (Linux/3.13.0-43-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <43288BDA-4BDD-4A18-A6DD-232BCFFDEB43@kitterman.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/YHJTsohVVj-Sfb7TE__4MV0cuEY Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 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, 24 Dec 2014 17:14:31 -0000 On Wednesday, December 24, 2014 10:46:42 Murray S. Kucherawy wrote: > On Wed, Dec 24, 2014 at 4:04 AM, Scott Kitterman > > wrote: > > The draft strongly encourages DMARC implementers to ignore SPF policy, so > > I don't think assuming messages will be deferred due only due to SPF or > > DKIM results indicating a temporary DNS error is appropriate. > > If there's a transient DNS error getting the SPF policy, then there's no > SPF policy to be ignored. That's quite a different situation. > > > I think that in the case of a temporary DNS error in one of the lower > > level protocols, insufficient inputs are available to conclude a message > > has failed DMARC tests. > > I agree. > > > Receivers can either ignore DMARC for this message due to incomplete > > evaluation or they can defer the message in the hope that the temporary > > error will be resolved when the message is retried. Receivers MUST NOT > > apply DMARC policy and reject or quarantine because the DMARC evaluation > > is > > incomplete. > > Can you provide specific changes, with section numbers, that you'd like to > see applied to resolve this? Yes, but I just finished a 20 hour drive, so I'll probably sleep first. Scott K From nobody Wed Dec 24 09: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 BCC741A07BD for ; Wed, 24 Dec 2014 09:15:15 -0800 (PST) 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 fcocnq_42Q10 for ; Wed, 24 Dec 2014 09:15:14 -0800 (PST) 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 794BF1A0095 for ; Wed, 24 Dec 2014 09:15:14 -0800 (PST) Received: from [10.182.208.29] (138.sub-70-195-71.myvzw.com [70.195.71.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id ADF7BC400D1; Wed, 24 Dec 2014 11:15:12 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1419441313; bh=tyxUClNH5JC1dtb9voCb4Ypmd3dDI+wgbpMh5/Mmsek=; h=In-Reply-To:References:Subject:From:Date:To:From; b=IGkX8k7dtOAuhq8Bk5h6uaTYQ+a3m4Pf1h6QnGVIE+sMquSXAJM1msso2BiAIsLK+ m0VvuoKT8s6emjnJzohTWpqmnj1teKYn3/2U9V0hvEPgiT6JJD8laJWr0Ev7G6OBJF JW2WSZIVoW/oYEFtxjuCMOrvYAd0nFCBKFpcxz+g= User-Agent: K-9 Mail for Android In-Reply-To: References: <6858606.AfKicQ9CJZ@kitterman-optiplex-9020m> <1712480034.45611.1419405204864.JavaMail.zimbra@peachymango.org> <62849448-BFA5-49C0-A2B6-7A4B5CC34F2C@kitterman.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Wed, 24 Dec 2014 11:05:21 -0600 To: "dmarc@ietf.org" Message-ID: <0A7FFDC3-CF31-45B8-9990-16F43410022A@kitterman.com> Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/WZFlmoN-oJIHdZefKxS7BUHeOlM Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 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, 24 Dec 2014 17:15:15 -0000 On December 24, 2014 9:43:40 AM CST, "Murray S. Kucherawy" wrote: >On Wed, Dec 24, 2014 at 4:09 AM, Scott Kitterman >wrote: > >> 5.6.2 promises 5.6.3 addresses the question and it doesn't. At the >very >> least, 5.6.2 should be fixed not to over promise what 5.6.3 will >provide. >> > >I'm not clear why you say "it doesn't". 5.6.3 describes two options >for >handling a message when the query for the DMARC policy fails due to >transient DNS errors. Is your issue that it doesn't prescribe one >specific >action? > >I also don't understand why you say the reference is dangling. 5.6.2 >says >that transient DNS errors for SPF and DKIM can occur and says the >handling >for that case is left to receiver discretion, but also points out that >what >5.6.3 says can also be applied when that happens. And 5.6.3 is completely silent on what to do with SPF or DKIM results indicating a temporary DNS error. The only references to transient DNS errors in 5.6.3 are specific to errors retrieving DMARC records. Scott K Scott K From nobody Wed Dec 24 14:48: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 2820D1A1BE9 for ; Wed, 24 Dec 2014 14:48:48 -0800 (PST) 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 AHjdSYPmtUuI for ; Wed, 24 Dec 2014 14:48:46 -0800 (PST) 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 071191A1BEC for ; Wed, 24 Dec 2014 14:48:20 -0800 (PST) Received: from scott-latitude-e6320.localnet (unknown [76.92.231.124]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 0472CC400D1; Wed, 24 Dec 2014 16:48:20 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1419461300; bh=QTITOY5NzDPgJsJeqLYY/Y4QsDie7UtvEcAIai+e+1I=; h=From:To:Subject:Date:In-Reply-To:References:From; b=vgmNVCMEj8VjnSx8BitluXhEvWcT20usWqD77MoucmdnIARmKryQnLf/lNS3zUCY0 Y1J72qrSrzJc5+YQ1+vHpACDxQPw5Q2aLsiAu/Fuy/lv4NUIwHYTlmvgXU5C57sbIl 3NUmy6b8qsRelVY5EAHtH0p1qE9y1aInwF4kMsEg= From: Scott Kitterman To: dmarc@ietf.org Date: Wed, 24 Dec 2014 17:48:17 -0500 Message-ID: <2397001.Fx3SqMl5ZI@scott-latitude-e6320> User-Agent: KMail/4.13.3 (Linux/3.13.0-43-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <43288BDA-4BDD-4A18-A6DD-232BCFFDEB43@kitterman.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Q3v7BeYWhMh03I3whCiShwULS88 Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 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, 24 Dec 2014 22:48:48 -0000 On Wednesday, December 24, 2014 10:46:42 Murray S. Kucherawy wrote: > On Wed, Dec 24, 2014 at 4:04 AM, Scott Kitterman > > wrote: > > The draft strongly encourages DMARC implementers to ignore SPF policy, so > > I don't think assuming messages will be deferred due only due to SPF or > > DKIM results indicating a temporary DNS error is appropriate. > > If there's a transient DNS error getting the SPF policy, then there's no > SPF policy to be ignored. That's quite a different situation. > > > I think that in the case of a temporary DNS error in one of the lower > > level protocols, insufficient inputs are available to conclude a message > > has failed DMARC tests. > > I agree. > > > Receivers can either ignore DMARC for this message due to incomplete > > evaluation or they can defer the message in the hope that the temporary > > error will be resolved when the message is retried. Receivers MUST NOT > > apply DMARC policy and reject or quarantine because the DMARC evaluation > > is > > incomplete. > > Can you provide specific changes, with section numbers, that you'd like to > see applied to resolve this? Here's my suggestion. Replace this text at the end of section 5.6.2: Handling of messages for which SPF and/or DKIM evaluation encounters a DNS error is left to the discretion of the Mail Receiver. Further discussion is available in Section 5.6.3. with: Messages for which SPF and/or DKIM evaluation encounters a temporary DNS error have not received a definitive result for steps 3 and/or 4 above. If the message has not passed the the DMARC mechanism check due to an SPF or DKIM check that did not have a DNS error, receivers can either ignore DMARC for this message due to incomplete evaluation or they can defer the message in the hope that the temporary error will be resolved when the message is retried. Receivers MUST NOT apply DMARC policy and reject or quarantine the message because the DMARC evaluation is incomplete. When otherwise appropriate due to DMARC policy, receivers MAY send feedback reports regarding temporary errors. Handling of messages for which SPF and/or DKIM evaluation encounters a permanent DNS error is left to the discretion of the Mail Receiver. How's that? Scott K From nobody Wed Dec 24 17:22: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 74C771A6F63 for ; Wed, 24 Dec 2014 17:22:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 P11VwPegpJbX for ; Wed, 24 Dec 2014 17:22:23 -0800 (PST) Received: from mx-out-1.zmailcloud.com (01.zmailcloud.com [192.198.85.104]) by ietfa.amsl.com (Postfix) with ESMTP id 3C34A1A6F61 for ; Wed, 24 Dec 2014 17:22:23 -0800 (PST) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id C09B15641A8; Wed, 24 Dec 2014 19:22:22 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id A5C29602AE; Wed, 24 Dec 2014 19:22:22 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntMzGfoSQPFW; Wed, 24 Dec 2014 19:22:22 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 4E57B602BA; Wed, 24 Dec 2014 19:22:22 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-2.01.com 4E57B602BA DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1419470542; bh=3oUyJR+MYSlmYWtRP7hu7K9m6faSHEB9tayC4XMmm8Q=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=nTd6kQAVC/jRq2YrpZdiECqh1OWxaOtcbkTbdUf+lfI0N9A9B2pIdpMlFI/eo5EtG oma5u6v+aFumP7MvEKfJKT6XpWka4DmrYTBPKJ8KhyEn/v/bSet0iUlKIb0u9QcOu9 /JWaqdn7Cuj7mqnj6gfTWXGtDrxJGPUukt06i3Yg= Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 2EE5A602B9; Wed, 24 Dec 2014 19:22:22 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id E4Mu_7YL5t-s; Wed, 24 Dec 2014 19:22:22 -0600 (CST) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-2.01.com (Postfix) with ESMTP id 150C7602AE; Wed, 24 Dec 2014 19:22:22 -0600 (CST) Date: Wed, 24 Dec 2014 19:22:21 -0600 (CST) From: Franck Martin To: Scott Kitterman Message-ID: <227572093.52751.1419470541903.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <43288BDA-4BDD-4A18-A6DD-232BCFFDEB43@kitterman.com> <2397001.Fx3SqMl5ZI@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.101.179] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF34 (Mac)/8.0.5_GA_5839) Thread-Topic: Jim Fenton's review of -04 Thread-Index: 7AvnrqDMptbFlMBgU1eK3TroyFOZGg== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/p-ibrC4qYeCeNs4ALWyAKCuKEmA Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 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, 25 Dec 2014 01:22:26 -0000 ----- Original Message ----- > From: "Scott Kitterman" > To: dmarc@ietf.org > Sent: Wednesday, December 24, 2014 2:48:17 PM > Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 > > On Wednesday, December 24, 2014 10:46:42 Murray S. Kucherawy wrote: > > On Wed, Dec 24, 2014 at 4:04 AM, Scott Kitterman > > > > wrote: > > > The draft strongly encourages DMARC implementers to ignore SPF policy, so > > > I don't think assuming messages will be deferred due only due to SPF or > > > DKIM results indicating a temporary DNS error is appropriate. > > > > If there's a transient DNS error getting the SPF policy, then there's no > > SPF policy to be ignored. That's quite a different situation. > > > > > I think that in the case of a temporary DNS error in one of the lower > > > level protocols, insufficient inputs are available to conclude a message > > > has failed DMARC tests. > > > > I agree. > > > > > Receivers can either ignore DMARC for this message due to incomplete > > > evaluation or they can defer the message in the hope that the temporary > > > error will be resolved when the message is retried. Receivers MUST NOT > > > apply DMARC policy and reject or quarantine because the DMARC evaluation > > > is > > > incomplete. > > > > Can you provide specific changes, with section numbers, that you'd like to > > see applied to resolve this? > > Here's my suggestion. Replace this text at the end of section 5.6.2: > > Handling of messages for which SPF and/or DKIM evaluation encounters > a DNS error is left to the discretion of the Mail Receiver. Further > discussion is available in Section 5.6.3. > > with: > > Messages for which SPF and/or DKIM evaluation encounters a temporary > DNS error have not received a definitive result for steps 3 and/or 4 > above. > If the message has not passed the the DMARC mechanism check due to > an SPF or DKIM check that did not have a DNS error, receivers can either > ignore DMARC for this message due to incomplete evaluation or they > can defer the message in the hope that the temporary error will be > resolved when the message is retried. Receivers MUST NOT apply DMARC > policy and reject or quarantine the message because the DMARC > evaluation is incomplete. When otherwise appropriate due to DMARC > policy, receivers MAY send feedback reports regarding temporary errors. > > Handling of messages for which SPF and/or DKIM evaluation encounters > a permanent DNS error is left to the discretion of the Mail Receiver. > > How's that? > What about pointing it may be a security issue to let these messages through? From nobody Wed Dec 24 21:02: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 83DA91A8701 for ; Wed, 24 Dec 2014 21:02:45 -0800 (PST) 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 cNyCnE9qCmLQ for ; Wed, 24 Dec 2014 21:02:43 -0800 (PST) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01CEA1A86F7 for ; Wed, 24 Dec 2014 21:02:42 -0800 (PST) Received: by mail-wg0-f51.google.com with SMTP id x12so12314808wgg.24 for ; Wed, 24 Dec 2014 21:02:41 -0800 (PST) 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=nZDWJXM9vY0cD8toTdCbA0V14W3tFP5qD+Uldi8MA+s=; b=lVtkARngrWYal9VVMMeaykdBBJ1QjKTWH6m/IvjVr4Gs+5rb2thYvj1+upUHEclYFj 0iHgcjxp4YL7mW3hrdIkF4aWTwNXjJGh9seZueqlt9HtpYZEuANNnp3/TbALRaIDtP6Y WCKRXOmWKVCNJ3VVj6LqbPMdH/NCcusnLTTXu/8UpbfhLSgCO+apWXmzqHT0uH8q5+PB Dy8IXhH/4qcFKa1WgEo2GO5NNRhcwd7wBTYXzKvQxoiupXayANIUKdlT0Q6QFlv/wMzU UN1+Owpi92mTErGEl3JX6WkLsjgVWazawq5jK/UO8ZuUxcX0jGwUN8US/i3und7XRpdC 4Y8w== MIME-Version: 1.0 X-Received: by 10.194.200.234 with SMTP id jv10mr69823572wjc.110.1419483761767; Wed, 24 Dec 2014 21:02:41 -0800 (PST) Received: by 10.27.204.198 with HTTP; Wed, 24 Dec 2014 21:02:41 -0800 (PST) In-Reply-To: <2397001.Fx3SqMl5ZI@scott-latitude-e6320> References: <43288BDA-4BDD-4A18-A6DD-232BCFFDEB43@kitterman.com> <2397001.Fx3SqMl5ZI@scott-latitude-e6320> Date: Thu, 25 Dec 2014 00:02:41 -0500 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=047d7bb70bb2627b5e050b035133 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/p4EM35XWFAT-SyMThmSP9b5s0bY Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 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, 25 Dec 2014 05:02:46 -0000 --047d7bb70bb2627b5e050b035133 Content-Type: text/plain; charset=UTF-8 On Wed, Dec 24, 2014 at 5:48 PM, Scott Kitterman wrote: > > Messages for which SPF and/or DKIM evaluation encounters a temporary > DNS error have not received a definitive result for steps 3 and/or 4 > above. > If the message has not passed the the DMARC mechanism check due to > an SPF or DKIM check that did not have a DNS error, receivers can either > ignore DMARC for this message due to incomplete evaluation or they > can defer the message in the hope that the temporary error will be > resolved when the message is retried. Receivers MUST NOT apply DMARC > policy and reject or quarantine the message because the DMARC > evaluation is incomplete. When otherwise appropriate due to DMARC > policy, receivers MAY send feedback reports regarding temporary errors. > > Handling of messages for which SPF and/or DKIM evaluation encounters > a permanent DNS error is left to the discretion of the Mail Receiver. > > How's that? > I think it pretty much says what's there, but is a lot more clear about it. I also think the second sentence is a bit convoluted, so I reworked it into this. Does it match what you're trying to say? Messages for which SPF and/or DKIM evaluation encounters a temporary DNS error have not received a definitive result for steps 3 and/or 4 above. When such an evaluation is done in conjunction with an aligned identifier, completion of the DMARC algorithm is not possible. In this case, receivers can either skip DMARC for this message due to incomplete evaluation, or they can arrange to defer handling of the message in the hope that the temporary error will be resolved when the message is retried. In any case, Receivers cannot apply DMARC policy and reject or quarantine the message because the DMARC evaluation is incomplete. When otherwise appropriate due to DMARC policy, receivers MAY send feedback reports regarding temporary errors. -MSK --047d7bb70bb2627b5e050b035133 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdiBkaXI9Imx0ciI+T24gV2VkLCBEZWMgMjQsIDIwMTQgYXQgNTo0OCBQTSwgU2NvdHQgS2l0 dGVybWFuIDxzcGFuIGRpcj0ibHRyIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOnNrbGlzdEBraXR0ZXJt YW4uY29tIiB0YXJnZXQ9Il9ibGFuayI+c2tsaXN0QGtpdHRlcm1hbi5jb208L2E+Jmd0Ozwvc3Bh bj4gd3JvdGU6PGJyPjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48ZGl2IGNsYXNzPSJnbWFpbF9x dW90ZSI+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAw cHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRp bmctbGVmdDoxZXgiPjxicj4NCsKgIMKgTWVzc2FnZXMgZm9yIHdoaWNoIFNQRiBhbmQvb3IgREtJ TSBldmFsdWF0aW9uIGVuY291bnRlcnMgYSB0ZW1wb3Jhcnk8YnI+DQrCoCDCoEROUyBlcnJvciBo YXZlIG5vdCByZWNlaXZlZCBhIGRlZmluaXRpdmUgcmVzdWx0IGZvciBzdGVwcyAzIGFuZC9vciA0 IGFib3ZlLjxicj4NCsKgIMKgSWYgdGhlIG1lc3NhZ2UgaGFzIG5vdCBwYXNzZWQgdGhlIHRoZSBE TUFSQyBtZWNoYW5pc20gY2hlY2sgZHVlIHRvPGJyPg0KwqAgwqBhbiBTUEYgb3IgREtJTSBjaGVj ayB0aGF0IGRpZCBub3QgaGF2ZSBhIEROUyBlcnJvciwgcmVjZWl2ZXJzIGNhbiBlaXRoZXI8YnI+ DQo8c3BhbiBjbGFzcz0iIj7CoCDCoGlnbm9yZSBETUFSQyBmb3IgdGhpcyBtZXNzYWdlIGR1ZSB0 byBpbmNvbXBsZXRlIGV2YWx1YXRpb24gb3IgdGhleTxicj4NCsKgIMKgY2FuIGRlZmVyIHRoZSBt ZXNzYWdlIGluIHRoZSBob3BlIHRoYXQgdGhlIHRlbXBvcmFyeSBlcnJvciB3aWxsIGJlPGJyPg0K wqAgwqByZXNvbHZlZCB3aGVuIHRoZSBtZXNzYWdlIGlzIHJldHJpZWQuwqAgUmVjZWl2ZXJzIE1V U1QgTk9UIGFwcGx5IERNQVJDPGJyPg0KPC9zcGFuPsKgIMKgcG9saWN5IGFuZCByZWplY3Qgb3Ig cXVhcmFudGluZSB0aGUgbWVzc2FnZSBiZWNhdXNlIHRoZSBETUFSQzxicj4NCsKgIMKgZXZhbHVh dGlvbiBpcyBpbmNvbXBsZXRlLiBXaGVuIG90aGVyd2lzZSBhcHByb3ByaWF0ZSBkdWUgdG8gRE1B UkM8YnI+DQrCoCDCoHBvbGljeSwgcmVjZWl2ZXJzIE1BWSBzZW5kIGZlZWRiYWNrIHJlcG9ydHMg cmVnYXJkaW5nIHRlbXBvcmFyeSBlcnJvcnMuPGJyPg0KPHNwYW4gY2xhc3M9IiI+PGJyPg0KwqAg wqBIYW5kbGluZyBvZiBtZXNzYWdlcyBmb3Igd2hpY2ggU1BGIGFuZC9vciBES0lNIGV2YWx1YXRp b24gZW5jb3VudGVyczxicj4NCjwvc3Bhbj7CoCDCoGEgcGVybWFuZW50IEROUyBlcnJvciBpcyBs ZWZ0IHRvIHRoZSBkaXNjcmV0aW9uIG9mIHRoZSBNYWlsIFJlY2VpdmVyLjxicj4NCjxicj4NCkhv dyYjMzk7cyB0aGF0Pzxicj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+PGRpdj5JIHRoaW5r IGl0IHByZXR0eSBtdWNoIHNheXMgd2hhdCYjMzk7cyB0aGVyZSwgYnV0IGlzIGEgbG90IG1vcmUg Y2xlYXIgYWJvdXQgaXQuwqAgSSBhbHNvIHRoaW5rIHRoZSBzZWNvbmQgc2VudGVuY2UgaXMgYSBi aXQgY29udm9sdXRlZCwgc28gSSByZXdvcmtlZCBpdCBpbnRvIHRoaXMuwqAgRG9lcyBpdCBtYXRj aCB3aGF0IHlvdSYjMzk7cmUgdHJ5aW5nIHRvIHNheT88YnI+PGJyPsKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCAmbHQ7dCZndDsgTWVzc2FnZXMgZm9yIHdoaWNoIFNQRiBhbmQvb3IgREtJ TSBldmFsdWF0aW9uIGVuY291bnRlcnM8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqAgYSB0ZW1wb3JhcnkgRE5TIGVycm9yIGhhdmUgbm90IHJlY2VpdmVkIGEgZGVmaW5p dGl2ZTxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCByZXN1bHQgZm9y IHN0ZXBzIDMgYW5kL29yIDQgYWJvdmUuwqAgV2hlbiBzdWNoIGFuIGV2YWx1YXRpb248YnI+wqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgaXMgZG9uZSBpbiBjb25qdW5jdGlv biB3aXRoIGFuIGFsaWduZWQgaWRlbnRpZmllciw8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqAgY29tcGxldGlvbiBvZiB0aGUgRE1BUkMgYWxnb3JpdGhtIGlzIG5vdCBw b3NzaWJsZS48YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgSW4gdGhp cyBjYXNlLCByZWNlaXZlcnMgY2FuIGVpdGhlciBza2lwIERNQVJDIGZvciB0aGlzPGJyPsKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIG1lc3NhZ2UgZHVlIHRvIGluY29tcGxl dGUgZXZhbHVhdGlvbiwgb3IgdGhleSBjYW4gYXJyYW5nZTxicj7CoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoCB0byBkZWZlciBoYW5kbGluZyBvZiB0aGUgbWVzc2FnZSBpbiB0 aGUgaG9wZSB0aGF0IHRoZTxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oCB0ZW1wb3JhcnkgZXJyb3Igd2lsbCBiZSByZXNvbHZlZCB3aGVuIHRoZSBtZXNzYWdlIGlzPGJy PsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHJldHJpZWQuwqAgSW4gYW55 IGNhc2UsIFJlY2VpdmVycyBjYW5ub3QgYXBwbHkgRE1BUkM8YnI+wqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqAgcG9saWN5IGFuZCByZWplY3Qgb3IgcXVhcmFudGluZSB0aGUg bWVzc2FnZSBiZWNhdXNlIHRoZTxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoCBETUFSQyBldmFsdWF0aW9uIGlzIGluY29tcGxldGUuwqAgV2hlbiBvdGhlcndpc2U8YnI+ wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgYXBwcm9wcmlhdGUgZHVlIHRv IERNQVJDIHBvbGljeSwgcmVjZWl2ZXJzIE1BWSBzZW5kPGJyPsKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgIGZlZWRiYWNrIHJlcG9ydHMgcmVnYXJkaW5nIHRlbXBvcmFyeSBl cnJvcnMuICZsdDsvdCZndDs8YnI+PGJyPjwvZGl2PjxkaXY+LU1TSzxicj48L2Rpdj48L2Rpdj48 L2Rpdj48L2Rpdj4NCg== --047d7bb70bb2627b5e050b035133-- From nobody Wed Dec 24 21:06: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 C1B341A004E for ; Wed, 24 Dec 2014 21:06:31 -0800 (PST) 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 esgDQkHxrG2N for ; Wed, 24 Dec 2014 21:06:29 -0800 (PST) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDCCD1A86F7 for ; Wed, 24 Dec 2014 21:06:28 -0800 (PST) Received: by mail-wg0-f51.google.com with SMTP id x12so12480329wgg.10 for ; Wed, 24 Dec 2014 21:06:27 -0800 (PST) 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=j9ksi2wRpEoO8CJdi77/Pgl/Stk1XuWb6DhRB4dGaHs=; b=sN3JwdJEPzTdYbwgAnwqaOuTJAePbQooBSym2P+Hpszr89ShCgPIQQv4tSgLPuuwsf xqsNLeI5VoFLbSLd0VV/5OaMcqDVJd7wlsQW3X1x1sXS7PI7QxowrRlI38/Az3X0Nwzu U3KJwte2tBH1wF+5SL0JulP2cE33ntwv+JqkVwuWX84Q8YpTPvktexR5cEmtvlc7hk4a 0ImevFDZ9v93Xvmcm2NV0DLgTcROTuNjtCiesyfvb3WgVCTh9RYYAQ8GcN7R/8SkMcKt 2u6nRtq/IvlUtMZn9h4o3uojOiIppLXcxw7bmhJqZ97mmNIHO38tQ7NOCJrIoK5rO5mX ilZQ== MIME-Version: 1.0 X-Received: by 10.180.218.39 with SMTP id pd7mr57999013wic.21.1419483987705; Wed, 24 Dec 2014 21:06:27 -0800 (PST) Received: by 10.27.204.198 with HTTP; Wed, 24 Dec 2014 21:06:27 -0800 (PST) In-Reply-To: <549AE89A.9070203@dcrocker.net> References: <5494A6F5.5020906@dcrocker.net> <549ADA41.40005@dcrocker.net> <549AE89A.9070203@dcrocker.net> Date: Thu, 25 Dec 2014 00:06:27 -0500 Message-ID: From: "Murray S. Kucherawy" To: Dave Crocker Content-Type: multipart/alternative; boundary=001a1134cd58da05f6050b035e04 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/fRvsZpHpiHYZibvqEEHxsEWaM3s Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 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, 25 Dec 2014 05:06:32 -0000 --001a1134cd58da05f6050b035e04 Content-Type: text/plain; charset=UTF-8 On Wed, Dec 24, 2014 at 11:23 AM, Dave Crocker wrote: > The goal, as you state it, is at the level of seeking world peace. It > is very laudable and and very, very broad. It covers vastly more than > the scope of DMARC. > > DMARC is a specific bit of technology working towards that broader goal. > That something happens to fall within this very broad scope does not > automatically justify documenting it within the much narrower scope of a > detailed specification, unless it is part of that specification's > technology. > > The MX record check has no /technical/ relationship to the /technical/ > details of DMARC. > > Please note that I'm not commenting on the efficacy of the record check, > but on the need to document it in a place that makes sense for the full > range of its implementers. > > There are, and will continue to be, plenty of operators using that check > but not DMARC. That simple fact provides a very pragmatic reason for > moving its specification into some document outside of DMARC. > I'm surprised we're not hearing more passionate voices in favor of keeping it given the genesis of the paragraph we're discussing. At any rate, I'm going to take it out in -09, because I just discovered that it's actually directly contradicting what Appendix A.4 says. -MSK --001a1134cd58da05f6050b035e04 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Dec 24, 2014 at 11:23 AM, Dave Crocker <dhc@dcro= cker.net> wrote:
The goal, as you state it, is a= t the level of seeking world peace.=C2=A0 It
is very laudable and and very, very broad.=C2=A0 It covers vastly more than=
the scope of DMARC.

DMARC is a specific bit of technology working towards that broader goal. =C2=A0That something happens to fall within this very broad scope does not<= br> automatically justify documenting it within the much narrower scope of a detailed specification, unless it is part of that specification's
technology.

The MX record check has no /technical/ relationship to the /technical/
details of DMARC.

Please note that I'm not commenting on the efficacy of the record check= ,
but on the need to document it in a place that makes sense for the full
range of its implementers.

There are, and will continue to be, plenty of operators using that check but not DMARC.=C2=A0 That simple fact provides a very pragmatic reason for<= br> moving its specification into some document outside of DMARC.

I'm surprised we're not hearing more passion= ate voices in favor of keeping it given the genesis of the paragraph we'= ;re discussing.

At any rate, I'm going to take it out= in -09, because I just discovered that it's actually directly contradi= cting what Appendix A.4 says.

-MSK
--001a1134cd58da05f6050b035e04-- From nobody Wed Dec 24 21:13: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 2319A1A6FF0 for ; Wed, 24 Dec 2014 21:13:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 oP0xChM-JoHw for ; Wed, 24 Dec 2014 21:13:30 -0800 (PST) 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 F16761A86F7 for ; Wed, 24 Dec 2014 21:13:29 -0800 (PST) Received: (qmail 86484 invoked from network); 25 Dec 2014 05:13:29 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 25 Dec 2014 05:13:29 -0000 Date: 25 Dec 2014 05:13:06 -0000 Message-ID: <20141225051306.28725.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <227572093.52751.1419470541903.JavaMail.zimbra@peachymango.org> 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/N-XokNJyBfl4cmq9j_ZbEBCp8T4 Cc: franck@peachymango.org Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 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, 25 Dec 2014 05:13:33 -0000 >What about pointing it may be a security issue to let these messages through? Only if we also point out that it may be a security issue not to let them through. Seasons xmas, John From nobody Wed Dec 24 22:04: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 3A27C1A8718 for ; Wed, 24 Dec 2014 22:04:19 -0800 (PST) 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 dg6X1d3yqpDe for ; Wed, 24 Dec 2014 22:04:14 -0800 (PST) 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 8F29D1A004C for ; Wed, 24 Dec 2014 22:04:13 -0800 (PST) Received: from scott-latitude-e6320.localnet (unknown [76.92.231.124]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id EB535C40103; Thu, 25 Dec 2014 00:04:11 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1419487452; bh=SOIFdGBnWIE++kh8in1ehWCQ0zPoYMsSb1c3d20XdLo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=mZ4F/OZdkyHOqp9KHCoOgJ+neE7S7C2tHPeqHhhHprOvr7F7wlrLxQC/OBYAPAt+i Wc0QmpSn+0Uw7GA3Hz5IKg8zw9/W9M66XjSmECvG8QzbhlLfY9YPOQCizKAPqgL4B/ FA4Kn0Fvjfd+rFhq/wf092yGmVrkMz3Q+9F5lok8= From: Scott Kitterman To: dmarc@ietf.org Date: Thu, 25 Dec 2014 01:04:08 -0500 Message-ID: <3560918.GJPr4VqMDe@scott-latitude-e6320> User-Agent: KMail/4.13.3 (Linux/3.13.0-43-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <227572093.52751.1419470541903.JavaMail.zimbra@peachymango.org> References: <227572093.52751.1419470541903.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/hUdNbNHwLzsabfrZyx8_WsUANiQ Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 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, 25 Dec 2014 06:04:19 -0000 On Wednesday, December 24, 2014 19:22:21 Franck Martin wrote: > ----- Original Message ----- > > > From: "Scott Kitterman" > > To: dmarc@ietf.org > > Sent: Wednesday, December 24, 2014 2:48:17 PM > > Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 > > > > On Wednesday, December 24, 2014 10:46:42 Murray S. Kucherawy wrote: > > > On Wed, Dec 24, 2014 at 4:04 AM, Scott Kitterman > > > > > > wrote: > > > > The draft strongly encourages DMARC implementers to ignore SPF policy, > > > > so > > > > I don't think assuming messages will be deferred due only due to SPF > > > > or > > > > DKIM results indicating a temporary DNS error is appropriate. > > > > > > If there's a transient DNS error getting the SPF policy, then there's no > > > SPF policy to be ignored. That's quite a different situation. > > > > > > > I think that in the case of a temporary DNS error in one of the lower > > > > level protocols, insufficient inputs are available to conclude a > > > > message > > > > has failed DMARC tests. > > > > > > I agree. > > > > > > > Receivers can either ignore DMARC for this message due to incomplete > > > > evaluation or they can defer the message in the hope that the > > > > temporary > > > > error will be resolved when the message is retried. Receivers MUST > > > > NOT > > > > apply DMARC policy and reject or quarantine because the DMARC > > > > evaluation > > > > is > > > > incomplete. > > > > > > Can you provide specific changes, with section numbers, that you'd like > > > to > > > see applied to resolve this? > > > > Here's my suggestion. Replace this text at the end of section 5.6.2: > > Handling of messages for which SPF and/or DKIM evaluation encounters > > a DNS error is left to the discretion of the Mail Receiver. Further > > discussion is available in Section 5.6.3. > > > > with: > > Messages for which SPF and/or DKIM evaluation encounters a temporary > > DNS error have not received a definitive result for steps 3 and/or 4 > > above. > > If the message has not passed the the DMARC mechanism check due to > > an SPF or DKIM check that did not have a DNS error, receivers can > > either > > ignore DMARC for this message due to incomplete evaluation or they > > can defer the message in the hope that the temporary error will be > > resolved when the message is retried. Receivers MUST NOT apply DMARC > > policy and reject or quarantine the message because the DMARC > > evaluation is incomplete. When otherwise appropriate due to DMARC > > policy, receivers MAY send feedback reports regarding temporary errors. > > > > Handling of messages for which SPF and/or DKIM evaluation encounters > > a permanent DNS error is left to the discretion of the Mail Receiver. > > > > How's that? > > What about pointing it may be a security issue to let these messages > through? It's a security risk to let any messages through. What text would you suggest for an addition to security considerations? Scott K From nobody Wed Dec 24 22:08: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 9E6F31A008A for ; Wed, 24 Dec 2014 22:08:19 -0800 (PST) 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 PKUlwUKwI-Et for ; Wed, 24 Dec 2014 22:08:16 -0800 (PST) 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 A94BA1A8718 for ; Wed, 24 Dec 2014 22:08:16 -0800 (PST) Received: from scott-latitude-e6320.localnet (unknown [76.92.231.124]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 8A84FC40103; Thu, 25 Dec 2014 00:08:15 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1419487695; bh=vPDX6jX2ilpu6HMiH2jruZVCLful2De37WWXRw8oh44=; h=From:To:Subject:Date:In-Reply-To:References:From; b=iRKlzOLM3t4IJ1i1qOBcOMM/Voo1K940wd6X/iPhuMXjcgXxZkJF+4jqzpa0JDo0L JM+qTHE3mrJUWA97vtyFC+YwdPvpaYT6ZdA8kzGJb3Jd48NBtYqILSIN2i0nQPsdAA /s0uT6Z3HUfJ7qdnxz5oGGAmv1BD4ZD/o1ow9iHI= From: Scott Kitterman To: dmarc@ietf.org Date: Thu, 25 Dec 2014 01:08:12 -0500 Message-ID: <3004337.MAocVZ5Co9@scott-latitude-e6320> User-Agent: KMail/4.13.3 (Linux/3.13.0-43-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <2397001.Fx3SqMl5ZI@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/y4JOUl7IhOYjgEkeAsTjFYJ99I4 Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 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, 25 Dec 2014 06:08:20 -0000 On Thursday, December 25, 2014 00:02:41 Murray S. Kucherawy wrote: > On Wed, Dec 24, 2014 at 5:48 PM, Scott Kitterman > > wrote: > > Messages for which SPF and/or DKIM evaluation encounters a temporary > > DNS error have not received a definitive result for steps 3 and/or 4 > > > > above. > > > > If the message has not passed the the DMARC mechanism check due to > > an SPF or DKIM check that did not have a DNS error, receivers can > > either > > ignore DMARC for this message due to incomplete evaluation or they > > can defer the message in the hope that the temporary error will be > > resolved when the message is retried. Receivers MUST NOT apply DMARC > > policy and reject or quarantine the message because the DMARC > > evaluation is incomplete. When otherwise appropriate due to DMARC > > policy, receivers MAY send feedback reports regarding temporary errors. > > > > Handling of messages for which SPF and/or DKIM evaluation encounters > > a permanent DNS error is left to the discretion of the Mail Receiver. > > > > How's that? > > I think it pretty much says what's there, but is a lot more clear about > it. I also think the second sentence is a bit convoluted, so I reworked it > into this. Does it match what you're trying to say? > > Messages for which SPF and/or DKIM evaluation encounters > a temporary DNS error have not received a definitive result for steps 3 > and/or 4 above. When such an evaluation > is done in conjunction with an aligned identifier, > completion of the DMARC algorithm is not possible. > In this case, receivers can either skip DMARC for this > message due to incomplete evaluation, or they can > arrange > to defer handling of the message in the hope that the > temporary error will be resolved when the message is > retried. In any case, Receivers cannot apply DMARC > policy and reject or quarantine the message because the > DMARC evaluation is incomplete. When otherwise > appropriate due to DMARC policy, receivers MAY send > feedback reports regarding temporary errors. > > -MSK I don't think it does. What I was trying to say is that if you already got an aligned pass from one method, you're done. It doesn't matter if they other one gets a DNS error, you already have a definitive result. I don't think your text says that, but I may be wrong. Also, I don't like the change from MUST NOT to cannot. Receivers can do whatever they want, so cannot isn't correct. This bit is meant to say that receivers aren't free to use DMARC as an excuse to throw away messages every time there's a DNS hiccup. Applying policy in an inappropriate way does have an interoperability impact (messages quarantined/rejected that should not be), so I think the MUST NOT is appropriate. Scott K From nobody Thu Dec 25 18:43: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 357081A1B66 for ; Thu, 25 Dec 2014 18:43:33 -0800 (PST) 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 JdNumaAeMpeo for ; Thu, 25 Dec 2014 18:43:31 -0800 (PST) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c: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 0FABA1A1B5E for ; Thu, 25 Dec 2014 18:43:31 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id n3so16264096wiv.17 for ; Thu, 25 Dec 2014 18:43:29 -0800 (PST) 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=RmTwhrJ8Dut6IZVLV4doH4doCZbie4E0KbKaOpkuhfY=; b=ZvC/QPI7XXS5X2+TIdV+b8unG2SxPltUFeRwvLsafBRyoIThKRnvhxqSsXaj7UvI+U FkJ3q6b09uxYVg7by2Asn340urd/CS+7+MXKFKBu++//ANo0RJ2aU3ISP9tRHZqdxU/Q KjQkUbUIv0EWJGVjb2zSqi9kg/sXPgGJ2AHcBQa5kY7Mjkm/UVVWrLgzLjZrL5VbrKvM N3+gjJEfHWGW2aIFHwizfCTZLXEpMKX6om7I7+YeGbgTjvRhEf/gkDCYxDlIWdUtvxz1 PPJG2ySKPbVZ4LoZ1UmVYn5+vi4a4phJJpmkRxnMq7hoiC44qcAgV16XuUXFPB9TGB0o UzxA== MIME-Version: 1.0 X-Received: by 10.194.86.135 with SMTP id p7mr77749548wjz.89.1419561809811; Thu, 25 Dec 2014 18:43:29 -0800 (PST) Received: by 10.27.204.198 with HTTP; Thu, 25 Dec 2014 18:43:29 -0800 (PST) In-Reply-To: <3004337.MAocVZ5Co9@scott-latitude-e6320> References: <2397001.Fx3SqMl5ZI@scott-latitude-e6320> <3004337.MAocVZ5Co9@scott-latitude-e6320> Date: Thu, 25 Dec 2014 21:43:29 -0500 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=089e0102e498691d2a050b157d43 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/3Swt7hO8vJ8184sle3C4DEASqsg Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 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, 26 Dec 2014 02:43:33 -0000 --089e0102e498691d2a050b157d43 Content-Type: text/plain; charset=UTF-8 On Thu, Dec 25, 2014 at 1:08 AM, Scott Kitterman wrote: > I don't think it does. What I was trying to say is that if you already > got an > aligned pass from one method, you're done. It doesn't matter if they other > one gets a DNS error, you already have a definitive result. I don't think > your > text says that, but I may be wrong. > I think it's close. I see the distinction you're making, and I've adjusted. Have a look at the diff now: http://www.blackops.org/~msk/dmarc/diff.html Also, I don't like the change from MUST NOT to cannot. Receivers can do > whatever they want, so cannot isn't correct. This bit is meant to say that > receivers aren't free to use DMARC as an excuse to throw away messages > every > time there's a DNS hiccup. Applying policy in an inappropriate way does > have > an interoperability impact (messages quarantined/rejected that should not > be), > so I think the MUST NOT is appropriate. > I think "cannot" does do that, actually. We're saying here that DMARC can't complete for the case you describe, namely where both SPF and DKIM suffered some kind of transient error. In that case, if you're rejecting, you aren't legitimately doing it in the name of DMARC. I'm deliberately avoiding using new RFC2119 language here because it's way too late to be adding major normative goo. These are supposed to be corrections to existing text, not addressing oversights in the protocol itself. If we got this wrong in the base spec, then it's potential material for a standards track revision. Otherwise, if we start down the path of fixing things, we're never going to be done with this version. (Pete and Barry would also point out here that it's possible for normative language to exist without using RFC2119's key words...) -MSK --089e0102e498691d2a050b157d43 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Dec 25, 2014 at 1:08 AM, Scott Kitterman <skli= st@kitterman.com> wrote:
I don't think it does.=C2=A0 What I was t= rying to say is that if you already got an
aligned pass from one method, you're done.=C2=A0 It doesn't matter = if they other
one gets a DNS error, you already have a definitive result.=C2=A0 I don'= ;t think your
text says that, but I may be wrong.

I t= hink it's close.=C2=A0 I see the distinction you're making, and I&#= 39;ve adjusted.=C2=A0 Have a look at the diff now:
http://www.blackops.org/~msk/dmarc/diff= .html

Also, I don't like the change from MUST NOT to cannot.=C2=A0 Receivers = can do
whatever they want, so cannot isn't correct.=C2=A0 This bit is meant to= say that
receivers aren't free to use DMARC as an excuse to throw away messages = every
time there's a DNS hiccup.=C2=A0 Applying policy in an inappropriate wa= y does have
an interoperability impact (messages quarantined/rejected that should not b= e),
so I think the MUST NOT is appropriate.

I think "cannot" does do that, actually.=C2=A0 We're saying = here that DMARC can't complete for the case you describe, namely where = both SPF and DKIM suffered some kind of transient error.=C2=A0 In that case= , if you're rejecting, you aren't legitimately doing it in the name= of DMARC.

I'm deliberately avoiding using new RFC2119 language = here because it's way too late to be adding major normative goo.=C2=A0 = These are supposed to be corrections to existing text, not addressing overs= ights in the protocol itself.=C2=A0 If we got this wrong in the base spec, = then it's potential material for a standards track revision.=C2=A0 Othe= rwise, if we start down the path of fixing things, we're never going to= be done with this version.

(Pete and Barry would also po= int out here that it's possible for normative language to exist without= using RFC2119's key words...)

-MSK