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

[Scott Kitterman <[e-mail]>]

On Tuesday, April 02, 2013 02:26:01 AM J. Gomez wrote:
> 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-financi
> >> a
> >> 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.

Not true at all.  I've done this many times where the domain owner publishes a 
CNAME to the relevant DNS entry in the provider's DNS.  That way the provider 
can manage the specifics/use their own private key (for DKIM) without any zone 
delegation being required.

Scott K