At the core of the Internet email ecosystem is SMTP. The growth in spamming in recent times has brought into short focus the limitations of the protocol. News.com recently wrote about an ongoing discussion on replacing SMTP:
Developed when the Internet was used almost exclusively by academics, the Simple Mail Transfer Protocol, or SMTP, assumes that you are who you say you are. SMTP makes that assumption because it doesn’t suspect that you’re sending a Trojan horse virus, posing as a relative of a deposed African dictator to make fraudulent pleas for money, or hijacking somebody else’s computer to send tens of millions of ads for herbal ViagraAt issue is the protocol’s lack of a comprehensive way of verifying an e-mail sender’s identity. This makes it easy for people to mask their identities by forging return addresses and taking over victim machines to conduct their activities.
Some say rewriting SMTP from the ground up would be prohibitively difficult because of the protocol’s global user base, which is estimated to be in the hundreds of millions. “The difficulty of changing the transfer technology as a way of managing unsolicited bulk e-mail is the installed base,” said Rodney Tillotson, the chair of the Anti-Spam Working Group for the Reseaux IP Europeens (RIPE), a consortium of European Internet service providers.
“There are thousands or millions of SMTP servers transferring and delivering mail, and getting them all changed will take years, during which time the (unsolicited bulk e-mail) problem probably remains unsolved,” Tillotson said. “Proposals requiring a change to desktop mail software are even harder to deploy.”
Sluizer counters this by suggesting two protocols–SMTP and a new one, with tighter authentication–could easily coexist, with e-mail applications supporting both side by side. In that way, people using one protocol would not be prevented from exchanging mail with those using another.
Eric Rescorla does not see the need to change SMTP:
One of the many ideas proffered for stopping spam is to require positive authentication for every email message sent. This would have a number of benefits:
1. Make forgery much more difficult, thus making it easier to track down spammers.
2. Allow the maintenance of black lists of known spammers.
3. Allow readers to use white lists of people known to send legitimate mail. (This doesn’t work currently because email addresses are often forged).The bad news, however, is that authentication probably won’t work, for three very important reasons:
1. In this context, authentication probably means cryptographic authentication. This means issuing certificates (or something like them) to every mail sender in the network. This is another case of assuming you have a can opener.
2. Since spam zombies are now taking control of legitimate user’s machines, they will be able to send mail as those users, which will make any authentication system pretty much irrelevant.
3. Because of relaying, it’s very difficult to figure out whether any given machine is a legitimate sender of mail for a given address. For instance, how do you know that foo.isp.com is a legitimate source of mail from ekr@rescorla.com?Due to these difficulties, full email authentication is probably a non-starter. It gets brought up pretty much every time stopping spam is mentioned, but noone really knows how to deploy it.
What does this mean for SMTP?
You may have noticed that of the three reasons I just gave, only one (relaying) has anything to do with SMTP and even that is a topological feature of the Internet rather than SMTP proper. We could perfectly well ban or restrict relaying and SMTP would continue to serve perfectly well–provided that we got the topology right so that mail could still be delivered, but that’s not an SMTP issue either.The truth of the matter is that not only is it trivial to retrofit SMTP to add server authentication, it’s already been done. RFC 2246 describes how to use TLS with SMTP. The only problem is that due to points (1) and (3) above, noone has appropriate certificates to authenticate with and so its mostly used for confidentiality (data secrecy) not authentication. But remember that that’s not a problem with SMTP either.
As far as I know (and I’m pretty close to this) there’s basically nothing that people have proposed as an anti-spam measure that SMTP can’t easily be modified to do. The movement to ditch SMTP strikes me as more of a howl of frustration at our collective inability to deal with spam than an actual reasoned argument for change.
Tomorrow: Solution Ideas (continued)
TECH TALK The Death and Rebirth of Email+T
