On Thursday, December 25, 2014 00:02:41 Murray S. Kucherawy wrote: > On Wed, Dec 24, 2014 at 5:48 PM, Scott Kitterman <skl...@kitterman.com> > > 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? > > <t> 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. </t> > > -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 _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
