On Thu, Dec 25, 2014 at 1:08 AM, Scott Kitterman <skl...@kitterman.com> 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
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
