E-Mail Server Administration 101
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Each TCP/IP network service has its own quirks and lingo. For the harried administrator who isn't responsible for a particular service (such as E-mail), trying to troubleshoot issues that could be related to that service ("Hey, I can't check my E-mail!") can become a royal pain, especially when it seems to take forever to get across what you're trying to say to the administrator of that particular service ("Run a what??").
In this article, you'll learn today's version of how E-mail works—it has changed somewhat since the early Internet days—along with the jargon, issues, and needs that go along with E-mail administration. By the end, you should feel much more competent when talking to your E-mail administrator, with the lovely side effect that the two of you will finish your interactions sooner, making your days less frustrating and wasteful.
How E-mail Works
E-mail has become such a common tool today that most of us use it without knowing or caring how it actually works. Everyone who uses E-mail knows that people have E-mail addresses. All E-mail users are also aware, at least vaguely, of the E-mail program they use to compose and send the message. However, between hitting Send and receiving the "You've got mail" notice, a lot goes on behind the scenes.
Let's follow a typical E-mail message along its journey. Alice wants to send E-mail to her friend Bob. She starts her favorite E-mail program, such as Eudora or Outlook, known in mail system jargon as a mail user agent (MUA). The MUA's job is more complex than it looks. First, it gives Alice an interface in which type her E-mail and enter the delivery information in the To: and From: boxes. Then, when she clicks Send, it attaches headers to the E-mail with the information needed for that message to get where it needs to go, and for the recipient to be able to respond: a message ID code, the date, and the contents of the To: and From: boxes. Once this packaging is completed, the MUA submits the E-mail to the mail system for delivery.
But what is this "mail system," anyway? Alice's MUA doesn't connect directly to Bob's MUA, after all. Bob's computer might not even be turned on at the time, so there's no guarantee that his E-mail client could receive the mail the moment it was available. Besides, most end-user machines on the Internet don't have a static IP address with a name mapped to them through DNS. How would Alice's MUA know where to send Bob's E-mail in the first place? Firewalls and other network routing games could also cause problems even if Bob has a static IP and name.
Fortunately, the mail system is designed to avoid all of these problems. Rather than trying to send directly from MUA to MUA, the mail system uses a network of mail servers that hand the E-mail off to one another, storing it until the handoff can take place. When Alice clicks that Send button in her MUA, the E-mail client sends the E-mail to the mail submission agent (MSA) that Alice configured the E-mail client to use when she first set it up—or that her helpful administrator set the machine to use.
The MSA's job is to validate the mail being submitted, making sure that it's coming from someone who is allowed to send mail through that particular server. A competent ISP's MSA typically checks the sender's IP address to make sure that the mail is being sent by one of its own customers, and rejects mail submitted from other addresses. Think of the MSA as the "gated on-ramp" to the E-mail superhighway—it's the only part of the system that can verify that the sender was indeed authorized to send that mail. The MSA might even require Alice to authenticate with a username and password to send out that mail.
Once the MSA at Alice's ISP approves her E-mail submission, it hands off the E-mail to the ISP's mail transfer agent (MTA). The MTA's job is to handle the long-haul delivery of the mail to other MTAs. However, how the E-mail gets from Alice to Bob isn't always as straightforward as you might think.
Usually the MTA at Alice's ISP talks directly to the MTA at Bob's ISP, handing off the E-mail in one nice, neat move. At other times, the E-mail can't travel directly from the source MTA to the destination MTA. For example, a large corporation or university may have offices in many buildings, possibly in different cities, so there might be a hierarchy of MTAs at the head office, the branch offices, and then in each department. If Bob works for such a corporation, Alice's ISP's MTA will probably relay the mail to the corporation's "main" MTA, which will then use its knowledge of the organization's structure to decide which branch MTA to relay the E-mail to. That branch MTA can then use its knowledge of the branch's structure to relay the mail to the MTA that services Bob's department.
Along the way, every MTA adds a Received: header to the top of the E-mail as a kind of postmark: "This mail item passed through this MTA at this time, from (previous MTA's hostname or IP address), destined for (recipient's E-mail address)." This setup makes it possible to trace the route that the mail took through the network of MTAs. Here's an example of a single Received: header; you'll probably have more than one of these in the headers of most of your E-mail messages:
Received: from hormel.redhat.com (hormel.redhat.com [209.132.177.30])
by michelangelo.renaissoft.com (8.12.10/8.12.10/1.1)
with ESMTP id i2T7sDtD013132
for <dee@renaissoft.com>; Sun, 28 Mar 2004 23:54:14 -0800
When the E-mail reaches the MTA at Bob's ISP or the final MTA at his company (the departmental MTA, in the case of our corporate example), it has nearly reached its ultimate destination. Next, the E-mail normally is handed off to a mail delivery agent (MDA). The MDA is like a secretary, responsible for delivering the E-mail to local mailboxes for storage. If the ISP does any content filtering, such as scanning for spam and/or viruses, the MTA may send the E-mail to the filtering program first—to be consistent, we can call it a mail filtering agent (MFA)—which then sends the filtered result to Bob's MDA.
On reaching the MDA, the E-mail sits in storage in Bob's mailbox at the ISP. When he starts up his own MUA and clicks Check Mail, his MUA connects to the ISP's MDA and downloads any waiting mail, including the E-mail that Alice sent so many words ago.
The whole process, in a nutshell, ends up looking something like this:
MUA->MSA->MTA->...->MTA->(MFA)->MDA->MUA
In practice, some of these functions are combined on the same servers, sometimes even within the same software. Most MTA software can also be configured as an MSA; for instance, handling both the "pickup" function from the sending E-mail clients and the passing-along function from server to server. However, keeping these various roles separate in an explanation helps illustrate the process better; if you're an administrator at a larger ISP, each of these E-mail system functions may in fact be handled separately.
These days, maintaining a separate MTA and MSA is becoming popular even among smaller ISPs, due to the added control it gives administrators over both processes. If an MSA is handling all the mail submissions and verifying the authorization of the senders, the MTA can limit itself to talking only to other registered MTAs, which prevents spammers from connecting directly to your MTA to send their mass mailings. There are a number of potential security and spam-attracting drawbacks in using a combined MTA/MSA solution.