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:[email protected]] On Behalf Of Scott Kitterman
> Sent: Thursday, December 25, 2014 11:55 PM
> To: [email protected]
> Subject: Re: [dmarc-ietf] Jim Fenton's review of -04
>
> 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
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
