Building a Policy Layer upon DKIM
by J.D. Falk
Director of Product Strategy
If you’ve read the IETF DKIM mailing list in recent months, you may get the idea that DKIM is fatally flawed, that ADSP is an affront to all that is good and holy on these here internets, or perhaps simply that some people have way too much time to argue.
Truth is, the applicability of ADSP is extremely limited. The vast majority of domains will never use it, and the vast majority of operators will see no value in it. But there are a few scenarios where implementation of an ADSP policy of “all” or “discardable” does make sense — and those account for a lot of mail that recipients really do want to receive.
ADSP — which stands for Author Domain Signing Policy, defined in RFC 5617 — is a way for domain owners to add a simple policy statement which receivers can consider when validating DKIM signatures. It applies only when the author domain, which is the domain name in the From: header of the message, is the same as the signing (d=) domain in the DKIM signature. This sets it apart from the more general DKIM scenario, where the author domain and signing domain can be different.
In an ADSP record, the domain owner can state “dkim=all”, which means they sign all the mail they care about. It’s still unclear what that’ll trigger on the receiving end. More interesting is a policy of “dkim=discardable”, which means they sign all the mail they care about and would prefer if receiving sites discard (throw away) any mail with that author domain which is not signed.
So the most basic questions for a domain owner who is considering publishing an ADSP record are:
1. Do you have control over all legitimate uses of the Author Domain? Are you sure there isn’t a branch office in Toledo still using their own Exchange 2003 server in the broom closet? If not, you do not want to publish a “discardable” policy.
2. Do you prefer for all mail to be delivered (and accept the possibility that some of that mail may be forged), or for potentially forged mail to be thrown away (and accept the possibility that some legitimate mail may appear forged)? If the former, you do not want to use discardable. If the latter, then a “discardable” policy is (probably) perfect for you.
As you might imagine, ADSP discardable is perfect for banks and e-commerce sites where there’s a major, obvious downside to even one forged phishing message arriving in a user’s inbox. For other scenarios, including most marketing email, deliverability is often seen as more important than security.
Much of the arguing on the IETF DKIM list (and elsewhere) is because there’s also a strong desire for a domain owner to be able to state “I sign all of my mail, and my ESP is allowed to sign some too.” Or “I sign all of my mail, but some of my users participate in discussion lists at these other domains.” All of these refer to what are commonly called “3rd party” signatures, and involve business or social relationships which we’re all used to, but would be very difficult to express in a simple policy statement. (1st party is the author, 2nd party is the recipient, 3rd party is anyone else.)
ADSP was quite intentionally written to address easier problems first, with the assumption that other drafts would explore the issues of 3rd party signing at some point in the future. There’ve been a few other proposals made, and it’s likely that eventually one of them will gain consensus. The toughest hurdle for any of these proposals to pass is that they have to either work for, or have absolutely no impact upon, nearly all possible email transactions. That’s why ADSP only applies to this single, easily defined scenario: d= and author domain must match, and the domain owner must sign all mail to use the “discardable” policy.
Standards work takes a while, especially when it involves drastic changes to the way we think about ancient technologies like email. DKIM and ADSP aren’t just cute new features; in a lot of ways they require a complete re-imagining of email. The author domain has never actually mattered this much before. These continuing discussions would all be helped greatly if there were more real-world examples of implementations that actually work and have worked, and can be proven to interoperate, but so far very few large-scale mail operators have been willing to risk it.
So instead, we’re doing that testing with Return Path’s Domain Assurance product. Part of Domain Assurance is a registry of domains equivalent to the ADSP discardable assertion, backed up by Return Path vouchsafing that the domain owner has access to tools and can make sure that they really are signing every message they care about. This registry may eventually be supplanted by ADSP or other policy records, but the auditing and takedown tools will still be necessary for domain owners to ensure that they’re still signing everything they care about — and be alerted when they’re not. Even if ADSP never takes off, staying stuck in the arguments forever, there’s still a great need for domain owners to be able to publish a “discardable” policy — and a great desire amongst our partner ISPs to have some reassurance that they can safely reject unauthenticated mail which purports to be from highly phished domains.
In the meantime, the standards discussions continue. A handful of us have been discussing additional policy statements, building from ADSP based on things we’ve already learned while discussing implementation options for Domain Assurance and similar initiatives. We’ll expand on the idea of a trusted party like Return Path saying “yes, this domain owner knows what they’re doing, their policy statement is valid.” A few others are working on other ideas. This is standards evolution in action — quite a bit faster than usual.
Not too many more years from now, the trust overlay for email — which starts with DKIM and SPF, but certainly doesn’t end there — will look very different. It’s an exciting time to be an email technologist.