So this article won't teach you to be an e-mail expert in five easy steps. Instead, it helps you calibrate your expectations, identifies the key issues in e-mail management and teaches you the least you need to know.

Nor does this article pretend to explain the vast inner workings of e-mail technology. That's a big subject, encompassing everything from the choice of e-mail desktop client to server configuration. That pool gets very deep, very fast, so for clarity we separate the subject into e-mail management (people and process) and e-mail technology (servers and the Internet).

Here, we discuss user and IT expectations for e-mail; touch on corporate policies on its use; and explain the relevance of Internet standards. Technology is mentioned in passing (it's impossible to ignore) but the methods by which all the gears engage is a subject left to another time. (That's a nice way of saying it isn't written yet.) Also, this article gives little attention to fighting spam; that topic is covered in Five Things CIOs Should Know about Fighting Spam. Although the subject is relevant, we barely mention e-mail legal issues; that's a topic for another time (which is a nice way of saying, "Don't you think this article is long enough?").

Table of Contents

• What are the major misconceptions about e-mail (outgoing)?


• What are the major misconceptions about e-mail (incoming)?


• What criteria should I use in choosing an e-mail server (and the people to manage it)?


• Sure, sure, we care about Internet standards. Don't we?


• What guidelines should the company use for setting e-mail policies?

What are the major misconceptions about e-mail (outgoing)?

While everyone depends on e-mail to get business done, it's not a reliable delivery mechanism. Nothing in the e-mail specifications guarantees that a message will be delivered in a timely manner, or that it will be delivered at all.

The specifications for Internet protocols are called RFCs, which stands for Request for Comment. It's a terrible abbreviation because it implies that the process is incomplete, but RFCs are indeed the agreed-upon standards from the Internet Engineering Task Force (IETF).

Mail moves around the Internet almost entirely via the Simple Mail Transport Protocol (SMTP). SMTP is not natively secure, it is not guaranteed, it is not trackable and it is not certified. SMTP was engineered to be a best effort-no more than that.

Relying on e-mail delivery is a bad idea. When e-mail fails, it's common to accuse the network and e-mail admins of wrongdoing, as though they intentionally threw their bodies between your vital message and its recipient just to disrupt your life. E-mail specifications don't and can't require a message to appear in your inbox in the three nanoseconds you desire. This isn't a specification failure but an acknowledgement of the challenges facing every message in the outgoing queue. Cut fibers, dead mail servers, routing loops, graylisting, DNS typos, filter delays, blacklists-all sorts of things can delay or kill mail in transit. An e-mail message arriving three days after it was sent is perfectly in line with the specifications.