Within Internet message handling services (MHS), a message transfer agent^[1] or mail transfer agent^[2] (MTA) or mail relay is a computer process or software agent that transfers electronic mail messages from one computer to another, in single hop application-level transactions. An MTA implements both the client (sending) and server (receiving) portions of the Simple Mail Transfer Protocol.^[3]

The term mail server is also loosely used to mean a computer acting as an MTA by running the appropriate software. The term mail exchanger (MX), in the context of the Domain Name System formally refers to an IP address assigned to a device hosting a mail server, and by extension also indicates the server itself.

Contents 1 Operation 2 Transfer versus access 3 See also 4 References

[edit] Operation

An MTA receives mail from another MTA or MSA or from a mail user agent (MUA). The transmission details are specified by the Simple Mail Transfer Protocol (SMTP). In case any recipients of a given message are not hosted locally, the message is relayed, that is, forwarded to another MTA. Every time an MTA receives an email message, it adds a Received trace header field to the top of the headers of the message^[4], thereby building a sequential record of MTAs handling the message. How to choose a target MTA for the next hop is also described in SMTP, but can usually be overridden by configuring the MTA software with specific routes.

The MTA works behind the scenes, while the user usually interacts with the MUA. One may distinguish initial submission as first passing through a mail submission agent (MSA) – formally, port 25 is used for communication between MTAs, or from an MSA to an MTA, while port 587 is used for communication between an MUA and an MSA^[5]; this distinction is first made in RFC 2476.

For recipients hosted locally, the final delivery of email to a recipient mailbox is the task of a message delivery agent (MDA). For this purpose the MTA transfers the message to the message handling service component of the message delivery agent. Upon final delivery, the Return-Path field is added to the envelope to record the return path.

[edit] Transfer versus access

An MTA is usually coupled with some means for email clients to gain access to stored messages. A MUA may use either Post Office Protocol (POP3) or Internet Message Access Protocol (IMAP) to retrieve a user's messages. Briefly, POP3 differs from IMAP as the former usually involved deletion of downloaded messages, while IMAP provides for access from multiple clients. Mail messages can also be accessed through a web interface.

Why use yet another protocol, SMTP, for the message transfer? In fact, IMAP (but not POP3) allows to upload mail messages; and there are implementations that can be configured to also send messages^[6], so as to avoid uploading the same message twice: one for sending, and one for storing it in the Sent folder on the server. Under the hood, however, they still use SMTP to inject messages into the mail transport system. The reason for using SMTP the way it is currently used is twofold:

1. Cope with discontinuous connections. Historically, inter-network connections were not continuously available as they are today, and many readers needed no access protocol as they could access the mailbox directly (as a file) through a terminal connection. If configured to use backup MXes, SMTP can transparently cope with temporary local network outages that may result, e.g., from solar flares. A message can be transmitted along a variable path by choosing the next hop from a preconfigured list of MXes.
2. Submission policies. Users should submit messages to their local servers for social, not technical, reasons. It has not always been that way. For example, the original Eudora (before it became an alpha-quality extension for a beta version of Thunderbird, in the early 90's) featured direct delivery of mail to the recipients' servers, out of necessity, in those early days of putting a MUA on a personal system. Today, funneling email through MSA systems run by providers that in principle have some means of holding their users accountable and are capable of at least understanding bad behavior in mail is the best partial workaround we have for controlling spam. ^[7]

[edit] See also

• Mail submission agent (MSA)
• Mail user agent (MUA) a.k.a. email client
• Mail delivery agent (MDA)
• Simple Mail Transfer Protocol
• Email forwarding
• List of mail servers, Comparison of mail servers
• SMTP proxy
• MX record

[edit] References