DKIM History, Progress, and Future
We’ve written about DKIM many times; if you’re new to the topic or need a refresher, there’s a long list of relevant articles here.
This week the IETF DKIM Working Group officially concluded, after publishing a final few documents and updates. I can’t help thinking back to the meetings where I first heard about DKIM, and DomainKeys before it. Nobody’s written a definitive history of the work, but the participants are still around — most, like me, are still in the industry, though many of us have changed jobs over the years.
It started with a historic meeting in 2003, when AOL, Earthlink, Microsoft (where I worked at the time), and Yahoo! met to discuss email spam and related abuse. Later, British Telecom and Comcast joined as well. We’d all conversed from time to time over the years, but this was the first formal meeting of what became the Anti-Spam Technical Alliance (ASTA). After ASTA published a set of best practices and technical recommendations in 2004, though, the group eventually fizzled out. Today, those conversations can instead be found at MAAWG.
The ASTA press release included this somewhat cryptic paragraph, which we can now recognize as the first public description of DomainKeys:
“Another approach to sender authentication uses a technology called Content Signing (CS). CS systems use public/private key pairs to generate the signatures that are used for sender verification. The public keys may be made broadly available through a variety of key exchange mechanisms or via publication in a directory or in DNS. The private keys are stored securely on the domains mail servers. When a user sends an e-mail message, the mail server uses the stored private key to automatically generate a digital signature for the message. When the recipients mail server receives the e-mail message, it retrieves the senders public key and uses it to verify the digital signature in the message. This verifies both the senders identity and the integrity of the message body (that the e-mail content was not modified during delivery).”
In 2004, DomainKeys was being developed and tested within the group following an initial proposal by Mark Delany of Yahoo!. Yet also in 2004, Jim Fenton at Cisco developed Identified Internet Mail, a similar but entirely distinct technology; Cisco was not part of ASTA. As you can imagine, this led to a lot of discussion between the various participants. The press picked up on it, painting it as two big companies competing (and getting other facts wrong as well.) Eventually, a group of IETF email experts split off, took parts of DomainKeys and parts of IIM, and combined them to create DomainKeys Identified Mail (DKIM). (I can’t remember for sure, but I think it was me who came up with the name. If so, that was probably my only important contribution during the early stages.)
On July 9, 2005, draft-allman-dkim-base-00 was submitted to the IETF for discussion and review. It’s interesting to go back and re-read that, and see how little has actually changed — though it’s all described far more clearly now.
Early in 2006, the IETF officially formed the DKIM working group. This week, the group officially ended. Here are some highlights of the DKIM WG’s work over the past five years:
• RFC 4871 (Feb 2007) was the big one, the “base spec” describing in detail what DKIM is and how it works. After a few years of collecting errata, however, 4871 was replaced this month with RFC 6376.
• RFC 5585 (July 2009) provides an overview of DKIM, and how it can fit into a mail system. This is actually the first document most implementors should read.
• RFC 5863 (May 2010) moves from theory into operations, describing key management practices and the like. This is the second document most implementors should read.
• RFC 6377 (Sep 2011) documents best current practices for using DKIM with discussion-style mailing lists, which is way easier than it appears at first.
Though those first meetings are long past and the DKIM working group has concluded, there’s still a lot to do before DKIM lives up to its’ promise. What DKIM does is deceptively simple: it provides a reliable identifier, a generally sufficient way to determine that the entity which sent this message also sent this other message which was signed by the same key. From there, a number of things become possible: giving special treatment (positive or negative) to known domains, or domains with known signing policies; more effective auditing and protection of your own mailstreams, with help from products like Return Path’s Domain Assurance; and eventually, reputation systems based on the DKIM signing domain rather than the last-hop IP address.
There’s already an effort within the IETF to create a new working group to discuss reputation, with domain names as one of the possible types of identifiers. This group won’t try to standardize the reputation calculation algorithms or other “secret sauce”, but will instead focus on the exchange of reputation-related data: the inputs and outputs of the algorithm. Return Path will be participating, of course; we have a lot of experience with reputation data.
It is (still) an exciting time to be working on email technology.