[dmarc-ietf] DMARC policy overrides

[Franck Martin <[e-mail]>]

"DMARC-compliant Mail Receivers SHOULD disregard any mail directive
   discovered as part of an authentication mechanism (e.g., ADSP, SPF)
   where a DMARC policy is also discovered that specifies a policy other
   than "none". {R7} To enable Domain Owners to receive DMARC feedback
   without impacting existing mail processing, discovered policies of
   "p=none" SHOULD NOT modify existing mail disposition processing.
   Note that some Mail Receivers may reject email based upon SPF policy
   mechanisms before email enters DMARC-specific processing.

   Mail Receivers SHOULD also implement reporting instructions of DMARC
   in place of any extensions to SPF or DKIM that might enable such
   reporting. {R10}"

As a sender I want certainty in the processing. The DMARC mechanism is of better strength than SPF alone, because it does SPF AND DKIM. However not everyone does DMARC on the receiving side, so there is still a need to publish a -all SPF policy for the receivers that are not yet on DMARC. If a sender does DMARC with p!=none this is because it has a (serious) spoofing problem.

With such SPF policy I don't want it to overrides DMARC, as DMARC is of more superior nature (this is my judgement otherwise I would not care about DMARC).

But to encourage adoption, and make transition smooth, when p=none, the email flow must not be affected by DMARC. DMARC is transparent to the email in that case, providing reports to allow you to put your mail in order.

The problem arises because SPF can be evaluated at the end of the RCPT TO phase, well before DKIM and therefore DMARC is evaluated. In practices, few enforces SPF policy and uses it later as a scoring mechanism like spamassassin do.

This is why in the text above there is a SHOULD, this brings constancy in the processing, but depending on the receiver infrastructure, then it certainly can deviate from ignoring SPF, but this is not the recommended practice.

Furthermore, for the aggregate reports to be accurate, they need to see all the emails, regardless of SPF policy. Once you implement DMARC as a receiver, you should move your SPF policy decision to the end of DATA, so you can make an accurate aggregate report. This will provide certainty on what will happen when the sender moves away from p=none policy.

A receiver can do what it wants, but the SHOULD above is common sense when you decide to do DMARC as a receiver. 

I think the text, could be more focused, and speak only of overriding only policies that use the same underlying authentication mechanisms, and this is only SPF, DKIM and ADSP. TLS to other scheme would not be affected.