The server-to-server communication process is somewhat different than it is when the server is talking to the client MUA, although both use SMTP. One difference is trust; between hard-coded programming and administrator settings, every mail server through which a message passes—and there may be several—has to assume that the message is wrongly formatted (like the post office refusing a letter because it lacks a full street address) or, sadly more likely, because it breaks the rules in the pursuit of sending spam or viruses.

Primarily because of spam, most mail servers put each message through a multistep process before they will even accept the data, much less store it and forward to the user. Those steps are covered a little more below, and in some detail in Getting Clueful: Five Things You Should Know About Fighting Spam; for this broad overview, just be aware that messages can be lost or rejected for many reasons, not all of which are intended to cause you personal grief.

Note that I'm vastly oversimplifying the communication process here. Sending a message requires a stylized dance in which the servers greet each other (hey, you available to talk?), identify themselves (I'm authorized to send messages from yourcompany.com, you betcha!), agree to send a message's header (I have a message for person@yourcustomer.com, got anybody by that name?), acknowledge its receipt, and so on.

Those details are more than you need to know at this point. Just be aware that there are a lot of steps in the process, and every one is governed by standards. For example, RFC 2821 defines SMTP, including how to send mail round the network. RFC 2822 defines the basic format of a mail message, including headers (To:, Cc:, Subject: and so on). Your e-mail administrators can probably recite portions of these by heart. (And, if they have a sense of humor, they can declaim from RFC 2549, IP over Avian Carriers with Quality of Service.)

Once the message arrives at the destination mail server, that is, the server responsible for delivering to the recipient (such as mail.yourcustomer.com), it's ready to distribute to the individual who is, presumably, anxiously waiting for a word from you.

Here, too, there are choices for the mail administrator, particularly in how mail should be stored and forwarded to end users. Every organization (or its e-mail admins) decides which method best serves its needs. Most likely, the primary protocol used in your shop is the Internet Message Access Protocol (IMAP), which keeps all messages on the incoming mail server, neatly sorted into user folders. It's far more rare, nowadays, for companies to use the Post Office Protocol (POP3). Using POP3 e-mail, the "Get new mail" command in your MUA causes the application to download all messages to the local computer. Under most circumstances, the POP3 e-mail messages are then deleted on the mail server.

The recipient presses "Get new mail" on her own MUA... and there is that brilliant message you wrote. Magic!

By the end of the process, your e-mail message may travel around the world through five or six separate computers. But in many cases, your brilliant message arrives on the recipient's desktop in a minute or two. Is that cool, or what?

All that happens quickly when the system works. But what happens when it doesn't?

How can e-mail be delayed or lost?

Early hype described the Internet as an "electronic superhighway," a phrase that grew dated faster than a 1970s olive-green polyester leisure suit. In this case, however, a network of highways and side roads is a useful analogy.

If you encounter no traffic on the way to work, you can get to the office in, say, 20 minutes. But inevitably, the road is clogged with other cars, causing you to wait 5 minutes just to turn left at one intersection. Construction can make it impossible to take the usual route. Your car may break down. The trip takes a lot longer than 20 minutes.

The same things apply to e-mail traffic. Mail servers are fast, but messages can queue up under a heavy load. Internet traffic can require messages to be rerouted through paths that aren't obvious. Servers can lose connectivity with the Internet. Users can unplug network cables, "helpfully" change MUA settings (what were they thinking?), and decide blithely to send a 10MB PowerPoint file to 35 of their closest friends (and then demand to know why the message didn't arrive in nanoseconds).

It isn't common for your mail server to hand off your brilliant message to the recipient's mail server with just one "hop." Like the postal service, messages may pass from one place to another before they are delivered. Messages are handed from machine to machine in a "store and forward" model that may involve many computers, so the overall speed of delivery is highly variable.