In 2002, Sendmail was the most popular MTA in the world, according to surveys of MTA use. It's also the MTA that's the default with most Linux distributions, including Caldera, Red Hat, Slackware, SuSE, and TurboLinux. Debian and Mandrake, although they install other SMTP servers by default, also provide the option of using sendmail. As I write, version 8.12.2 is the latest, but some Linux distributions still ship with older versions of 8.11. x or earlier.
Sendmail uses a fairly obtuse configuration file format, but utilities exist to configure the software by compiling a simpler file format into the one that sendmail actually reads. Knowing how to do this is critical to configuring sendmail. In addition to the configuration files themselves , this section covers a few specific areas of sendmail configuration: address masquerading, accepting incoming mail, and relay configuration.
Sendmail's Configuration Files
Sendmail's primary configuration file is called sendmail.cf , and it's usually located in /etc . This file is difficult to edit directly, though, because there are many options, they use very non-mnemonic names , and they're formatted in a way that's difficult to read.
To work around the difficulties inherent in directly editing sendmail.cf , most distributions use the m4 macro processing utility to create the sendmail.cf file from a simpler and more easily understood file. The m4 source file usually has a filename that ends in .mc , but the exact name varies from one distribution to another. For instance, in Red Hat it's /etc/sendmail.mc , in Slackware it's /usr/src/sendmail/cf/cf/linux.smtp.mc , and in SuSE it's /etc/mail/linux.mc . No matter the name, the m4 source files are much shorter and more readable than the .cf files they create. For instance, in SuSE 7.1, the sendmail.cf file is 1669 lines long, whereas the linux.mc file that creates it is only 221 lines long ”and most of those lines are comments (lines that begin with dnl ). A working sendmail m4 file can be less than 50 lines long.
To create a sendmail.cf file from an m4 file, you must run the m4 command, using input redirection to feed it the m4 configuration file and using output redirection to send the output to a file. For instance, you might use the following command on SuSE Linux:
# m4 < /etc/mail/linux.mc > /etc/sendmail.cf
You'll have to restart sendmail after you rebuild its configuration file in order to see your changes take effect. Most distributions start sendmail through SysV scripts, so you should restart sendmail via the script's restart option.
Most options in an m4 configuration file take the following form:
FEATURE-NAME( ` option1'[, ` option2'[,...])
The FEATURE-NAME is a name that's at least somewhat descriptive, such as define or MASQUERADE_AS . The options ( option1 , option2 , and so on) may be hostnames, sendmail-specific option names such as always_add_domain , and so on. Some feature definitions can omit the single quote marks, but most use them.
In addition to the sendmail.cf file and the m4 file that creates it, sendmail relies on additional files. A couple of the more important of these include the following:
You'll probably find these files in /etc or /etc/mail , along with other database files that control other details of sendmail's operation. These files are referenced by the m4 file, and by sendmail.cf .
Sendmail Address Masquerading
If you want your SMTP server to announce itself under a name other than its regular hostname, you must configure sendmail to perform some form of address masquerading, as described earlier. There are two lines you can set in your m4 configuration file to activate two different facets of address masquerading:
MASQUERADE_AS(` desired-address ') FEATURE(masquerade_envelope)
The MASQUERADE_AS feature enables the most basic level of masquerading, which only changes the address used in the mail header's From: field if the user's mail program doesn't specify a hostname. Because many mail programs set this field, this option is most useful as a fallback in case a user's mail program isn't completely or correctly configured. The FEATURE (masquerade_envelope) line does more, because it actively changes the From: header even if the sender's mail program set this option.
If you want your masquerading to apply only to mail from certain domains' users, you can use a couple of additional lines to limit the application of these masquerading features:
MASQUERADE_DOMAIN(` source-domain ') FEATURE(`limited_masquerade')
These options tell sendmail to limit its masquerading to addresses within the specified source-domain . Such a configuration is most likely to be helpful if your system functions as a mail server for two domains; you can set it to masquerade as a system within the appropriate domain for each message it sends.
Configuring Sendmail to Accept Mail
When a remote server sends mail to your system, the mail is addressed to a specific user on a specific computer. In order to accept delivery of local mail, sendmail must be able to recognize all the local addresses, as described earlier. Sendmail allows you to add all the names for the mail server to a local hostnames file, including the raw domain name if you've configured an MX record for it. This file has different names in different distributions, and these names are set in files loaded with the sendmail m4 package. In Red Hat, it's /etc/mail/local-host-names ; in SuSE, it's /etc/sendmail.cw . If you can't find the file, try searching for a line in sendmail.cf that begins Fw . This line sets the name of the local hostnames file. Whatever its name, this file consists of a series of lines, each of which contains a hostname that the computer will consider to be local. Sendmail ignores lines that begin with a pound sign ( # ), though. You can omit the computer's regular hostname, although including it will do no harm.
Sendmail Relay Configuration
As described earlier, relay configurations are extremely important in setting up a mail server. You must be able to configure sendmail to relay its own mail, possibly mail from the local network, and perhaps even mail from remote networks, as appropriate, without opening up the system as one that might be abused by spammers. In addition, you may want or need to configure the system to send its outgoing mail through another system as a relay. Fortunately, sendmail offers many mail relay options.
Configuring Sendmail to Relay Mail
One common mail relay configuration is to have a mail server forward mail for a local network. The idea is to use a mail server to relay mail, storing it temporarily in the event of network problems. You then point other local systems' mail programs to the mail server.
Out of the box, most sendmail installations will not work as mail relays. If you try it, the mail server refuses to relay the message. Most mail clients inform you that they've received a "relaying denied " response from the mail server. Sendmail allows you to activate several different relay options if you want it to function as a relay. You can include any of the following options in a FEATURE line:
An example of a relay configuration line is the following:
This option is present in many installations' default m4 configuration files, but it doesn't actually enable practical relaying because the default access.db file permits only localhost relaying, as described shortly. If the access_db option is active, sendmail reads the access.db file when it starts. As described earlier, this file is usually stored in /etc or /etc/mail , and it's built from a file called access . A typical access file looks like this:
# Allow relaying from localhost... localhost.localdomain RELAY localhost RELAY 127.0.0.1 RELAY # Relay for the local network 192.168.99 RELAY
The first three entries are present in most configurations; they tell sendmail to accept mail from the localhost computer (that is, the sendmail computer itself) for relaying. Some local mail programs rely on such a configuration. The final entry tells sendmail to relay any mail that comes from the 192.168.99.0/24 network. You can also provide hostnames or domain names instead of IP addresses, but IP addresses are slightly harder to forge , and so are preferable whenever possible.
All of the preceding examples end in RELAY , but there are other options you can use:
Once you've edited the access file, you can create a binary database file from it with the makemap command, thus:
# makemap hash /etc/mail/access.db < /etc/mail/access
Many sendmail installations include such a command in their startup scripts, so this step may not be strictly necessary. Either way, you should restart sendmail to have it reread the access file.
Configuring Sendmail to Send Through a Relay
The preceding section dealt with the question of using sendmail as a mail relay. There's one other aspect of relay configuration you may want to consider, though: Having sendmail use another system as a mail relay. You might do this if you run a small network or even a single computer, and want or need to use your ISP's mail server as a relay. Although Linux and sendmail are capable of queuing mail locally and delivering it directly, a few ISPs require you to use their own mail servers for outgoing mail. Some mail servers refuse mail that's sent directly from dial-up IP addresses that are listed on certain anti-spam lists, so dial-up users may need to use this approach to send mail reliably. Also, some Linux systems ”particularly laptops ”might be shut down much of the time, so you'd do well to configure them to use another system as a mail relay.
Most Linux distributions' sendmail configurations don't use an outgoing mail relay, but you can use one by adding a single line to your m4 configuration file:
In this example, outgoing.mail.relay is the hostname of the computer that's to relay your mail. After you rebuild sendmail.cf and restart the server, it should relay all mail through the specified outgoing mail server. Be sure to test that mail is being delivered correctly after making this change.
Sendmail Anti-Spam Configuration
There are several ways to configure sendmail to block spam and to prevent unauthorized relay use. One simple anti-spam configuration is to use the access file and its binary equivalent, access.db , to block spam based on source hostnames or domains. If you associate a hostname, domain name, or IP address with a REJECT or DISCARD action, as described earlier, sendmail will block all mail from that address. This can be an effective tool if you regularly receive spam from certain source sites, but you should be cautious about using this approach; you can easily block a great deal of legitimate mail if spammers happen to abuse a popular ISP.
Another approach to blocking incoming spam with sendmail is to use one or more blackhole lists. You can do this with the dnsbl feature in your m4 file, thus:
FEATURE(dnsbl, `blackholes.mail-abuse.org', `Rejected - see \ http://www.mail-abuse.org/ rbl/')
This line causes sendmail to use the MAPS RBL. Change the second option of FEATURE to the value listed in the Server Address column of Table 19.1 to use another blackhole list. The final argument is a string that's included in bounced mail. You should use it to point the bounce recipient to the appropriate blackhole list's Web site, so that if legitimate e-mail is mistakenly bounced, the sender can take steps to correct the problem. You can specify multiple blackhole lists if you like.
Preventing unauthorized relaying with sendmail is a matter of configuring sendmail to relay in the most stringent manner possible. The simplest approach is usually to list individual IP addresses or IP address blocks in access , but some of the other relay options may be useful in some situations. You should never use the promiscuous_relay feature.