Transferring Mail by MTAs
Mail transfer agents do not transfer mail. They make transfer decisions about messages and hand them off to mail delivery agents for the actual transfer. In other words, MTAs are responsible for ensuring that a message is sent to its next destination (not necessarily its final one) and that the message is of the appropriate form to get there and be properly interpreted.
MTAs receive messages from either MUAs or other MTAs. They parse information provided by the SMTP protocol called envelope information to determine the message’s sender and recipient. They rewrite the message as needed to pass through their part of the network, then they pass the message to a mail delivery agent for delivery to a local mailbox or transfer to another MTA or mail system.
Envelope information is part of the SMTP protocol and separate from the message itself. A full description of the SMTP envelope is given in Chapter 9.
Part or all of a message may need to be rewritten by an MTA en route. This could take place because the message is destined to another type of network. Different networks and protocols allow different types of data to be passed. In the case of Internet mail, only simple US-ASCII text characters are allowed in mail messages. Binary data is encoded in that character set. Other networks may be more or less restrictive. If a message is received by an MTA destined for the Internet, the MTA is responsible for ensuring that the message is properly encoded and will cleanly pass through the mail system.
The MTA’s routing decision is based on the recipient’s address located in the envelope. The MTA determines if the recipient’s mailbox is on the local system, on another system, or invalid. If the address is local, it is passed to a local-delivery MDA for appending to the recipient’s mailbox. If it is not a valid address, an error message is generated and sent back to the sender. If it is a valid address that cannot be delivered locally, then the domain name of the address is used to determine the mail server that accepts mail for that domain. This is done via the DNS’s MX record notation.
An MTA may receive a message because it was listed in DNS as the mail server for the domain of the recipient. This does not imply that the message must be locally delivered. The MTA may have directions to route the message to another address, for example. This is becoming rather common as corporations register and use domain names that have no services associated with them but are operated and administered by others. These are known as virtual domains.
Similarly, an MTA may affect local delivery of a message to a mailbox, but that mailbox may be read by a mail retrieval agent for delivery elsewhere. Indeed, the messages so retrieved may be remailed to another address, ad nauseam. For this reason, it is not possible for an MTA to know that a message has been delivered to its final destination. This decision may only be made by a receiving MUA.
Anti-spamming MTAs
The sender’s address in the SMTP envelope and headers in the message itself are used by many modern MTAs to limit unsolicited junk email or spam. Services, both commercial and free, now exist on the Internet to provide lists of known spammers’ addresses. Mail can therefore be rejected based on those addresses. Surely, many spammers create messages with incorrect addreses, but those addresses are also on the lists. Some U.S. states are currently passing laws that would make such address misrepresentation a criminal offense.
Since an MTA can be made to accept mail from anywhere, a favorite attack by spammers is to use an unsuspecting MTA to relay many millions of spam messages. Therefore, MTA operators should restrict the ability of others to relay messages from arbitrary locations. Normally, messages should only be relayed if they are sent from the MTA’s own domain.
sendmail and other MTAs provide such anti-spam support. If you operate an MTA, use of the anti-spam rules is highly encouraged. If you write an MTA, please allow the use of anti-spam filters where necessary.
Types of MTAs
The most powerful and complex MTA in existence is sendmail, a general purpose MTA capable of being configured to transfer mail between a wide variety of networks. For simple mail environments, sendmail may be overkill and a simpler but less capable MTA chosen.
Consider two environments: One is a company whose single LAN is connected to the Internet, and the other is a similar company that has multiple offices and many traveling salespersons.
The first company has simple needs. They wish to send and receive mail via the Internet and locally. Any of a number of simple MTAs that handle local and Internet delivery can do the job, such as smail or qmail.
The second company’s needs are much greater. They may have executives traveling to remote locations who need to get their email via fax. Their sales staff may wish to gain access to their mailboxes whether or not they are traveling. They wish to have a single MTA that handles mail for their entire domain and yet serve their multiple offices. This company will very likely use sendmail to handle their more complex needs.
A custom MTA may be created to allow a machine to receive mail from only one source, or just to keep a very low profile on the hardware. For example, one might create a simple MTA in Perl to allow a machine running Windows 95 to accept mail messages from a remote server without requiring a constant socket connection. In this way, the Windows desktop may receive this mail directly, without the message passing through a (perhaps complex and time-delayed) internal mail system. This technique may be used when asynchronous information needs to be passed to any machine, without modifying the normal mail system.