Configuring sendmail

The sendmail configuration files reside in /etc/mail, where the primary configuration file is sendmail.cf. This directory contains other text configuration files, such as access, mailertable, and virtusertable. The sendmail daemon does not read these files but instead reads the corresponding *.db files in the same directory.

makemap

You can use makemap or give the command make from the /etc/mail directory to generate the *.db files, although this step is not usually necessary. The sendmail init script automatically generates these files when you start or restart sendmail:

# /sbin/service sendmail restart

The sendmail.mc and sendmail.cf Files

This sendmail.cf file is not intended to be edited by hand and contains a large warning to this effect:

$ cat/etc/mail/sendmail.cf ... ###################################################################### ##### #####   DO NOT EDIT THIS FILE!  Only edit the source .mc file. ##### ###################################################################### ...

Editing sendmail.mc and Generating sendmail.cf

The sendmail.cf file is generated from sendmail.mc using the m4 macro processor. It can be helpful to use a text editor that supports syntax highlighting, such as vim, to edit sendmail.mc.

dnl

Many of the lines in sendmail.mc start with dnl, which stands for delete to new line; this token causes m4 to delete from the dnl to the end of the line (the next NEWLINE character). Because m4 ignores anything on a line after a dnl instruction, you can use dnl to introduce comments; it works the same way as # does in a shell script.

Many of the lines in sendmail.mc end with dnl. Because NEWLINEs immediately follow these dnls, these dnls are superfluous; you can remove them if you like.

After you edit sendmail.mc, you need to regenerate sendmail.cf to make your changes take effect. When you restart sendmail, the sendmail init script regenerates sendmail.cf.

About sendmail.mc

Lines near the beginning of sendmail.mc provide basic configuration information:

divert(-1)dnl include('/usr/share/sendmail-cf/m4/cf.m4')dnl VERSIONID('setup for Red Hat Linux')dnl OSTYPE('linux')dnl

The line that starts with divert tells m4 to discard extraneous output it may generate when processing this file.

The include statement tells m4 where to find the macro definition file that it will use to process the rest of this file; it points to the file named cf.m4. The cf.m4 file contains other include statements that include parts of the sendmail configuration rule sets.

The VERSIONID statement defines a string that indicates the version of this configuration. You can change this string to include a brief comment about changes you have made to this file or other information. The value of this string is not significant to sendmail.

Do not change the OSTYPE statement unless you are migrating a sendmail.mc file from another operating system.

Other statements you may want to change are explained in the following sections and in the sendmail documentation.

Tip: Quoting m4strings

The m4 macro processor, which converts sendmail.mc to sendmail.cf, requires strings to be preceded by a back tick (') and closed with a single quotation mark (').

Masquerading

Typically you want your email to appear to come from the user and the domain where you receive email; sometimes the outbound server is in a different domain than the inbound server. You can cause sendmail to alter outbound messages so that they appear to come from a user and/or domain other than the one they are sent from: In other words, you masquerade (page 1042) the message.

Several lines in sendmail.mc pertain to this type of masquerading. Each is commented out in the file that Red Hat distributes:

dnl MASQUERADE_AS('mydomain.com')dnl dnl MASQUERADE_DOMAIN(localhost)dnl dnl FEATURE(masquerade_entire_domain)dnl

The MASQUERADE_AS statement causes email that you send from the local system to appear to come from the specified domain (mydomain.com in the commented-out line in the distributed file). Remove the leading dnl and change mydomain.com to the domain name that you want mail to appear to come from.

The MASQUERADE_DOMAIN statement causes email from the specified system or domain to be masqueraded, just as local email is. That is, email from the system specified in this statement is treated as though it came from the local system: It is changed so that it appears to come from the domain specified in the MASQUERADE_AS statement. Remove the leading dnl and change localhost to the name of the system or domain that sends the email that you want to masquerade. If the name you specify has a leading period, it specifies a domain. If there is no leading period, the name specifies a system or host. The sendmail.mc file can include as many MASQUERADE_DOMAIN statements as necessary.

The masquerade_entire_domain feature statement causes sendmail also to masquerade subdomains of the domain specified in the MASQUERADE_DOMAIN statement. Remove the leading dnl to masquerade entire domains.

Accepting Email from Unknown Hosts

As configured by Red Hat, sendmail accepts email from domains that it cannot resolve (and that may not exist). To turn this feature off and cut down the amount of spam you receive, add dnl to the beginning of the following line:

FEATURE('accept_unresolvable_domains')dnl

When this feature is off, sendmail uses DNS to look up the domains of all email it receives. If it cannot resolve the domain, it rejects the email.

Setting Up a Backup Server

You can set up a backup mail server to hold email when the primary mail server experiences problems. For maximum coverage, the backup server should be on a different connection to the Internet from the primary server.

Setting up a backup server is easy. Just remove the leading dnl from the following line in the backup mail server's sendmail.mc file:

dnl FEATURE('relay_based_on_MX')dnl

DNS MX records (page 726) specify where email for a domain should be sent. You can have multiple MX records for a domain, each pointing to a different mail server. When a domain has multiple MX records, each record usually has a different priority; the priority is specified by a two-digit number, where lower numbers specify higher priorities.

When attempting to deliver email, an MTA first tries to deliver email to the highest-priority server. If that delivery attempt fails, it tries to deliver to a lower-priority server. If you activate the relay_based_on_MX feature and point a low-priority MX record at a secondary mail server, the mail server will accept email for the domain. The mail server will then forward email to the server identified by the highest-priority MX record for the domain when that server becomes available.

Other Files in /etc/mail

The /etc/mail directory holds most of the files that control sendmail. This section discusses three of those files: mailertable, access, and virtusertable.

mailertable: Forwards Email from One Domain to Another

When you run a mail server, you may want to send mail destined for one domain to a different location. The sendmail daemon uses the /etc/mail/mailertable file for this purpose. Each line in mailertable holds the name of a domain and a destination mailer separated by whitespace; when sendmail receives email for the specified domain, it forwards it to the mailer specified on the same line. Red Hat enables this feature by default: Put an entry in the mailertable file and restart sendmail to use it.

The following line in mailertable forwards email sent to tcorp.com to the mailer at bravo.com:

$ cat /etc/mail/mailertable tcorp.com          smtp:[bravo.com]

The square brackets in the example instruct sendmail not to use MX records but rather to send email directly to the SMTP server. Without the brackets, email could enter an infinite loop.

A period in front of a domain name acts as a wildcard and causes the name to match any domain that ends in the specified name. For example, .tcorp.com matches sales.tcorp.com, mktg.tcrop.com, and so on.

The sendmail init script regenerates mailertable.db from mailertable each time you run it, as when you restart sendmail.

access: Sets Up a Relay Host

On a LAN, you may want to set up a single server to process outbound mail, keeping local mail inside the network. A system that processes outbound mail for other systems is called a relay host. The /etc/mail/access file specifies which systems the local server relays email for. As configured by Red Hat, this file lists only the local system:

$ cat /etc/mail/access ... # by default we allow relaying from localhost... localhost.localdomain           RELAY localhost                       RELAY 127.0.0.1                       RELAY

You can add systems to the list in access by adding an IP address followed by whitespace and the word RELAY. The following line adds the 192.168. subnet to the list of hosts that the local system relays mail for:

192.168.                        RELAY

The sendmail init script regenerates access.db from access each time you run it, as when you restart sendmail.

virtusertable: Serves Email to Multiple Domains

When the DNS MX records are set up properly, a single system can serve email to multiple domains. On a system that serves mail to many domains, you need a way to sort the incoming mail so that it goes to the right places. The virtusertable file can forward inbound email addressed to different domains (aliases cannot do this).

As sendmail is configured by Red Hat, virtusertable is enabled. You need to put forwarding instructions in the /etc/mail/virtusertable file and restart sendmail to serve the specified domains. The virtusertable file is similar to the aliases file (page 633), except the left column contains full email addresses, not just local ones. Each line in virtusertable starts with the address that the email was sent to, followed by whitespace and the address sendmail will forward the email to. As with aliases, the destination can be a local user, an email address, a file, or a pipe symbol (|), followed by a command.

The following line from virtusertable forwards mail addressed to [e-mail] to zcs, a local user:

[e-mail] zcs

You can also forward email for a user to a remote email address:

[e-mail]          [e-mail]

You can forward all email destined for a domain to another domain without specifying each user individually. To forward email for every user at bravo.com to tcorp.com, specify @bravo.com as the first address on the line. When sendmail forwards email, it replaces the %1 in the destination address with the name of the recipient. The next line forwards all email addressed to bravo.com to tcorp.com, keeping the original recipients' names:

@bravo.com          [e-mail]

Finally you can specify that email intended for a specific user should be rejected by using the error namespace in the destination. The next example bounces email addressed to [e-mail] with the message 5.7.0:550 Invalid address:

[e-mail]          error:5.7.0:550 Invalid address

.forward, aliases, and virtusertable

The .forward (page 634), aliases (page 633), and virtusertable files all do the same thing: They forward email addressed to one user to another user. They can also redirect email to a file or to serve as input to a program. The difference between them is scope and ownership; see Table 20-1.