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

["MH Michael Hammer (5304)" <[e-mail]>]

Comments in-line.

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Dave Crocker
> Sent: Monday, April 01, 2013 5:58 PM
> To: Terry Zink
> Cc: [e-mail]
> Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally
> require SPF and DKIM
> 
> Terry,
> 
> On 4/1/2013 2:15 PM, 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.
> 

This is a bad idea. While it solves your internal problem it potentially increases false positives for bigbank.com externally, thus trading one problem for another. I've been implementing SPF (ending with -all) and DKIM with private channel assertions since the end of 2007. One of the reasons for using the combination of SPF and DKIM ( and requiring only one to pass) is the reduction of false positives. 

Before trying to extend DMARC to account for internal problems - as Dave points out - I would look for other ways of resolving the problem. As I have said many times regarding email authentication implementation, one needs to get control of their mail flows. That is true in this case. If bigbank.com cannot control it's managers/employees and how they send mail then that is an internal problem that bigbank needs to address. There are plenty of other mechanisms for bigbank to control what it emits (in the case of spam). Perhaps MS should offer bigbank dedicated IPs - ESPs do this all the time for their customers. It may not be so critical for other customers. Sounds like a business opportunity to me.

> The draft working group charter that Murray just circulated would make this
> effort out of scope, since it explicitly prohibits protocol enhancement.
> 
> Are you suggesting a change to the draft charter?
> 

I prefer to avoid relying on limitations in the charter and focusing on the merits which IMHO don't rise to a level justifying this extension. One of the key merits of DMARC is that it focuses on solving a particular problem and based on the data it does that very well.

> An alternative might be to find a way for this example scenario to provide the
> basis for some discussion, in the draft BCP, about the proper limits of
> DMARC.  It wouldn't solve your protocol problem, but it might provide good
> pedagogy.
> 

This sounds like a good idea.

> Perhaps there are other alternatives?
> 
> 
> > 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
> > [e-mail], we can detect this and shut it down. But what
> > happens if they start sending out mail [e-mail]?
> 

It sounds like someone needs btter internal controls to prevent this.

> I tend to draw a distinction between protection against internal problems,
> versus protection against external ones.  Internal means that the
> misbehavior is caused by an activity within the administrative scope of the
> entity needing protection.  External means that the problem behavior comes
> from some other administrative scope.
> 

+1

> The usual examples of the distinction are misbehaviors by a department,
> within the company owning the domain name, versus misbehavior from a
> classic spammer who is using the domain name without authorization. On the
> average, the tendency has been to pursue standardization that protect
> against external threats rather than internal ones. Internal ones are thought
> to be best handled... internally.
> 
> > 1. example.com ----+
> >                    |
> > 2. BigBank.com ----+----> Microsoft Forefront IPs ----> Internet
> >                    |
> > 3. Learning.edu ---+
> 
> 
> The scenario you give might be considered as internal misbehavior, since
> there is a contractual relationship between Forefront and the sources of
> messages that you list.  That is, the essence of the challenge is for Forefront
> to have mechanisms that distinguish what mail is authorized from what
> source, and what mail isn't.  Per your example, it would require that it
> enforce its /own/ dmarc-ish policy to require that mail it is relaying for
> learning.edu be attributed to learning.edu, and so on.
> 
> If I understand your note correctly, the problem that you cite with this is that
> Forefront doesn't know all of the acceptable domains for a given customer.
> Wouldn't it make more sense to fix this issue, rather than change the public
> standard and burden all recipients with the added complexity in software
> and operations?
> 

+1

> Without have thought about it much, I suspect that one approach to fixing
> this is for Forefront to /privately/ assert the type of dmarc-ish enhancement
> that you propose.  That is, impose the requirement on its customers, thereby
> assuring that the mail it is relaying to the public Internet is 'safe', at least
> along this one line of concern.
> 
>