Re: [dmarc-ietf] DMARC policy overrides

[Matt Simerson <[e-mail]>]

On Jul 2, 2013, at 1:42 PM, "Murray S. Kucherawy" <[e-mail]> 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