Re: [dmarc-ietf] DMARC policy overrides

["Murray S. Kucherawy" <[e-mail]>]

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

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


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