Re: [dmarc-ietf] DMARC policy overrides

[Franck Martin <[e-mail]>]

This is what I just said, if you want to implement DMARC as a receiver this is what you have to do, for all the reasons I have explained. You are free to not implement DMARC as a receiver if your infrastructure cannot do it, but you are not free to implement it in a way that brings inconsistency across implementers which create inconsistent aggregate reports and therefore email discarding because the receiver does not send to the sender a complete view.

On Jul 2, 2013, at 11:58 AM, Scott Kitterman <[e-mail]> wrote:

> 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.