What Ever Happened to ADSP?
The January/February 2011 issue of IEEE Internet Computing includes a “Point and Counterpoint” article about ADSP, written by two of the leading authorities on the topic and edited by a third. I’m somewhat amused to realize that I agree wholeheartedly with both sides.
The Author Domain Signing Practices (ADSP) RFC describes a way to tie the DKIM signing (d=) domain with the domain in the email address in the From: header of a message (also known as the “author domain.”) To create that connection, a domain owner publishes an ADSP record in DNS, containing a policy statement about the mail sent from that domain. A policy of “all” is intended to convey to receiving systems that all of their mail is signed with DKIM, but does not make any request about what to do with unsigned mail. A policy of “discardable” requests that unsigned messages be discarded — dropped, deleted, dumped in the trash, too dangerous to show to users.
(We’ve previously described ADSP on this blog in Searching for Truth in DKIM: Part 2 of 5.)
The “point” side of the argument was written by Mike Thomas, who compared ADSP’s “discardable” option to the infamous Tylenol recall in 1982. “In the Tylenol case,” he wrote, “the originator made a strong statement that safety is a great concern and caution is paramount” and told people to throw away any pills from the suspect batches. Similarly, when a domain owner feels that safety is a great concern for their email, Thomas says the same principle applies: by providing “powerful guidance” that “the email should’ve been signed at one time” (via either “discardable” or “all” policies) the spam filters have more knowledge, and thus can be more effective.
Dave Crocker’s “counterpoint” suggests that the benefit is “narrow, derivative, and possibly only short-term” because it is “predicated on soft assumptions and hard limitations.” The soft assumption is that spoofing of the email address in the From: header is “essential — or even particularly helpful — for email abuse to succeed.” The hard limitation, Crocker explains, is that an ADSP statement “imposes processing path limitations” — in other words, email can’t freely travel as many legitimate paths as it does today.
Crocker agrees with Mike Thomas that the appeal of ADSP is partly “the general hope that publishing specific information” will help to “distinguish legitimate senders from bad actors,” and he recognizes that ADSP is “partly based on a specific, powerful, deployed example” involving some of “the largest phishing targets on the Internet.” But he asks whether this large-scale example will “generalize to the broader Internet, to be used without prior arrangement between senders and receivers.”
It’s a valid question. Many mailbox providers are concerned about liability and expectations: they know they’ll be blamed by their users and even by senders when a senders’ ADSP policy leads to a legitimate (but unsigned) message being discarded. They’re also concerned that they’ll be expected to provide technical support for every mail operator who wants to use ADSP. Similarly, those same mail operators — whether senders of bulk marketing email, enterprise Exchange administrators, or mailbox providers themselves — are worried that there may be mail streams that aren’t applying DKIM correctly, or aren’t authenticating at all. And so far, these concerns have resulted in very few domains publishing ADSP records.
Similar conversations have been talking place in various corners of the email industry since before ADSP was standardized. Some commonly requested additions include the ability to have a domain’s ADSP record apply to all subdomains, including subdomains which don’t exist in DNS. Some people want SPF to be mixed in, with all the additional complexity. And there are often calls for other types of policies besides “all” and “discardable”: perhaps a policy that would place non-conforming messages into a spam quarantine. I’ve even heard some desire for the policy to apply randomly to a stated percentage of the mail, which would allow a slow rollout but make debugging difficult. And, of course, there are the usual calls for guaranteed inbox placement (yawn.)
Even with all of those concerns, ADSP records are being checked by Google and even Microsoft, along with many smaller operators.
In the IEEE Internet Computing article Thomas and Crocker both agree that ADSP is, as Thomas described it, “one mechanism in a much, much larger picture of ensuring safety in today’s email streams.” We respectfully submit that another necessary safety mechanism is a tool allowing senders of all kinds to audit the authentication applied to their mail streams — a tool we call the Domain Assurance Dashboard. By aggregating real-world data from major ISPs, this dashboard makes it easier to monitor all of your mail, and provides quick visibility into phishing or spoofing attacks.
By working with those same ISPs, mailbox providers, and filtering companies — including Google, Yahoo!, Tucows, Cloudmark, and others — the Domain Assurance Registry can communicate more detailed and dynamic information about signing practices and desired results than ADSP alone. We’ve added support for SPF, for subdomains, and for a few additional policy statements that the mailbox providers are okay with (no false promises here.)
In time, a successor to the ADSP standard could be developed which includes this same information — and we’ll support it. But why wait? Your customers are getting phished now. We’d like to help you keep the bad stuff out of their inboxes, and let only the good and true stuff in. Contact us for more information, and be sure to mention this article.