Cover | Table of Contents | Colophon

Table of Contents

Chapter 1: Getting Started

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

To follow a recipe successfully, you must clearly understand the instructions it contains. You must understand the difference between folding and stirring and be able to find the spices when the recipe calls for a pinch of cumin. Just as you must be able to find your way around the kitchen to become a cook, you must know your way around the sendmail distribution in order to build or customize a sendmail configuration.

The directory structure—created by the sendmail source code distribution tarball— contains the tools and ingredients used to build and configure sendmail. The top-level directory created by the tarball is assigned a name that identifies the sendmail version number. At the time of this writing, the current version is sendmail 8.12.9; therefore, the top-level directory is named sendmail-8.12.9. By the time you read this, there will be a newer version of sendmail, and the directory name will reflect that new version number. An ls of the top-level directory shows the following:

$ ls sendmail-8.12.9
Build     doc      INSTALL    libsmdb     mailstats  praliases      sendmail
cf        editmap  KNOWNBUGS  libsmutil   Makefile   README         smrsh
contrib   FAQ      libmilter  LICENSE     makemap    RELEASE_NOTES  test
devtools  include  libsm      mail.local  PGPKEYS    rmail          vacation

Most of these files and directories are used to compile sendmail. The Build script uses the Makefile to compile sendmail and its utilities. The devtools directory is used to set compiler options, as discussed in Recipe 1.2 to Recipe 1.7. The source code is located in aptly named subdirectories. For example, the sendmail source code is in the sendmail directory, the libraries are in directories such as libsm and libsmutil, and the source code of utilities such as makemap and smrsh is located in easily identified directories.

There are also several important sources of information in the distribution:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Introduction

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

To follow a recipe successfully, you must clearly understand the instructions it contains. You must understand the difference between folding and stirring and be able to find the spices when the recipe calls for a pinch of cumin. Just as you must be able to find your way around the kitchen to become a cook, you must know your way around the sendmail distribution in order to build or customize a sendmail configuration.

The directory structure—created by the sendmail source code distribution tarball— contains the tools and ingredients used to build and configure sendmail. The top-level directory created by the tarball is assigned a name that identifies the sendmail version number. At the time of this writing, the current version is sendmail 8.12.9; therefore, the top-level directory is named sendmail-8.12.9. By the time you read this, there will be a newer version of sendmail, and the directory name will reflect that new version number. An ls of the top-level directory shows the following:

$ ls sendmail-8.12.9
Build     doc      INSTALL    libsmdb     mailstats  praliases      sendmail
cf        editmap  KNOWNBUGS  libsmutil   Makefile   README         smrsh
contrib   FAQ      libmilter  LICENSE     makemap    RELEASE_NOTES  test
devtools  include  libsm      mail.local  PGPKEYS    rmail          vacation

Most of these files and directories are used to compile sendmail. The Build script uses the Makefile to compile sendmail and its utilities. The devtools directory is used to set compiler options, as discussed in Recipe 1.2 to Recipe 1.7. The source code is located in aptly named subdirectories. For example, the sendmail source code is in the sendmail directory, the libraries are in directories such as libsm and libsmutil, and the source code of utilities such as makemap and smrsh is located in easily identified directories.

There are also several important sources of information in the distribution:

• The INSTALL

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Downloading the Latest Release

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You must keep your sendmail software up-to-date.

Sticking with the standard software management method used on your system is the easiest way to upgrade sendmail. If you use a package manager, go to your Unix vendor's web site, download the appropriately packaged sendmail update, and install it using the package manager. If the vendor cannot provide a critical sendmail update or does not provide the compiled-in features you need, and you decide to use the sendmail source code distribution, gracefully transition from the package manager to the source code distribution by following the Unix vendor's advice on how to remove a package that was installed by the package manager. Recipe 1.1.3 shows an example of using the Red Hat Package Manager to remove the sendmail RPM before the sendmail source code distribution is installed.

If you need to use the sendmail source code distribution, download the latest version of sendmail from ftp://ftp.sendmail.org/, from http://www.sendmail.org/current-release.html, or from one of a large number of mirror sites. A link to the mirror sites is found on the http://www.sendmail.org/ home page. The Discussion section provides an example of downloading the sendmail source code distribution via ftp.

Get the signature file associated with the version of sendmail you downloaded. For example, the signature file for the sendmail.8.12.9.tar.gz tarball downloaded in the Discussion section is sendmail.8.12.9.tar.gz.sig.

Download the PGP keys needed to verify the signature, and add them to your key ring (you only need to do this approximately once a year). After the PGP keys are added to your key ring, they can be used to verify the signature file of any further downloads made during that calendar year.

Use the pgp or gpg programs to verify the signature of the downloaded file (the Discussion section shows an example using gpg). If you accept the signature, restore the sendmail distribution tarball file.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Installing sendmail

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The sendmail tarball is a source code distribution that must be compiled. Additionally, adding a special user ID and group ID may be necessary before the new sendmail software can be installed and used.

Compile sendmail using the Build utility provided by the sendmail developers. For most systems, only a few commands are needed to compile sendmail:

# cd sendmail-8.12.9
# ./Build
            

The next installation step is to create the smmsp user and group for sendmail to use when it runs as a mail submission program. Do this by using the tools appropriate to your system. Here are the /etc/passwd and /etc/group entries added to the example Red Hat system used throughout this book:

# grep smmsp /etc/passwd
smmsp:x:25:25:Mail Submission:/var/spool/clientmqueue:/sbin/nologin
# grep smmsp /etc/group
smmsp:x:25:

Next, backup the current sendmail binary, the sendmail utilities, and the current sendmail configuration files. After the system is backed up, install the new sendmail and utilities as follows:

# ./Build install
            

Build detects the architecture of the system and builds a Makefile customized to that system. It then uses make to compile sendmail. Build does an excellent job of correctly detecting the system architecture.

A basic Build command should work for most situations. If it doesn't work for you, either because of your unique hardware and software, or because you have unique requirements, create a custom configuration for Build to use. sendmail calls these custom configurations site configurations and looks for them in the devtools/Site directory, where it expects to find the local custom configuration stored under the name site.config.m4. By default, Build looks for files named site.OS .m4, where OS is the name of the computer's operating system,

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Compiling sendmail to Use LDAP

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

sendmail must be compiled with the correct options in order to read data from an LDAP server. The LDAP server must also be properly configured to understand queries from sendmail.

Use the command sendmail -bt -d0.1 to check the sendmail compiler options. If the string LDAPMAP appears in the "Compiled with:" list, there is no need to recompile sendmail. If LDAPMAP does not appear in the "Compiled with:" list, recompile sendmail to add LDAP support.

To add LDAP support, set LDAP values in the site.config.m4 file and recompile sendmail as shown below:

# cd /usr/local/src/sendmail-8.12.9/devtools/Site
# cat >> site.config.m4
               APPENDDEF(`confMAPDEF', `-DLDAPMAP')
               APPENDDEF(`confLIBS', `-lldap -llber')
               Ctrl-D
# cd /usr/local/src/sendmail-8.12.9
# ./Build -c
            

After recompiling sendmail, reinstall it:

# ./Build install
            

The LDAP server must also be configured to work with sendmail. Give the LDAP administrator a copy of the sendmail.schema file, which is found in the cf directory of the sendmail distribution. The LDAP administrator must store the sendmail.schema file in the appropriate directory on the LDAP server. For example, an LDAP server running OpenLDAP often stores schema files in the /etc/openldap/schema directory.

Next, the LDAP administrator must add the sendmail.schema file to the LDAP configuration. On a system running OpenLDAP, add the following include to the /etc/openldap/slapd.conf file:

include         /etc/openldap/schema/sendmail.schema

Restart LDAP on the LDAP server to ensure that the sendmail schema are included in the LDAP configuration. Here is an example from an LDAP server running OpenLDAP:

# ps -ax | grep slapd
 1426 ?        S      0:00 /usr/sbin/slapd -u ldap
# kill -TERM 1426
# /usr/sbin/slapd -u ldap
            

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Adding the regex Map Type to sendmail

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Support for the regex map type must be compiled into sendmail if the error message "class regex not available" is displayed when sendmail is run.

To add support for the regular expression map type, add MAP_REGEX to the confMAPDEF compiler variable in the site.config.m4 file and then recompile sendmail. Here is an example:

# cd /usr/local/src/sendmail-8.12.9/devtools/Site
# cat >> site.config.m4
               APPENDDEF(`confMAPDEF', `-DMAP_REGEX')
               Ctrl-D
# cd /usr/local/src/sendmail-8.12.9
# ./Build -c
            

After recompiling sendmail, reinstall it:

# ./Build install
            

Attempting to run a configuration that specifies a regex map type on a sendmail system without regex support compiled in produces an error, as this test shows:

# sendmail -bt
sendmail.cf: line 115: readcf: map dottedquad: class regex not available
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> /quit
            

The first line after the sendmail -bt command is an error message. It tells us that line 115 in the sendmail.cf file contains a K command that defines a map using the regex map type, which results in an error because regex is not supported on this system.

The fix for this requires defining a local compiler variable in the site.config.m4 file in the devtools/Site directory. The APPENDDEF command used in the Solution section appends the -DMAP_REGEX command-line argument to any values that already exist in the confMAPDEF variable. The Build command that is used to recompile sendmail uses the -c flag to ensure that Build incorporates the new data from the site.config.m4 file.

After compiling sendmail, run it with the -bt and the -d0.1 command-line arguments to check the compiler options:

# sendmail -bt -d0.1
Version 8.12.9
 Compiled with: DNSMAP LOG MAP_REGEX MATCHGECOS MIME7TO8 MIME8TO7 NEWDB
                NAMED_BIND NETINET NETUNIX PIPELINING SCANF USERDB XDEBUG

============ SYSTEM IDENTITY (after readcf) ============
      (short domain name) $w = chef
  (canonical domain name) $j = chef.wrotethebook.com
         (subdomain name) $m = wrotethebook.com
              (node name) $k = chef
========================================================

ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> 

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Compiling sendmail with SASL Support

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

sendmail must be compiled with SASL support before it can be configured to offer the AUTH protocol extension.

Check the sendmail compiler options. If sendmail was compiled with the SASL flag, it does not need to be recompiled. If sendmail was not compiled with SASL support, add SASL to the -D flags used to specify compiler environment information, add sasl to the -l flags used to select libraries for linking, and recompile sendmail. After recompiling sendmail, reinstall and restart it.

Use the -d0.1 flag to check the compiler options of the sendmail binary. The SASL flag should be clearly shown in the "Complied with:" list, as in this example:

# sendmail -bt -d0.1
Version 8.12.9
 Compiled with: DNSMAP LOG MAP_REGEX MATCHGECOS MIME7TO8 MIME8TO7
                NAMED_BIND NETINET NETUNIX NEWDB PIPELINING SASL
                SCANF USERDB XDEBUG

============ SYSTEM IDENTITY (after readcf) ============
      (short domain name) $w = chef
  (canonical domain name) $j = chef.wrotethebook.com
         (subdomain name) $m = wrotethebook.com
              (node name) $k = chef
========================================================

ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> /quit
            

If the flag is not displayed, create a site.config.m4 file in the devtools/Site directory that contains the following commands:

               APPENDDEF(`conf_sendmail_ENVDEF', `-DSASL')
               APPENDDEF(`conf_sendmail_LIBS', `-lsasl')
            

Recompile, reinstall, and restart sendmail, as in this example:

# cd /usr/local/src/sendmail-8.12.9
# ./Build -c
               ...many lines of output deleted...
# cd /usr/local/src/sendmail-8.12.9/sendmail
# ./Build install
               ...many lines of output deleted...
# kill -HUP `head -1 /var/run/sendmail.pid`
            

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Compiling sendmail with STARTTLS Support

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

sendmail must be specially compiled to support the STARTTLS extension.

Use the command sendmail -bt -d0.1 to check the sendmail compiler options. If the string STARTTLS appears in the "Compiled with:" list, there is no need to recompile sendmail. If sendmail was not compiled with STARTTLS support, edit the devtools/Site/site.config.m4 file to add STARTTLS to the compiler's -D flags and to add ssl and crypto to the -l flags used to select libraries for linking. See the following example:

# cd /usr/local/src/sendmail-8.12.9/devtools/Site
# cat >> site.config.m4
               APPENDDEF(`conf_sendmail_ENVDEF', `-DSTARTTLS')
               APPENDDEF(`conf_sendmail_LIBS', `-lssl -lcrypto')
               Ctrl-D
            

Recompile, reinstall, and restart sendmail:

# cd /usr/local/src/sendmail-8.12.9
# ./Build -c
               ...many lines of output deleted...
# ./Build install
               ...many lines of output deleted...
# kill -HUP `head -1 /var/run/sendmail.pid`
            

In the sample site.config.m4 file, the first APPENDDEF command adds -DSTARTTLS to the list of compiler options stored in the conf_sendmail_ENVDEF define. The second APPENDDEF command adds -lssl and -lcrypto to the list of libraries stored in the conf_sendmail_LIBS define.

Build is then used to recompile sendmail. The -c option on the Build command line ensures that Build detects the changes made to the site.config.m4 file. Build install is run to install the freshly compiled sendmail binary. The HUP signal is used to restart sendmail with the new binary.

After recompiling sendmail, rerunning sendmail with the -d0.1 option shows that STARTTLS is included in the "Compiled with:" list. sendmail can now be configured to offer

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Compiling in STARTTLS File Paths

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

When compiling sendmail to support the STARTTLS extension, "No such file or directory" errors are displayed in regard to OpenSSL files.

Set the correct path values in conf_sendmail_INCDIRS and conf_sendmail_LIBDIRS to tell sendmail where the OpenSSL files are located. Add the defines to the site.config.m4 configuration file, as in this example:

# cd /usr/local/src/sendmail-8.12.9/devtools/Site
# cat >> site.config.m4
               APPENDDEF(`conf_sendmail_INCDIRS', `-I/usr/share/ssl/include')
               APPENDDEF(`conf_sendmail_LIBDIRS', `-L/usr/share/ssl/lib')
               Ctrl-D
            

Recompile, reinstall, and restart sendmail:

# cd /usr/local/src/sendmail-8.12.9
# ./Build -c
               ...many lines of output deleted...
# ./Build install
               ...many lines of output deleted...
# kill -HUP `head -1 /var/run/sendmail.pid`
            

The sendmail configuration assumes that OpenSSL is installed in the standard location. If it is not, "No such file or directory" errors are displayed during the sendmail build when the system attempts to use the OpenSSL files. Use APPENDDEF commands to add the correct location of the OpenSSL include file to the conf_sendmail_INCDIRS variable and the correct location of the OpenSSL library to the conf_sendmail_LIBDIRS variable. The APPENDDEF commands are added to the site.config.m4 file.

After defining the correct values in site.config.m4, recompile sendmail with the Build -c command. If the path values are correctly defined, the build should run without errors.

Recipe 1.2 to Recipe 1.6 provide additional information on compiling sendmail. In particular, Recipe 1.6 provides an example of compiling sendmail with STARTTLS support. Chapter 8 covers STARTTLS configuration. The

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Building a sendmail Configuration

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

sendmail configurations are written using m4 macros. The configuration must be processed by m4 to produce the sendmail.cf configuration file that is read by sendmail.

Change to the configuration directory.

Create the m4 master configuration file. For this example, we name the master configuration file sendmail.mc.

Build the sendmail.cf file, copy it to the standard directory, and restart the sendmail daemon:

# ./Build sendmail.cf
Using M4=/usr/bin/m4
rm -f sendmail.cf
/usr/bin/m4 ../m4/cf.m4 sendmail.mc > sendmail.cf || ( rm -f sendmail.cf && exit 1 )
chmod 444 sendmail.cf
# cp /etc/mail/sendmail.cf /etc/mail/sendmail.cf.bak
# cp sendmail.cf /etc/mail/sendmail.cf
# kill -HUP `head -1 /var/run/sendmail.pid`
            

Notice, in this example, that sendmail is restarted with a HUP signal. This assumes that sendmail is already running with some current configuration, which is a good assumption for the majority of recipes in this book. If, however, sendmail has just been installed, is not running, and has not been previously configured, use Build install-cf to properly install both the sendmail.cf file and the submit.cf file. See Recipe 1.8.3.3 of the following discussion for an example of the Build install-cf command.

New sendmail configurations are generally built inside the cf/cf directory. Of course, cf/cf is a relative path, so where this directory is located can vary from system to system. For example, the Red Hat RPM places the configuration files in /usr/share/sendmail-cf/cf. If you're using the sendmail distribution, the cf/cf directory is relative to where you installed the distribution. All of the examples in this book assume you're using the sendmail 8.12.9 distribution and that you installed it in /usr/local/src. Given these assumptions, the following

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Testing a New Configuration

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You need to test the sendmail configuration before it is deployed.

Use the sendmail command-line options -bt, -bv, and -v.

At the end of Recipe 1.8, the newly created sendmail.cf is copied over the old configuration. Do not copy a customized configuration into the /etc/mail directory until it is thoroughly tested. sendmail provides excellent test tools that are used extensively in this book.

The single most important tool for testing sendmail is sendmail itself. When started with the -bt command-line option, sendmail enters test mode . While in test mode, sendmail accepts a variety of commands that examine the configuration, check settings, and observe how email addresses are processed by sendmail. Table 1-2 lists the commands that are available in test mode.

Table 1-2: sendmail test mode commands

Command	Usage
rulesets address	Process the address through the comma-separated list of rulesets.
=S ruleset	Display the contents of the ruleset.
=M	Display all of the mailer definitions.
$ v

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Logging sendmail

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Debugging a problem in the sendmail configuration may require more detailed information than sendmail logs by default.

Use the LogLevel option, either on the sendmail command line using the -O flag or in the sendmail configuration using the confLOG_LEVEL define, to increase the LogLevel above the default level of 9.

If the confLOG_LEVEL define is used, rebuild and reinstall sendmail.cf, and restart sendmail, as described in Recipe 1.8.

sendmail logs messages through syslog using the mail facility. Where the messages are logged is determined by the syslog.conf file. A grep of syslog.conf shows where the sendmail messages are logged on our sample Linux system:

$ grep mail /etc/syslog.conf
# Log anything (except mail) of level info or higher.
*.info;mail.none;authpriv.none;cron.none            /var/log/messages
# Log all the mail messages in one place.
mail.*                                              /var/log/maillog

Disregarding the comments, there are two lines in this particular syslog.conf file that mention the mail facility. The first line has a wildcard character in the facility field, meaning that it applies to every syslog facility. At first glance, you might think this applies to sendmail messages until you notice mail.none, which means that no messages from the mail facility will be logged in /var/log/messages. /var/log/maillog is the place to look for sendmail log entries on this sample Linux system. The mail.* entry means that, no matter what the level, all messages from the mail facility are logged in /var/log/maillog. Of course, this syslog.conf file is specific to our sample system. Your file might look different and, even if it looks exactly like this one, you can change it in anyway that you wish. You completely control where sendmail logs messages.

The syslog.conf file controls where sendmail messages are logged. The sendmail

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Chapter 2: Delivery and Forwarding

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Inbound mail is either delivered directly to the addressee or relayed to another mail host for delivery. Mail is directly delivered only if it is destined for the local host; mail destined for any other host is relayed. In this chapter, we look at ways to properly configure sendmail to deliver mail locally and forward it to other systems.

Delivery is a multistep process. First, sendmail must process the host portion of the delivery address and recognize that the mail is, in fact, addressed to the local host. If it isn't addressed to the local host, it is relayed as described in Chapter 3. If it is addressed to the local host, the user portion of the address is processed against the aliases file to determine the proper delivery address. If the aliases file returns an external address, the mail is forwarded to the external host for delivery. If it returns the address of a local mailbox, sendmail checks for a .forward file. If the .forward file exists, the mail is delivered as specified by that file. Otherwise, the mail is delivered to the local mailbox. Figure 2-1 illustrates this delivery flow.

Figure 2-1: The multistep delivery process

sendmail processes each delivery address through the canonify ruleset and through the parse ruleset—rulesets 3 and 0. Aliasing starts when the result of that process tells sendmail to deliver the mail through a mailer that has the A flag set. If ruleset 0 returns the name of a mailer that does not have the A flag set, aliasing is not done. While the A flag can be set for any mailer, only the cyrus mailers and the local mailer set the A flag by default. For our discussion of aliasing, we'll use the local mailer as an example.

Aliasing first looks up the delivery address in the aliases database. If the lookup returns a different email address, the new address is processed. If the mailer used for the new address has the

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Introduction

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Inbound mail is either delivered directly to the addressee or relayed to another mail host for delivery. Mail is directly delivered only if it is destined for the local host; mail destined for any other host is relayed. In this chapter, we look at ways to properly configure sendmail to deliver mail locally and forward it to other systems.

Delivery is a multistep process. First, sendmail must process the host portion of the delivery address and recognize that the mail is, in fact, addressed to the local host. If it isn't addressed to the local host, it is relayed as described in Chapter 3. If it is addressed to the local host, the user portion of the address is processed against the aliases file to determine the proper delivery address. If the aliases file returns an external address, the mail is forwarded to the external host for delivery. If it returns the address of a local mailbox, sendmail checks for a .forward file. If the .forward file exists, the mail is delivered as specified by that file. Otherwise, the mail is delivered to the local mailbox. Figure 2-1 illustrates this delivery flow.

Figure 2-1: The multistep delivery process

sendmail processes each delivery address through the canonify ruleset and through the parse ruleset—rulesets 3 and 0. Aliasing starts when the result of that process tells sendmail to deliver the mail through a mailer that has the A flag set. If ruleset 0 returns the name of a mailer that does not have the A flag set, aliasing is not done. While the A flag can be set for any mailer, only the cyrus mailers and the local mailer set the A flag by default. For our discussion of aliasing, we'll use the local mailer as an example.

Aliasing first looks up the delivery address in the aliases database. If the lookup returns a different email address, the new address is processed. If the mailer used for the new address has the

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Accepting Mail for Other Hosts

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You must configure sendmail to accept mail for local delivery that is addressed to other hosts. A common reason for doing this is to configure a mail exchanger to accept mail for a domain or for individual hosts.

Create an /etc/mail/local-host-names file. Put into that file the hostnames and domain names for which sendmail should accept mail for local delivery. Enter the names with one hostname or domain name per line.

Add the use_cw_file feature to the sendmail configuration to make use of the newly created local-host-names file. Here are sample lines that could be added to the configuration, if it does not already contain the use_cw_file feature:

dnl Load class $=w with other names for the local host 
FEATURE(`use_cw_file')

Finally, rebuild the sendmail.cf file, copy the new sendmail.cf file to /etc/mail, and restart sendmail, as shown in Recipe 1.8.

Mail addressed to one host can be routed to another host for a variety of reasons: forwarding, relaying, mailertable entries, and so on. One common reason for routing mail in this manner is because DNS says to do so. A system sending mail routes the mail based on information obtained from DNS. Mail is addressed to some hostname. The remote system takes that hostname and asks DNS if it has mail exchange (MX) records for that host. If no MX record is found for a given host, the address record of the host is obtained from DNS, and the mail is sent directly to the host. If DNS returns MX records, the remote system sends the mail to the system with the lowest preference number listed on the MX record.

Regardless of why the mail is routed to your mail host, the sendmail system must be configured to accept the mail or it will generate a Relaying denied error. This is an interesting error because the remote system is not necessarily trying to relay mail; it may be attempting to deliver the mail to the mail exchanger as directed by DNS. However, sendmail only accepts inbound mail for delivery that is addressed to the local system. All other mail is relayed. For local delivery, sendmail accepts mail that is addressed to another host only if it finds the name of that host in class

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Fixing the Alias0 Missing Map Error and Creating Simple Aliases

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

sendmail displays the following error message:

hash map "Alias0": missing map file /etc/mail/aliases.db: No such file or directory

Create a text file named /etc/mail/aliases and populate that file with entries in the form of:

               alias: recipient
            

where alias is an alias username and recipient is the address to which mail addressed to the alias is delivered.

Run newaliases to process the text file and build the aliases database file required by sendmail:

# newaliases
            

No m4 configuration commands are needed to access the aliases database. Any basic sendmail configuration should work.

Most systems come with an aliases database. All you need to do is add the aliases that you desire to the existing aliases text file and run the newaliases command. However, if your system displays the "missing map file" error shown in the problem description, you either do not have an aliases database or the one you have is placed in the wrong directory. In either case, you need to put a valid aliases database in the proper path. If your system does not have an aliases file, use one from a similar system or the sample aliases file from the sendmail directory of the sendmail distribution as a starting point. If the file you have is in the wrong path, move it or change the sendmail configuration to point to the place where you keep the aliases database.

Some older systems store the aliases database in the /etc directory. To keep it in that directory, add the following ALIAS_FILE define to the sendmail.mc file:

define(`ALIAS_FILE', `/etc/aliases')

The ALIAS_FILE define can accept various flags. You can make the aliases database optional using the -o flag exactly as it was used in Recipe 2.1 with the confCW_FILE define. However, this is not a good idea. The

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Reading Aliases via LDAP

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

When your organization stores aliases on an LDAP server, you need to configure sendmail to read aliases from the LDAP server.

Use sendmail -bt -d0.1 to check the sendmail compiler options. If sendmail was not compiled with LDAP support, recompile and reinstall sendmail as described in Recipe 1.3.

If the LDAP server has not yet been configured to support sendmail queries, copy the sendmail.schema file to the appropriate location on the LDAP server and update the server configuration to use the schema file. Recipe 1.3 covers the necessary LDAP server configuration.

Once the LDAP server is configured to support the sendmail schema, add sendmail aliases to the LDAP database using the format defined by that schema. When OpenLDAP is used, this is done by first creating an LDIF file containing the LDAP records and then running ldapadd to add these records to the LDAP database. The Discussion section shows an example of doing this for alias records.

On the sendmail system, add an ALIAS_FILE define, containing the string ldap:, to the sendmail configuration. Also add a confLDAP_CLUSTER define containing the same value as the sendmailMTACluster attribute used in the entries added to the LDAP server. Here is an example of these configuration commands:

# Set the LDAP cluster value
define(`confLDAP_CLUSTER', `wrotethebook.com')
# Tell sendmail that aliases are available via LDAP
define(`ALIAS_FILE', `ldap:')

Build the sendmail configuration file, copy it to /etc/mail/sendmail.cf, and restart sendmail with the new configuration, as described in Recipe 1.8.

This recipe provides instructions for both the sendmail administrator and the LDAP administrator because the LDAP server must be properly installed, configured, and running, and it must include the sendmail schema in order to understand and properly process queries from sendmail. Nothing in this recipe will work without the close cooperation of the LDAP administrator. In fact, the bulk of the configuration takes place on the LDAP server. You should have some experience with LDAP before attempting to use it with sendmail.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Configuring Red Hat 7.3 to Read Aliases from a NIS Server

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You want to use NIS to access the aliases database on a Red Hat 7.3 system.

Change to the /etc/mail directory and create a service.switch file. Here is an example:

# cd /etc/mail
# cat - > service.switch
aliases nis files
hosts   dns files
passwd  files nis

No m4 configuration commands are needed to enable support for the service.switch file—it is available by default. The basic sendmail configuration already installed on your system will probably work with this file; the generic configuration discussed in Recipe 1.8 certainly will.

Network Information Service (NIS), developed by Sun Microsystems, makes many system administration databases available over the network. NIS allows an organization to centrally control and maintain important configuration files for all Unix clients. The aliases database is one of the files that can be centrally maintained and accessed through NIS.

A service switch file defines the sources for various system administration files and the order in which those sources should be queried. service.switch is the default filename that sendmail uses for a service switch file if the system does not have a service switch file that sendmail can use. When running on a Red Hat Linux system, current versions of sendmail look for service.switch in the /etc/mail directory; earlier versions looked for the file in the /etc directory. The path to the sendmail service switch file can be changed using the confSERVICE_SWITCH_FILE define. However, it is generally easier to place the service.switch file in the /etc/mail directory where sendmail, and most administrators, expect to find it.

The sendmail service.switch file is much shorter than the system's service switch file because sendmail is only interested in three types of system administration information: mail aliases, host information, and user information.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Configuring Solaris 8 to Read Aliases from a NIS Server

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You must configure a Solaris 8 system to read aliases from a NIS server.

Edit the aliases entry in the /etc/nsswitch.conf file, changing it to the following:

aliases:    nis files

No m4 configuration commands are needed to use the nsswitch.conf file on a Solaris system. The basic sendmail configuration already installed on your system should work. If your system is not yet configured to run sendmail, use the generic-solaris.mc file as a starting point to get your Solaris server running.

Both the Linux system and the Solaris system have a system-wide service switch file named /etc/nsswitch.conf. The difference is that the Red Hat Linux 7.3 system does not use the aliases entry in that file, and the Solaris system does. When the system has an active system service switch file, sendmail uses that file and ignores the file identified by the confSERVICE_SWITCH_FILE define. The correct solution for the Solaris system is to identify the sources of alias information in the nsswitch.conf file. Any source that is compatible with the nsswitch.conf syntax and with sendmail can be specified. See the nsswitch.conf manpage for information about the syntax supported on your computer.

Recipe 2.3 and Recipe 2.4 also show aliases being read from an external server. But Recipe Recipe 2.2 and most examples in this book assume the aliases database is a local file located directly on the sendmail system. This is a common design, and there are some good reasons why.

Aliases are only searched for mailers that have the A flag set. On most systems, only the local mailer has this flag set, which means that aliases only apply to inbound mail that has been accepted for delivery through the local mailer. A centralized database that includes aliases for all of the users in the organization is needed only by a server that will accept mail for all of the users in the organization. For most Unix workstations, the bulk of the entries in a centralized database are unused—only those users who actually receive their mail at the workstation are looked up.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Forwarding to an External Address

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Mail addressed to the local host needs to be forwarded to another host for final delivery.

Add an alias to the aliases file for each user whose mail must be forwarded to another system. The recipient field of the alias entry must be a full email address that includes the host part.

After adding the desired aliases, rebuild the aliases database file with the newaliases command.

There are many reason why mail delivered to your system must then be forwarded to another host. For example, a user may have changed addresses, a user may have several addresses but only read mail at one of them, or your host might be a mail hub that collects mail for several different systems. A mail exchanger is a good example of a system that receives mail that might need to be forwarded to another host for delivery.

A mail exchanger receives mail addressed to other hosts and accepts that mail as local mail. (This is discussed in Recipe 2.1.) It is possible, however, that not every user on every host that routes mail to the mail exchanger has a local account on the mail exchanger. Two sendmail -bv tests illustrate this:

# sendmail -bv pat@wrotethebook.com
pat@wrotethebook.com... deliverable: mailer local, user pat
# sendmail -bv andy@wrotethebook.com
andy@wrotethebook.com... User unknown

In the first case, pat is a user account on the mail exchanger, so the mail can be delivered directly to Pat's local mailbox. In the second case, andy is not a local user account, so the mail is bounced with a "User unknown" error. Assume, however, that this mail should not be returned with an error because Andy is a current employee who is allowed to receive mail at the address andy@wrotethebook.com. Andy doesn't have an account on the mail exchanger, but he does have a valid account on another system in the wrotethebook.com domain, and it is on that system that Andy reads his mail.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Creating Mailing Lists

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You have been asked to create mailing lists.

Add an entry to the aliases text file for each mailing list, where the alias field contains the name of the mailing list, and the recipient field contains a comma-separated list of all of the recipients of the mailing list.

Add the special alias that sendmail uses to deliver error messages concerning the mailing list. This special alias must have a name in the format of owner- list, where owner- is a required string and list is the name of the list for which this owner alias is being declared. For example, if the list is named admin, this alias must be named owner-admin. The recipient field of the special alias should contain the address where the errors are to be sent.

For the convenience of users, add an alias that can be used to reach the person who maintains the mailing list. The format of the alias field should be list -request, where list is the name of the list for which this request alias is being declared, and -request is a required string. For example, if the list is named admin, this alias should be named admin-request.

Run newaliases to rebuild the aliases database file:

# newaliases
/etc/mail/aliases: 43 aliases, longest 30 bytes, 592 bytes total

To illustrate how to create mailing lists, let's assume we have been asked to create three different mailing lists:

• Mail addressed to root is to be sent to the normal login accounts of the three people who administer the mail server.
• The boss wants to have a mailing list for the management council, which is composed of the four department chiefs and their scientific advisor, and he wants an archive kept of all the mail sent to that mailing list.
• The boss wants a mailing list for all mail users.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Migrating Ex-Users to New Addresses

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You have been told to gracefully migrate ex-users to their new delivery addresses.

Add the redirect feature to the sendmail configuration using the following FEATURE command:

dnl Notify senders about discontinued addresses
FEATURE(`redirect')

Rebuild the sendmail.cf file, copy the new sendmail.cf file to /etc/mail, and restart sendmail, as described in Recipe 1.8.

Add an entry to the aliases text file for each ex-user. The alias field of the entry is the local username where the ex-user previously received mail. The recipient field is the user's new email address with the string .REDIRECT appended to the end of the address.

As always, when the aliases file is updated, run the newaliases script:

# newaliases
/etc/mail/aliases: 45 aliases, longest 30 bytes, 670 bytes total

The first two steps in the Solution section create a sendmail configuration containing the redirect feature. Of course, if your configuration already contains that feature, as does the generic Linux configuration described in Recipe 1.8, you can skip those first two steps and go right to creating the aliases.

As an example, let's assume we want to gracefully handle mail for an ex-employee for six months. Michael recently left the company. Proper customer relations is the first and most important step in transitioning Michael's mail. Jay has taken over all of his customers, and we now want those customers to send their business communications to Jay. During Michael's last week in the office, he took Jay to visit all of his local customers, and used conference calls to introduce Jay to all of his remote customers. The customers have been notified, and the business mail should flow to the right destination. If management drops the ball on customer relations, there is very little that a sendmail administrator can do about it. However, you can make sure that Michael gets his personal mail by adding an alias to forward the mail to his new address:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Delivering Mail to a Program

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You want sendmail to pass mail messages to another program.

Address the mail to the program using the pathname of the program preceded by a pipe character.

A recipient email address can contain a pipe character and the name of a program. For example:

|/usr/local/bin/rtmproc

sendmail uses the prog mailer to deliver mail to