E-mail happens invisibly. No creaking and groaning of IT infrastructure reminds you that e-mail delivery is actually a complex system with a lot of moving parts. Overall, that's a great success story—how many long-term IT services work so smoothly that users take them for granted? But if you have any responsibility for ensuring that the mail arrives, or for managing the hardworking e-mail administrators who do, it behooves you to know a minimum of the technology basics.

This article centers on the technology of e-mail. It doesn't go into e-mail management, corporate policies or matters that involve human behavior. (That subject is covered in ABC: An Introduction to E-Mail Management, which I like to think is a companion piece, suitable for framing.) Nor does this article address the key issues to consider in the war against spam, though spam fighting represents a huge amount of an e-mail administrator's energy (and angst) these days; another article addresses what managers should know about spam fighting.

Don't expect technical depth: This is, after all, an ABC, not the entire alphabet. Managers should, however, understand that a full conceptual explanation could easily fill 40 pages with dense technical definition; most of it is far more than I want to know, too. If e-mail is important for your business, however, you should have skilled people around who are up to the challenge.

This article covers the underlying technology (or, if you prefer, the most essential of those magic spells), so you have some idea of how the process works, and thus what can go wrong.

How does e-mail get from the sender to the receiver?
How can e-mail be delayed or lost?
What's the difference between all these protocols, like IMAP and POP, and why should I care?
How does spam filtering work?

How does e-mail get from the sender to the receiver?

A. Perhaps the first fundamental is that e-mail isn't handled by one kind of server or technology. It's a suite of protocols that are served by distinct processes. We'll look at those in a little more detail after the overview.

Let's say you've written a brilliant message in your e-mail client—the software application you use on your desktop to compose and organize messages, such as Microsoft Outlook, Apple Mail or Thunderbird. E-mail professionals call that client application the mail user agent (MUA).

The MUA may not be a desktop application; it may be a "Web mail" application that runs on a Web server and which you control using your browser. Web mail clients, whether through Gmail, Yahoo or a corporate front end to another system (say, to Lotus Notes), are treated the same way as desktop client MUAs by the rest of the e-mail transport process.

When you click on the Send button, the message disappears from your screen... and sets an entire chain of events in motion.

After you click Send, the message is transferred to your outgoing mail server, which is probably named something like mail.yourcompany.com. The mail server—formally called a mail transfer agent (MTA)—knows to accept the message, either because you are in a network it trusts, or because you provided a username and password (generally stored in the MUA's configuration files). This network process is accomplished using the Simple Mail Transfer Protocol (SMTP), and the "make sure the sender is trustworthy" process is called authenticated SMTP.

With your brilliant message in hand (or in queue), your mail server needs to send it along. The mail server contacts the recipient's mail server and transfers the mail, again using SMTP. But of the millions of mail servers, which does it contact? Your mail server does a lookup on the domain name servers (DNS), which are a kind of library card catalog for the Internet, to find out who's signed up to accept mail for the recipient's domain. The DNS gives your mail server the mail exchange (MX) records (there can be more than one) that are registered for that domain. That gives your mail server the server to contact, and it can start on its "Hey, I've got mail for you" conversation.

The message is sent over the Internet, via TCP/IP (Transmission Control Protocol/Internet Protocol). Don't generalize and say "over the Web," here; while you can occasionally use the terms interchangeably, this isn't one of those times. Hearing you say this will make your techies wince.