(Dent, 2004) – Email and the Internet
Unlike most proprietary email solutions, where a single software package does everything, Internet email is built from several standards and protocols that define how
messages are composed and transferred from a sender to a recipient. There are many different pieces of software involved, each one handling a different step in message delivery. Postfix handles only a portion of the whole process. Most email users are only familiar with the software they use for reading and composing messages, known as a mail user agent (MUA). Examples of some common MUAs include mutt, elm, Pine, Netscape Communicator, and Outlook Express. MUAs are good for reading and composing email messages, but they don’t do much for mail delivery. That’s
where Postfix fits in.
5.1.1 Email Components
When you tell your MUA to send a message, it simply hands off the message to a mail server running a mail transfer agent (MTA). Figure 1-1 shows the components involved in a simple email transmission from sender to recipient. MTAs (like Postfix) do the bulk of the work in getting a message delivered from one system to
another. When it receives a request to accept an email message, the MTA determines if it should take the message or not. An MTA generally accepts messages for
its own local users; for other systems it knows how to forward to; or for messages from users, systems, or networks that are allowed to relay mail to other destinations.
Once the MTA accepts a message, it has to decide what to do with it next. It might deliver the message to a user on its system, or it might have to pass the message along to another MTA. Messages bound for other networks will likely pass through many systems. If the MTA cannot deliver the message or pass it along, it bounces the message back to the original sender or notifies a system administrator. MTA servers are usually managed by Internet Service Providers (ISPs) for individuals or by corporate
Information Systems departments for company employees.
Ultimately, a message arrives at the MTA that is the final destination. If the message is destined for a user on the system, the MTA passes it to a message delivery agent (MDA) for the final delivery. The MDA might store the message as a plain file or pass it along to a specialized database for email. The term message store applies to persistent message storage regardless of how or where it is kept.
Once the message has been placed in the message store, it stays there until the intended recipient is ready to pick it up. The recipient uses an MUA to retrieve the message and read it. The MUA contacts the server that provides access to the message store. This server is separate from the MTA that delivered the message and is
designed specifically to provide access for retrieving messages. After the server successfully authenticates the requester, it can transfer that user’s messages to her MUA.
Because Internet email standards are open, there are many different software packages available to handle Internet email. Different packages that implement the same
protocols can interoperate regardless of who wrote them or the type of system they are running on. If you are putting together a complete email system, most likely the software that handles SMTP will be a different package than the software that handles POP/IMAP, and there are many different software choices for each aspect of
your complete email system.
5.1.2 Major Email Protocols
The communications that occur between each of these email system components are defined by standards and protocols. The standards documents are maintained by the Internet Engineering Task Force (IETF) and are published as Request For Comments (RFC) documents, which are numbered documents that explain a particular
technology or protocol.
The Simple Mail Transport Protocol (SMTP) is used for sending messages, and either the Post Office Protocol (POP) or Internet Mail Application Protocol (IMAP) is used for retrieving messages. SMTP, defined in RFC 2821, describes the conversation that takes place between two hosts across a network to exchange email messages. The IMAP (RFC 2060) and POP (RFC 1939) protocols describe how to retrieve messages from a message store. The IMAP protocol was developed after POP and offers additional features. In both protocols, email messages are kept on a central server for
message recipients who generally retrieve them across a network.
Note that the MUA does not necessarily use the same system for POP/IMAP as it does for SMTP, which is why email clients have to be configured separately for POP/IMAP and SMTP. An ISP might provide separate servers for each function to their customers, and corporate users who are away from the office often retrieve their messages from the company POP/IMAP server, but use the SMTP server of a dial-up ISP to send messages. MTA software running on SMTP servers constantly listens for requests to accept messages for delivery. Requests might come from
MUAs or other MTA servers.
5.1.3 Email Routing
Let’s consider for a moment one way that email routing might work. A user horatio in the domain example.com has a workstation named denmark. He could receive mail
by using the email address horatio@denmark.example.com . An MTA with a message to deliver would simply look up the IP address for denmark.example.com and deliver it
to that system for the user horatio. This scenario requires that Horatio’s workstation is always turned on, that it has a functional MTA running at all times to receive messages, and that it is accessible by unknown MTAs from anywhere on the Internet.
Rather than manage hundreds or thousands of MTAs on workstations and expose them to the Internet, nearly all sites make use of mail hubs that receive all the mail for a domain. MTAs such as Postfix need a way to determine which host or hosts are the mail hubs for a domain. DNS MX records provide this information.
A mail exchanger either delivers mail it receives or forwards it to another mail system.
A domain may have multiple mail systems for reliability, and therefore multiple MX records. Generally, one host is the primary mail server and the others serve as backup or secondary mail servers. Each MX record in DNS contains a preference value that orders mail systems from most preferred to least preferred.
BIND is one of the most common DNS server applications. (O’Reilly’s DNS and BIND by Paul Albitz and Cricket Liu fully explains the DNS system and documents the BIND software.) A simple BIND configuration file for the domain example.com looks like the following:
example.com. IN SOA ns.example.com. kdent.example.com. ( 1049310513
10800 3600 604800 900 )
;
; Nameservers
;
example.com. IN NS ns.example.com.
;
; Host Addresses
;
example.com. IN A 192.168.100.50 server1.example.com. IN A 192.168.100.220 ns.example.com. IN A 192.168.100.5 mail1.example.com. IN A 192.168.100.50 mail2.example.com. IN A 192.168.100.54 mail3.example.com. IN A 192.168.100.123
;
; Mail Exchangers
;
example.com. IN MX 10 mail1.example.com.
example.com. IN MX 20 mail2.example.com.
example.com. IN MX 30 mail3.example.com.
;
; CNAME Records
;
pop.example.com. IN CNAME mail1.example.com.
www.example.com. IN CNAME server1.example.com.
For this discussion, we’re primarily interested in the mail exchanger records:
example.com. IN MX 10 mail1.example.com.
example.com. IN MX 20 mail2.example.com.
example.com. IN MX 30 mail3.example.com.
The domain name is in the first column. The second column indicates that the
entries are Internet class records, and the third indicates that they are mail exchanger resource records. The last column shows the mail exchanger host, and the second-tolast column shows its preference value. Preference values can be any number
between 0 and 65,536, and a lower value indicates a more preferred host. The numbers are meaningful only in relation to each other and can be anything within the
allowed range. By convention, most administrators create priority values in multiples of 10, which allows some flexibility for inserting or temporarily rearranging preferences.
In our simple example above, mail1.example.com receives all the mail for the domain example.com. In this case, all mail must eventually arrive at mail1.example.com.
When an MTA has to deliver a message to a user at the domain example.com, it retrieves all of the MX records and sorts them in order of priority. It first attempts
delivery to mail1.example.com. If mail1.example.com is available and accepts the message, the delivery is finished; however, if for some reason mail1.example.com is not
available to accept the message, the MTA continues down the list until it finds a mail exchanger able to accept the message. If a secondary mail exchanger accepts a message, it takes the responsibility of delivering it to a more preferred mail server (possibly
the primary) when the unavailable server comes back online.
If no MX records are found for a domain, an MTA checks to see if there is an A record associated with the domain name itself. If there is an A record, the MTA attempts delivery to the system at that IP address.
This mail-routing scheme seems simple enough, but it does get slightly more complicated.
Consider an example where the MTA on mail2.example.com receives a
message for ophelia@example.com . Presumably, mail1.example.com is offline, since mail2 received the message. The MTA running on mail2.example.com gets the list of mail exchangers for example.com, determines that the message should go to mail1.example.com, and discovers that mail1 is not available. The next mail exchanger on the list is itself. Delivery to itself doesn’t really make sense. So, the next mail exchanger in line is mail3.example.com. The MTA could deliver the message there, but mail3 will go through the same process and immediately try to hand the message back to mail2, creating a mail loop. (MTAs actually resolve hostnames to IP addresses for comparisons, since MX hosts might have multiple A records.
Postfix compares the IP address to its list of addresses in inet_interfaces and proxy_interfaces.)
The solution is that when an MTA gets the list of mail exchangers and discovers itself among them, it discards its own record plus all other mail exchangers with an equal or less preferred priority (higher number). For our example, the host mail2 eliminates itself and mail3, thus reducing the list of mail exchangers to only mail1.
Since mail1 is not available and mail2 has no other options for delivery, it queues the message and makes the delivery when mail1 comes back online.
In order for mail routing to work successfully, you should be very careful when setting up MX records. In particular, you should observe the following rules for MX
records in your DNS configuration:
Mail exchangers must have valid A records. The mail exchanger pointed to by the MX record must be a hostname with a valid A record. Once an MTA has determined which host should receive the mail, it has to be able to find that host.
Mail exchangers cannot be aliases. The host pointed to by an MX record should not be an alias (CNAME record). Under normal circumstances, an MTA knows itself by its canonical name and looks for that name when checking the list of mail exchangers to prevent mail loops. The server must be able to find itself, so make sure that you list the canonical name in the MX record, or you risk creating a mail loop. Even if an MTA accommodates CNAME records (by looking up and using the canonical name), using them causes inefficiencies in mail delivery.
Use hostnames and not IP addresses for mail exchangers. List a hostname rather than an IP address for mail exchangers. While you may get by with a bare IP address, RFC 974 states that you must use a name of a host. Future changes (IPv6, for example) might cause bare IP addresses to break mail routing.
Make sure that you specify preference values. Leaving out the preference value for MX records may have different effects, depending on your DNS server and
MTA. At best, the problem creates ambiguity; at worst, it can prevent mail delivery.