Five Tips for a Better sendmail Configurationby Craig Hunt, author of the sendmail Cookbook
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
sendmailUp to Date
It is important to upgrade to a new
sendmail release when the release fixes a
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 email@example.com that contains the following line:
Keep track of new
sendmail releases in order to determine when upgrading is
important to you. When you decide to upgrade, download the
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
If you do not have the current
sendmail PGP keys on your key ring, also
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:
$ gpg --import PGPKEYS gpg: key 16F4CCE9: not changed gpg: key 396F0789: public key imported gpg: key 678C0A03: not changed gpg: key CC374F2D: not changed gpg: key E35C5635: not changed gpg: key A39BA655: not changed gpg: key D432E19D: not changed gpg: key 12D3461D: not changed gpg: key BF7BA421: not changed gpg: key A00E1563: non exportable signature (class 10) - skipped gpg: key A00E1563: not changed gpg: key 22327A01: not changed gpg: Total number processed: 11 gpg: imported: 1 (RSA: 1) gpg: unchanged: 10
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 --fingerprint 396F0789 pub 1024R/396F0789 2003-01-15 Sendmail Signing Key/2003 <sendmail@Sendmail.ORG> Key fingerprint = C4 73 DF 4A 97 9C 27 A9 EE 4F B2 BD 55 B5 E0 0F
Compare the displayed fingerprint against the valid fingerprints for
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
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.
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.
sendmail is an alternative to downloading a new source code
sendmail with a source code patch is very similar to
installing a completely new
sendmail source code distribution. In both cases:
pgpto verify the downloaded source file.
The biggest differences between the two approaches to closing a security hole are:
tarto create a completely new source tree.
patchto 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
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.
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
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 using the Build utility provided by the
Build detects the architecture of the system and builds a basic
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.
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:
# cd /usr/local/src/sendmail-8.12.10/devtools/Site # cat >> site.config.m4 APPENDDEF('confMAPDEF', '-DLDAPMAP') APPENDDEF('confLIBS', '-lldap -llber') Ctrl-D # cd /usr/local/src/sendmail-8.12.10 # ./Build -c # ./Build install
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
-llber to the list of libraries stored
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.
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
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
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
configuration, including the generic configuration files.
The top-level directory created by the tarball is assigned a name that identifies
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:
$ ls sendmail-8.12.10/cf cf feature m4 ostype sendmail.schema siteconfig domain hack mailer README sh
The cf directory contains two files, README and sendmail.schema, and nine
subdirectories. The cf/cf directory is the working directory of the
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
Limit the number of systems running a
sendmail listener to reduce security
vulnerability and to simplify maintenance. Every network service that accepts
inbound connections is a potential target of security attacks. Limiting the SMTP
listener to servers increases security. Because SMTP servers must accept
connections and data from unknown hosts via the SMTP port, intruders scan for
systems that respond to SMTP connections and target attacks against those
systems. Mail servers must run the SMTP listener, but on other systems the
listener is an unnecessary risk. Controlling the SMTP ports at the firewall and
limiting the number of systems listening to those ports provide defense in depth.
If an administrator fails to disable the ports on a host, the firewall should stop an
attack. If the firewall fails, limiting the number of systems listening to the SMTP
ports limits the number of targets.
Limiting the number of systems that run the SMTP listener also reduces the
security administrator's workload. If only servers listen on the SMTP port, only
servers are in critical need of a security fix for SMTP vulnerabilities. A site with
thousands of desktop workstations might have only a handful of valid
servers. Fixing a few servers is much easier than fixing thousands of desktops.
Not only that, the skill level of the server administrators is generally high. Most
of those administrators can handle the fix by themselves. Desktop users, on the
other hand, require much more support. If anyone fails to correctly apply a
critical security fix, the entire network remains in danger. Reducing the number of
systems that require a critical fix is clearly a security and a maintenance win.
When planning your
sendmail architecture, select a limited number of hosts to act
as mail exchangers and mail relay hosts. Configure those selected systems to
accept inbound mail. Configure the other
sendmail systems using one of the two
techniques described here.
One technique for limiting the number of SMTP listeners requires modifications to the submit.mc file. Before making any changes, make a backup copy of the original submit.mc file.Edit the submit.mc file. Add the
MASQUERADE_ASmacro to the configuration so that replies to mail sent by the local host will go to a server that has an active SMTP port, and add the name of the mail relay host to the MSP
FEATUREcommand. Here are sample lines from a modified submit.mc file:
MASQUERADE_AS(`mail.example.com') FEATURE('msp', 'mail.example.com')
Rebuild the submit.cf file and restart the MSP daemon.
Edit the system startup script. Change the command that starts the
daemon, deleting the
-bd flag. For example, change this:
/usr/sbin/sendmail -bd -q15m
Terminate the currently running daemon and re-run
sendmail without the -bd
Modifying the submit.mc file in the manner described above prevents
from accepting any SMTP connections -- even from the local host. This
technique is popular with security types because even someone with login
access to the local host cannot attack
sendmail through the SMTP ports. The
increased security of modifying submit.mc comes at the cost of increased
complexity, because this approach requires changes to the MSP configuration
and to the system startup files. A simpler alternative is described next.
In this alternative, all changes take place in the master configuration file you use
to build the sendmail.cf file. First add the
no_default_msa feature to the
configuration to prevent
sendmail from creating a default MSA configuration.
DAEMON_OPTIONS macros to create your own configuration that
limits inbound mail connections to the loopback address. Finally, add the
MASQUERADE_AS macro to the configuration so that replies to mail sent by the
local host will go to a server that has an active SMTP port. Then rebuild and
reinstall sendmail.cf, and restart
sendmail. Here are sample lines that could be
added to the
dnl Don't create a default MSA configuration FEATURE('no_default_msa') dnl Limit the MSA to the loopback address DAEMON_OPTIONS('Name=MSA, Port=587, Addr=127.0.0.1, M=E') dnl Limit the MTA to the 127.0.0.1 interface DAEMON_OPTIONS('Name=MTA, Addr=127.0.0.1') dnl Make sure replies go to the mail host MASQUERADE_AS('mail.example.com')
Note that the
no_default_msa feature must be used before you can change the
DaemonPortOptions settings of the MSA. The
FEATURE macro must
DAEMON_OPTIONS macro in the configuration. This feature is not
required when you are only changing MTA values.
DAEMON_OPTIONS macro sets values for the sendmail.cf
DaemonPortOptions statements. A basic
sendmail configuration has two
DaemonPortOptions statements -- one for the MTA mode of the
daemon and one for the MSA mode. Both port 25, used by the MTA, and port
587, used by the MSA, are accessible from the network, and thus are potentially
vulnerable to network attacks.
Addr value used by
which means that the daemon accepts connections from any address. Identifying
a specific address with the
Addr value limits incoming connection to that
specific address. Thus, setting
Addr=127.0.0.1 means that only
connections from the local host that come through the loopback interface will be
accepted, which eliminates any inbound connections from the network. Inbound
network connections are not accepted on either port 25 or port 587. However,
mail can still be sent from the local host. Both of the techniques described here are covered in more detail in
Recipe 10.1 and 10.2 of sendmail Cookbook.
Databases are a key component of
sendmail configuration. While the
configuration files get most of the attention in print, the databases often get most
of the attention in practice. Use the
sendmail databases for day-to-day
configuration changes and to control the way in which
sendmail processes mail.
I'm using the term "database" loosely. Some of the files described here are flat
files used to load the sendmail.cf classes. Others are true databases that must be
makemap before they can be used. All are useful files that
This database specifies how mail is forwarded for the entire system. (Individual users define personal forwarding for their own mail in the .forward file.) The aliases database defines mailing lists, forwards mail to other hosts, and forwards mail to the correct individual users while providing for a flexible mail address structure. No
changes are needed to use this database.
This file lists the hosts that are allowed to relay mail. To enable relaying for a host, add the hostname to this file and pass
sendmail configuration changes are needed to use this file.
This file lists hostnames that are treated as hostname aliases for the local host. Mail addressed to any of these hostnames is accepted for local delivery. To use this file, add
FEATURE(use_cw_file) to the
The access database is a powerful and flexible
sendmail configuration tool. It
provides fine-grained control over relaying, spam control, authentication,
and other services. Each line in the database contains two fields: a
conditional test and an action taken when the condition is met. A wide
variety of conditions and actions are available to control a wide range of
services. To use the database, add
FEATURE(access_db) to the
The genericstable database rewrites sender addresses. The original sender address is the database key, and the rewritten sender address is the return value. Use the genericstable to present consistent sender addresses to the outside world. Add
FEATURE(genericstable) to the
configuration to use this database.
This database routes mail for virtual mail domains. A virtual mail domain is similar to a virtual host in the Apache web server. In the same way that a web server can be configured to serve web pages for host computers that do not physically exist, the
sendmail server can be configured to provide mail
service for mail domains that do not have any existence beyond the
server itself. This database can be used to ease the transition when
changing domain names, to provide an alternate identity when the products
you sell are not clearly associated with your official domain name, or to
support a large number of client domains if you provide a centralized mail
service. It is particularly useful if you run an ISP that provides service to a
large number of customers or you run an e-business site. Add
FEATURE(virtusertable) to the
sendmail configuration to use this
The mailertable maps domain names to the internal mailer that should handle mail bound for that domain. Use this database to control mail routing, particularly to handle exceptional circumstances, such as a remote server that cannot handle the standard mail protocol, or to access the
procmail mailer when it is defined internally to the
FEATURE(mailertable) to the
configuration to use this database.
There are other
sendmail files and databases, but the ones listed above are those
I consider most useful for simplifying
sendmail configuration. All of the files and
databases listed above can be centrally maintained on an LDAP server and
sendmail using the
sendmail schema. Maintaining the files centrally
further simplifies configuration by providing consistency across an enterprise or
department, and by limiting the number of copies of the files that must be
maintained. The sendmail Cookbook show how all of these file and databases
can be read from an LDAP server.
Craig Hunt has worked with computer systems for the last thirty years.
O'Reilly & Associates recently released (December 2003) sendmail Cookbook.
Sample Chapter 2, "Delivery and Forwarding," is available free online.
For more information, or to order the book, click here.
Return to ONLamp.com.
Copyright © 2009 O'Reilly Media, Inc.