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

[Terry Zink <[e-mail]>]

Hi, Mike.

> 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 agree that there is the potential for false positives. But shouldn't this choice be given to the sender? If they understand the risks then they should be able to say "Yes, this can cause false positives. But we can get those under control (or delegate sub-domains for third parties, or some other workaround like using DMARC to collect feedback on where the unsigned mail originates). The bottom line is we don't want anyone spoofing our domain."

> 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). 

True enough. But it happens with regularity. At a large company, people move on all the time. Groups change and people retire, change jobs, or otherwise move on. The people in charge of maintaining all this IT stuff do not keep pace with the scope of change. This is especially true in a large organization (it is one of our own challenges).

But even beyond that, it's not the only legitimate case we have to deal with. We have companies like real estate companies (e.g., Remax -- if they were a customer) that have independent sales agents. The inbound mail is [e-mail]. The independent agent gets the mail forwarded to their personal email account and then they send outbound mail through us [e-mail]. Remax does not own yahoo.com, but this is a legitimate case where a user "spoofs" a legitimate domain that they do not own.

Thus, shutting down this case is not going to work. The majority of the mail from "legitimately spoofed" senders is non-spam. But the cases of spoofing a domain maliciously is what I want to target.

> 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.

This would solve one problem but introduces other:

a) We have plenty of small businesses that sign up for our service. They may all want their own IPs. Microsoft has plenty of IPs but we don't have an near-infinite amount (the ones Microsoft has, we share them with the rest of the company; they don't all belong to our division).

b) Even if we did give customers their own IPs, they each would get at least two IPs - one in two different data centers for redundancy. This reduces the available pool of IPs.

c) The networking challenge of maintaining IPs-to-customers mapping is painful. Running a service with as much redundancy, failover, cross-datacenter routing as ours is difficult and maintaining all these network mappings adds too much complexity. We can barely keep track of our own IPs.

Thus, the cost/benefit tradeoff of giving everyone (or even some customers) their own IP skews heavier towards the costs compared the benefits.

-- Terry


-----Original Message-----
From: MH Michael Hammer (5304) [mailto:[e-mail]] 
Sent: Monday, April 01, 2013 4:01 PM
To: Dave Crocker; Terry Zink
Cc: [e-mail]
Subject: RE: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM

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.
> 
>