Basic Sendmail Configuration

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  

NOTE

Some distributions require you to install a separate package of support files before you can build your m4 source files into a working sendmail.cf file. For instance, Red Hat needs the sendmail-cf package before you can rebuild a sendmail configuration file.

WARNING

Be sure not to overwrite a working sendmail.cf file. It's generally best to back up this file, and your original m4 source file, to a location in another directory. This way if something goes wrong and you can't seem to get sendmail working again, you can restore the original files.

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.

WARNING

When present, the single quote marks surrounding the options are unusual because they're dissimilar. The opening quote in any given option is a backquote character ( ` ), which is located on the key to the left of the 1 key on most keyboards. The ending quote is a regular single quote character, which is located on the key to the right of the semicolon ( ; ) key on most keyboards. If you use two regular single quote characters , as you would in most configuration files, either m4 won't be able to process the file or the sendmail configuration file will not work as expected.

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:

• access.db ” This file is a binary file that's derived from the plain-text access file. This file controls what computers may access sendmail in what ways. Sendmail relay configurations, described shortly, often depend upon this file's contents. Most sendmail startup scripts run makemap to automatically generate access.db if access has changed since the last time access.db was built.

• aliases.db ” This is another binary file derived from a text file with a similar name ( aliases ). It defines mail aliases ”that is, names that are to be considered equivalent to one another. For instance, most distributions set up postmaster as an alias for root , and you may want to set up an alias for root to direct root 's mail to your ordinary user account. As with access.db , many sendmail startup scripts automatically generate aliases.db from aliases .

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:

• relay_entire_domain ” When this option is used, sendmail accepts relay mail that originates from within its own domain, or that's addressed to any system within its local domain. Sendmail uses DNS to verify the sender's domain based upon the IP address. This can be a quick and convenient way to enable relaying.

• relay_local_from ” This option tells sendmail to accept relays of any message that uses a From: address within sendmail's local domain. This differs from the preceding option in that this one uses only the claimed address in the From: header, which is easily forged. This option is therefore a poor one from an anti-spam point of view.

• relay_based_on_MX ” This option tells sendmail to accept a relay if the domain in which the sender resides lists your sendmail system as a mail exchanger . This can be a quick and convenient way to control relaying, because you don't need to modify the sendmail configuration if you want to add domains; you need only modify the DNS records. The drawback is that spammers who control their own domains can easily adjust their MX records and hijack your mail server.

• relay_hosts_only ” If you use this option, sendmail uses an access database, described shortly. Only individual hosts listed in this database are allowed to relay. This can be a good way to limit relays to an arbitrary set of computers.

• access_db ” Many sendmail configurations use this option by default. Like relay_hosts_only , it causes sendmail to use an access database. This option causes the database to be interpreted a bit more loosely, though; you can list entire domains in the database by using this option.

WARNING

A final option, promiscuous_relay , should be avoided at all costs. This feature tells sendmail to accept any relay request. Such an open relay configuration is almost certain to be discovered and abused by spammers.

An example of a relay configuration line is the following:

 FEATURE(`access_db') 

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:

• OK ” This option tells sendmail to accept the mail for local delivery even if other rules would cause the mail to be rejected.

• RELAY ” As you might guess, this causes sendmail to relay mail that originates from the specified host or domain. It also causes mail addressed to these hosts or domains to be relayed, as well.

• REJECT ” If you want to block mail coming from or going to a given host or domain, you can use this option, which rejects the mail and generates a bounce message.

• DISCARD ” This option works very much like REJECT , but no bounce message is generated.

• nnn text ” This is another option that works like REJECT , but it generates the error code nnn along with text as a bounce message.

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:

 FEATURE(`nullclient', `outgoing.mail.relay') 

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.

NOTE

The use of blackhole lists has changed substantially with sendmail 8.10, and this discussion applies to that version and later. Prior versions had much less sophisticated blackhole provisions. Consult http://mail-abuse.org/rbl/usage.html for further information on this point.

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.

WARNING

If you're using a version of sendmail that's older than 8.9.0, it's probably configured to allow relays by default. You should upgrade to a newer version of sendmail, or consult http://mail-abuse.org/tsi/ar-fix.html#sendmail_8 for information on how to reconfigure sendmail to not relay promiscuously. Versions prior to 8.8.4 are not easily reconfigured to prevent unauthorized relays; they should almost certainly be upgraded.