Apr 12

Stopping Spam

By Larry J. Seltzer

If you look carefully at messages containing spam and e-mail worms, you see some things that aren’t right. In almost every case, the addressing information that accompanies any such e-mail message is fraudulent. (For more information see “Heading Off Spam”.) This is an important characteristic of these messages—and a big part of what allows them to spread so far and be so resistant to defensive measures. A solution is on the way, but it won’t come easily.

The solution is SMTP authentication. The idea is that when one mail server receives a message from another, there should be some mechanism for confirming the sender’s identity. That wouldn’t put an absolute end to spam and e-mail worms, but it would put considerable hurdles in their path. It would make effective blacklisting practical, and it would stop the existing, endemic population of worms from spreading.

Heading Off Spam

Why hasn’t this happened already? There are a number of proposals in various stages of development, but progress in so fundamental an area takes time. More important, perhaps, is that implementing SMTP authentication would almost certainly require every e-mail server on the Internet to be upgraded and thus would cause considerable disruption and expense—even if the implementation is free of intellectual-property entanglements and direct cost.

Many mail servers out there haven’t been upgraded in years. It may be impossible to change some, such as those in appliances, and those will need to be replaced. SMTP authentication requires nothing of the end user, though, which is one of the factors that make it so appealing.

Most SMTP authentication schemes take a somewhat similar approach: The DNS administrator of the domain where the mail server is located must publish information that allows external users to confirm the identity of the domain’s mail servers. There are a number of ways to do this. With most of them, the recipient server can confirm that a message purporting to come from user@domain.com in fact does come from domain.com. Whether the message actually came from the specified user is a matter for the domain.com administrators to enforce.

This last point is important: For SMTP authentication to work properly, SMTP software and administrators will have to tighten procedures. For instance, open relays—which are mail servers that allow anyone to connect and send mail through them—will have to be eliminated, so users will be forced to log on to the server if they want to send mail.

Other security improvements are also necessary. Trivial passwords, like password or the same value as the username, need to be banned, or worms will guess at the values. For the same reason, servers will need to disable accounts if a specified consecutive number of wrong guesses at log-on are attempted. Practices such as these are common in other network log-on scenarios.

Beyond security, we can expect other problems with SMTP authentication. Many of the proposed schemes break mail forwarding, which allows one address to forward mail to another. Instead, servers will have to remail each message.

By the same token, many roaming users will have problems, for instance with sending mail “from” their corporate accounts using separate ISP accounts. Such users will probably need to use VPNs.

SMTP authentication will also mess with those E-mail This Page links on many Web pages. Usually such features will send an e-mail from your address to someone else’s address. With authentication, the message will have to come from a domain controlled by the Web site.

The most mature authentication scheme is SPF (Sender Policy Framework, http://spf.pobox.com), which was published as an Internet Draft on February 11.

Put very simply, with SPF the site advertises data in its DNS server, and other mail servers can use the data to confirm that a message sent from that server actually comes from the domain it claims to come from. Quite a few systems have begun implementing this scheme. As of February 10, 6,708 domains had put SPF records in their DNSs, including aol.com, gnu.org, google.com, symantec.com, ticketmaster.com, and w3.org. Deersoft will use SPF in Version 2.70 of SpamAssassin, and Sophos plans to support SPF in upcoming releases of its antispam product PureMessage.

Since SPF works by checking the addresses of mail servers, it is subject to the problems noted above, such as breaking message forwarding and inconveniencing traveling users. There are workarounds for these problems, and even if they require changes in the mail server, that’s not a big deal, since the mail server will have to change in order to support SPF anyway. Free tools are available to help you to implement SPF on your own site, including a wizard that builds the DNS entries.

Yahoo!’s Domain Keys proposal, announced several months ago but not revealed in detail, takes the idea of authentication to the next level. Instead of working with IP addresses, Domain Keys works with public-key encryption. The sending mail server signs each message using its private key and includes the signature in a special message header. Recipient mail servers can retrieve the sender’s public key from the DNS to confirm the signature. In fact, with Domain Keys a domain can have many public/private key combinations for various purposes, such as supporting subdomains or even different keys for different users.

DNS Security Extensions (DNSSEC) also works with public-key encryption and, much like Domain Keys, allows mail servers to sign some portion of each message with a private key and allow outsiders to authenticate the signature with the public key. If the signatures match, the message’s origin is authenticated; if not, the message is suspicious. But DNSSEC itself may not be secure and may introduce other problems. It’s a controversial spec that has been in the works for over ten years, held up both by the problems it would create and by inertia.

Several other proposals are out there in various stages of development and neglect. Two of them, Remote Mail Exchange (RMX) and Designated Mailer Protocol (DMP), were scavenged to create SPF. The RMX spec creates a new RMX record type for the DNS, which in turn requires upgrades to DNS. RMX is more ambitious than SPF, in that it aims to authorize not just domains but e-mail addresses. DMP is still alive too, and claims it doesn’t break mail forwarding. Neither has a practical implementation yet.

Authenticated Mail Transfer Protocol (AMTP) is different from the others. It actually replaces SMTP by creating a secure connection between mail servers, using Transport Layer Security (TLS) and X.509 certificates. The specification is still in development.

Faced with SMTP authentication, what could a worm author do? The worm would have to send mail from the same domain as the mail server to which it connects. Then it would have to trick the user’s mail client into sending the message or sniff the log-on credentials from the network. Neither option is easy, and in both cases the worm would be sent from the actual user’s address.

We feel SMTP authentication has a reasonable chance of success only if the major mail providers—principally AOL, Microsoft, and Yahoo!—agree on one proposal and give a date beyond which they will either reject or tag unauthenticated mail. SPF is the clear candidate for that proposal. They need to move quickly before spam overwhelms us.

Leave a Reply