Published on
O'Reilly (http://oreilly.com/)
See this if you're having trouble printing code examples
Let's Get Rid of Electronic Mail, Once and for All
by Andy Oram
01/01/2000
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.
Copyright © 2009 O'Reilly Media, Inc.