Stop Spam Soon - Page 2
Microsoft's Caller ID for E-Mail
Microsoft's Caller ID would require e-mail senders to publish their MX IP addresses in the DNS in a new format called the Caller ID for E-Mail specification. A receiving mail system would then look at a message to determine which domain sent it, and then check to see if the message's IP address and MX IP address record match. If they match, the message goes out. If they don't, the message is killed off and sent to the big bit bucket in the sky.
There is already a similar approach called Sender Policy Framework (SPF) before the IETF in an experiential RFC. SPF is an extension to SMTP. In it, Mailbox MX (Mail Exchange) Domain Name Server (DNS) records will include SPF protocol information, which is then used to see if the originating message's IP address matches the proper domain name.
SPF's authors, from mail forwarding company Pobox.com, are urging the IETF to immediately adopt SPF. One anti-spam business, CipherTrust Inc., is already using SPF in its products, and other major companies like Symantec are already deploying it. SPF seems to have a groundswell of support from corporate e-mail users. Historically, though, the IETF is loath to quickly make changes to its fundamental protocols.
Microsoft's Caller ID has additional challenges. While it has support from Sendmail and spam prevention companies like BrightMail, it also would include Microsoft-patented technologies and a terse Microsoft Extensible Markup Language (XML) vocabulary. Although Microsoft claims it would make use of these patents free for Caller ID users, many administrators doubt their word. Eben Moglen, law professor at Columbia Law School and General Counsel for the Free Software Foundation, also thinks that the Caller ID's license is incompatible with GPL open source mail servers.
Despite the popularity of Microsoft Exchange and its support from other customers, this may prove fatal to Caller ID. None of these authentication systems will work well unless an overwhelming majority of the e-mail server community adopts it.
Thus, it seems that thanks to the overwhelming spam loads ISPs and businesses are seeing, we will soon see an IETF-blessed authentication scheme that will work with today's SMTP clients and servers. That said, of the three methods, I think SPF, although it hasn't gotten the press of DomainKeys or Caller ID, is likely to be the winner since it doesn't require a public key infrastructure like Yahoo's solution does and it doesn't come with the political baggage of a Microsoft solution.
That we should eventually have an answer that can stop much of today's spam traffic is the good news. The bad news is that no matter what scheme wins in the end, it will be a slow process.
Thus, for now we're going to continue to need to improve our gateway anti-spam programs and wait for the standards tussle to work itself out before our spam traffic starts to drop. Bill Gates is on record as saying that "spam will be solved" by 2006. He may be right; it just probably won't be Microsoft that solves it.
Given, of course, that spammers don't find another way to spam that doesn't rely on unauthorized SMTP clients. But that's a problem for another day. Fixing our current number one source of spam is enough of a problem for today.
Feature courtesy of Enterprise IT Planet.
» See All Articles by Columnist Steven J. Vaughan-Nichols
