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

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

On Tuesday, April 02, 2013 1:28 AM [GMT+1=CET], Franck Martin wrote:

> On 4/1/13 4:15 PM, "J. Gomez" <[e-mail]> wrote:
> 
>> 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-financia
>> l-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. 
> 
> Google apps, send grid, messagebus, (and many other ESPs) do not have
> problem to create a DKIM key for each customer, to sign the emails
> that pass through them. We used to have open-relays because they were
> easy to setup/manage, but we moved away from them because they were
> insecure. 

If your worry is moving away from insecure, then Terry Zink's proposal is just making DMARC more secure, as it is raising the bar on the mechanisms that have (optionally) to concur to obtain a DMARC-pass.

Apart from that, you would need to control your client's DNS to sign their DKIM in their behalf, and that only works with very small clients which lack in-house technical people and outsource the whole thing to you. But if you want to have clients of medium size which gateway their mail to the Internet through your cloud service, good luck getting their technical people to surrender their administrative control of their DNS to you.

I would like to hear, instead of suggestions for Terry to "fix" his infrastructure and his business model, some contributions as to why his proposal is detrimental to the goals of DMARC.

Regards,

J. Gomez