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

[Terry Zink <[e-mail]>]

Hi, Mike, thanks for your response.

> I'd really like to hear you explain to the other customers when their mail is being 
> rejected because the shared IP is on a blocklist. DMARC doesn't help your customers 
> in this case.

I'm not sure where this comment comes from, protecting and monitoring our outbound IP
reputation is something I have spent many years working on but is orthogonal to this 
discussion (you don't need one for the other, although they help). 

Please let me know if you believe otherwise.


> Not all businesses (with domains) are candidates for having their own IPs or implementing 
> DMARC. This includes most small businesses.

I disagree. I think that small businesses are great candidates for DMARC. As an industry we should help them move there.


> There is this very new standard called IPv6. I hear this provides a couple of extra IPs 
> to the mix. Someone on this list even brought up NIST working on requirements for IPv6 
> only mail sending hosts. I would argue that the case you are putting forward is an 
> unwillingness to address internal implementation/business structure issues.

IPv6 adoption is still in its infancy. Are you really proposing that simply giving each sender its own IPv6 address is the solution, when there are many email receivers who don't receive any mail over IPv6 (e.g., Hotmail)?

I agree that there are things that can be done in parallel. But at the same time, some of these implementations do not have critical mass. 


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

> A lot of ESPs do this on some scale with much more limited resources. Other 
> large providers are dealing with the issue.

Without knowing the implementation details of various ESPs, I don't think it's useful to say Company A does this and therefore so should Company Y. Organizations have varying needs and have their own reasons for pursuing the things they do.


>> Thus, the cost/benefit tradeoff of giving everyone (or even some 
>> customers) their own IP skews heavier towards the costs compared the benefits.
>
> The other option is to propose to externalize those costs to everyone else.

I understand your point. My goal in this discussion is to bring the problem of shared IP space and how to authenticate. DMARC seems like a natural place to do it since it is still a new protocol.

-- Terry


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



> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf 
> Of Terry Zink
> Sent: Monday, April 01, 2013 8:46 PM
> To: [e-mail]
> Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to 
> optionally require SPF and DKIM
> 
> 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."
> 

Then don't let people "spoof" your domain. You have another problem with shared IPs that hasn't been brought into the discussion. By sharing IPs you are sharing reputation across customers. If one of those customers starts spewing abusive mail then the other customers suffer as a consequence. I'd really like to hear you explain to the other customers when their mail is being rejected because the shared IP is on a blocklist. DMARC doesn't help your customers 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).
> 
> 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).
> 

I'm not sympathetic. My company has multiple divisions, brands and operating units around the globe, 10s of thousands of employees and yet we seem to be able to manage it. Other large organizations manage it as well. What I'm hearing is "we are out of control and want to modify DMARC to account for this". 

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

Again, DMARC is not intended for organizations that do this. It's not a question of "legitimate case of spoofing". It's a question of whether a domain/brand owner wishes to prevent direct domain abuse using DMARC. The reason that large (and small) mailbox providers - including your own - got on board with DMARC and the private channel assertions that preceded it is because it works. DMARC only works to the extent that mailbox providers are willing to buy into it. I'd also point out that domains with end users such as the example you use above are simply not good candidates for implementing DMARC policy. Ask John Levine to explain the mailing list issue with regard to DMARC policy assertions.

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

And this is only relevant to the extent that this legitimate mail is originating from domains subject to direct domain abuse and which do not have uncontrolled end users sending mail.

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

Not all businesses (with domains) are candidates for having their own IPs or implementing DMARC. This includes most small businesses.

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

There is this very new standard called IPv6. I hear this provides a couple of extra IPs to the mix. Someone on this list even brought up NIST working on requirements for IPv6 only mail sending hosts. I would argue that the case you are putting forward is an unwillingness to address internal implementation/business structure issues.

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

A lot of ESPs do this on some scale with much more limited resources. Other large providers are dealing with the issue.

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

The other option is to propose to externalize those costs to everyone else.

Mike