E-mail as we know it today is facing certain death. Not at the hands of a newer technology that provides more features, but because the software protocols that drive Internet e-mail today are causing us to be buried in mountains of unwanted e-mail spam.

The twin protocols responsible for sending and receiving most e-mail today, called SMTP and POP, were designed in the early 1980s, when the Internet was a sparsely populated frontier town. Back then, the expense of being online virtually guaranteed good behavior. If you had access to e-mail then, you were probably working in the research community, at a large corporation, or in the defense industry. In other words, if you abused your e-mail privileges, you could kiss your career goodbye. Very few checks were built into the system, because SMTP and POP were designed in a world where trust was assumed.

SMTP is the protocol responsible for delivering e-mail to the recipient’s mail server, while POP is what a recipient uses to fetch e-mail from that server. (IMAP is a newer cousin of POP, but it’s less widely used and suffers from the same security deficiencies as its older relative.)

Both of these protocols were designed to operate independently from one another. If I send you an e-mail through SMTP, unless I’m a spammer, my e-mail address should have a corresponding POP (or IMAP) account associated with it. But spammers exploit the fact that SMTP and POP aren’t tied together.

Spammers are able to utilize bogus addresses because SMTP servers and POP servers don’t talk to each other. As long as the domain name of the sending e-mail address appears legitimate, the SMTP server will gladly accept an e-mail, even though the sending e-mail address might not even exist. That’s because only a sender’s POP server knows whether the sending address is valid, and there’s no way for an SMTP server on the receiving end to query the POP server on the other end. The recipient server can’t determine if the address claiming to be the source actually exists.

Address hijacking is another common problem. I found this out when I started getting bounce messages for e-mails I never sent. On several occasions, some spammer sent out mass mailings using my address. But those e-mails didn’t originate from my server, because the spammer doesn’t know my password. Another server was the source of those e-mails, but there’s no way for the recipient to verify whether the claimed sender was really responsible for them; such a function isn’t built into the protocol.

From a technological standpoint, these problems can be solved relatively easily:

First, the server software that sends e-mail must also be the same software that receives e-mail. By having unified user accounts for both sending and receiving, recipient servers can ensure that sending addresses are valid. Right now, at the protocol level, you can send e-mails to someone without ever logging in anywhere. Requiring sending and receiving servers to be unified will inconvenience many, but it’s the only way to ensure the blocking of messages that aren’t sent from valid accounts.

Second, there needs to be a way for servers to validate messages with one another. The various computer networks that make up the Internet often have segments that, for security and other reasons, can’t talk directly to one another. To allow for such a network design, any e-mail system must allow messages to pass through intermediate servers. But this means that a server can lie about the origin of a message. So e-mails should have embedded fingerprints created in such a way that they can only be validated by the originating server, something that’s possible using public key cryptography. The receiving server can ask the originating server whether a message is legitimate. If the sending address exists but the message doesn’t contain a fingerprint generated by the originating server, the message can be discarded.

Third, mail servers must be tied to valid domain names. If an e-mail is received whose sending server can’t be looked up in the domain name system (DNS), then the mail should be dropped. The domain name system can then have a notion of trust built into it. If domain registrants provide more identification to the registry, if they agree to voice verification by phone to register, they can be assigned a higher level of trust. Spammers are unlikely to reveal too much about themselves, so they would have a lower trust level. Mail servers can then evaluate a domain’s trust level and decide to apply stricter spam filtering to new domains and those that are less trusted. Even without the added notion of trust, requiring valid DNS entries for mail servers raises the costs of moving servers around, something that spammers need to do frequently to stay ahead of spam blacklists. A domain name requirement would also make spam blacklists more effective by giving them more data to use for blocking spammers.

Lastly, home users need to get control over their machines. Insecure operating systems and casual users who run any old program they receive in an attachment are opening up millions of home systems to abuse by spammers. And until that stops, even the most secure e-mail protocol in the world wouldn’t help. Because if spammers control your machine, they can control your e-mail address, and there would be no way to tell which messages were sent by you or by a program on your computer pretending to be you.

None of these ideas would solve the spam problem on their own. But combined, they would make the business of spam far more difficult to sustain in the long run.

Unfortunately, any solution would take years to implement, because it will require the entire Internet switching over to newer protocols. Half-measures have already been tried to fix the inherent deficiencies in the protocols, and spam filters will always be playing catch-up because they can’t anticipate how spammers will adapt in the future.

As disruptive as it’ll be, the change will have to happen. Right now, more than 90% of all Internet e-mails are spam. And as that percentage rises, e-mail as it exists today will become increasingly unusable.

It’s only a matter of time until we finally decide to bury the e-mail protocols we use today. And the sooner it happens, the better.