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 9:52 PM
> To: [e-mail]
> Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally
> require SPF and DKIM
> 
> 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.

The original case for a DMARC extension of requiring DKIM only was predicated on one customer on shared IPs sending spam and another part of your organization (Hotmail) having difficulties because DMARC will pass on either SPF or DKIM. The issue of a sender on shared IPs emitting spam is certainly relevant to this discussion. Either spam is being emitted or it is not. Neutering (fixing) DMARC doesn't solve the wider problem of spam being emitted even if it solves the internal DMARC issue for Forefront/Hotmail.
> 
> 
> > 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)?
> 

You can provide an IPv6 to IPv4 gateway..... You'll break SPF but if you do it right you won't break DKIM. Implementing aligned DKIM and SPF in 2007 was a significant effort for us, yet we did it.

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

And organizations choose to implement standards or they choose not to. You pointed to the difficulty level and I pointed out that others are managing these things. I like to tell a joke about this space. Q: How many Psychiatrists does it take to change a light bulb?  Answer: One, but the bulb has to want to change. What I'm hearing is that in this case the bulb doesn't want to change (for whatever reason).

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

DMARC is not particularly new. The private implementations date back to the 2007 timeframe. The goal of creating a public standard based on the successes seen in the private channel implementations was intended to open it up from a private club with limited membership to something that anyone could implement. Trying to overload other design parameters to attempt to solve something that DMARC intentionally did not try to solve is a dangerous path to go down.

There are lots of problems DMARC doesn't address. For example, DMARC doesn't address cousin domains, the display (friendly ) name issue or the use of other character sets to present a look alike domain name. Shared IP space is shared IP space. Sharing IP space across organizations reduces the granularity and utility of SPF. If you don't want to use SPF then sign with DKIM. You can still use DMARC if you are only using DKIM and not SPF. I use shared IPs across domains but I DKIM sign those domains and each of the domains has similar security implementations. So from my perspective it is possible to do.... I've been doing it for years.

Mike