file:///C|/mynapster/Downloads/warez/tcpip/ch09_08.htm
Previous: 9.7 Mail Servers
Chapter 9
Configuring Network Servers
Next: 10. sendmail
9.8 Summary
This chapter covers several important TCP/IP network services.
Network File System (NFS) is the leading TCP/IP file-sharing protocol. It allows server systems to
share directories with clients that are then used by the clients as if they were local disk drives. NFS
uses trusted hosts and UNIX UIDs and GIDs for authentication and authorization. pcnfsd provides
password-based user authentication and NFS-based printer sharing for non-UNIX clients.
NFS-based printer sharing is not the only type of printer sharing available on a TCP/IP network. It is
also possible to use the Line Printer Daemon (LPD). This software is originally from BSD UNIX but
is widely available. The lpd program reads the printer definitions from the printcap file.
Network Information Service (NIS) is a server that distributes several system administrations
databases. It allows central control of and automatic distribution of important system configuration
information.
Bootstrap Protocol provides a wide range of configuration values to its client. Each implementation
of BOOTP has a different configuration file and command syntax. The CMU BOOTP server stores
configuration parameters in the /etc/bootptab file and uses a syntax very similar to the /etc/printcap
syntax.
Dynamic Host Configuration Protocol (DHCP) extends BOOTP to provide the full set of
configuration parameters defined in the Requirements for Internet Hosts RFC. It also provides for
dynamic address allocation, which allows a network to make maximum use of a limited set of
addresses.
Large networks use distributed boot servers to avoid overloading a single server and to avoid sending
boot parameters through IP routers. The configuration files on distributed boot servers are kept
synchronized through file transfer, NFS file sharing, or the Remote File Distribution Program (rdist).
Post Office Protocol (POP) and Internet Message Access Protocol (IMAP) servers allow email to be
stored on the mail server until the user is ready to read it. In the next chapter, we take a closer look at
configuring an electronic mail system as we explore sendmail.
file:///C|/mynapster/Downloads/warez/tcpip/ch09_08.htm (1 of 2) [2001-10-15 09:18:35]
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
file:///C|/mynapster/Downloads/warez/tcpip/ch09_08.htm
Previous: 9.7 Mail Servers
TCP/IP Network
Administration
Next: 10. sendmail
9.7 Mail Servers
Book Index
10. sendmail
[ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ]
file:///C|/mynapster/Downloads/warez/tcpip/ch09_08.htm (2 of 2) [2001-10-15 09:18:35]
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
[Chapter 10] sendmail
Previous: 9.8 Summary
Chapter 10
Next: 10.2 Running
sendmail as a Daemon
10. sendmail
Contents:
sendmail's Function
Running sendmail as a Daemon
sendmail Aliases
The sendmail.cf File
sendmail Configuration
Rewriting the Mail Address
Modifying a sendmail.cf File
Testing sendmail.cf
Summary
Users have a love-hate relationship with email; they love to use it, and hate when it doesn't work. It's
the system administrator's job to make sure it does work. That is the job we tackle in this chapter.
sendmail is not the only mail transport program. MMDF (Multichannel Memorandum Distribution
Facility) predates sendmail and is still used today. There are also variations of basic sendmail, such as
IDA sendmail, that are widely used. But plain sendmail is the most widely used mail transport
program, and it's the one we cover.
This entire chapter is devoted to sendmail, and an entire book is easily devoted to the subject. [1] In
part this is because of email's importance, but it is also because sendmail has a complex configuration.
[1] See sendmail, by Costales and Allman (O'Reilly & Associates), for a book-length
treatment of sendmail.
The variety of programs and protocols used for email complicates configuration and support. SMTP
sends email over TCP/IP networks. Another program sends mail between users on the same system.
Still another sends mail between systems on UUCP networks. Each of these mail systems - SMTP,
UUCP, and local mail - has its own delivery program and its own mail addressing scheme. All of this
can cause confusion for mail users and for system administrators.
file:///C|/mynapster/Downloads/warez/tcpip/ch10_01.htm (1 of 3) [2001-10-15 09:18:35]
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
[Chapter 10] sendmail
10.1 sendmail's Function
sendmail eliminates some of the confusion caused by multiple mail delivery programs. It does this by
routing mail for the user to the proper delivery program based on the email address. It accepts mail
from a user's mail program, interprets the mail address, rewrites the address into the proper form for
the delivery program, and routes the mail to the correct delivery program. sendmail insulates the end
user from these details. If the mail is properly addressed, sendmail will see that it is properly passed
on for delivery. Likewise, for incoming mail, sendmail interprets the address and either delivers the
mail to a user's mail program or forwards it to another system.
Figure 10.1 illustrates sendmail's special role in routing mail between the various mail programs
found on UNIX systems.
Figure 10.1: Mail is routed through sendmail
In addition to routing mail between user programs and delivery programs, sendmail:
●
Receives and delivers SMTP (internet) mail
●
Provides system-wide mail aliases, which allow mailing lists
Configuring a system to perform all of these functions properly is a complex task. In this chapter we
discuss each of these functions, look at how they are configured, and examine ways to simplify the
task. First, we'll see how sendmail is run to receive SMTP mail. Then we'll see how mail aliases are
used, and how sendmail is configured to route mail based on the mail's address.
file:///C|/mynapster/Downloads/warez/tcpip/ch10_01.htm (2 of 3) [2001-10-15 09:18:35]
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
[Chapter 10] sendmail
Previous: 9.8 Summary TCP/IP Network
Administration
Next: 10.2 Running
sendmail as a Daemon
9.8 Summary
Book Index
10.2 Running sendmail as a
Daemon
[ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ]
file:///C|/mynapster/Downloads/warez/tcpip/ch10_01.htm (3 of 3) [2001-10-15 09:18:35]
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
[Chapter 10] 10.2 Running sendmail as a Daemon
Previous: 10.1 sendmail's
Function
Chapter 10
sendmail
Next: 10.3 sendmail Aliases
10.2 Running sendmail as a Daemon
To receive SMTP mail from the network, run sendmail as a daemon during system startup. The sendmail
daemon listens to TCP port 25 and processes incoming mail. In most cases the code to start sendmail is
already in one of your boot scripts. If it isn't, add it. The following code is from the Slackware Linux
/etc/rc.d/rc.M startup script:
# Start the sendmail daemon:
if [ -x /usr/sbin/sendmail ]; then
echo "Starting sendmail daemon (/usr/sbin/sendmail -bd -q 15m)..."
/usr/sbin/sendmail -bd -q 15m
fi
First, this code checks for the existence of the sendmail program. If the program is found, the code displays
a startup message on the console and runs sendmail with two command-line options. One option, the -q
option, tells sendmail how often to process the mail queue. In the sample code, the queue is processed every
15 minutes (-q15m), which is a good setting to process the queue frequently. Don't set this time too low.
Processing the queue too often can cause problems if the queue grows very large, due to a delivery problem
such as a network outage. For the average desktop system, every hour (-q1h) or half hour (-q30m) is an
adequate setting.
The other option relates directly to receiving SMTP mail. The option (-bd) tells sendmail to run as a daemon
and to listen to TCP port 25 for incoming mail. Use this option if you want your system to accept incoming
TCP/IP mail.
The Linux example is a simple one. Some systems have a more complex startup script. Solaris 2.5, which
dedicates the entire /etc/init.d/sendmail script to starting sendmail, is a notable example. The mail queue
directory holds mail that has not yet been delivered. It is possible that the system went down while the mail
queue was being processed. Versions of sendmail prior to sendmail V8, such as the version that comes with
Solaris 2.5, create lock files when processing the queue. Therefore lock files may have been left behind
inadvertently and should be removed during the boot. Solaris checks for the existence of the mail queue
directory and removes any lock files found there. If a mail queue directory doesn't exist, it creates one. The
additional code found in some startup scripts is not required when running sendmail V8. All you really need
is the sendmail command with the -bd option.
file:///C|/mynapster/Downloads/warez/tcpip/ch10_02.htm (1 of 2) [2001-10-15 09:18:36]
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
[Chapter 10] 10.2 Running sendmail as a Daemon
Previous: 10.1 sendmail's
Function
TCP/IP Network
Administration
Next: 10.3 sendmail Aliases
10.1 sendmail's Function
Book Index
10.3 sendmail Aliases
[ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ]
file:///C|/mynapster/Downloads/warez/tcpip/ch10_02.htm (2 of 2) [2001-10-15 09:18:36]
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
[Chapter 10] 10.3 sendmail Aliases
Previous: 10.2 Running
sendmail as a Daemon
Chapter 10
sendmail
Next: 10.4 The sendmail.cf
File
10.3 sendmail Aliases
It is almost impossible to exaggerate the importance of mail aliases. Without them, a sendmail system
could not act as a central mail server. Mail aliases provide for:
●
Alternate names (nicknames) for individual users
●
Forwarding of mail to other hosts
●
Mailing lists
sendmail mail aliases are defined in the aliases file. [2] The basic format of entries in the aliases file
is:
[2] The location of the file is defined in the "Options" section of the sendmail
configuration file.
alias: recipient[, recipient,...]
alias is the name to which the mail is addressed, and recipient is the name to which the mail is
delivered. recipient can be a username, the name of another alias, or a full email address
containing both a username and a hostname. Including a hostname allows mail to be forwarded to a
remote host. Additionally, there can be multiple recipients for a single alias. Mail addressed to that
alias is delivered to all of the recipients, thus creating a mailing list.
Aliases that define nicknames for individual users can be used to handle frequently misspelled names.
You can also use aliases to deliver mail addressed to special names, such as postmaster or root, to the
real users that do those jobs. Aliases can also be used to implement simplified mail addressing,
especially when used in conjunction with MX records. [3] This aliases file from almond shows all of
these uses:
[3]
Chapter 8, Configuring DNS Name Service , discusses MX records.
# special names
postmaster: clark
root: norman
file:///C|/mynapster/Downloads/warez/tcpip/ch10_03.htm (1 of 3) [2001-10-15 09:18:36]
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
[Chapter 10] 10.3 sendmail Aliases
# accept
rebecca.hunt: becky@peanut
jessie.mccafferty: jessie@walnut
anthony.resnick: anthony@pecan
andy.wright: andy@filbert
# a mailing list
admin: kathy, david@peanut, sara@pecan, becky@peanut, craig,
anna@peanut, jane@peanut, christy@filbert
owner-admin: admin-request
admin-request: craig
The first two aliases are special names. Using these aliases, mail addressed to postmaster is delivered
to the local user clark, and mail addressed to root is delivered to norman.
The second set of aliases is in the form of firstname and lastname. The first alias in this group is
rebecca.hunt. Mail addressed to rebecca.hunt is forwarded from almond and delivered to
becky@peanut. Combine this alias with an MX record that names almond as the mail server for
nuts.com, and mail addressed to is delivered to This
type of addressing scheme allows each user to advertise a consistent mailing address that does not
change just because the user's account moves to another host. Additionally, if a remote user knows
that this firstname.lastname addressing scheme is used at nuts.com, he can address mail to Rebecca
Hunt as without knowing her real email address.
The last two aliases are for a mailing list. The alias admin defines the list itself. If mail is sent to
admin, a copy of the mail is sent to each of the recipients (kathy, david, sara, becky, craig, anna, jane,
and christy). Note that the mailing list continues across multiple lines. A line that starts with a blank
or a tab is a continuation line.
The owner-admin alias is a special form used by sendmail. The format of this special alias is owner-
listname where listname is the name of a mailing list. The person specified on this alias line is
responsible for the list identified by listname. If sendmail has problems delivering mail to any of the
recipients in the admin list, an error message is sent to owner-admin. The owner-admin alias points to
admin-request as the person responsible for maintaining the mailing list admin. Aliases in the form of
listname-request are commonly used for administrative requests, such as subscribing to a list, for
manually maintained mailing lists. Notice that we point an alias to another alias, which is perfectly
legal. The admin-request alias resolves to craig.
sendmail does not use the aliases file directly. The aliases file must first be processed by the
newaliases command. newaliases is equivalent to sendmail with the -bi option, which causes
sendmail to build the aliases database. newaliases creates the database files that are used by sendmail
when it is searching for aliases. Invoke newaliases after updating the aliases file to make sure that
sendmail is able to use the new aliases. [4]
[4] If the D option is used (see
Appendix E, A sendmail Reference), sendmail
automatically rebuilds the aliases database - even if newaliases is not run.
file:///C|/mynapster/Downloads/warez/tcpip/ch10_03.htm (2 of 3) [2001-10-15 09:18:36]
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
[Chapter 10] 10.3 sendmail Aliases
10.3.1 Personal mail forwarding
In addition to the mail forwarding provided by aliases, sendmail allows individual users to define
their own forwarding. The user defines her personal forwarding in the .forward file in her home
directory. sendmail checks for this file after using the aliases file and before making final delivery to
the user. If the .forward file exists, sendmail delivers the mail as directed by that file. For example,
say that user kathy has a .forward file in her home directory that contains The
mail that sendmail would normally deliver to the local user kathy is forwarded to kathy's account at
podunk.edu.
Use the .forward file for temporary forwarding. Modifying aliases and rebuilding the database takes
more effort than modifying a .forward file, particularly if the forwarding change will be short-lived.
Additionally, the .forward file puts the user in charge of his own mail forwarding.
Mail aliases and mail forwarding are handled by the aliases file and the .forward file. Everything else
about the sendmail configuration is handled in the sendmail.cf file.
Previous: 10.2 Running
sendmail as a Daemon
TCP/IP Network
Administration
Next: 10.4 The sendmail.cf
File
10.2 Running sendmail as a
Daemon
Book Index
10.4 The sendmail.cf File
[ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ]
file:///C|/mynapster/Downloads/warez/tcpip/ch10_03.htm (3 of 3) [2001-10-15 09:18:36]
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
[Chapter 10] 10.4 The sendmail.cf File
Previous: 10.3 sendmail
Aliases
Chapter 10
sendmail
Next: 10.5 sendmail
Configuration
10.4 The sendmail.cf File
The sendmail configuration file is sendmail.cf. [5] 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:
[5] 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.
10.4.1 Locating a Sample sendmail.cf File
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
file:///C|/mynapster/Downloads/warez/tcpip/ch10_04.htm (1 of 7) [2001-10-15 09:18:37]
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
[Chapter 10] 10.4 The sendmail.cf File
version of sendmail.
The tar file can be downloaded via anonymous ftp from ftp.sendmail.org. [6] 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.
[6] 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.
10.4.1.1 Building a sendmail.cf with m4 macros
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.
[7]
[7] 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.
file:///C|/mynapster/Downloads/warez/tcpip/ch10_04.htm (2 of 7) [2001-10-15 09:18:37]
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
[Chapter 10] 10.4 The sendmail.cf File
The OSTYPE macro defines operating system-specific information for the sendmail.cf file. The
cf/ostype directory contains more 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: bsd4.4, solaris2, and linux.
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 from unknown to
linux to specify the correct operating system. In the example we use sed to change unknown to
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. [8] In fact, the output file produced above is almost identical to the sample linux.smtp.cf
configuration file delivered with Linux.
[8] 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)
file:///C|/mynapster/Downloads/warez/tcpip/ch10_04.htm (3 of 7) [2001-10-15 09:18:37]
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
[Chapter 10] 10.4 The sendmail.cf File
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
tyler
pat
willy
craig
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. [9] 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:
[9] See
Appendix E for a sample script that builds the realnames database from
/etc/passwd.
makemap type name
makemap reads the standard input and writes the database out to a file it creates using the value
provided by name as the filename. The type field identifies the database type. The most commonly
supported database types for sendmail V8 are dbm, btree, and hash. [10] All of these types can be
made with the makemap command.
[10] 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
file:///C|/mynapster/Downloads/warez/tcpip/ch10_04.htm (4 of 7) [2001-10-15 09:18:37]
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
[Chapter 10] 10.4 The sendmail.cf File
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., the key 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 DOMAIN(nuts.com) 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. [11] 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.
[11] 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
file:///C|/mynapster/Downloads/warez/tcpip/ch10_04.htm (5 of 7) [2001-10-15 09:18:37]
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
[Chapter 10] 10.4 The sendmail.cf File
contains, and the tools used to debug it are universal.
10.4.2 General sendmail.cf Structure
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:
Local Information
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.
Options
Defines the sendmail options. This section usually requires no modifications.
Message Precedence
Defines the various message precedence values used by sendmail. This section is not modified.
Trusted Users
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.
Format of Headers
Defines the format of the headers that sendmail inserts into mail. This section is not modified.
Rewriting Rules
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.
Mailers
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
file:///C|/mynapster/Downloads/warez/tcpip/ch10_04.htm (6 of 7) [2001-10-15 09:18:37]
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
[Chapter 10] 10.4 The sendmail.cf File
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.
Look at the comments in your sendmail.cf file. Sometimes these comments provide valuable insight
into the file structure and the things that are necessary to configure a system.
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.
Previous: 10.3 sendmail
Aliases
TCP/IP Network
Administration
Next: 10.5 sendmail
Configuration
10.3 sendmail Aliases
Book Index
10.5 sendmail Configuration
[ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ]
file:///C|/mynapster/Downloads/warez/tcpip/ch10_04.htm (7 of 7) [2001-10-15 09:18:37]
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
file:///C|/mynapster/Downloads/warez/tcpip/ch10_05.htm
Previous: 10.4 The
sendmail.cf File
Chapter 10
sendmail
Next: 10.6 Rewriting the
Mail Address
10.5 sendmail Configuration
Every time sendmail starts up, it reads sendmail.cf. For this reason, the syntax of the sendmail.cf
commands is designed to be easy for sendmail to parse - not necessarily easy for humans to read. As a
consequence, sendmail commands are very terse, even by UNIX standards.
The configuration command is not separated from its variable or value by any spaces. This "run
together" format makes the commands hard to read.
Figure 10.2 illustrates the format of a command. In
the figure, a define macro command assigns the value nuts.com to the macro D.
Figure 10.2: A sendmail.cf configuration command
Starting with version 8 of sendmail, variable names are no longer restricted to a single character. Long
variable names, enclosed in braces, are now acceptable. For example, the define macro shown in
Figure
10.2 could be written:
D{Domain}nuts.com
However, a quick check of the sendmail.cf delivered with my Linux system shows that not a single long
variable name was used. The traditional, short variable names are still the most common. This terse
syntax can be very hard to decipher, but it helps to remember that the first character on the line is
always the command. From this single character you can determine what the command is and therefore
its structure.
Table 10.1 lists the sendmail.cf commands and their syntax.
Table 10.1: sendmail Configuration Commands
file:///C|/mynapster/Downloads/warez/tcpip/ch10_05.htm (1 of 13) [2001-10-15 09:18:39]
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
file:///C|/mynapster/Downloads/warez/tcpip/ch10_05.htm
Command Syntax Meaning
Version Level
Vlevel[/vendor]
Specify version level.
Define Macro
Dxvalue Set macro x to value.
Define Class
Ccword1[ word2]... Set class c to word1 word2....
Define Class
Fcfile Load class c from file.
Set Option
Ooption=value Set option to value.
Trusted Users
Tuser1[ user2...] Trusted users are user1 user2....
Set Precedence
Pname=number Set name to precedence number.
Define Mailer
Mname, {field=value} Define mailer name.
Define Header
H[?mflag?]name:format
Set header format.
Set Ruleset
Sn Start ruleset number n.
Define Rule
Rlhs rhs comment Rewrite lhs patterns to rhs format.
Key File
Kname type [argument] Define database name.
The following sections describe each configuration command in more detail.
10.5.1 The Version Level Command
The version level command is an optional command not found in all sendmail.cf files. You don't add a
V command to the sendmail.cf file or change one if it is already there. The V command is inserted into
the configuration file when it is first built from m4 macros or by the vendor.
The level number on the V command line indicates the version level of the configuration syntax. V1
is the oldest configuration syntax and V7 is the version supported by sendmail V8.8.5. Every level in
between adds some feature extensions. The vendor part of the V command identifies if any vendor
specific syntax is supported. The default vendor value for the sendmail distribution is "Berkeley".
The V command tells the sendmail executable the level of syntax and commands required to support
this configuration. If the sendmail program cannot support the requested commands and syntax, it
displays the following error message:
# /usr/lib/sendmail -Ctest.cf
test.cf: line 63: Bad V line: Only V1/sun syntax is supported in
this release
The error message shown above indicates that this sendmail program supports level 1 configuration files
with Sun syntax extensions. [12] The example was produced on a Solaris 2.5.1 running the sendmail
program that came with the operating system. In the example we attempted to read a sendmail.cf that
was created by the m4 macros that came with sendmail 8.8.5. The syntax and functions needed by the
sendmail.cf file are not available in the sendmail program. To use this configuration file, we would have
to compile a newer version of the sendmail program. See
Appendix E for an example of compiling
sendmail.
file:///C|/mynapster/Downloads/warez/tcpip/ch10_05.htm (2 of 13) [2001-10-15 09:18:39]
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
file:///C|/mynapster/Downloads/warez/tcpip/ch10_05.htm
[12] See Table 10-4 for Sun-specific syntax.
You will never change the values on a V command. You might, however, need to customize some D
commands.
10.5.2 The Define Macro Command
The define macro command (D) defines a macro and stores a value in it. Once the macro is defined, it is
used to provide the stored value to other sendmail.cf commands and directly to sendmail itself. This
allows sendmail configurations to be shared by many systems, simply by modifying a few system-
specific macros.
A macro name can be any single ASCII character or, as of sendmail V8, a word enclosed in curly
braces. User-created macros use uppercase letters as names. sendmail's own internal macros use
lowercase letters and special characters as names. This does not mean that you won't be called upon to
define a value for a macro with a lowercase name. A few of these internal macros are sometimes
defined in the sendmail.cf file.
Table 10.2 provides a complete list of sendmail's internal macros.
Table 10.2: sendmail's Internal Macros
Name Function
a Origination date in RFC 822 format
b Current date in RFC 822 format
c Hop count
d Date in UNIX (ctime) format
e SMTP entry message
f Sender \(lqfrom\(rq address
g Sender address relative to the recipient
h Recipient host
i Queue id
j Fully qualified domain name (host plus domain)
k UUCP node name
l Format of the UNIX from line
m Name of this domain (domain only)
n Name of the daemon (for error messages)
o Set of "operators" in addresses[13]
p Sendmail's pid
q Default format of sender address[13]
r Protocol used
s Sender's hostname
t Numeric representation of the current time
file:///C|/mynapster/Downloads/warez/tcpip/ch10_05.htm (3 of 13) [2001-10-15 09:18:39]
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.