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

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

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