Is it time to replace SMTP?

When the industry first adopted the Simple Mail Transfer Protocol (SMTP) as the ubiquitous e-mail transmission standard, we didn't have the Internet security problems that now plague e-mail. Although e-mail chain letters and some minor junk e-mailing surfaced occasionally, the first commonly known unsolicited junk e-mail was actually a mass posting to USENET. The event broke an unwritten rule of the Internet, causing outrage in the then-small Internet community.

But it wasn't long before unsolicited messages evolved into true junk e-mailing. Automated e-mail address harvesters began gathering e-mail addresses from USENET postings, and junk postings eventually killed USENET as an open discussion forum. Previously unmoderated newsgroups found themselves forced into moderating posts in order to stop the flood of advertisements cross-posted to hundreds of popular newsgroups.

When I began using the Internet in 1985, there were a handful of "reference" implementations of the various protocols that enable information flow on the Internet. The de-facto SMTP server implementation of the time was Eric Allman's Sendmail program. (In fact, many still consider Sendmail to be the reference implementation of e-mail.)

But as security problems with Sendmail began to surface, other users began writing their own SMTP server implementations. And as alternatives emerged, Sendmail itself also matured, becoming considerably more secure.

However, regardless of these security improvements, SMTP remains at the heart of our current junk e-mail problems. And in a time when junk e-mail is approaching 90 percent of all e-mail traffic on the Internet, using an obviously outdated e-mail protocol doesn't seem like the best plan.

I can't be the only person who thinks it's time to replace SMTP with a new e-mail protocol standard—or at least stop depending on disparate methods to stop junk e-mail. The prevalence of junk e-mail has created a booming market for a wide variety of products and services for junk e-mail filtering.

Most commercial e-mail server software includes features to stop junk e-mail, as do popular open source SMTP server implementations, including Sendmail, Postfix, and QMail. In addition, several open source junk e-mail filtering solutions are available, such as SpamAssassin, DSPAM, and MailScanner.

So these days, it's more than possible to apply layers of security to SMTP and e-mail to help stem the tide of junk e-mail. But is this really the best solution? And how much longer can we keep adding new layers as new threats emerge?

Replacing SMTP with a newer e-mail protocol will be possible only when the cost of using SMTP exceeds its worth. But that time is coming. We've applied as many Band-Aids as we can and layered as many methods to stop junk e-mail and e-mail worms as possible. And yet, these solutions still aren't addressing the core issue: SMTP has exhausted its usefulness.

The industry needs to recognize this fact and accept that it's time for a replacement. If replacing SMTP isn't a realistic proposal, I think the only viable long-term solution is to adopt a model similar to the method used to obtain a Secure Sockets Layer (SSL) certificate.

An SMTP server registration process would certify that an e-mail server belongs to a specific organization or company. Combine this concept with a forced registration of e-mail servers and a global registry of MD5 hashes of sender/receiver e-mail address pairs (i.e., a global whitelist), and junk e-mail would become impossible.

But when it comes down to it, this predicament really isn't an issue of technology—it's an issue of failing to accept that fixing the problem of junk e-mail will require changing a standard operating procedure for the millions of people who use e-mail. This solution, whatever its potential, would require a massive adjustment from all the users and companies who send e-mail. And that means it likely won't ever see the light of day.

Jonathan Yarden is the senior UNIX system administrator, network security manager, and senior software architect for a regional ISP.