• 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?

Your e-mail administrators want you to understand the basics. You don't have to be a guru, they insist; they'd be happy if you're simply somewhere past “ignorant.” If your eyes don't glaze over, the admins believe, they could better explain a thorny problem, and the company could make better decisions. You don't have to solve their problem; but it would help for you to understand it.

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. Although the subject is relevant, we barely mention e-mail legafl issues; that's a topic for another time (which is a nice way of saying, “Don't you think this article is long enough?”).

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 fibres, dead mail servers, routing loops, greylisting, 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.

Within an organisation, you can make e-mail highly available, reliable and auditable-if you are willing to invest enough human and technical resources toward that goal. However, no amount of effort and expense can make external e-mail function like your corporate mail. Part of that is intentional. Some features of corporate mail systems (such as out of office notices, read receipts, address lookup and verification) carry security concerns. Getting Internet e-mail to work nearly like corporate e-mail can only be done on a piecemeal basis by making special arrangements with outside partners in the specific cases where you need corporate-level e-mail functionality.