Five Tips for a Better sendmail Configuration
Pages: 1, 2

Limit the Number of sendmail Servers

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 sendmail 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_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, and add the name of the mail relay host to the MSP FEATURE command. 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 sendmail daemon, deleting the -bd flag. For example, change this:

/usr/sbin/sendmail -bd -q15m

to this:

/usr/sbin/sendmail -q15m

Terminate the currently running daemon and re-run sendmail without the -bd flag.

Modifying the submit.mc file in the manner described above prevents sendmail 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 sendmail configuration to prevent sendmail from creating a default MSA configuration. Then add 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 sendmail configuration:

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 precede the DAEMON_OPTIONS macro in the configuration. This feature is not required when you are only changing MTA values.

The 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 sendmail 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.

The default Addr value used by DaemonPortOptions is INADDR_ANY, 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.

Use sendmail Databases

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 processed through makemap before they can be used. All are useful files that simplify sendmail configuration.

• aliases
  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 sendmail configuration changes are needed to use this database.

• relay-domains
  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 the SIGHUP signal. No sendmail configuration changes are needed to use this file.

• local-host-names
  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 sendmail configuration.

• access
  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 sendmail configuration.

• genericstable
  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 sendmail configuration to use this database.

• virtusertable
  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 sendmail 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 database.

• mailertable
  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 sendmail configuration. Add FEATURE(mailertable) to the sendmail 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 accessed by 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.

• You can also look at the Table of Contents, the Index, and the full description of the book.

• For more information, or to order the book, click here.

---

Return to ONLamp.com.