Re: [dmarc-ietf] Proposing an extension to DMARC to optionally requireSPF and DKIM

["J. Gomez" <[e-mail]>]

On Monday, April 01, 2013 11:15 PM [GMT+1=CET], Terry Zink wrote:

> I am proposing an extension to DMARC. Whereas today DMARC requires
> one of a DKIM pass or SPF pass, I propose we extend DMARC so that is
> has the *option* to require both.  
>
> (...)
>
> Let's assume that BigBank.com has been dutiful and has published a
> DMARC record. The problem occurs when Learning.edu gets compromised
> and starts sending out spam. If a user starts sending out spam from
> [e-mail], we can detect this and shut it down. But what
> happens if they start sending out mail as [e-mail]?    
> 
> example.com ------------+
>                         |
> BigBank.com ------------+----> Microsoft Forefront IPs ----> Internet
>                         |
> Learning.edu            |
>  [e-mail] --+
>
> (...)
>
> Extending DMARC this way lets brands/domains protect their outbound
> reputation behind a shared service without worrying whether or not
> some other customer will spoof them.  
> 
> Make sense?

I does make sense. I also like the explanation in your blog:

http://blogs.msdn.com/b/tzink/archive/2012/10/18/how-should-large-financial-institutions-use-hosted-filtering.aspx

In a multitenant cloud environment, and/or when you are giving customers a MTA-smarthost service to gateway their mail to the Internet, you cannot be sure that they will always be signing their email with DKIM, and you usually will not have their private DKIM keys to sign their email yourself as it flows through the smarthost towards the Internet, so taking the DMARC oportunity to close this hole in SPF is golden.

When we will all be on IPv6, and sharing IPs will be a thing of the past, this will be a non issue. But it is an issue now, and will be even a bigger issue as we remain in IPv4 and more and more things move to the cloud. Your proposal for DMARC would solve this problem scenario of SPF just fine.

Also, your proposal has more benefits:

-- makes DMARC more resilient in case any of its underliying authentications mechanisms becomes compromised/broken/moot in the future.
-- future is hard to predict, this would build into the DMARC specification an optional more strict authentication threshold which may be useful in the future.

As to how to fit your suggestion in the syntax of the DMARC record, I would add an additional (and optional) tag to the specification, "m=" (mechanisms required to pass) with the possible values of "all" and "any", where "all" would require all the mechanisms of DMARC to pass for a DMARC pass itself to be gotten, and where "any" would be the default.

Regards,

J. Gomez