I Like Domain Keys

By Larry Seltzer  |  Posted 2004-03-02 Print this article Print

After reading all three, Im inclined to like Yahoos Domain Keys the best. It does have its downsides; its the most heavyweight for one, adding a fair processing load to outbound mail serving. And then theres the fact that not only has the spec not been made public, but there isnt even a Yahoo press release about it. Certainly its not clear that Domain Keys is a practical solution yet, but if it could be made to work it would be a leap straight into the next generation, without as many of the problems that IP-based solutions create, such as breaking mail forwarding. Domain Keys shouldnt interfere with mail forwarding, and in fact it supports multiple levels of signed messages, so that even if I remail spam to a third party and I authenticate as the sender, the recipient can confirm that the original sender was a spammer. Neat.

And the validity of the signatures and keys in the Domain Keys scheme should be almost beyond reproach. Its not going to be worth the work involved in brute-forcing your way around the cryptography, and even if the keys were compromised it would be a quick matter to regenerate new ones, leaving only the DNS TTL as a variable in recovery. Because DNS is used as the public key repository, theres no need for complicated and expensive certificate authorities. Anyone can generate their own keys using a variety of free tools.

The signature approach takes any uncertainty about the contents of headers out of consideration. Its irrelevant. The signature either matches the key for the appropriate domain or it doesnt. Theres less gray area for policy management than there is with Caller ID, which allows the administrator to handle mail with different degrees of validity in different ways. Domain Keys is black and white.

So it could be that some combination of SPF and one of the alternatives could be the ideal solution. It seems to me that if envelope processing could determine that a message was illegitimate SPF could dispose of it. The ones that validated through SPF could go on to a different type of testing through Caller ID or Domain Keys. This would save a lot of bandwidth by using SPF for pre-screening, and avoid all the extra processing of Caller ID and Domain Keys unless they were necessary. And in the end, the only mail to be subjected to actual spam filtering would likely be genuine. It could change the nature of filtering software a great deal when spam is a rare thing, but thats another column.

In the meantime, the disaster I feared, that of having three important authentication standards in operation, doesnt seem all that horrible anymore. My hope is that mail server vendors will offer support for all of the standards. Were entering a period of experimentation to find out what works best. But it is the case that everyone will have to support all the standards that are left standing when its all over. Otherwise, you wont be able to send mail to their users and receive mail from them. Kind of stupid, since there is a certain level of redundancy, but as long as nobodys a jerk about the intellectual property rights, theres no reason why all of them cant coexist.

If you asked me six months ago how I thought the spam and worm problems would work out, I would confess to being an avowed pessimist. Spam and worms were taking over; only a fundamental change in the structure of Internet e-mail could stop them, and we all knew that wouldnt happen. Good thing I was wrong; it looks like the only question is what changes will happen.

Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983. Be sure to check out eWEEK.coms Security Center at http://security.eweek.com for the latest security news, views and analysis.

Be sure to add Our eWEEK.com Security news feed to your RSS newsreader:
More from Larry Seltzer

Larry Seltzer has been writing software for and English about computers ever since—,much to his own amazement—,he graduated from the University of Pennsylvania in 1983.

He was one of the authors of NPL and NPL-R, fourth-generation languages for microcomputers by the now-defunct DeskTop Software Corporation. (Larry is sad to find absolutely no hits on any of these +products on Google.) His work at Desktop Software included programming the UCSD p-System, a virtual machine-based operating system with portable binaries that pre-dated Java by more than 10 years.

For several years, he wrote corporate software for Mathematica Policy Research (they're still in business!) and Chase Econometrics (not so lucky) before being forcibly thrown into the consulting market. He bummed around the Philadelphia consulting and contract-programming scenes for a year or two before taking a job at NSTL (National Software Testing Labs) developing product tests and managing contract testing for the computer industry, governments and publication.

In 1991 Larry moved to Massachusetts to become Technical Director of PC Week Labs (now eWeek Labs). He moved within Ziff Davis to New York in 1994 to run testing at Windows Sources. In 1995, he became Technical Director for Internet product testing at PC Magazine and stayed there till 1998.

Since then, he has been writing for numerous other publications, including Fortune Small Business, Windows 2000 Magazine (now Windows and .NET Magazine), ZDNet and Sam Whitmore's Media Survey.

Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel