On December 25, 2014 8:43:29 PM CST, "Murray S. Kucherawy" <[email protected]> wrote: >On Thu, Dec 25, 2014 at 1:08 AM, Scott Kitterman <[email protected]> >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 [email protected] https://www.ietf.org/mailman/listinfo/dmarc
