Re: [dmarc-ietf] DMARC policy overrides

[Scott Kitterman <[e-mail]>]

Except you can't tell if DMARC applies to a message until DATA, so the only way to implement this is to change all SPF checks to after DATA whether they are related to DMARC or not.  I think imposing such architectural change on unrelated message processing is inappropriate. I think some discussion of this absent the 2119 words is fine.

Scott K

Franck Martin <[e-mail]> wrote:

>"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.
>_______________________________________________
>dmarc mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/dmarc