Email: Managing users’ expectations

That email has established itself as a universal communication medium is a credit to all those who contributed to the standards that define its implementation.

Truly, only “www.” is a more familiar as an Internet medium for information exchange and, even then, HTTP is routinely dumbed down to “it’s on my Facebook” and other similar paradigms.   This is not a criticism, it’s a tribute to the Internet’s ongoing integration into our everyday lives.

People seem desperately confused about email.  It’s an aged beast and it suffers from having been reinvented and redefined over a long period of time to meet the demands of a succession of users with different expectation levels.

Stepping back a bit, SMTP  as a protocol was originally designed to be incredibly tolerant of all kinds of problems.  It had to be.  Shonky links, low bandwidth and infrequent network connectivity meant we needed a protocol that could deal with the idea that messages could be significantly delayed.  SMTP has a built in a mechanism for notifying when things aren’t going well, and makes a really good effort to tell a sender that things didn’t work out and the message didn’t make it. Then things changed.

Sending files over the Internet is sometimes hard.  I know!  Let’s extend email so it can transfer files.

Not everyone can type in 7 bit ASCII. I know! Let’s extend email so all character sets can be represented.

Sending messages in plain text isn’t always desirable. I know!  Let’s extend email so it can handle PGP/GPG mail.

Attachments are okay, but what if there were some way my image could appear in my email body. I know! Let’s extend the message format so it can do that.

Text is boring. I know! Let’s extend email so I can send HTML content.


You get the idea.   Email has evolved far beyond the original specification and still fails to meet users’ expectations.  And it should not, because they confuse email with instant messaging and with a reliable file transport mechanism.  If your users want messages to be delivered instantly, use an instant messaging system, not email.  If you want files transferred, use some kind of file transfer protocol.   Anyone training users to expect anything other than “it’ll almost certainly get there, probably today” out of email is creating a rod with which to beat themselves when deadlines tighten.  The right tool for the right job.






Leave a Reply

Your email address will not be published. Required fields are marked *