Mail host

A mail host is a computer on the internet that helps move e-mail messages from senders to recipients.

Such machines are generally operated and maintained by internet service providers (ISPs), or by businesses (or government agencies, private organizations, schools, etc.) that operate mail services for their staff or for other users. Usually, these machines are dedicated solely to their assigned e-mail tasks, and are not called upon to do other work (such as hosting websites).

Generally, end-users of e-mail do not operate their own mail hosts, although as we will see later, the mail programs on end-users' machines can sometimes be considered to be mail hosts of a sort.

Most internet mail hosts are designed to use well-known standard e-mail protocols, including SMTP, POP3, and IMAP; some proprietary mail-management systems (like Microsoft Exchange or Lotus Domino) use their own procedures for internal handling of mail, but they generally use the standard protocols and methods when dealing with outside mail hosts via the public internet.

---

Types of mail hosts

Mail hosts come in several varieties, and get different names depending upon their precise role(s) in the mail transfer process, and the manner in which they receive and send the messages they are called upon to handle. Here's a table that may help decode some of the jargon, followed by some more detailed explanation.

	role...	what comes in...	what goes out...
MUA	End-user's mail program (Outlook, Thunderbird, etc.)	messages picked up from MDA using POP3 or IMAP	messages sent to outgoing MTA via SMTP relay
MTA (general)	A host that relays messages (using SMTP) to or from other hosts	messages received from another host via SMTP relay	incoming messages resent via immediate SMTP relay to another host
Outgoing MTA	An MTA that sends outgoing mail on behalf of end-users of its domain	messages received from MUA via SMTP relay	incoming messages sent to MX via immediate SMTP relay
MX (Mail exchanger)	An MTA that receives mail coming into a domain	messages received from MTA via SMTP relay	incoming messages sent to an "internal" MTA or MDA via immediate SMTP relay
MDA	A host that holds incoming mail for pickup by recipients (end-users)	messages received from MX or "internal" MTA via SMTP relay	messages held for delivery pending user request (via IMAP or POP3)

Mail user agent (MUA)

A mail user agent (MUA) is the technical term for what we usually call a "mail client" or "mail program" (e.g., Microsoft Outlook Express, Apple Mail, Eudora, Thunderbird, PINE, and many, many others). In other words, the MUA is the program on your own computer that you use to send and receive mail.

MUAs are essentially the end-user's complete interface to the e-mail system; they send outgoing mail (to an outgoing MTA) via the SMTP protocol, and they receive mail by querying MDAs using the POP3 or IMAP protocols.

As we noted, an MUA isn't strictly a "mail host" (that is, not a dedicated machine), although it acts as one whenever it sends or picks up mail.

The MUA is analogous to your home's postal mailbox (i.e., outside your front door, in your building's lobby entrance, or around the corner); you put your outgoing mail into it, and you take your incoming mail out of it.

Mail transfer agent (MTA)

We need some mechanism to transfer the mail between the sender's MUA and the recipient's MUA; this is provided by a class of mail hosts known as mail transfer agents (MTAs). These are the workhorses of the e-mail system. The hallmark of an MTA is that it can act both as the sink (recipient) and source (sender) of SMTP relays; that is, the MTA can "talk" SMTP at both ends.

An MTA is, in the general case, a machine that is designed to relay mail messages from one host to another; that is, an MTA accepts incoming messages from outside hosts (usually MUAs or other MTAs), and then immediately relays these to other outside mail hosts (usually MDAs or other MTAs) that are "closer" to the final recipients.

The relay is immediate, as we say, because the MTA will attempt to retransmit the mail right away. It may sometimes be unable to do so, however, due to problems with the message, the destination address, or the destination mail hosts; in such cases, the MTA will follow a more-or-less standard procedure to retry the relay at intervals until it is (1) accepted, (2) permanently refused by the recipient's mail system, or (3) becomes too old (for instance, one week). In the latter two cases, the sender of the message generally gets a non-delivery notification or bounce from one of these hosts, indicating that the mail did not go through.

While general-purpose MTAs are often used for internal relays within mail systems or domains, there are two special classes of MTAs deployed in e-mail systems: outgoing MTAs, and mail exchangers. These are important in the study of spam because they represent what network engineers call "edge machines," which sit at the possibly-insecure boundary between a private network (for example, that of your ISP or your employer) and the public network.


An outgoing MTA is a mail host that is designed for one task alone: to accept messages that end-users want to send, and to forward these to the appropriate mail exchanger that serves each recipient. You can think of the outgoing MTA as being like your local post office, when it takes the mail from your mailbox (your MUA) and begins the process of routing it to the recipients.

Typically, when you set up e-mail service on your computer, you must supply the name of an outgoing MTA (which you get from your internet provider). Thereafter, all of your outgoing mail will be relayed to this host in order to be sent to the recipients.

The outgoing MTA has the job of figuring out where exactly (i.e., to which other host) it must send the messages that its users give to it. This is done by looking at the domain-part of the recipient's address, and then looking up this domain in DNS to find the appropriate mail exchanger host(s) (see the wiki page on DNS MX records for further details). This feature helps make e-mail a "fire-and-forget" operation for its users; the sender does not have to know anything about the recipient other than his or her e-mail address, and does not have to supervise the delivery of outgoing messages.

Usually, outgoing MTAs are "protected" in some fashion, so that only certain people can use them (that is, bona fide customers of the mail service). If they were not so protected, they might be used by anyone (including spammers) to send mail, and they would then be known as open relays. Usually the protection is afforded simply by blocking access to the MTA by anyone outside the domain that the MTA serves; it may in some cases also be provided by requiring all users to authenticate themselves with a username and password (if you were required to enter a username and password when setting up your outgoing MTA service, then you are probably using this so-called SMTP-AUTH service).


The second special variety of MTA is the mail exchanger or MX. The MX is an MTA that has been specially "blessed" by its operators to be the collecting point for all mail coming into the domain it serves. You can think of the MX as being like your local post office when it receives your incoming mail as part of bulk deliveries from other post offices (or MTA hosts, in this case).

For example, the operators of the domain anywhere.foo might set up an MTA named mx.anywhere.foo, and then register this host within their DNS records as the MX for the domain; as we described above, if you wanted to send mail to a user in the anywhere.foo domain, your outgoing mail service would look up the domain in DNS to find the MX host (that is, mx.anywhere.foo), and then relay your message to this host for delivery.

In reality, busy mail operations will have more than one MX host; this allows the incoming mail load to be shared among several machines, and also provides backup should one or more of the individual MX hosts fail. Typically, these hosts will be assigned preference numbers that tell delivering hosts which ones should be used and in what order.

The most popular method of spam delivery these days involves spammers figuring out for themselves which MX hosts they must contact in order to send to each recipient; this technique is known as direct-to-MX mailing. Using this technique, spammers no longer require the support of an outgoing MTA, and can thus lower their visibility to the services they use (or steal) to send their mailings.

Fortunately, perhaps, you don't have to know anything about the MX hosts that support your ISP or other mail system, because you do not interact with them directly; you get your mail from an MDA.

Mail delivery agent (MDA)

A mail delivery agent is a machine that is designed to accept messages from MTAs and to hold them for pickup by recipients. It does this by sorting incoming messages into individual "pigeonholes" (known in e-mail parlance as spools) that are uploaded to users when they check in to pick up their mail (using POP3 or IMAP). You can think of the MDA, then, as being like the sorting room in your local post office, where incoming mail is sorted into individual piles for pickup and delivery by a postal carrier.

If you want to receive mail on your brand-new computer or ISP account, you usually have to enter the name of an appropriate MDA into your mail program (this can be, and usually is, a separate machine from the outgoing MTA host that you also must identify in order to send mail).

The MDA does not relay mail; that is, it can receive messages via SMTP relay, but it generally does not retransmit these messages using SMTP. As we noted above, end-users generally get their mail from the MDAs not through SMTP, but by querying the MDAs using one of the mail pickup protocols (POP3 or IMAP). On the other hand, MDAs can where required send new messages (such as delayed bounces) via SMTP relay to an MTA.

Many mail services also use their MDAs to do other tasks, such as calling out to spam or virus filters (for tagging or detaining suspect messages), or (as noted) sending delayed bounces.

---

Mail host software

We have already mentioned the very large variety of MUA programs in use today; the software applications used by MTAs and MDAs are less numerous and less well known to e-mail end-users, although they are very familiar to mail administrators.

The two most popular MTA applications are Sendmail (www.sendmail.org∞) and Postfix (www.postfix.com∞); both have been around for a very long time, and have been continually updated to deal with the expanding capabilities (and problems) of e-mail.

Likewise, MDAs use applications such as Procmail (www.procmail.org∞) and Maildrop (www.courier-mta.org/maildrop∞).

Typically, end-users do not need to know anything about these mail-host programs (which is good, because they can be very complicated).

As we noted, some organizations use proprietary mail-handling systems like Exchange or Domino; these systems run by their own rules when moving mail around within a domain, but generally behave like MTAs when they must exchange mail across the public network.

---

Mail delivery paths (and SpamCop mail host configuration)

Now that we know something about the various kinds of mail hosts, we can describe the transmission of an e-mail message in terms of the handoffs (from one mail host to another) through which it passes along the way. In these terms, the typical path taken by a basic e-mail message might look something like this:

1. Sender's MUA relays it (using SMTP) to an outgoing MTA operated by the sender's e-mail service;
2. Outgoing MTA relays the mail (again using SMTP) to the MX for the recipient's domain (after identifying this MX via a DNS lookup for the domain's MX records);
3. The MX relays the mail (again, usually via SMTP) to an MDA within the recipient's domain;
4. The MDA holds the mail until the recipient picks it up with his or her MUA (using POP3 or IMAP).

If we are interested in tracing a spam message, then we want to identify the handoff at #2 above, since this is the "injection point" where the mail is first offered to a machine (an MX) in the recipient's domain. The sending host in this case will generally be the one we want to report as a spam source. If the path is as (relatively) simple as that described above, then the task of finding this key handoff is not difficult. However, not every message will follow such a simple path. For example, if either the sender or recipient uses a proprietary mail-management system (like Exchange or Domino), then the steps at either end may look quite different. Also, particular providers may relay incoming messages internally in a fashion that makes it difficult for automated mail-tracing tools (like SpamCop) to follow the action.

It is for this reason that SpamCop users must submit all their e-mail addresses to the mail hosts configuration process (see the wiki page for mail host configuration). This process enables SpamCop to figure out the precise sequence of handoffs that a message will follow when it is offered for delivery to one of these addresses; this helps SpamCop to locate the precise "injection point" of the message, and not to lay the blame elswhere due to confusing header entries.

---

CategorySpamCopGlossaryWikiM
CategorySpamCopReporting
CategoryMailHostConfiguration

---