This also means that messages travel through computers that are not visible to or even known to the sender or recipient. The store and forward model is critical to the robustness of e-mail, because it permits secondary routes for mail to get from one place to another, and for technical practices that cope with failures by taking alternate paths or retrying to create a connection when a problem is encountered.

And that's without reference to the "nasties" such as spam and viruses, the road rage of Internet traffic. In addition to consuming a vast amount of bandwidth (I could quote percentages, but any numbers I cite would be higher by the time you read this), spam, viruses and Trojan horses cause network admins to invest a lot of time and effort in building traps to prevent the bad stuff from reaching users' inboxes. Every gateway takes time, like a highway tollbooth that slows traffic.

Historically, mail servers were very forgiving of technical carelessness. But in the modern world, mail deliverability can be harmed by minor technical hygiene issues like inaccurate domain name servers (DNS), ill-considered tuning of timeout parameters and unusual mail formatting.

And then there's the burden placed on everyone for dealing with spam, phishing and viruses. There's no such thing as a perfect spam filter. They're getting better, sure, but you've probably encountered at least one situation in which a real e-mail message was stuffed wrongly into a spam folder.

Another barrier comes from misconfigured e-mail clients and servers (such as your own!) failing to follow the rules; more and more commonly, their mail is rejected by the recipient's mail server (which is not always kind enough to tell you). If that happens, the message is delayed or lost. This means that companies must enforce standards-based e-mail technology (such as ensuring that their servers adhere to the RFCs), and that users must be taught proper e-mail behavior (such as sending a message from the same server from which their e-mail ID originates).

What's the difference between all these protocols, like IMAP and POP, and why should I care?

It's time to get a little more techie. As mentioned earlier, e-mail can use a lot of Internet protocols—protocols being industry standard methods of transmitting data—and it's helpful to be familiar with these, at least at a high level.

At minimum, you have protocols used by inbound servers—what I've been calling "the recipient's server," generally POP3 and IMAP. Outbound servers, the ones that are mailing messages elsewhere, use SMTP. A company may also have a separate authentication server (LDAP) and perhaps other pieces providing calendaring (often involving SQL databases), Web mail (uses Web browsers, for which the relevant protocols are HTTP and IMAP), and central storage of client configuration (ACAP).

The different protocols exist not because some programmer thought it would be cool to create one, but because each protocol serves a completely different need. For example, POP3 was designed to support lightweight, disconnected clients. IMAP provides server-based storage of mail folders. LDAP provides authentication not just for mail systems but for many other applications. And so on. Each solves a particular problem.

Most of these protocols are just, well, how the pieces fit together and no decisions are necessary or possible. One of the few instances where your company has an active choice is IMAP versus POP3. IMAP is more popular than POP3 nowadays, though both have their adherents. So let's take a quick look at their advantages and disadvantages.

IMAP has gained popularity because the mail stays on the server. Most mail clients (MUAs) permit users to sync the data to a local hard disk—a necessity for mobility, such as the omnipresent plane trips—but the messages' primary home is on the server. IMAP makes administration far easier for IT managers since there's only one computer to back up and it's easier to control how much disk space is consumed by limiting mailbox size. Users appreciate the ability to access their e-mail from any computer using whichever MUA is convenient, and because IMAP can store message state (such as whether an individual message was read or replied to) and keep Sent messages.

Companies also have more access to the contents of the e-mail, which can be important for regulatory and compliance reasons (such as archiving mail, a topic we won't address here) but also irritating to some users.

IMAP (particularly SSL IMAP, which adds security features) can also enable more efficient bandwidth use. Instead of downloading the messages to the user's inbox, by default IMAP sends message headers (sender, recipient, subject line, etc.). Only the messages selected are sent to the inbox, and clients may retrieve the text portion without retrieving attached files.

However, IMAP has its downsides. If a corporation keeps all the mail on one server, and doesn't back it up (and test those backups) there's a single point of failure. Plus, e-mail messages can be huge, particularly with attachments or embedded images; many companies cope with this by creating rules about disk space (such as "maximum of 100MB"), which irk users who really do need more (or at least who believe they do).