Re: [dmarc-ietf] draft-kucherawy-dmarc-base updated (-06)
Hi, Murray, On 12/24/2014 06:45 AM, Murray S. Kucherawy wrote: Hi Rolf, getting back to your review (thanks for the nudge): On Wed, Nov 12, 2014 at 6:26 PM, Rolf E. Sonneveld mailto:r.e.sonnev...@sonnection.nl>> wrote: 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. The new text focuses on what's being provided, not what was missing. Do you want to take another run at it? No need for it, the text of the Abstract in -09 is OK. 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. OK. 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 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 reference to "Mail Sender". OK. 2.2 Out of Scope Add: ocousin domain attacks Covered in Section 2.4 of -08. OK. 3.1.2 Key Concepts Last sentence: add a reference to this 'other referenced material'. Good idea; added. Thanks. 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 delivery to a mailbox. I'd suggest to label this box 'rMDA'. That's already done in -08. OK. Well, it's MDA, but that's OK. One typo in the diagram. When: "sMTA" is the sending MTA, and "rMTA" is the receiving MTA. is correct, the box in the diagram should be labelled 'sMTA', not 'oMTA'. 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’s 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. Whether or not to generate reports in the case of non-alignment is not clear from the text, or am I missing something? Par. 3.1.3: 8. If a policy is found, it is combined with the Author's domain and the SPF and DKIM results to produce a DMARC policy result (a "pass" or "fail"), and can optionally cause one of two kinds of reports to be generated (not shown). and par. 6.2 goes right into the format of reports, not the conditions under which a report is to be sent. 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=cousindomain and RFC5322.From=localpart@cousindomain It's not there in -08. OK. 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 reas
Re: [dmarc-ietf] Jim Fenton's review of -04
On 12/29/2014 12:32 PM, MH Michael Hammer (5304) wrote: > >> -Original Message- >> From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Scott Kitterman >> [...] >> I think the only two reasonable choices are defer and see what happens on >> retry or to treat it as DMARC none and press on with other checks. >> > I suppose it's ultimately another example of local policy. I feel like a > DMARC "none" opens the door to abuse (I'm thinking of abused financials for > example). How easily can an abuser induce temporary failures for DNS for a > given host/domain? I'd prefer a recommendation of "defer and retry" rather > than a fail open (DMARC none). Is this a point where the phrase "documenting existing common practice" should guide us? That sounded a lot like recommending a practice versus documenting... --S. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Jim Fenton's review of -04
On 12/29/2014 12:32 PM, MH Michael Hammer (5304) wrote: > I suppose it's ultimately another example of local policy. Depends on what that means. The rule within the protocol needs to be -- and is -- mechanical and universal: In order to apply DMARC policy, you must first obtain an authenticated (or, described more usefully, 'authorized') domain name that is aligned with the From: field domain. A protocol that treats an initial, temporary error as producing a permanent error is a pretty fragile protocol, in a networking environment. As such, DMARC should at least strongly recommend retries, in the case of no passes and at least one temp fail. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Jim Fenton's review of -04
> -Original Message- > From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Scott Kitterman > Sent: Monday, December 29, 2014 3:22 PM > To: dmarc@ietf.org > Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 > > On December 29, 2014 3:15:26 PM EST, "MH Michael Hammer (5304)" > wrote: > >Still not quite correct... > > > >> -Original Message- > >> From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Dave Crocker > >> Sent: Monday, December 29, 2014 2:32 PM > >> To: Scott Kitterman; dmarc@ietf.org > >> Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 > >> > >> On 12/29/2014 10:40 AM, Scott Kitterman wrote: > >> TO: > >> >> > > >> DMARC evaluation can only complete and yield a "pass" result when one > >of > >> the underlying authentication mechanisms passes for an aligned > >identifier. If > >> neither passes and one or both of them failed due to > >> >> >a > >> temporary error, the Receiver evaluating the message is also unable > >> >> >to > >> conclude that the DMARC mechanism had a permanent failure and > thereby > >> can apply the advertised DMARC policy. > >> >> > > >> >> >This looks good to me. > >> > Shouldn't it be cannot apply the advertised DMARC policy? > >> > >> Actually, no, but I also was confused. It took me some serious > >effort to > >> decide that the current wording was correct. And a spec should not > >require > >> that sort of linguistic diligence, IMO. > >> > >> Looks like a small change can make your form correct... > >> > >> So I suggest: > >> > >> DMARC evaluation can only yield a "pass" result after one of the > >> underlying authentication mechanisms passes for an aligned > >identifier. If > >> neither passes and one or both of them fails due to a temporary > >error, the > >> Receiver evaluating the message is unable to conclude that the DMARC > >> mechanism had a permanent failure; they therefore cannot (yet) apply > >the > >> advertised DMARC policy. > >> > >> d/ > >> -- > > > >If neither of them passes and only one of them fails due to a temporary > >error (but the other one does not fail due to a temporary error) then > >the other one should (must?, not in the normative sense) be an actual > >failure. Perhaps the wording should be: "If neither SPF nor DKIM pass > >and both of them fail due to temporary errors...". The case we seem to > >be discussing is where we have temporary failures for both SPF and > >DKIM. > > No. As long as either of them have a temporary DNS error, then you can't > apply DMARC policy. > DOH! I stand corrected. > >The other issue (more than a quibble) I have is leaving it at "; they > >therefore cannot (yet) apply the advertised DMARC policy." What should > >they do? I prefer the treat it as a tempfail and allow for retries. The > >problem with that approach is if the mail has been accepted for > >delivery. I don't like the idea of DSNs or out of band bounces. > > I think the only two reasonable choices are defer and see what happens on > retry or to treat it as DMARC none and press on with other checks. > I suppose it's ultimately another example of local policy. I feel like a DMARC "none" opens the door to abuse (I'm thinking of abused financials for example). How easily can an abuser induce temporary failures for DNS for a given host/domain? I'd prefer a recommendation of "defer and retry" rather than a fail open (DMARC none). Mike ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Jim Fenton's review of -04
On December 29, 2014 3:15:26 PM EST, "MH Michael Hammer (5304)" wrote: >Still not quite correct... > >> -Original Message- >> From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Dave Crocker >> Sent: Monday, December 29, 2014 2:32 PM >> To: Scott Kitterman; dmarc@ietf.org >> Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 >> >> On 12/29/2014 10:40 AM, Scott Kitterman wrote: >> TO: >> >> > >> DMARC evaluation can only complete and yield a "pass" result when one >of >> the underlying authentication mechanisms passes for an aligned >identifier. If >> neither passes and one or both of them failed due to >> >> >a >> temporary error, the Receiver evaluating the message is also unable >> >> >to >> conclude that the DMARC mechanism had a permanent failure and thereby >> can apply the advertised DMARC policy. >> >> > >> >> >This looks good to me. >> > Shouldn't it be cannot apply the advertised DMARC policy? >> >> Actually, no, but I also was confused. It took me some serious >effort to >> decide that the current wording was correct. And a spec should not >require >> that sort of linguistic diligence, IMO. >> >> Looks like a small change can make your form correct... >> >> So I suggest: >> >> DMARC evaluation can only yield a "pass" result after one of the >> underlying authentication mechanisms passes for an aligned >identifier. If >> neither passes and one or both of them fails due to a temporary >error, the >> Receiver evaluating the message is unable to conclude that the DMARC >> mechanism had a permanent failure; they therefore cannot (yet) apply >the >> advertised DMARC policy. >> >> d/ >> -- > >If neither of them passes and only one of them fails due to a temporary >error (but the other one does not fail due to a temporary error) then >the other one should (must?, not in the normative sense) be an actual >failure. Perhaps the wording should be: "If neither SPF nor DKIM pass >and both of them fail due to temporary errors...". The case we seem to >be discussing is where we have temporary failures for both SPF and >DKIM. No. As long as either of them have a temporary DNS error, then you can't apply DMARC policy. >The other issue (more than a quibble) I have is leaving it at "; they >therefore cannot (yet) apply the advertised DMARC policy." What should >they do? I prefer the treat it as a tempfail and allow for retries. The >problem with that approach is if the mail has been accepted for >delivery. I don't like the idea of DSNs or out of band bounces. I think the only two reasonable choices are defer and see what happens on retry or to treat it as DMARC none and press on with other checks. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Jim Fenton's review of -04
Still not quite correct... > -Original Message- > From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Dave Crocker > Sent: Monday, December 29, 2014 2:32 PM > To: Scott Kitterman; dmarc@ietf.org > Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 > > On 12/29/2014 10:40 AM, Scott Kitterman wrote: > TO: > >> > > DMARC evaluation can only complete and yield a "pass" result when one of > the underlying authentication mechanisms passes for an aligned identifier. If > neither passes and one or both of them failed due to > >> >a > temporary error, the Receiver evaluating the message is also unable > >> >to > conclude that the DMARC mechanism had a permanent failure and thereby > can apply the advertised DMARC policy. > >> > > >> >This looks good to me. > > Shouldn't it be cannot apply the advertised DMARC policy? > > Actually, no, but I also was confused. It took me some serious effort to > decide that the current wording was correct. And a spec should not require > that sort of linguistic diligence, IMO. > > Looks like a small change can make your form correct... > > So I suggest: > > DMARC evaluation can only yield a "pass" result after one of the > underlying authentication mechanisms passes for an aligned identifier. If > neither passes and one or both of them fails due to a temporary error, the > Receiver evaluating the message is unable to conclude that the DMARC > mechanism had a permanent failure; they therefore cannot (yet) apply the > advertised DMARC policy. > > d/ > -- If neither of them passes and only one of them fails due to a temporary error (but the other one does not fail due to a temporary error) then the other one should (must?, not in the normative sense) be an actual failure. Perhaps the wording should be: "If neither SPF nor DKIM pass and both of them fail due to temporary errors...". The case we seem to be discussing is where we have temporary failures for both SPF and DKIM. The other issue (more than a quibble) I have is leaving it at "; they therefore cannot (yet) apply the advertised DMARC policy." What should they do? I prefer the treat it as a tempfail and allow for retries. The problem with that approach is if the mail has been accepted for delivery. I don't like the idea of DSNs or out of band bounces. Mike ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Jim Fenton's review of -04
On December 29, 2014 2:32:27 PM EST, Dave Crocker wrote: >On 12/29/2014 10:40 AM, Scott Kitterman wrote: >TO: >>> > >DMARC evaluation can only complete and yield a "pass" result when one >of the underlying authentication mechanisms passes for an aligned >identifier. If neither passes and one or both of them failed due to >>> >a >temporary error, the Receiver evaluating the message is also unable >>> >to >conclude that the DMARC mechanism had a permanent failure and thereby >can apply the advertised DMARC policy. >>> > >>> >This looks good to me. >> Shouldn't it be cannot apply the advertised DMARC policy? > >Actually, no, but I also was confused. It took me some serious effort >to decide that the current wording was correct. And a spec should not >require that sort of linguistic diligence, IMO. > >Looks like a small change can make your form correct... > >So I suggest: > > DMARC evaluation can only yield a "pass" result after one >of the underlying authentication mechanisms passes for an aligned >identifier. If neither passes and one or both of them fails due to a >temporary error, the Receiver evaluating the message is unable to >conclude that the DMARC mechanism had a permanent failure; they >therefore cannot (yet) apply the advertised DMARC policy. > >d/ I think that's better. I'd prefer to leave out the parenthetical yet as I think it raises ambiguity rather than reduces it. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Jim Fenton's review of -04
On 12/29/2014 10:40 AM, Scott Kitterman wrote: TO: >> > DMARC evaluation can only complete and yield a "pass" result when one of the underlying authentication mechanisms passes for an aligned identifier. If neither passes and one or both of them failed due to >> >a temporary error, the Receiver evaluating the message is also unable >> >to conclude that the DMARC mechanism had a permanent failure and thereby can apply the advertised DMARC policy. >> > >> >This looks good to me. > Shouldn't it be cannot apply the advertised DMARC policy? Actually, no, but I also was confused. It took me some serious effort to decide that the current wording was correct. And a spec should not require that sort of linguistic diligence, IMO. Looks like a small change can make your form correct... So I suggest: DMARC evaluation can only yield a "pass" result after one of the underlying authentication mechanisms passes for an aligned identifier. If neither passes and one or both of them fails due to a temporary error, the Receiver evaluating the message is unable to conclude that the DMARC mechanism had a permanent failure; they therefore cannot (yet) apply the advertised DMARC policy. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Jim Fenton's review of -04
On December 29, 2014 11:50:51 AM EST, ned+dm...@mrochek.com wrote: >> On 12/29/2014 7:26 AM, MH Michael Hammer (5304) wrote: >> > It's still not quite right: >> > >> > DMARC evaluation can only complete and yield a "pass" result when >one >> > >> > >> > of the underlying authentication mechanisms passes for an aligned >> > >> > identifier. If this is not the case and either or both of them >> > >> > suffered some kind of temporary error (such as a transient DNS >> > >> > problem), the Receiver evaluating the message is also unable to >> > >> > conclude that the DMARC mechanism failed and thereby apply the >> > >> > advertised DMARC policy. Rather, the Receiver can either skip >DMARC >> > >> > >> > processing for this message due to incomplete evaluation, or it can >> > >> > >> > arrange to defer handling of the message in the hope that the >> > >> > temporary error will be resolved when the message is retried. When >> > >> > >> > otherwise appropriate due to DMARC policy, receivers MAY send >> > >> > feedback reports regarding temporary errors. >> > >> > >> > The problem is with: >> > >> > "If this is not the case and either or both of them suffered some >> > kind of temporary error (such as a transient DNS problem),...", >> > Specifically the use of "either or". If only one (SPF or DKIM) has >a >> > transient DNS error then presumably the other, which has not had an >> > error, can be evaluated (resulting in a "pass" or "DMARC failure". >It >> > only becomes an issue when BOTH SPF and DKIM have concurrent >> > temporary errors. I'm thinking that removing the "either or" is >> > appropriate. I'm still cogitating on the rest of the paragraph. > > >> Good catch. This is complicated by there really being two >conditions. > >> The first is the negative that neither method authenticates. The >second >> is the affirmative that one of them failed with a temporary error. > >> So perhaps something like: > >> FROM: > >> > DMARC evaluation can only complete and yield a "pass" result when >one >> > of the underlying authentication mechanisms passes for an aligned >> > identifier. If this is not the case and either or both of them >> > suffered some kind of temporary error (such as a transient DNS >> > problem), the Receiver evaluating the message is also unable to >> > conclude that the DMARC mechanism failed and thereby apply the >> > advertised DMARC policy. > > >> TO: > >> DMARC evaluation can only complete and yield a "pass" result when one >> of the underlying authentication mechanisms passes for an aligned >> identifier. If neither passes and one or both of them failed due to >a >> temporary error, the Receiver evaluating the message is also unable >to >> conclude that the DMARC mechanism had a permanent failure and thereby >> can apply the advertised DMARC policy. > >This looks good to me. Shouldn't it be cannot apply the advertised DMARC policy? Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Jim Fenton's review of -04
> On 12/29/2014 7:26 AM, MH Michael Hammer (5304) wrote: > > It's still not quite right: > > > > DMARC evaluation can only complete and yield a "pass" result when one > > > > > > of the underlying authentication mechanisms passes for an aligned > > > > identifier. If this is not the case and either or both of them > > > > suffered some kind of temporary error (such as a transient DNS > > > > problem), the Receiver evaluating the message is also unable to > > > > conclude that the DMARC mechanism failed and thereby apply the > > > > advertised DMARC policy. Rather, the Receiver can either skip DMARC > > > > > > processing for this message due to incomplete evaluation, or it can > > > > > > arrange to defer handling of the message in the hope that the > > > > temporary error will be resolved when the message is retried. When > > > > > > otherwise appropriate due to DMARC policy, receivers MAY send > > > > feedback reports regarding temporary errors. > > > > > > The problem is with: > > > > "If this is not the case and either or both of them suffered some > > kind of temporary error (such as a transient DNS problem),...", > > Specifically the use of "either or". If only one (SPF or DKIM) has a > > transient DNS error then presumably the other, which has not had an > > error, can be evaluated (resulting in a "pass" or "DMARC failure". It > > only becomes an issue when BOTH SPF and DKIM have concurrent > > temporary errors. I'm thinking that removing the "either or" is > > appropriate. I'm still cogitating on the rest of the paragraph. > Good catch. This is complicated by there really being two conditions. > The first is the negative that neither method authenticates. The second > is the affirmative that one of them failed with a temporary error. > So perhaps something like: > FROM: > > DMARC evaluation can only complete and yield a "pass" result when one > > of the underlying authentication mechanisms passes for an aligned > > identifier. If this is not the case and either or both of them > > suffered some kind of temporary error (such as a transient DNS > > problem), the Receiver evaluating the message is also unable to > > conclude that the DMARC mechanism failed and thereby apply the > > advertised DMARC policy. > TO: > DMARC evaluation can only complete and yield a "pass" result when one > of the underlying authentication mechanisms passes for an aligned > identifier. If neither passes and one or both of them failed due to a > temporary error, the Receiver evaluating the message is also unable to > conclude that the DMARC mechanism had a permanent failure and thereby > can apply the advertised DMARC policy. This looks good to me. Ned ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Jim Fenton's review of -04
On 12/29/2014 7:26 AM, MH Michael Hammer (5304) wrote: > It's still not quite right: > > DMARC evaluation can only complete and yield a "pass" result when one > > > of the underlying authentication mechanisms passes for an aligned > > identifier. If this is not the case and either or both of them > > suffered some kind of temporary error (such as a transient DNS > > problem), the Receiver evaluating the message is also unable to > > conclude that the DMARC mechanism failed and thereby apply the > > advertised DMARC policy. Rather, the Receiver can either skip DMARC > > > processing for this message due to incomplete evaluation, or it can > > > arrange to defer handling of the message in the hope that the > > temporary error will be resolved when the message is retried. When > > > otherwise appropriate due to DMARC policy, receivers MAY send > > feedback reports regarding temporary errors. > > > The problem is with: > > "If this is not the case and either or both of them suffered some > kind of temporary error (such as a transient DNS problem),...", > Specifically the use of "either or". If only one (SPF or DKIM) has a > transient DNS error then presumably the other, which has not had an > error, can be evaluated (resulting in a "pass" or "DMARC failure". It > only becomes an issue when BOTH SPF and DKIM have concurrent > temporary errors. I'm thinking that removing the "either or" is > appropriate. I'm still cogitating on the rest of the paragraph. Good catch. This is complicated by there really being two conditions. The first is the negative that neither method authenticates. The second is the affirmative that one of them failed with a temporary error. So perhaps something like: FROM: > DMARC evaluation can only complete and yield a "pass" result when one > of the underlying authentication mechanisms passes for an aligned > identifier. If this is not the case and either or both of them > suffered some kind of temporary error (such as a transient DNS > problem), the Receiver evaluating the message is also unable to > conclude that the DMARC mechanism failed and thereby apply the > advertised DMARC policy. TO: DMARC evaluation can only complete and yield a "pass" result when one of the underlying authentication mechanisms passes for an aligned identifier. If neither passes and one or both of them failed due to a temporary error, the Receiver evaluating the message is also unable to conclude that the DMARC mechanism had a permanent failure and thereby can apply the advertised DMARC policy. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Jim Fenton's review of -04
It's still not quite right: DMARC evaluation can only complete and yield a "pass" result when one of the underlying authentication mechanisms passes for an aligned identifier. If this is not the case and either or both of them suffered some kind of temporary error (such as a transient DNS problem), the Receiver evaluating the message is also unable to conclude that the DMARC mechanism failed and thereby apply the advertised DMARC policy. Rather, the Receiver can either skip DMARC processing for this message due to incomplete evaluation, or it can arrange to defer handling of the message in the hope that the temporary error will be resolved when the message is retried. When otherwise appropriate due to DMARC policy, receivers MAY send feedback reports regarding temporary errors. The problem is with: "If this is not the case and either or both of them suffered some kind of temporary error (such as a transient DNS problem),...", Specifically the use of "either or". If only one (SPF or DKIM) has a transient DNS error then presumably the other, which has not had an error, can be evaluated (resulting in a "pass" or "DMARC failure". It only becomes an issue when BOTH SPF and DKIM have concurrent temporary errors. I'm thinking that removing the "either or" is appropriate. I'm still cogitating on the rest of the paragraph. Mike > -Original Message- > From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Scott Kitterman > Sent: Thursday, December 25, 2014 11:55 PM > To: dmarc@ietf.org > Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 > > On December 25, 2014 8:43:29 PM CST, "Murray S. Kucherawy" > wrote: > >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 > > I believe that covers it. > > >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...) > > OK. I think this solves the problem I was worried about. > > Thanks, > > Scott K > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
