Probably the single biggest news out of last weeks RSA conference was Microsofts announcement of its Caller ID for E-Mail standard. Caller ID may be the third of the three major proposals that have been announced, but now that Microsoft has put its cards on the table, a great experiment will begin. Over the next year or so, the big players in e-mail—ISPs, software vendors, major corporate users and the government—will see which of them works best.
The three major proposals are SPF, Caller ID and Yahoos Domain Keys. SPF is actually up and running, with (as of Feb. 27) 7,957 domains registered as implementing it (although a large number of those appear to be parked, inactive domains). Caller ID is starting to roll out as Microsoft sets up the Hotmail servers to support it for outbound mail. Hotmail will begin checking inbound mail for Caller ID this summer, while other major companies, including Amazon.com and Brightmail, have agreed to test it too. Domain Keys, to be honest, hasnt even been officially announced, although Yahoo has conducted private briefings all over the place and Sendmail, the famous mail server company, has announced it is working on support for it.
This isnt like three brands of bleach, where youve got the same chemicals in all three bottles. In fact, the more you look at these standards, the more different they look. I had been fearful that having three major standards competing would be discouraging to the market, since explaining even one of them isnt easy. And consider that the three major mail providers in the United States—AOL, Yahoo! and Microsoft—are implementing the three different standards. I think, however, that the three, or at least two of them, could complement each other. The ideal solution may be all three, or some later standard that combines the features of two or three.
I also think that the vendors involved in these standards arent necessarily going to be hardcore proprietary about their proposals. AOL, which has implemented SPF for outside users to confirm AOLs mail servers (inbound AOL mail doesnt check SPF though), tells me they view this implementation as an experiment. They are not committed to SPF. But the dual problems of spam and e-mail worms had gotten so bad, and SPF was the most mature of authentication standards, that they moved on to the test phase. If some other standard, or combination of standards, proves more effective, AOL wont have a problem implementing it.
Vendor Attitudes
Meng Wong, the chief designer of the SPF spec, recently posted part of his discussions with Microsoft prior to Microsoft deciding to go it alone with Caller ID. The discussion basically deals with why they chose to use XML for their encoding as opposed to a more terse custom format like SPFs. From this and other sources Im sure Microsoft seriously considered all the possibilities before coming out with Caller ID. If you want to assume Microsoft is stupid, go right ahead (Meng Wong believes emphatically that they are
At first glance, Caller ID and SPF have a lot in common, but theres an important and fundamental difference between them. Nothing to do with XML encoding; thats an interesting argument, but not all that important. The real difference is that SPF checks only the SMTP envelope address, whereas Caller ID reads the actual message in order to examine the headers.
The envelope is a prefix of sorts to an SMTP mail message. It just gives the address of who the message is from (the SMTP “MAIL FROM:” command) and who it is to (the “RCPT TO:” command). These are not the same addresses that the user sees in the From: and To: lines, but they do govern the address to which the mail server sends a “bounce” message in case the send fails.
One might ask: Dont spammers forge both the envelope sender and the From: address in the headers? They almost certainly do. But a phishing attacker could use a legitimate envelope address and false headers could slip through SPF. This was the main motivation for Microsoft going beyond SPFs envelope examination to full header analysis.
Its not something to do capriciously. All else being equal, SPF would be desirable because it should perform better. All it needs to check is the envelope, and it can reject messages without having to receive any of the headers or data. Caller ID and Domain Keys need to read it all.
But then Caller ID has the job of determining from the headers what they call the purported responsible address. I wont explain the algorithm for it here; see the spec itself, section 3.2 –
Its possible Microsoft has other motivations for digging into message headers, especially when you consider the policy framework they are building to manage this data. Perhaps there are more opportunities to sell development and management tools with Caller ID than with the alternative approaches. Clearly you would want the opportunity to do what Caller ID does if you could be sure it was reliable. But if it doesnt work well, well soon find out, since both spammers and customers will certainly beat on it as hard as they can over the next few months.
I Like Domain Keys
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
More from Larry Seltzer
