A lot of people seem to be in a rush to blame the spam deluge on the lack of authentication provided by the venerable Simple Mail Transfer Protocol (SMTP) standard. The truth is, existence of SMTP authentication would, by itself, do almost nothing to alleviate the spam problem. It’s important to understand what SMTP authentication really adds to the equation, how it might be useful in the fight against spam and what are its limitations.
There are two kinds of authentication. One is domain based authentication—a mechanism that connects each sender of an e-mail to his or her domain name. Several such schemes have been proposed recently, most notably Reverse MX and SPF, which provide the recipient with an assurance that the e-mail actually originated from the sender’s domain name. For example, if you receive mail from [email protected], and wonderland.com was participating in one of the domain authentication schemes, you could be sure that her e-mails actually originated from wonderland.com.
The second kind of authentication is identity authentication with digital signatures, in which the sender digitally signs the e-mail such that it can be verified by the recipient with help of sender’s public key. PGP has been used for identity authentication for the last 10 years by the cryptography and security community, but has not been widely integrated into e-mail applications.
Both kind of authentications have one thing in common: they allow us to trust the “From” field. But what would we do next? Should we “whitelist” known correspondents and quarantine the mail from unknown people in a folder labeled something like, “potential spam”? Clearly, that just shifts the problem from Inbox to the “potential spam” folder; we’d still have to sift through the spam to get at legit messages. We could issue challenge/responses to unknown but authenticated senders. Several challenge/response tools exist today (Spam Arrest, Matador, etc.) that respond to unknown senders with a graphical or analytical question to establish they are indeed human (as opposed to spam-spewing automata). Such systems are flawed without authentication, however, since they end up sending challenges to whatever fake address the spammer puts in the From field. Authentication would benefit these systems but challenge/response interactions alter the e-mail experience (and don’t work for mailing lists), and is perhaps the least desired “solution” to spam. We could use network origination information coupled with sender’s e-mail addresses as a vector in a statistical spam filtration system. Cloudmark does this to some extent already and SPF based systems intend to do this as well; the technique turns out to be a decent metric to prioritize and filter e-mail. However, it’s does not “solve” the spam problem better than filtration technologies available today.
