Share with your network!
Email is a remarkably resilient technology. For the number of times we've heard pundits claim "email is dead" upon the advent of SMS, IM, Myspace or Facebook, it remains an underpinning of communication online. You can't get a Facebook or Gmail account without some other permanent email address, so I don't think email is going anywhere.
It also continues to evolve, taking on new and important capabilities. Over 15 years ago it added MIME, which enables one to send more than just plain text through email; nowadays photos, movies, or even entire CD or DVD images can be mailed around in ways that easily transit various gateways.
As I've written before, an important evolution has been DomainKeys Identified Mail, or DKIM. This newest invention gives one the ability to attach a domain name to a piece of email in a way that can't be falsified, which will give rise to powerful new reputation and anti-fraud technologies. This will be especially valuable as we make the transition to IPv6, where the future of Realtime Block Lists (RBLs) is uncertain.
On the surface, DKIM has a simple task to do, but to do so in a highly variable environment means its mechanics are complicated. It's easy to get the details of it wrong, which creates a need for a very strong and precise specification so that implementers and users alike can deploy and use it correctly, and to maximum effect. Although the working group has done a very good and thorough job on the DKIM specification, unfortunately some public commentary about it shows that there are parts of the technology community that are still in the dark.
DKIM can be thought of as a layer of authentication on top of email, just like HTTP is a method of transport for web pages on top of TCP; the lower layers don't know how the data they transport will be used, and the higher layers don't know the nitty-gritty about how the data got there. That's well-established systems and software design practice. To assert that DKIM needs to enforce the rules of the lower layers breaks this paradigm. On top of that, the problem being asserted in that blog exists even in email that doesn't use DKIM, such as Mailman or any other piece of software that only looks at one From: field in a message. So how is it legitimate to call this a flaw in DKIM? There's no doubt that the attack described is a legitimate concern, but DKIM is absolutely the wrong place to fix it.
Several other issues with that blog post can be found in a recent post by Dave Crocker on CircleID, which will hopefully help set the record straight. Links to other rebuttals can be found in the comments there.
With this exciting new technology (and one we really need) making its way into the mainstream to improve the email ecosystem, unwarranted fear and doubt can only serve to impede success and leave parts of the community behind.