End users have it easy with spam. They only have to delete a few hundred messages a day. For real spam misery, try being a network or e-mail administrator, with tens of thousands of daily spam messages clogging up your network pipes or mail server's storage.
Fortunately, an old approach, mail server authentication, which has often been suggested to stop spam, may be making a return in a variety of new forms. The tack is to modify how Simple Mail Transport Protocol (SMTP) works.
Today, when a mail server gets a message from any SMTP client, it passes it on to its destination without bothering to check if the user or domain is legitimate. It's that very trick that worms like MyDoom, Gibe, and Netsky use to turn infected systems into spam-generating machines.
SMTP's other problem, as anyone who has ever received spam from what appeared to be a friend knows, is that it doesn't do a decent job of stopping spammers from spoofing (aka forging) e-mail headers. Besides making you open messages you otherwise would never have touched, it's this security hole that makes phishing messages (e-mails that appear to be from companies you deal asking for personal information) the bane of naïve users today.
So what can you do about it? Well, some have suggested that SMTP, which was written in an era when all computers were trusted, simply be dumped and replaced. While this is an interesting notion, it hardly seems likely to happen, given that SMTP has displaced all other would-be popular Internet-level mail protocols such as X.400. For better or worse, it's an SMTP world.
There have also been attempts to modify SMTP. For example, there is already an Internet Engineering Task Force (IETF) SMTP over SSL/TLS protocol Request for Comment (RFC) - 2821. However, using this (or other such methods) requires that servers, if not users, be authenticated as being legit by some third-party directory service.
Other approaches, such as RFC-2015, would use MIME Security with Pretty Good Privacy (PGP) for authentication. Until recently, these ideas got more lip service than practice, but now major companies like Microsoft, Sendmail, and Yahoo are moving in the authentication direction.
Sendmail, which claims that its self-named e-mail server is used by seven of the Fortune Top Ten companies, will work on developing and distributing sender authentication technologies. This doesn't mean, however, that Sendmail will be creating its own authentication scheme. Instead, Sendmail appears to be looking towards Yahoo's DomainKeys and Microsoft's "Caller ID for E-Mail."
DomainKeys would incorporate a public-key authentication system on top of SMTP. This would work by having each message be digitally "signed" with a digital signature and public key for each domain. On the other side, the receiving e-mail system uses the public key to validate the signature. Since this signature is incorporated as a new header, and SMTP can already handle such headers, mail administrators would not have to update their mail servers.
They would, however, have to use a preprocessing program or an add-on to their existing mail server in order to authenticate these signatures. In addition, as with any public key encryption system, this system would require a trusted third-party directory system to ensure that the keys are authenticated.
All this puts more of a load on the mail server. On the other hand, the overall load on the mail server and network should be reduced since it will no longer be at the mercy of having to send on much bulkier spam messages. Another plus for this method is that it requires absolutely nothing from end users.
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.