Subject: [dmarc-ietf] DMARC policy overrides

From: Franck Martin <[email-masked]>
Date: Tue, 2 Jul 2013 18:44:26 +0000

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

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 02 Jul 2013 14:58:09 -0400

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 <[email-masked]> wrote:

>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
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dmarc

---

From: Franck Martin <[email-masked]>
Date: Tue, 2 Jul 2013 19:11:50 +0000

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.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 02 Jul 2013 12:35:27 -0700

My own view is that we should not call this anything as formal as 
'policy overrides'.

What it is is simply leaving the DMARC spec.  Let me repeat:  If someone 
does something differently than the DMARC says they need to do, they are 
no longer performing DMARC.

Anyone can do that whenever they want.  The results will be outside the 
spec, too.

DMARC dictates some behaviors.  Participants choose to... participate. 
They can choose not to.

If they choose to participate only partially, they risk unknown results 
including non-interoperability.  That's their choice.

d/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 2 Jul 2013 13:42:48 -0700

On Tue, Jul 2, 2013 at 12:35 PM, Dave Crocker <[email-masked]> wrote:

> My own view is that we should not call this anything as formal as 'policy
> overrides'.
>
> does something differently than the DMARC says they need to do, they are no
> longer performing DMARC.
>

It seems to me that prose which spells this out, including the costs of the
"override" (namely processing through to the end of DATA), is potentially a
fine compromise.

I also think it's necessary to consider some current realities.  In an
architecture such as the one I use, filters operate serially on the data.
The SPF module runs ahead of DKIM, which in turn runs ahead of DMARC.  If
the SPF module decides to act on a "-all" and reject the message, DMARC and
DKIM simply can't happen.  DMARC, by saying SHOULD over SPF, is attempting
to require that the SPF module change what it's doing.  That means, at
least in my local example, that DMARC is not a pure overlay atop SPF and
DKIM.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Tue, 02 Jul 2013 13:59:15 -0700

On 7/2/2013 1:42 PM, Murray S. Kucherawy wrote:
> It seems to me that prose which spells this out, including the costs of
> the "override" (namely processing through to the end of DATA), is
> potentially a fine compromise.

Since the horse is possible still having some spasms, whether alive or 
not, I'll beat it some more:  My comments are about language, not 
technical details.  My concern is that the language many folk are using 
can lead to misunderstanding what is inside or outside the spec.

> architecture such as the one I use, filters operate serially on the
> data.  The SPF module runs ahead of DKIM, which in turn runs ahead of
> DMARC.  If the SPF module decides to act on a "-all" and reject the
> message, DMARC and DKIM simply can't happen.  DMARC, by saying SHOULD
> over SPF, is attempting to require that the SPF module change what it's
> doing.  That means, at least in my local example, that DMARC is not a
> pure overlay atop SPF and DKIM.

Right. It's not.

As for DMARC 'replacing' some SPF portions, yeah, it's doing that.

If someone thinks the text is not sufficiently clear about what is 
specified to do or why, we know how to fix that.  As for /whether/ to do 
it, again, one can choose to live within DMARC or...

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 02 Jul 2013 17:53:45 -0400

> it, again, one can choose to live within DMARC or...

Ah, so DMARC is what it's defined as, so by definition any suggestion that it 
should be changed is incorrect.  Got it.  Glad we cleared that up.

Scott K

---

From: Franck Martin <[email-masked]>
Date: Tue, 2 Jul 2013 22:21:56 +0000

> should be changed is incorrect.  Got it.  Glad we cleared that up.

Scott,

There are more than 20 people that developed this spec, we reached consensus on this is the best path and we deployed it and we have not seen it should be done otherwise. Any suggestion that it should be changed is not incorrect, it needs more support than the 20 people or so behind it... 

As Barry said, review the current spec, build support and the spec will be changed.

It seems I'm flogging a dead horse here.

---

From: Matt Simerson <[email-masked]>
Date: Tue, 2 Jul 2013 15:39:06 -0700

On Jul 2, 2013, at 1:42 PM, "Murray S. Kucherawy" <[email-masked]> wrote:

> I also think it's necessary to consider some current realities.  In an architecture such as the one I use, filters operate serially on the data.  The SPF module runs ahead of DKIM, which in turn runs ahead of DMARC.

That is how I deploy as well.

> If the SPF module decides to act on a "-all" and reject the message, DMARC and DKIM simply can't happen.

SPF just returns a policy result. Whether or not your SPF module decides to reject the message based on that is a function of your module.  It is only your *implementation* that needs to be modified, not SPF.

I use qpsmtpd "out front" and I hacked in a universal 'reject' method that plugins call when they want to reject a message. Each plugin gets to specify a reject type. Most plugins (like SPF & DKIM) have a reject method of deferred, letting all the plugins have a go at the message first. Later plugins can override earlier ones (DMARC can override SPF and/or DKIM, AUTH can override everything, etc). 

> DMARC, by saying SHOULD over SPF, is attempting to require that the SPF module change what it's doing.  That means, at least in my local example, that DMARC is not a pure overlay atop SPF and DKIM.

I run SPF and DKIM with a deferred rejection and then run the DMARC plugin.  If no DMARC policy is published, then the DMARC plugin exits and any deferred rejections get applied later.  If a DMARC policy is discovered, then any SPF and DKIM rejections should be nulled. 

Again, these are implementation issues, not SPF or DKIM issues.

Matt

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 02 Jul 2013 18:46:57 -0400

Franck Martin <[email-masked]> wrote:

>There are more than 20 people that developed this spec, we reached
>consensus on this is the best path and we deployed it and we have not
>seen it should be done otherwise. Any suggestion that it should be
>changed is not incorrect, it needs more support than the 20 people or
>so behind it... 
>

This isn't an IETF working group with an established consensus that I'm seeking to overturn. Please stop pretending it is.

That group wasn't representative of senders, so I question the relevance to the IETF of your private consensus. 

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Tue, 02 Jul 2013 19:58:41 -0700

On 7/2/2013 2:53 PM, Scott Kitterman wrote:
>> >specified to do or why, we know how to fix that.  As for/whether/  to do
> should be changed is incorrect.

1. Your logic is flawed to the point of silliness and the conclusion you 
invented is simple and completely wrong.

2. You have yet to indicate what technical work needs to be done on the 
specification and, for extra points, indicate who else wants that work done.

d/

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 03 Jul 2013 01:08:43 -0400

On Tuesday, July 02, 2013 07:58:41 PM Dave Crocker wrote:
> > Ah, so DMARC is what it's defined as, so by definition any suggestion that
> > it should be changed is incorrect.
> 

I have, you're not listening, so I'm done.

Scott K