Making the case for registered e-mail servers
In a recent article, I discussed why Simple Mail Transfer Protocol (SMTP) is becoming more and more obsolete, and I offered my reasons for why the industry should start shopping for a replacement. In the meantime, however, it's not enough to just accept SMTP's shortcomings. In the article, I suggested that the next-best solution would be to adopt a SMTP server registration process. Here's a look at how registered e-mail servers could not only boost security but also help win the war on spam.
It's a rare occurrence, but I occasionally receive a note in my mailbox that someone has sent me registered mail. While registered mail can be a bit of a hassle, I definitely understand its use.
People send registered mail to guarantee that the right person—and that person alone—receives the mail. More important, people are willing to pay more for this guarantee.
Of course, this doesn't stop someone from sending registered junk mail, but the key here is cost. Junk mail is less expensive than a regular piece of mail; that's why there's so much of it. If junk mail were more expensive, it wouldn't exist.
The same goes for unsolicited commercial e-mail (UCE), more commonly known as spam. UCE has become such a problem because the cost of sending millions of e-mails is minimal.
It's the receiver who bears the brunt of the cost of UCE. These associated costs include wasted bandwidth, additional storage requirements, and implementations of filters and other solutions that attempt to prevent the user from having to manually sort through UCE. And some of these solutions present their own problems, not the least of which is the loss of legitimate e-mail.
That's why I believe the industry should consider implementing a procedure for registering e-mail servers, similar to the process for registering domains. Until we've established globally accepted legal penalties for sending UCE, spam will continue. So a global Internet body needs to set the rules.
There are no real standards for filtering UCE and no real way to ensure the separation of UCE from legitimate e-mail. Everyone does it differently, and the only real e-mail standard is Simple Mail Transfer Protocol (SMTP), which really isn't so simple anymore.
SMTP accepts mail from both e-mail clients and e-mail servers, making it easy to send junk e-mail. But we can't throw away SMTP because the alternative--a complete redesign of the globally accepted e-mail protocol--isn't all that feasible.
In my opinion, UCE wouldn't have become such an issue if developers had designed SMTP to work more like registered postal mail. And that's precisely why I think that the only long-term solution is to require the registration of all SMTP servers, by IP address, using a system similar to how root DNS servers operate.
Mail server software might require some modifications for this system to work, but its basis on existing DNS protocol would make those tweaks relatively minor. A simple DNS query would be able to determine if a connecting host were a registered e-mail server. By making the registration process for SMTP servers similar to the process for registering domain names, the same legal oversight would apply, accelerating the imminent discovery and eventual shutdown of rogue SMTP servers.
Right now, we're playing with solutions that still haven't found global acceptance, despite their effectiveness (or perhaps ineffectiveness) to stop UCE. Presently, companies must implement solutions to stop UCE either before accepting the e-mail (when it doesn't know the contents) or after receiving the e-mail (when it's too late).
As the war on spam progresses, I fully expect to see more casualties in the losses of legitimate e-mail and more UCE that infiltrates inboxes. In my opinion, only when an internationally sanctioned Internet body, perhaps ICANN, requires SMTP servers to register in the same manner as domain names will spam cease to be a problem.
Jonathan Yarden is the senior UNIX system administrator, network security manager, and senior software architect for a regional ISP.