If you’re like the majority of Internet users, a good
quantity of your e-mail is junk. Perhaps the amount seems like less
than it actually is thanks to filtering, but it’s still there.
The world is fighting a losing battle with junk e-mail—primarily because
of weaknesses
in the Simple Mail Transfer Protocol (SMTP)
—and everyone knows it.

Many users have given up on traditional e-mail
services entirely, or they’ve switched to alternatives such as Hotmail, Gmail,
Yahoo, or any of the other dozens of free e-mail services. In the corporation and ISP arena, there’s a commercial sector built entirely
on supporting the outdated SMTP protocol, and e-mail
“insecurity” is how these companies make their money.

We haven’t replaced SMTP because the benefit doesn’t
outweigh the profits for either the commercial junk e-mailers or the
e-mail security companies. This isn’t a conspiracy theory—e-mail security is a
multibillion-dollar industry that will go to great lengths to
protect itself, and we can say the same for the junk e-mailers.

A newe-mail protocol that could potentially render
such companies obsolete presents both significant legal and illegal barriers
that any new solution would need to overcome. But would it be worth it? Do we
really need a new e-mail protocol at all?

Methods to mitigate junk e-mail exist, but actual e-mail
servers directly incorporate few, if any, such solutions. One of the more
common methods in use today is the Relay Block List
(RBL) method. While RBLs rely on DNS, which is technically outside
the implementation of SMTP, it’s simple enough to implement that most
open source SMTP implementations support RBL queries.

Another particularly notable method to
reduce junk e-mail is greylisting
,
which returns a “try again” message to the sending SMTP
server. Here’s an oversimplified explanation of how greylisting works: Because
junk e-mail relays typically aren’t e-mail servers themselves,
they don’t process this message correctly and immediately attempt
delivery again, which results in the temporary blocking of sending IP addresses
for an interval of time.

Other methods use slightly different approaches, but they attempt to accomplish the same goals. While these approaches all work to
varying degrees, a motivated spammer can defeat them with enough innovation and
incentive. And, with the exception of RBLs, none of these solutions has seen global adoption because of the complexity of
implementation in the e-mail server itself.

That’s why I think we need a new solution, and I’m working
on it myself. Now, I’ll be the first to admit that I’m not a
“productive” programmer—technically, I’m a systems administrator—because
it’s difficult for me to balance the sometimes competing needs of usability and
security. My bias leans too much toward security.

But since I am able to write software, I’ve decided to take
on a new project: Finding a way to better secure e-mail. Of course, much
smarter people than I have attempted to make SMTP more secure—but none of the
current solutions address the real issue. Despite the fact that e-mail has
become far too useful to simply cast aside, it’s becoming far too costly to
continue with the status quo.

And so, I present to the world my idea for a new e-mail
protocol, which I call the Not So Simple Mail Transfer Protocol (NSSMTP). Let’s
look at what such a protocol needs to be able to accomplish.

First, NSSMTP must remain 100 percent compatible with SMTP,
and we must be able to integrate it into the existing SMTP standard in a
way that won’t affect legitimate e-mail. Remember that millions of
regular Internet users and hundreds, if not thousands, of applications currently
use SMTP. Unless NSSMTP is entirely compatible with SMTP, not only will it simply
not work—it will fail to gain acceptance.

Second, we need to return to the “simple” part of
SMTP’s name. The most easily implemented solution will be the one
that stands the best chance of global adoption and therefore
success.

In addition, NSSMTP needs to be completely
open. We already have far too many proprietary “standards,”and
NSSMTP must be public domain.

When it comes down to it, NSSMTP needs to extend SMTP—much in
the same way authentication and encryption have already extended it—in a
manner that draws on the strengths of all these other methods,
without infringing on any patents. The real question remains: Can
I do it?

Considering that I’m well aware of the current
status of SMTP—including the legal and technical challenges—and
I’m able to write code, why not at least try? Given the current
state of Internet security, particularly when it comes to e-mail, any effort is
better than none at all.

What do you think about the proposed NSSMTP? If you had the
opportunity, which security issue would you most like to develop a solution
for? Share your thoughts in this article’s discussion.

Miss an issue?

Check out the Internet Security Focus
Archive
, and catch up on the most recent editions of Jonathan Yarden’s
column.

Want more advice for
locking down your network? Stay on top of the latest security issues and
industry trends by automatically
signing up for our free Internet Security Focus newsletter
, delivered each
Monday.

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