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

[Tim Draegen <[e-mail]>]

Hi Terry,

I like your proposal, but see problems:

- SPF and DKIM don't always work in production.

	By themselves, both SPF and DKIM sometimes fail to yield correct results, even when they *should*.  Be this because of transient DNS errors, DKIM canonicalization errors (its a real thing, and "relaxed" unintuitively breaks more), or bad luck, the error rate introduced by requiring both SPF and DKIM to pass 100% of the time is just too high to be useful.  Keep in mind that this is not about Domain-A sending just to Receiver-B; the problem space is every domain sending to every possible receiver/stack/environment.

- Requiring both DKIM and SPF to yield aligned domain identifiers overshoots the goal.

	The Receiver side of the coin (the "receiving function" if you'll allow me to talk about all and everything that processes incoming email) needs a basic, reliable way to link a domain to a piece of email.. when processing trillions of emails from across millions of domains on top of thousands of software environments.  Even if the reality of imperfect implementations didn't matter (see #1), the receiving function is hunting for an assertion of "this email really does come from X domain".  By requiring both DKIM and SPF to "pass", you're asking the receiving function to consider an extra assertion of "does this email really *really* come from X domain?".

- Complexity is an adoption barrier.

	Because email is used everywhere by everyone all the time and dwarfs everything else, trying to change it is really hard.  The installed base is "yes", everyone has their customized way to squeeze it, Mars lost its water when it tried to upgrade its email.  Any bell, whistle, or tiny piece of extra functionality equates to a real-life adoption barrier.  If said bell, whistle, or tiny piece of extra functionality *significantly* increases the ability to adopt DMARC everywhere, then OK, let's all talk about it and do it.

- DMARC cannot fix the shared IP problem.

	If a company:
		- is activity managing its security envelope,
		- determines that it needs DMARC, and
		- is using a service provider that allows any of its clients to send email pretending to be any other client..
	..then the company needs to think in terms of risk management.  I won't break this down any further unless someone asks.

- There is a work-around to address your proposal:

	What the company can do in this situation is: use a different domain or a sub-domain for the traffic coming out of the service provider, and require "strict" identifier alignment as needed.  Problem solved without changing DMARC.

Lastly, I hope the above does not read like it contains any hostility.  The tone of email-related IETF lists are sometimes hard to modulate, so I just want to be clear: I like your idea, but for the above reasons I think it asks DMARC to do too much for too little (esp 'cause there's a viable way to work-around your scenario).

=- Tim