Let's Get Rid of Electronic Mail, Once and for All

by Andy Oram

Email protocols are older than gopher or archie. They're ill-suited for multimedia communication, a burden on the network when used to broadcast information, and a mess to manage. But most of us use email more than all other online services put together. Can't the computer field do better by now?

If you have an in with the Internet Engineering Task Force, or with VCs handing out million-dollar checks to dot-commers, I'd like to present you with a challenge: Create new, standard protocols and services that eliminate all the frustrations we currently experience with email.

Of course, email has evolved over the years to meet user demand. But each step forward makes one pine (no pun intended) for a more robust system that provides everything we want now and makes it easy for even an eight-year-old newbie to use:

  • MIME is a wonderful extension that can be used to create beautiful combinations of any recognizable data types. But the process of creating and attaching documents still seems cobbled together.

  • The silly waste of data replication (where somebody sends an enormous spreadsheet to 300 recipients and each one stores it on his or her PC) can be solved by putting the document on a Web site and sending a URL, which many mailers automatically render as a clickable link. But the system works only if the sender has easy access to a Web server--everybody else is still contributing to disk sales.

  • With a little effort you can encrypt your email and thumb your nose at the U.S. Commerce Department. Even electronic signatures are making commercial and legislative progress. But we're far from having standards, not to mention off-the-shelf products. And the encryption is an afterthought, which does not make for robust security.

  • Mailing lists are really impressive when you think of them in computer- science terms: a channel for multiperson-to-multiperson communication that each participant can enter and leave at will. But setting one up requires permissions on a mail server. And respect for the different software capabilities of users reduces the different types of traffic to the lowest common denominator.

What would be a better system? Don't ask too much from me; I'm no business-solutions analyst. All I can do is push a bit further ahead, looking at the directions email is moving (based on extensions such as the ones I just listed), other popular services, and experimental multi-user environments. (We have a book about how to build modest systems of that type: Practical Internet Groupware.)

Somebody more visionary than I might design a system that lasts decades longer than what I'm suggesting. Remember, I'm not trying to design the ultimate communications service to last till the end of time; I'm just looking for something that does the kind of small, one-to-one or many-to-many communications we do now with email. As a minimum, we could have a system supporting:

More efficient delivery
How can we still be using store-and-forward technology in an age of emerging real-time QOS [Quality of Service]? Store-and-forward means a lot of junk traveling a lot of links. Yes, there are nice things about it; it's very reliable in an environment where so many systems are poorly configured. You can sleep well knowing that if fire ants eat through a cable in the middle of the country and disconnect millions of Internet users, your mail will still be on a server somewhere waiting to be delivered when service is restored a couple days later. But I bet we could get just as good service by taking the intelligence out of the intermediate servers (That's the trend on the Internet; read The Rise of the Stupid Network) and putting it at the end-users' software. Just consider: If you find out your mail can't be delivered for two days, you may want to cancel or update it. In general, it would be nice to apply all the research being done on multicasting to our everyday exchanges.

Seamless tunneling, encryption, and validation
Some of these requirements go far beyond protocols, of course--they require a whole infrastructure of certificate authorities--but that's not much harder than providing reliable Internet service. This is the age where the Internet is supposed to be driven by commerce, isn't it? With secure dating, non-repudiation, and all the other benefits of encrypted communications, why can't anyone who signs up for an Internet connection get automatic end-to-end security? Government fussing and FUD [fear, uncertainty, doubt] got in the way for a long time, but now that the industry is prying government's fingers off of encryption technology it's high time to secure the whole channel.

Electronically signed communication assumes the presence of responsible, collaborating correspondents and rules out anonymity. I think anonymity is valuable and should be provided through other channels, but we don't need it for email or for the replacement I'm asking for here.

If we're securing communications, we have to allow systems where the owner of the system has access to keys. I'm not talking about key escrow, an unworkable and intrusive idea, but something as simple as making an employer the certificate authority for all its employees. Everybody cares about privacy, and laws limiting corporate snooping on employees are well worth consideration, but we have to accept that sometimes a company has to decrypt a message sent by an employee. And I think it's reasonable for government agencies to know what their employees are saying too, so they can catch future Oliver Norths making foreign policy on their own.

Effortless switching between media and channels
Wouldn't it be nice if the most casual user could send an email saying, "Join this forum if you'd like to continue the discussion" or even "Click here to open a channel for real-time communication with me" and have all the switches take place with hardly any effort?

Versioning and editorial control
Everybody's done something like send out a long email inviting people to an event and then find they have to send a second email saying, "I gave you the wrong phone number, here's the right one..." Instead of keeping a message with the wrong information, it would be nice if you could send the second message as an edit to the first one and let people apply the edit automatically. At the same time, some part of the system would have to keep a memory of the old message. Otherwise, someone could needle an enemy by sending a nasty or misleading message, and then change it and refuse to admit the original had ever been sent. The possibilities for confusion and abuse, along with the implicit archiving requirement, probably make versioning unfeasible.

Well, that's just a start, a taste of what we could achieve. If you're interested in this topic, guess how you can get in touch with me? That's right, email. Put "Eliminate email" in the subject line, please.