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

[Elizabeth Zwicky <[e-mail]>]

On Apr 1, 2013, at 5:53 PM, J. Gomez wrote:

> 
> Ok, DMARC has been devised by brand-companies (Facebook, Linkedin, Big-Bank-X) and mailbox-providers (Hotmail, Yahoo, Gmail), I see that and I understand their needs to reliably exchange email policies. But there is more people in the email ecosystem, like for example cloud-services providers, who also happen to do email.

I note that Yahoo!, Google, and Microsoft are all, in fact, cloud-service providers in some form.  You can make the argument that Hotmail is not, it's only other parts of Microsoft, but Gmail and Yahoo! Mail both are. 

There are edge cases where a both option might be helpful -- I've talked to an Amazon customer who said that he had a case where his client required SPF to pass, which left him stuck configuring SPF so all of Amazon's cloud passed. This is a more compelling case than Terry's, since it can't be handled just by SPF configuration. It still could be handled by enforcement within Amazon.

The question is, "Which serves the community better, handling this within DMARC or forcing cloud providers to handle it internally?" and that's not a question where the answer is immediately clear. We know from private-channel experience that almost nobody uses this kind of option, and that people who try to often discover belatedly that they don't consistently get a double-pass everywhere they care about and back off. So there is some reason to believe that it is marginally useful and noticeably dangerous.

If it's really cheap to implement, or it's more useful than previously believed, because there's some large class of people who don't use private channel but have a phishing problem, then maybe it's worth giving people more chances to get things wrong. But accidentally blocking mail is the main failure mode of this kind of standard, so that's pretty intimidating. And not getting widespread, interoperable implementation is another big failure mode, and anything that complicates implementation also risks that. 

So there's a pretty high barrier to surmount in adding this kind of option. 

	Elizabeth