Five Tips for a Better sendmail Configuration

Unix vendors bundle sendmail with the operating system and ship it out preconfigured. It is very easy to install the OS and use the sendmail configuration delivered with the system. Don't be
fooled by this apparent simplicity. In the long run, it is better to take charge of
your fate. Creating a custom sendmail configuration using current software and
features selected for your environment will give you better performance,
reliability, security, and maintainability. Here are some tips to get you started on
building a better sendmail configuration.

Keep sendmail Up to Date

It is important to upgrade to a new sendmail release when the release fixes a
security problem. sendmail is a popular target for network intruders. They attack
sendmail because it is a large, complex program that runs on a very large number
of systems. The weaknesses exposed by these attacks are quickly fixed in new
sendmail releases. Subscribing to the sendmail-announce mailing list helps you
stay informed about these potential problems and lets you know as soon as the
problems are fixed. Subscribe to the sendmail-announce mailing list by sending
mail to majordomo@lists.sendmail.org that contains the following line:

subscribe sendmail-announce

Keep track of new sendmail releases in order to determine when upgrading is
important to you. When you decide to upgrade, download the sendmail source
code distribution from http://www.sendmail.org/current-release.html, from any
of the mirror sites, or from ftp://ftp.sendmail.org/pub/sendmail/. Additionally, get
the signature file associated with the version of sendmail you downloaded. For
example, the signature file for sendmail.8.12.10.tar.gz is
sendmail.8.12.10.tar.gz.sig.

If you do not have the current sendmail PGP keys on your key ring, also
download the PGPKEYS file; you need it to verify the signature. Add the PGP
keys to your key ring. In the following example, gpg (GNU Privacy Guard) is used
to import the PGPKEYS file:

Of the 11 exportable keys in the PGPKEYS file, only one is imported to our
key ring. The not changed comments for the other ten keys shows that they were
already installed on the key ring. The first time you import PGPKEYS, all 11
keys will be added to the key ring. Before using the new key, verify its fingerprint, as in this gpg example:

Compare the displayed fingerprint against the valid fingerprints for sendmail
signing keys. (Table 1-1 in the sendmail Cookbook lists the valid keys, as does
page 41 in Bryan Costales' sendmail book.) If the fingerprint is correct, you can sign, and
thus validate, the key using a tool such as gpg.

Remember, it is not necessary to download and import the PGPKEYS file every
time you download a new sendmail release. New keys are only added to the
PGPKEYS file about once a year.

After the sendmail keys have been added to the key ring and signed, verify the
sendmail distribution tarball. Only when the tarball is verified can it be safely
restored, compiled, and installed.

Patching sendmail is an alternative to downloading a new source code
distribution. Updating sendmail with a source code patch is very similar to
installing a completely new sendmail source code distribution. In both cases:

You download source code from sendmail.org. In one case, it is a large .tar
file, and in the other it is a small patch file.

You download a signature file to verify the source code.

You use gpg or pgp to verify the downloaded source file.

You recompile, reinstall, and restart sendmail.

The biggest differences between the two approaches to closing a security hole
are:

In one case, you use tar to create a completely new source tree.

In the other case, you use patch to change files in an existing source tree.

The approach you use depends on your personal preferences and the nature of
the version of sendmail currently installed on your system. If you use a version of sendmail
provided by a vendor that has some special features, patching may be a way to
fix a security problem while retaining those features. Of course, there is no
guarantee. If the vendor has extensively modified the sendmail source, the patch
may not work.

Roll Your Own Binary

There are good reasons to compile your own copy of sendmail instead of using
the copy provided to you as part of your Unix distribution. First, the copy of
sendmail included in your Unix distribution is probably grossly out of date.
sendmail changes frequently, and some of these changes provide critical security
fixes. Sticking with an outdated copy of sendmail is just asking for trouble.

You can usually obtain an updated sendmail binary from your Unix vendor for
any critical security fix; however, I prefer to have more personal control over the
process. I like to decide what fixes are important to me, instead of letting the
vendor decide for me. Additionally, I like to decide what features should be
compiled into sendmail instead of settling for the features the vendor chooses.

Another advantage to compiling your own sendmail binaries is that you can
create consistency across all systems. Sun will compile sendmail with some
settings, HP will use others, and Red Hat will use still others. By selecting the
features you want compiled in, and using those settings on all of your Unix
platforms, you can create a consistent sendmail environment.

Compile sendmail using the Build utility provided by the sendmail developers.
Build detects the architecture of the system and builds a basic sendmail binary
that should work for most situations. To customize the compile, create a
site.config.m4 configuration file in the devtools/Site directory. As the file
extension ".m4" implies, the site.config.m4 file contains m4 commands. Three
commands are commonly used:

define, which stores a value in a variable.

APPENDDEF, which appends a value to an existing list of values stored in a
variable.

PREPENDDEF, which adds values to the beginning of a list of values stored
in a variable.

Customizing the sendmail binary to support OpenLDAP is an example of when a
site.config.m4 file is needed. To add LDAP support, set LDAP values in the
site.config.m4 file, and recompile and reinstall sendmail, as shown in the following example:

In this example, the first APPENDDEF command adds -DLDAPMAP to the list of
supported map types stored in the confMAPDEF define. The second
APPENDDEF command adds -lldap and -llber to the list of libraries stored
in the confLIBS define.

Build is then used to recompile sendmail. Notice the -c option on the Build
command line. It is needed to make sure that Build detects the changes made
to the site.config.m4 file. After recompiling, sendmail is reinstalled.

Most custom Build configurations are no more complicated than this example.
However, there are more than 100 variables that can be set for the Build
configuration. See the devtools/README file for a complete list.

Create Custom Configurations

The sendmail configuration provided by your Unix vendor is, out of necessity, a
compromise. The vendor cannot anticipate exactly how you will use the system,
let alone how you will use sendmail on that system. Vendors create
configurations that are useful for a wide variety of situation, which makes it
difficult for the vendor to optimize the configuration for any one situation. Create
a custom configuration to optimize sendmail for your specific system, which
means you must create different configurations for the different types of systems
you plan to use.

The first step is to create a sendmail architecture that shows the role each system
will play in delivering the mail. This doesn't need to be a complicated plan. For
example, you might say that this system will be allowed to receive mail through the
firewall, that system will be allowed to send mail through the firewall, and these
systems will use a relay for outbound mail and retrieve inbound mail via POP or
IMAP. This sample architecture only defines three different sendmail
configurations: one for the mail hub that collects inbound mail, one for the relay
that handles outbound mail, and one for all of the other systems that use the hub
and the relay.

A custom configuration can be based on the vendor configuration, but it is often
better to start with the simple generic configurations provided by the sendmail
developers. It is easier to add features to a simple configuration than it is to start
with a complex configuration, which may need to have many things removed as
well as added. The directory structure created by the sendmail source code
distribution tarball contains the ingredients needed to build a sendmail
configuration, including the generic configuration files.

The top-level directory created by the tarball is assigned a name that identifies
the sendmail version number. Thus, the tarball for sendmail 8.12.10 creates a top-
level directory named sendmail-8.12.10. Within this directory structure, the
m4 source files and libraries used to build the sendmail configuration are located
in the cf directory. The cf directory contains the following 11 items:

The cf directory contains two files, README and sendmail.schema, and nine
subdirectories. The cf/cf directory is the working directory of the sendmail
configuration. The directory contains more than forty files. Most of these files -- more than 30 of them -- are sample master configuration files. You can identify a
master configuration file by the .mc extension. Particularly interesting are the
generic files designed for use with different operating systems. These are easily
identified by names such as generic-linux.mc and generic-solaris.mc.

Copy the generic file for your operating system to a working file. Make the
changes required for your configuration to the working file, and then use Build
to create the sendmail.cf file for sendmail.