The Internet is now indispensable to business at the cost of Internet abuse. Spam cascaded from an annoying trickle to a raging flood of ads, viruses, spyware, and phishing scams that pour into millions of inboxes everyday all over the world. With upwards of 80% of all e-mail traffic now spam, it's no wonder that organizations worldwide are looking for new ways to eradicate this blight. This article will discuss some of the newer developments in the "battle of the inbox."

E-Mail Authenication: SPF, Sender-ID, DomainKeys and IIM

Like traditional mail, e-mail is supposed to have a return address, often called a "bounce address," where undeliverable e-mail is returned. This address isn't always the same as the address of the author, which is called the "from address," just like in the real world where the return address on the envelope doesn't necessarily match the person who sent it.

Spammers fake these addresses since they don't want to pay for servers to handle all the undeliverable spam they send out, which can be in the millions of messages. Many times they make someone else's address the bounce address and the undeliverable e-mails are sent to some innocent bystander, a situation called a "joe job."

To add insult to injury, the bystander is usually blamed for sending the original spam. Spammers like to fake the "from" address, especially when phishing since it makes the message look more realistic to the unsuspecting.

In many ways, the e-mail system is modeled after the real world postal system. Unfortunately, just like real post offices, the return address isn't verified so spammers can fake the bounce and from addresses.

To combat the problem, several authentication schemes are being developed. The most popular ones are SPF or "Sender Permitted From," now renamed "Sender Policy Framework," (http://spf.pobox.com), Microsoft's Sender-ID (www.microsoft.com/senderid/) and Yahoo's DomainKeys (http://antispam.yahoo.com/domainkeys).

They all operate the same way: Domain name owners publish information about their domains in DNS and e-mail receivers check that information against the e-mail they get. For SPF and Sender-ID the information consists of a list of e-mail servers that are authorized to use the owner's domain in the bounce address (for SPF) or the author's address (for SID). For DomainKeys, domain owners digitally sign outgoing e-mail and publish the corresponding public keys in DNS.

The logic behind these techniques is that by having domain owners publish this information, it prevents anyone else from using their domain names without their permission. Receivers can check whether the information in incoming e-mail matches the data published by the domain owners, and can discard non-matching messages as fake.

Software support for e-mail authentication is sketchy. SPF enjoys the widest support, with implementations available for most major MTAs (http://spf.pobox.com/downloads.html).

DomainKeys implementations are also available for most major e-mail software (http://domainkeys.sourceforge.net/) but unlike SPF, most DomainKeys implementations haven't been widely tested. Support for Sender-ID is very slim; even Microsoft won't support Sender-ID in Exchange until the second half of 2005 (http://blogs.msdn.com/exchange/archive/2004/12/22/330184.aspx).

There's no support for SID in any major MTA software except Sendmail (www.sendmail.net/sid-milter/) partly because of licensing issues with Microsoft patents and the collapse of IETF's standardization efforts.

However, the biggest sticking point is not necessarily lack of software support, but lack of participants. Few domain owners publish any records. Without the participation of domain owners, software support is basically useless.

Another issue is the lack of standardization. And there's no resolution in sight because IETF's MARID working group has disintegrated.

Nevertheless, SPF boasts a following of over 200,000 domains publishing SPF records (http://spftools.infinitepenguins.net/register.php).

While both Sender-ID and DomainKeys don't have many participants, they do have some big names such as AOL and Google publishing records and testing them. But compared to the number of domains and the volume of e-mail traffic on the Internet it's insignificant.

At the same time, significant technical and legal issues surround these schemes. SPF requires major changes in mailing lists and only protects the "bounce address," which is pretty thin. Questions have been raised about possible fatal flaws in Sender-ID's key algorithm. Sender-ID's license and patents have legal problems. Forwarding and mailing lists have to be reconfigured or changed. There's insufficient real-world testing and it's unclear these schemes can stand up outside the lab.

Nevertheless, the implementations that are dribbling out are letting organizations experiment. As field test data increases, it's hoped the flaws and technical problems can be resolved, though no technology is mature enough to be deployed in a production environment without pausing over the potential legal and technical issues. Since the protocols may be tweaked and changed many times before a final standard is set, managers must proceed with caution before spending valuable resources. While organizations may seek to protect themselves and rush to deploy these solutions, they must realize that e-mail authentication is only one step in a larger attack on spam.