eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Its taken so long for e-mail authentication to get to this point that you might assume the whole idea had failed and been forgotten. Not true. The really important work has gone on, out of the spotlight.
Yahoo and Ciscos announcement that they will merge their similar public key cryptography-based specs for authentication is a good example. Yahoo hasnt blabbed about it, but DomainKeys has gained a lot of momentum since its formal announcement late last year. DomainKeys support is available for most, if not all, the major mail servers, and further significant announcements will come in the next few days.
And Microsoft has not sat still with its Sender ID spec, even if the license was widely rejected. (You can assume that the licenses for DomainKeys and the new DomainKeys Identified Mail will not include the poison pills in Microsofts, and will be acceptable to open-source developers.) Microsoft has continued with promised Sender ID development for its own Hotmail and has also added support for Habeas e-mail certification.
All through the contentious and ultimately failed e-mail authentication standards proceedings last year there was an undercurrent of opinion that DomainKeys was the better solution, but an assumption that practical deployment of it was further out than for the alternatives, principally Sender ID. In fact, there were a variety of alternatives discussed in technical circles, but all these months later none of them has any real traction aside from SPF, and no serious people view SPF as a real solution to the problems of e-mail. Even the father of SPF, Meng Weng Wong, founder of pobox.com, worked with Microsoft on Sender ID because SPF didnt address the full range of problems it needed to.
So with a small amount of hesitation I hereby declare DomainKeys—and, by extension, DomainKeys Identified Mail—the winner in the SMTP authentication battle. (I bet you didnt know I had the authority to do that.) But will they win the battle and lose the anti-spam war?
There is still the problem of Sender ID and alternative implementations, and its necessary in the long term for one standard to be dominant. If more than one authentication standard is supported by major players in the world of e-mail and you want your e-mail to authenticate properly, you have to support both standards both inbound and outbound. This could get interesting if the two specs are DomainKeys Identified Mail and Sender ID, since both add a chunk of data in the DNS, and well hear some administrator whining about it all.
But DomainKeys, at least, can clearly work in the real world. Yahoo has been using it on its own servers and claims that it has been “receiving more than 350 million messages signed by DomainKeys per day,” so someone else is using it.
Next page: Reputation is the key.
Reputation is the key
But the real key to authentication isnt the authentication itself, but what that authentication enables for reputation services. After all, authentication just tells you who the sender is (or rather, who their domain is). It doesnt tell you whether the senders mail is worth reading.
This has led to a common misleading story about authentication: that spammers can make it impotent by adopting it. We have read about large numbers of spammers publishing SPF records or DomainKeys records. In fact, by doing this they are playing right into our hands.
In a world of authenticated e-mail the first thing you would do is create a whitelist and populate it with known good senders, probably the contents of your address book; and you might have a blacklist too. But if you dont know about a particular sender you can ask a reputation service. These services track mail senders and information about them.
When you ask the service about sender X you might get back a level of confidence (y%) that the sender is a legit sender or a level of confidence (z%) that it is a spammer. You might get the number of complaints that the service has received about that sender in the last day or week. You might get information about the senders policies and whether the sender observes them. Different reputation services track things differently.
Now that you have the reputation information for the sender you can make a policy decision. If all you do is accept mail from domains that authenticate then youll accept a lot of spam. If a domain doesnt authenticate you can still get reputation information about the IP address of the sender, and you might also decide to distrust the sender because it did not authenticate.
The other trap spammers, phishers and other malefactors fall into by authenticating is to make themselves much easier to track. Once they are identified it becomes easier to shut them down and, even better, sue them. Facilitating litigation against spammers is actually a deliberate goal of the DomainKeys crew.
How can consumers and ISPs and enterprises make sense of a large market of reputation information? One interesting proposal is from Wong. It is a reputation aggregation service called Karma and is still under development.
There are a lot of companies in the reputation business, including Ironport, Cloudmark and Habeas. There are also all the RBLs such as Kelkea and Spamhaus. This latter group has focused on IP address-based information, but theres no reason they couldnt supplement with domain information. An aggregation service like Karma could act as a single point of subscription for users. The more a user pays, the more data goes into the judgment about the sender.
This is a model that could work. Combined with other responsible security policies, such as requiring SMTP AUTH and blocking unrestricted use of port 25 from dynamic addresses, its a model that could make it much harder for spammers and malware authors to deliver their messages. I wont go so far as to state that it will work, but its the best idea Ive seen so far and the only one in which I have any hope.
Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983.
Check out eWEEK.coms for the latest security news, reviews and analysis. And for insights on security coverage around the Web, take a look at eWEEK.com Security Center Editor Larry Seltzers Weblog.
More from Larry Seltzer