The sendmail configuration file is sendmail.cf.  It contains most of the sendmail configuration, including the information required to route mail between the user mail programs and the mail delivery programs. The sendmail.cf file has three main functions:
 The default location for the configuration file is the /etc directory, but it is often placed in other directories, such as /etc/mail and /usr/lib.
It defines the sendmail environment.
It rewrites addresses into the appropriate syntax for the receiving mailer.
It maps addresses into the instructions necessary to deliver the mail.
Several commands are necessary to perform all of these functions. Macro definitions and option commands define the environment. Rewrite rules rewrite email addresses. Mailer definitions define the instructions necessary to deliver the mail. The terse syntax of these commands makes most system administrators reluctant to read a sendmail.cf file, let alone write one! Fortunately, you can avoid writing your own sendmail.cf file, and we'll show you how.
There is rarely any good reason to write a sendmail.cf file from scratch. Locate an existing file with a configuration similar to your system's and modify it. That's how you configure sendmail, and that's what we discuss in this section.
Sample configuration files are delivered with most systems' software. Some system administrators use the configuration file that comes with the system and make small modifications to it to handle site-specific configuration requirements. We cover this approach to sendmail configuration later in this chapter.
Other system administrators prefer to use the latest version of sendmail. They download the sendmail.tar file and use the m4 source files it contains to build a sendmail.cf file. The samples that come with your system are adequate only if you also use the sendmail executable that comes with your system. If you update sendmail, use the m4 source files that are compatible with the updated version of sendmail.
The tar file can be downloaded via anonymous ftp from ftp.sendmail.org.  Login and change to the pub/sendmail directory. This displays a list of the available versions of sendmail. See Appendix E, for an example of downloading and installing the sendmail distribution.
 Even if your UNIX system comes with its own version of sendmail, obtain the tar file for the useful documentation it contains, e.g., the Sendmail Installation and Operation Guide, by Eric Allman.
The sendmail cf/cf directory contains several sample configuration files. Several of these are generic files preconfigured for different operating systems. The cf/cf directory on my system contains generic configurations for BSD, Solaris, SunOS, HP Unix, Ultrix, OSF1, and Next Step. The directory also contains a few prototype files designed to be easily modified and used for other operating systems. We will modify the tcpproto.mc file, which is for systems that have direct TCP/IP network connections and no direct UUCP connections, to run on our Linux system.
The prototype files that come with the sendmail tar are not "ready to run." They must be edited and then processed by the m4 macro processor to produce the actual configuration files. For example, the tcpproto.mc file contains the following macros:
divert(0)dnl VERSIONID(`@(#)tcpproto.mc 8.5 (Berkeley) 3/23/96') OSTYPE(unknown) FEATURE(nouucp) MAILER(local) MAILER(smtp)
These macros are not sendmail commands; they are input for the m4 macro processor. The few lines shown above are the important lines in the tcpproto.mc file. They are preceded by a section of comments, not shown here, that is discarded by m4 because it follows a divert(-1) command, which diverts the output to the "bit bucket." This section of the file begins with a divert(0) command that means these commands should be processed and that the results should be directed to standard output. 
 The dnl option is used to prevent excessive blank lines from appearing in the output file. It affects the appearance, but not the function, of the output file. dnl can appear at the end of any macro command.
The VERSIONID macro is used for version control. Usually the value passed in the macro call is a version number in RCS (Release Control System) or SCCS (Source Code Control System) format. This macro is optional and we just ignore it.
The OSTYPE macro defines operating system-specific information for the
sendmail.cf file. The cf/ostype directory
than 30 pre-defined operating system macro files. The OSTYPE macro is
required and the value passed in the OSTYPE macro call must match the
name of one of the files in the directory. Examples of values are:
The FEATURE macro defines optional features to be included in the sendmail.cf file. The nouucp feature in the sample shown above says that no special UUCP address processing is to be included in the output file. Recall that in the previous section we identified tcpproto.mc as the prototype file for systems that have no UUCP connections. Another prototype file would have different FEATURE values.
The prototype file ends with the mailer macros. These must be the last macros in the input file. The sample shown above specifies the local mailer macro, which adds the local mailer and the prog mailer to the output, and the smtp mailer macro, which adds mailers for SMTP, Extended SMTP, 8-bit SMTP and relayed mail. All of these mailers are described later in this chapter.
To create a sample sendmail.cf for a Linux system from the
tcpproto.mc prototype file, copy the prototype
file to a work file. Edit the work file by changing the OSTYPE line
linux to specify the correct operating
system. In the example we use sed to change
linux. We store the result in a file we call linux.mc:
# sed 's/unknown/linux/' < tcpproto.mc > linux.mc
Then enter the m4 command:
# m4 ../m4/cf.m4 linux.mc > sendmail.cf
The sendmail.cf file output by the m4 command is in the correct format to be read by the sendmail program.  In fact, the output file produced above is almost identical to the sample linux.smtp.cf configuration file delivered with Linux.
 New syntax and functions in the latest version of the sendmail.cf file may not be supported by older versions of the sendmail program.
OSTYPE is not the only thing in the macro file that can be modified to create a custom configuration. There are a large number of configuration options, all of which are explained in Appendix E. As an example we modify a few options to create a custom configuration that converts user@host email addresses originating from our computer into firstname.lastname@domain. To do this, we create two new configuration files: a macro file with specific values for the domain that we name nuts.com.m4 and a modified macro control file, linux.mc, that calls the new nuts.com.m4 file.
We create the new macro file nuts.com.m4 and place it in the cf/domain directory. The new file contains the following:
MASQUERADE_AS(nuts.com) FEATURE(masquerade_envelope) FEATURE(genericstable)
These lines say that we want to hide the real hostname and display the name nuts.com in its place in outbound email addresses. Also, we want to do this on "envelope" addresses as well as message header addresses. The last line says that we will use the generic address conversion database, which converts login usernames to any value we wish. We must build the database by creating a text file with the data we want and processing that file through the makemap command that comes with sendmail V8.
The format of the database can be very simple:
dan Dan.Scribner@nuts.com tyler Tyler.McCafferty@nuts.com pat Pat.Stover@nuts.com willy Bill.Wright@nuts.com craig Craig.Hunt@nuts.com
Each line in the file has two fields: the first field is the key, which
is the login name, and the second field is an email address
containing the user's real first and
last names separated by a dot. Fields are separated by spaces. Using
this database, a query for
dan will return the value
A small database such as this one can be easily built by hand. On a
system with a large number of existing user accounts, you may want to
automate this process by extracting the user's login name, and first
and last names from the /etc/passwd file.
The gcos field of the
/etc/passwd file often contains the user's real name.
Once the data is in a text file convert it to a database with the
makemap command. The makemap command is included in
the sendmail V8 tar file. It requires the ndbm library.
The syntax of the makemap command is:
 See Appendix E for a sample script that builds the realnames database from /etc/passwd.
makemap reads the standard input and writes the database out to a
file it creates using the value provided by
name as the filename.
type field identifies the database type. The most commonly
supported database types for sendmail V8 are dbm, btree, and hash.
All of these types can be made with the makemap command.
 On Sun OS and Solaris systems, NIS maps and NIS+ tables are built with standard commands that come with those operating systems. The syntax for using those maps within sendmail is different (see Table 10-4). Networking Personal Computers with TCP/IP, by Craig Hunt (O'Reilly & Associates) provides an example of using a NIS map inside of sendmail.
Assume that the data shown above has been put in a file named realnames. The following command converts that file to a database:
# makemap hash genericstable < realnames
makemap reads the text file and produces a database file called
genericstable. The database maps login names to real names, e.g.,
willy returns the value
Now that we have created the database, we create a new sendmail
configuration file to use it. All of the m4 macros related to
using the database are in the nuts.com.m4 file. We need to include
that file in the configuration. To do that, add a
line to the macro control file (linux.mc)
and then process the
linux.mc through m4. The following grep command shows
what the macros in the file look like after the change:
# grep '^[A-Z]' linux.mc VERSIONID(`@(#)tcpproto.mc 8.5 (Berkeley) 3/23/96') OSTYPE(linux) DOMAIN(nuts.com) FEATURE(nouucp) MAILER(local) MAILER(smtp) # m4 ../m4/cf.m4 linux.mc > sendmail.cf
Use the prototype mc files as the starting point of your configuration if you install sendmail from the tar file. To use the latest version of sendmail you must build a compatible sendmail.cf file using the m4 macros. Don't attempt to use an old sendmail.cf file with a new version of sendmail. You'll just cause yourself grief. As you can see from the sample above, m4 configuration files are very short and can be constructed from only a few macros. Use m4 to build a fresh configuration every time you upgrade sendmail.
Conversely, you should not use a sendmail.cf file created from the prototype files found in the sendmail distribution with an old version of sendmail. Features in these files require that you run a compatible version of sendmail, which means it is necessary to recompile sendmail to use the new configuration file.  This is not something every system administrator will choose to do, because some systems don't have the correct libraries; others don't even have a C compiler! If you choose not to recompile sendmail, you can use the sample sendmail.cf file provided with your system as a starting point. However, if you have major changes planned for your configuration, it is probably easier to recompile sendmail and build a new configuration with m4 than it is to make major changes directly to the sendmail.cf.
 See Appendix E for information about compiling sendmail.
In the next part of this chapter, we use one of the sample sendmail.cf files provided with Linux. The specific file we start with is linux.smtp.cf found in the /usr/src/sendmail directory on the Slackware 96 version of Linux. All of the things that we discuss in the remainder of the chapter apply equally well to sendmail.cf files that are produced by m4. The structure of a sendmail.cf file, the commands that it contains, and the tools used to debug it are universal.
Many sendmail.cf files have more or less the same structure because most are descendants of a few original files. Therefore, the files provided with your system probably are similar to the ones used in our examples. Some systems use a different structure, but the functions of the sections described here will be found somewhere in most sendmail.cf files.
The Linux file, linux.smtp.cf, is our example of sendmail.cf file structure. The section labels from the sample file are used here to provide an overview of the sendmail.cf structure. These sections will be described in greater detail when we modify a sample configuration. The sections are:
Defines the information that is specific to the individual host. In the linux.smtp.cf file, Local Information defines the host name, the names of any mail relay hosts, and the mail domain. It also contains the name that sendmail uses to identify itself when it returns error messages, the message that sendmail displays during an SMTP login, and the version number of the sendmail.cf file. (Increase the version number each time you modify the configuration.) This section is usually customized during configuration.
Defines the sendmail options. This section usually requires no modifications.
Defines the various message precedence values used by sendmail. This section is not modified.
Defines the users who are trusted to override the sender address when they are sending mail. This section is not modified. Adding users to this list is a potential security problem.
Defines the format of the headers that sendmail inserts into mail. This section is not modified.
Defines the rules used to rewrite mail addresses. Rewriting Rules contains the general rules called by sendmail or other rewrite rules. This section is not modified during the initial sendmail configuration. Rewrite rules are usually only modified to correct a problem or to add a new service.
Defines the instructions used by sendmail to invoke the mail delivery programs. The specific rewrite rules associated with each individual mailer are also defined in this section. The mailer definitions are usually not modified. However, the rewrite rules associated with the mailers are sometimes modified to correct a problem or to add a new service.
The section labels in the sample file delivered with your system are probably different from these. However, the structure of your sample file is probably similar to the structure discussed above in these ways:
The information that is customized for each host is probably at the beginning of the file.
Similar types of commands, e.g., option commands, header commands, etc., are usually grouped together.
The bulk of the file consists of rewrite rules.
The last part of the file probably contains mailer definitions intermixed with the rewrite rules that are associated with the individual mailers.
It's important to realize how little of sendmail.cf needs to be modified for a typical system. If you pick the right sample file to work from, you may only need to modify a few lines in the first section. From this perspective, sendmail configuration appears to be a trivial task. So why are system administrators intimidated by it? In large part it is because of the difficult syntax of the sendmail.cf configuration language.