Electronic mail: servers
In the previous chapter, we looked at email from a user perspective. The other part of a mail system is the Mail Transfer Agent, or MTA. As the name suggests, MTAs perform the transfer of mail from one system to another. Specifically, they perform three related tasks:
- They send outgoing mail, in other words mail that originates from their system. If the destination system is not available, they look for an alternative system, and if none is available, they retry delivery at a later date. Typically an MTA will retry every 30 minutes for five days before giving up.
- They receive incoming mail, possibly for multiple domain names. They may be quite picky about how they perform this task: since the advent of spam, a number of techniques have developed. We'll look at some in the section on postfix configuration.
- They relay mail. Consider the case where a sending MTA can't reach the destination MTA and chooses an alternative. The alternative MTA is called a relay ,and it must be prepared to deliver the mail to the final recipient at a later time. Until a few years ago, MTAs performed relaying by default, but the advent of spam has changed that radically.
Mail has been around for a long time now, well over 25 years. In that time, many mail systems have come and gone. One seems to have been around for ever: the sendmail MTA. sendmail has an unparalleled reputation. On the one hand, it can do just about anything, but on the other hand, its configuration file is one of the most arcane ever to be seen. Still, it's holding well against the competition, and it is still actively being developed.
The definitive book on sendmail, called the "bat book" after its cover, was written by Bryan Costales and others (O'Reilly)—see Appendix A, Bibliography for more details. It is over 1000 pages long. Obviously this book can't compete with it.
The good news about sendmail is: it works. It is possible to install sendmail and run it with no configuration whatsoever. The less good news is that in the past few years it has been constantly changing, and any information I write here is liable to be out of date by the time you read it. As a result, I recommend:
If sendmail works for you, use it. If you have difficulties, use postfix instead.
The following sections show how to configure a mail system using postfix. In general, sendmail is quite similar. You'll find every detail in the bat book, and the original sendmail distribution, available from http://www.sendmail.org/, contains instructions for experts.
How mail gets delivered
Ideally, to send mail, the source MTA contact the destination MTA and sends the message. In practice, this doesn't always work. Here's the general method:
- Each time an MTA receives a message not addressed to its system, this MTA collects all MX records for the destination that are not higher than its own MX record.
- If the MTA finds any MX records, it attempts to send to one of them, starting at the lowest preference.
- If the lowest MX record points to the MTA's own machine, then there's a mail misconfiguration: the MTA doesn't know what to do with it locally, but the MX is telling it to deliver it locally. When this happens, the MTA reject the message (" mail loops back to myself ").
- If there are no MX records at all (which implies that the MTA doesn't have one either), most, but not all versions of sendmail will look up an A record for the system name. If they find one, they will try to deliver there, and only there.
- If all else fails, the MTA rejects the message ("can't find the destination").
MTA files
MTAs use three different kinds of files:
- Configuration files tell the MTA what to do. Typical configuration issues include what name to present to the outside world, and when to accept mail for delivery and when to reject it. The issue of spam (unsolicited commercial email) makes this quite a complicated issue. Postfix keeps its configuration files in the directory /usr/local/etc/Postfix, and sendmail keeps them in /etc/mail.
- Outgoing postfix mail is stored in the directory hierarchy /var/spool/Postfix, while sendmail currently stores its mail in the hierarchies /var/spool/mqueue and /var/spool/clientmqueue.
- Incoming mail is stored in the directory /var/mail. Normally each user gets a file that corresponds to his user name.
Who gets the mail?
According to RFC 2822, a mail ID is something like grog@example.org. This looks very much like a user ID, the @ sign, and the name of a machine. This similarity is intended, but it's still only a similarity. Consider the system manager of example.org. At different times he might send mail from freebie.example.org, bumble.example.org, and wait.example.org. If the mail ID were associated with the machine, he would have three different mail IDs: fred@freebie.example.org, fred@bumble.example.org and fred@wait.example.org. It would make things a whole lot simpler (and easier to type) if his mail ID were simply fred@example.org. This name change is called masquerading.
One way to do this would be to associate the name example.org as a CNAME with one of the machines—say wait.example.org. This would work, but it would mean that mail would always have to come from and go to wait.example.org. If for any reason that machine were inaccessible, the mail would not get through. In practice, it's possible to run MTAs on more than one machine. DNS solves this problem with a special class of record, the MX record (mail exchanger). MX records can point to more than one machine, so if one machine is not accessible, the mail can be sent to another. We saw how to add them on page 370. MX records are not directly associated with any particular machine, though they point to the names of machines that run an MTA.
Postfix
Postfix is in the Ports Collection, not the base system, so before you can use it, you must install it. It is an interactive port: at various points in the installation process it asks for input. The first is a menu offering optional additional configurations, as shown in Figure 27-1 . For the configuration in this book, you don't need anything in addition to what the menu suggests; just select OK and continue.
Some time later you get the informational messages:
Added group "postfix". Added group "maildrop". Added user "postfix". You need user "postfix" added to group "mail". Would you like me to add it [y]? Enter pressed Done.
The build continues for a while, and finally you get the information:
Installed HTML documentation in /usr/local/share/doc/postfix ===> Generating temporary packing list Would you like to activate Postfix in /etc/mail/mailer.conf [n]? y
The output goes on to explain which fags to set in your system configuration file /etc/rc.conf. In particular, it tells you to set sendmail_enable and finishes by saying "This will disable Sendmail completely." This may look strange, especially if you don't have any sendmail-related entries in /etc/rc.conf. Why should setting sendmail_enable to YES disable sendmail? Well, it's a somewhat unfortunate choice of naming, and it's possible it will change, but the answer is in the details: sendmail_enable should really be called something like mail_enable. The other sendmail parameters turn off all sendmail-related components.