On Mon, Dec 22, 2014 at 11:16 AM, Dave Crocker <[email protected]> wrote:
> On 12/22/2014 11:11 AM, Rolf E. Sonneveld wrote: > >> > >> Perhaps 5.6.3 needs something like "SHOULD NOT act on DMARC policy if a > >> temporary error in SPF or DKIM processing prevents a full evaluation." > > > > +1 > > We need to be careful about how this is phrased. I specifically suspect > that the above suggested wording is a bad idea, or worse, probably wrong. > > DMARC /requires/ prior validation of the author From domain via a > lower-level mechanism. SPF and DKIM are defined for now. If neither of > them validates the domain, then DMARC fails. > > There is no 'should' about it. It fails. > > Failing means that the polices are not applied. As in MUST NOT be applied. DMARC is built on a positive assertion model. To say that a failure means that no policy is applied is contrary to the model. The policy is explicitly *applied* if neither SPF nor DMARC validates the aligned domain. I disagree with the "not act. . .[if not] full evaluation" - if SPF tempfails, but DKIM passes, that is sufficient for a DMARC pass and I don't see any reason to force the DMARC evaluation to some other value. If SPF tempfails and DKIM is missing or fails, then treating the outcome as "unknown" seems reasonable If SPF or DKIM come up with a temp error, that could be an attack vector to bypass DMARC enforcement, but if receivers simply tempfail such mail, it seems consistent to me with the handling of any other error that is expected to be transient in nature. If it really is an attack of some sort, the mail will eventually time out on the sender's machine. I'm not sure that adding this detail prior to the WG's work output would be prudent or in keeping with the intent of the current "stake in the sand" spec. --Kurt
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
