Cover | Table of Contents | Colophon

Table of Contents

Chapter 1: Some Basics

Content preview·Buy reprint rights for this chapter

We began previous editions of this book with a very long tutorial aimed at those new to sendmail. In this edition, however, much of that tutorial has been folded into the chapters that follow, and we present, instead, a brief introductory chapter intended to get new people started. It begins with a look at some of the basic concepts of email and the sendmail program. We will show you sendmail's basic parts, explore the three parts of an email message, then demonstrate how to run sendmail by hand. We finish with an overview of the roles sendmail plays and of its various modes, and lastly, we take a preliminary look at its configuration file.

Imagine yourself with pen and paper, writing a letter to a friend far away. You finish the letter and sign it, reflect on what you've written, then tuck the letter into an envelope. You put your friend's address on the front, your return address in the lefthand corner, and a stamp in the righthand corner, and the letter is ready for mailing. Electronic mail (email for short) is prepared in much the same way, but a computer is used instead of pen and paper.

The post office transports real letters in real envelopes, whereas sendmail transports electronic letters in electronic envelopes. If your friend (the recipient) is in the same neighborhood (on the same machine), only a single post office (sendmail running locally) is involved. If your friend is in a distant location, the mail message will be forwarded from the local post office (sendmail running locally) to a distant one (sendmail running remotely) for delivery. Although sendmail is similar to a post office in many ways, it is superior in others:

• Delivery typically takes seconds rather than days.
• Address changes (forwarding) take effect immediately, and mail can be forwarded anywhere in the world.
• Host addresses are looked up dynamically. Therefore, machines can be moved or renamed and email delivery will still succeed.
• Mail can be delivered through programs that access other networks (such as UUCP and BITNET). This would be like the post office using United Parcel Service to deliver an overnight letter.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Email Basics

Content preview·Buy reprint rights for this chapter

Imagine yourself with pen and paper, writing a letter to a friend far away. You finish the letter and sign it, reflect on what you've written, then tuck the letter into an envelope. You put your friend's address on the front, your return address in the lefthand corner, and a stamp in the righthand corner, and the letter is ready for mailing. Electronic mail (email for short) is prepared in much the same way, but a computer is used instead of pen and paper.

The post office transports real letters in real envelopes, whereas sendmail transports electronic letters in electronic envelopes. If your friend (the recipient) is in the same neighborhood (on the same machine), only a single post office (sendmail running locally) is involved. If your friend is in a distant location, the mail message will be forwarded from the local post office (sendmail running locally) to a distant one (sendmail running remotely) for delivery. Although sendmail is similar to a post office in many ways, it is superior in others:

• Delivery typically takes seconds rather than days.
• Address changes (forwarding) take effect immediately, and mail can be forwarded anywhere in the world.
• Host addresses are looked up dynamically. Therefore, machines can be moved or renamed and email delivery will still succeed.
• Mail can be delivered through programs that access other networks (such as UUCP and BITNET). This would be like the post office using United Parcel Service to deliver an overnight letter.

This analogy between a post office and sendmail will break down as we explore sendmail in more detail. But the analogy serves a role in this introductory material, so we will continue to use it to illuminate a few of sendmail's more obscure points.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Requests for Comments (RFCs)

Content preview·Buy reprint rights for this chapter

A complete understanding of sendmail is not possible without at least some exposure to Requests for Comments (RFC) issued by the Internet Engineering Task Force (IETF) at the Network Information Center (NIC). These numbered documents define (among other things) the SMTP and the format of email message headers.

When you see a reference to an RFC in this book, it will appear, for example, as RFC2821. The RFCs of interest to sendmail are listed in the Bibliography at the end of this book.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Email and sendmail

Content preview·Buy reprint rights for this chapter

A mail user agent (MUA) is any of the many programs that users run to read, reply to, compose, and dispose of email. Examples of an MUA include the original Unix mail program (/bin/mail); the Berkeley Mail program; its System V equivalent (mailx); free software programs such as mush, elm, and mh; and commercial programs such as Zmail. Examples of MUAs also exist for PCs. Eudora and ClarisWorks are two standalone MUAs. Netscape and Explorer are web browsers that can also act as MUAs. Many MUAs can exist on a single machine. MUAs sometimes perform limited mail transport, but this is usually a very complex task for which they are not suited. We won't be covering MUAs in this book.

A mail transfer agent (MTA) is a highly specialized program that delivers mail and transports it between machines, like the post office does. Usually, there is only one MTA on a machine. The sendmail program is an MTA.

Beginning with V8.10, sendmail also recognizes the role of a mail submission agent (MSA), as defined in RFC2476. MTAs are not supposed to alter an email's text, except to add Received:, Return-Path:, and other required headers. Email submitted by an MUA might require more modification than is legal for an MTA to perform, so the new role of an MSA was created. An MSA accepts messages from an MUA, and has the legal right to heavily add to, subtract from, and screen or alter all such email. An MSA, for example, can ensure that all hostnames are fully qualified, and that headers, such as Date:, are always included.

The sendmail program is not the only MTA on the block. Others have existed for some time, and new MTAs appear on the scene every once in a while. Here we describe a few of the other major MTAs:

qmail

Stressing modularity and security, qmail claims to be a replacement for sendmail. The qmail program is an open source offering, available from http://www.qmail.org.

Postfix

Written by Wietse Venema, a security expert on the IBM Research staff, Postfix is advertised to be a drop-in replacement for sendmail that purports to deliver email more quickly, conveniently, and safely. The

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Basic Parts of sendmail

Content preview·Buy reprint rights for this chapter

The sendmail program is actually composed of several parts, including programs, files, directories, and the services it provides. Its foundation is a configuration file that defines the location and behavior of these other parts and contains rules for rewriting addresses. A queue directory holds mail until it can be delivered. An aliases file allows alternative names for users and the creation of mailing lists. Database files can handle tasks ranging from spam rejection to virtual hosting.

The configuration file contains all the information sendmail needs to do its job. Within it you provide information, such as file locations, permissions, and modes of operation.

Rewriting rules and rule sets also appear in the configuration file. They transform a mail address into another form that might be required for delivery. They are perhaps the single most confusing aspect of the configuration file. Because the configuration file is designed to be fast for sendmail to read and parse, rules can look cryptic to humans:

R $+ @ $+             $: $1 < @ $2 >       focus on domain
R $+ < $+ @ $+ >      $1 $2 < @ $3 >       move gaze right

But what appears to be complex is really just succinct. The R at the beginning of each line, for example, labels a rewrite rule. And the $+ expressions mean to match one or more parts of an address. With experience, such expressions (and indeed the configuration file as a whole) soon become meaningful.

Fortunately you don't need to learn the details of rule sets to configure and install sendmail. The mc form of configuration insulates you from such details, and allows you to perform very complex tasks easily.

Not all mail messages can be delivered immediately. When delivery is delayed, sendmail must be able to save a message for later transmission. The sendmail queue comprises one or more directories that hold mail until it can be delivered. A mail message can be queued:

• When the destination machine is unreachable or down. The mail message will be delivered when the destination machine returns to service.
• When a mail message has many recipients. Some mail messages might be successfully delivered but others might not. Those that have transient failures are queued for later delivery.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Basic Parts of a Mail Message

Content preview·Buy reprint rights for this chapter

In this section, we will examine the three parts that make up a mail message: the header, body, and envelope. But before we do, we must first demonstrate how to run sendmail by hand so that you can see what a message's parts look like.

Most users do not run sendmail directly. Instead, they use one of many MUAs to compose a mail message. Those programs invisibly pass the mail message to sendmail, creating the appearance of instantaneous transmission. The sendmail program then takes care of delivery in its own seemingly mysterious fashion.

Although most users don't run sendmail directly, it is perfectly legal to do so. You, like many system managers, might need to do this to track down and solve mail problems.

Here's a demonstration of one way to run sendmail by hand. First create a file named sendstuff with the following contents:

This is a one-line message.

Second, mail this file to yourself with the following command line, where you is your login name:

% /usr/sbin/sendmail you <sendstuff 

Here, you run sendmail directly by specifying its full pathname. When you run sendmail, any command-line arguments that do not begin with a - character are considered to be the names of the people to whom you are sending the mail message.

The <sendstuff sequence causes the contents of the file that you have created (sendstuff) to be redirected into the sendmail program. The sendmail program treats everything it reads from its standard input (up to the end of the file) as the mail message to transmit.

Now view the mail message you just sent. How you do this will vary. Many users just type mail to view their mail. Others use the mh(1) package and type inc to receive and show to view their mail. No matter how you normally view your mail, save the mail message you just received to a file. It will look something like this:

From you@Here.US.EDU  Fri Dec 13 08:11:44 2002
Received: (from you@localhost)
       by Here.US.EDU (8.12.7/8.12.7)
       id d8BILug12835 for you; Fri, 13 Dec 2002 08:11:44 -0600 (MDT)
Date: Fri, 13 Dec 2002 08:11:43
From: you@Here.US.EDU (Your Full Name)
Message-Id: 200201011548.d872mLW24467@Here.US.EDU>
To: you   

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Basic Roles of sendmail

Content preview·Buy reprint rights for this chapter

The sendmail program plays a variety of roles, all critical to the proper flow of electronic mail. It listens to the network for incoming mail, transports mail messages to other machines, and hands local mail to a local program for local delivery. It can append mail to files and pipe mail through other programs. It can queue mail for later delivery and understand the aliasing of one recipient name to another.

The sendmail program's role (position) in the local filesystem hierarchy can be viewed as an inverted tree (see Figure 1-3).

Figure 1-3: The sendmail.cf file leads to everything else

When sendmail is run, it first reads the /etc/mail/sendmail.cf configuration file. Among the many items contained in that file are the locations of all the other files and directories that sendmail needs.

Files and directories listed in sendmail.cf are usually specified as full pathnames for security (such as /var/spool/mqueue rather than mqueue). As the first step in our tour of those files, run the following command to gather a list of them:

% grep =/ /etc/mail/sendmail.cf

The output produced by the grep(1) command might look something like the following:

O AliasFile=/etc/mail/aliases
#O ErrorHeader=/etc/mail/error-header
O HelpFile=/etc/mail/helpfile
O QueueDirectory=/var/spool/mqueues/q.*
O StatusFile=/etc/mail/statistics
#O UserDatabaseSpec=/etc/mail/userdb
#O ServiceSwitchFile=/etc/mail/service.switch
#O HostsFile=/etc/hosts
#O SafeFileEnvironment=/arch
#O DeadLetterDrop=/var/tmp/dead.letter
O ControlSocketName=/var/spool/mqueues/.control
#O PidFile=/var/run/sendmail.pid
#O DefaultAuthInfo=/etc/mail/default-auth-info
Mlocal,       P=/usr/lib/mail.local, F=lsDFMAw5:/|@qPSXfmnz9, S=EnvFromSMTP/HdrFromL,
Mprog,        P=/bin/sh, F=lsDFMoqeu9, S=EnvFromL/HdrFromL, R=EnvToL/HdrToL, D=$z:/,

Notice that some lines begin with an O character, some with an M, and others with a #. The O marks a line as a configuration option. The word following the O is the name of the option. The options in the preceding output show the location of the files that sendmail uses.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Basic Modes of sendmail

Content preview·Buy reprint rights for this chapter

Besides the daemon mode (discussed earlier), sendmail can be run in a number of other useful modes. In this section we'll have a look at some of these. Others we'll leave for later.

One way to run sendmail is to provide it with the name of a recipient as the only command-line argument. For example, the following sends a mail message to george:

% /usr/lib/sendmail george

Multiple recipients can also be given. For example, the following sends a mail message to george, truman, and teddy:

% /usr/lib/sendmail george,truman,teddy

The sendmail program accepts two different kinds of command-line arguments. Arguments that do not begin with a - character (such as george) are assumed to be recipients. Arguments that do begin with a - character are taken as switches that determine the behavior of sendmail. The recipients must always follow all the switched arguments. Any switched arguments that follow recipients will be interpreted as recipient addresses, potentially causing bounced mail.

In this chapter we will cover only a few of these switch-style command-line arguments (see Table 1-1). The complete list of command-line switches, along with an explanation of each, is presented in Chapter 15.

Table 1-1: Some command-line switches

Flag	Description
-b	Set operating mode
-v	Run in verbose mode
-d	Run in debugging mode

Section 1.7.1.1: Become a mode (-b)

The sendmail program can function in a number of different ways depending on which form of -b argument you use. One form, for example, causes sendmail to display the contents of the queue. Another causes sendmail to rebuild the aliases database. A complete list of the -b command-line mode-setting switches is shown in Table 1-2. We will cover only a few in this chapter.

Table 1-2: Forms of the -b command-line switch

Form	Description
-ba	Use ARPAnet (Grey Book) protocols
-bD	Run as a daemon, but don't fork
-bd	Run as a daemon
-bH	Purge persistent host status
-bh	Print persistent host status
-bi	Rebuild alias database

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

The sendmail.cf File

Content preview·Buy reprint rights for this chapter

The sendmail.cf file is read and parsed by sendmail every time sendmail starts. It contains information that is necessary for sendmail to run. It lists the locations of important files and specifies the default permissions for those files. It contains options that modify sendmail's behavior. Most important, it contains rules and rule sets for rewriting addresses.

The sendmail.cf configuration file is line-oriented. A configuration command, composed of a single letter, begins each line:

V9/Berkeley                   ←good
 V9/Berkeley                  ←bad, does not begin a line
V9/Berkeley Fw/etc/mail/mxhosts   ←bad, two commands on one line
Fw/etc/mail/mxhosts           ←good

Each configuration command is followed by parameters that are specific to it. For example, the V command is followed by a number, a slash, and a vendor name. Whereas the F command is followed by a letter (a w in the example), then the full pathname of a file. The complete list of configuration commands is shown in Table 1-4.

Table 1-4: The sendmail.cf file's configuration commands

Command	Description
C	Define a class macro
D	Define a macro
E	Define an environment variable (beginning with V8.7)
F	Define a class macro from a file, pipe, or database map
H	Define a header
K	Declare a keyed database (beginning with V8.1)
L	Include extended load average support (contributed software, not covered)
M	Define a mail delivery agent
O	Define an option
P	Define delivery priorities
Q	Define a queue (beginning with V8.12)
R	Define a rewriting rule
S	Declare a rule-set start
T	Declare trusted users (ignored in V8.1, restored in V8.7)
V	Define configuration file version (beginning with V8.1)
X	Define a mail filter (beginning with V8.12)

Some commands, such as V, should appear only once in your sendmail.cf file. Others, such as R, can appear often.

Blank lines and lines that begin with the # character are considered comments and are ignored. A line that begins with either a tab or a space character is a continuation of the preceding line:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Chapter 2: Build and Install sendmail

Content preview·Buy reprint rights for this chapter

In this chapter we show you how to obtain the latest version of sendmail in source form, then how to build and install it yourself. Although this process can be simple, many decisions that can complicate it must be made ahead of time.

Should you compile sendmail from the source or obtain it from a vendor? Vendors tend to ship old versions of sendmail with their operating systems. Current versions of operating systems frequently ship V8.11 sendmail. Very old versions of sendmail should be replaced because they are insecure. Newer versions should also be replaced because the latest version (V8.12) contains many new and valuable features.

To find out which version you are running, issue the following command:

% /usr/sbin/sendmail -d0.1 -bt < /dev/null

The first line (of possibly many) printed should contain the version number. If no version is displayed, you might be running a very old version of sendmail indeed, or some other program masquerading as sendmail. In either instance, you should upgrade.

If V8.9.2 or earlier is displayed, you should plan to upgrade. V8.9.3 was the last secure version of the V8.9 series.

If V8.11.5 or earlier is displayed, you should plan to upgrade. V8.11.6 was the last secure version of the V8.11 series.

A more difficult decision is whether to upgrade to V8.12 if you are already running V8.9.3 or V8.11.6 sendmail. Potential reasons for upgrading are as follows:

Security

The sendmail program has always been a prime target of attack by crackers (probably because it is distributed as fully commented source code). Although sendmail has been secure since V8.11.6, one of your C-language libraries might not be. If you have been notified of a security hole in your library, you should consider recompiling sendmail, using a new, secure library. You can do this only with the open source. Recompiling is not an option with vendor-supplied binaries.

Spam

If your site is beset by spam mailings (as most sites are these days), you should at least be running V8.9.3 sendmail with the access_db FEATURE support included and utilized (Section 7.5). The V8.9 release of

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Vendor Versus Compiling

Content preview·Buy reprint rights for this chapter

Should you compile sendmail from the source or obtain it from a vendor? Vendors tend to ship old versions of sendmail with their operating systems. Current versions of operating systems frequently ship V8.11 sendmail. Very old versions of sendmail should be replaced because they are insecure. Newer versions should also be replaced because the latest version (V8.12) contains many new and valuable features.

To find out which version you are running, issue the following command:

% /usr/sbin/sendmail -d0.1 -bt < /dev/null

The first line (of possibly many) printed should contain the version number. If no version is displayed, you might be running a very old version of sendmail indeed, or some other program masquerading as sendmail. In either instance, you should upgrade.

If V8.9.2 or earlier is displayed, you should plan to upgrade. V8.9.3 was the last secure version of the V8.9 series.

If V8.11.5 or earlier is displayed, you should plan to upgrade. V8.11.6 was the last secure version of the V8.11 series.

A more difficult decision is whether to upgrade to V8.12 if you are already running V8.9.3 or V8.11.6 sendmail. Potential reasons for upgrading are as follows:

Security

The sendmail program has always been a prime target of attack by crackers (probably because it is distributed as fully commented source code). Although sendmail has been secure since V8.11.6, one of your C-language libraries might not be. If you have been notified of a security hole in your library, you should consider recompiling sendmail, using a new, secure library. You can do this only with the open source. Recompiling is not an option with vendor-supplied binaries.

Spam

If your site is beset by spam mailings (as most sites are these days), you should at least be running V8.9.3 sendmail with the access_db FEATURE support included and utilized (Section 7.5). The V8.9 release of sendmail was the first that specifically targeted the suppression of spam. If your site suffers from spam mailings, consider upgrading to V8.12 soon.

Bug fixes

After widespread use and abuse, any program will begin to show its bugs. The

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Obtain the Source

Content preview·Buy reprint rights for this chapter

The latest release of sendmail is available via:

http://www.sendmail.org/current-release.html

When you download the source you must select one file from many that are listed. In addition to selecting the version you want, you must choose between two forms of compressed tar(1) distributions. Those that end in .Z are compressed with Unix compress(1); those that end in .gz are compressed with GNU gzip(1). The latter is the preferred form because the file is smaller and therefore quicker to transfer.

In addition to the two forms of distribution, each release has a PGP signature file associated with it. This is a signature of the uncompressed file, so you need to uncompress the tar(1) file before verifying it.

To verify V8.5 or earlier distributions, get Eric Allman's public key by sending email to pgp-public-keys@keys.pgp.net with the following subject line:

Subject: MGET Allman

Eric Allman's public key will be mailed back to you a few minutes later. Save that returned email to a file—for example, /tmp/eric.asc—and add that key to your public "keyring" with the command:

% pgp -ka /tmp/eric.asc             ← for pgp version 2.x 
% pgpk -a /tmp/eric.asc             ← for pgp version 5.x 

For V8.6 and above, you download a special signing key from www.sendmail.org, instead of Eric's key. The fingerprint for the signing key is:

CA AE F2 94 3B 1D 41 3C  94 7B 72 5F AE 0B 6A 11   ← 1997
F9 32 40 A1 3B 3A B6 DE  B2 98 6A 70 AF 54 9D 26   ← 1998
25 73 4C 8E 94 B1 E8 EA  EA 9B A4 D6 00 51 C3 71   ← 1999
81 8C 58 EA 7A 9D 7C 1B  09 78 AC 5E EB 99 08 5D   ← 2000
59 AF DC 3E A2 7D 29 56  89 FA 25 70 90 0D 7E C1   ← 2001
7B 02 F4 AA FC C0 22 DA  47 3E 2A 9A 9B 35 22 45   ← 2002

The fingerprint for Eric's key is:

C0 28 E6 7B 13 5B 29 02 6F 7E 43 3A 48 4F 45 29    ←  V8.5 and earlier

Once you have the appropriate key, execute the following command for the uncompressed source file:

pgp signature-file           ←  for pgp version 2.x 
pgpv signature-file here     ←  for pgp version 5.x 

If the uncompressed tar file is good, pgp(1) will report that the signature is valid.

A few things can go wrong here, causing the verification to fail:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

The Build Script

Content preview·Buy reprint rights for this chapter

The first step in compiling sendmail is to establish an object directory and a Makefile that is appropriate to your machine architecture and operating system. You do this by running the Build script in the sendmail source directory:

% cd sendmail
% ./Build -n
Configuration: pfx=, os=SunOS, rel=4.1.4, rbase=4, rroot=4.1, arch=sun4, sfx=
Using M4=/usr/5bin/m4
Creating ../obj.SunOS.4.1.4.sun4/sendmail using ../devtools/OS/SunOS
←  many more lines here
%

Here, Build found that our machine was a sun4, running the SunOS 4.1.4 release of Unix. Build then created the working directory ../obj.SunOS.4.1.4.sun4, set up symbolic links to all the source files in that directory, and finally generated a Makefile there.

The Build program understands several command-line switches that can be used to modify its behavior (see Table 2-2). Any switch or other command-line argument that is not in that table is carried through and passed as is to the make(1) program. For example, specifying the -n switch to Build (in the earlier example) caused Build to pass that switch to make(1), thereby preventing make(1) from actually building sendmail.

Table 2-2: Build command-line switches

Switch	§	Description
-A	-A	Show the architecture for the build.
-c	-c	Clean out an existing object tree.
-E	-E	Pass environment variables to build.
-f	-f	Use site file in alternative directory.
-I	-I	Add additional include directories.
-L	-L	Add additional library directories.
-m	-m	Show but don't create the directory.
-M	-M	Show the name of the object directory.
-O	-O	Specify the path of the object directory.
-Q	-Q	Set prefix for the object directory and Build m4 configuration file.
-S	-S	Skip system-specific configuration.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Building with m4

Content preview·Buy reprint rights for this chapter

The make(1) program is used to compile and install sendmail, a site that provides precompiled compilers that you can easily install. The Build script creates not only an object working directory, but also an appropriate Makefile in that directory using m4(1). Unless you tell Build to do otherwise, the Makefile it creates will be based solely on information it finds in the appropriate devtools/OS and devtools/Site subdirectories.

For most sites this default behavior will produce the desired result. For other sites different defaults are needed.

In this section we discuss those m4 directives necessary for building a Makefile. To understand m4(1), leap ahead to Chapter 4, review the information there, then return here.

Creating a Makefile with Build is simplicity itself. First decide whether you wish to maintain your m4 file inside the sendmail source tree, or outside it. If you choose to maintain your m4 file inside the source tree, just name it devtools/Site/site.config.m4 (see Section 2.5 for details) and run Build like this:

% ./Build

Note, here we have chosen to maintain all our Build m4 files inside the sendmail source tree. This approach allows administrators to rebuild sendmail without needing to remember where the m4 file is located.

If you choose to maintain your m4 file outside the source tree, use the -f command-line switch with Build to specify the location of that file:

% ./Build -f /usr/local/configs/sendmail/oursite.m4

Note that here, we have chosen to maintain all our Build m4 files in a directory that is outside the sendmail distribution. This approach allows you to upgrade to new releases of sendmail without having to remember to copy the devtools/Site directory each time. The downside to this approach is that you must remember to use the -f command-line switch every time you build. If you fail to remember, or if someone else builds without knowing the need for -f, the created sendmail binary may not work as you expect or might lack the abilities you require.

Your m4 file is built using the directives shown in Table 2-3, which are described more fully in the sections that follow. One example of an

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Build sendmail

Content preview·Buy reprint rights for this chapter

Before building sendmail, leap ahead to Chapter 3 and review the many #define macros defined there. Consider those marked as tune, and for any that you find important, include a definition for each in your m4 build file. When your m4 build file is complete, return here.

After you have finished configuring your m4 build file, you are ready to build sendmail. First run the following command in the sendmail source directory:

# ./Build -f /path/to/your/m4/file -n

This command first creates the obj directory in which sendmail will be built, populates that directory with symbolic links, and places a configured Makefile there. It then displays all the commands that make will generate without actually executing them.

If you are building a vanilla sendmail, or if you have placed your m4 file in the devtools/Site directory, you can omit the -f and the path to your m4 build file. If you wish to tune sendmail to your custom needs first, before running Build, you need to create an m4 file (as discussed earlier).

You can create your Build m4 files either outside the sendmail distribution or inside a special directory inside the distribution. If you maintain them outside, you will have to use the -f switch each time you build, but will avoid having to copy them again for each release of sendmail.

If you create a special file inside the devtools/Site directory, that file will be included without the need for a -f. The name of the file is site.config.m4. If you want to maintain several master files in that directory, you can do so depending on your operating system type. When Build runs, it prints a line that looks like the following line split to fit the page:

Configuration: pfx=, os=SunOS, rel=4.1.4, rbase=4, rroot=4.1, arch=sun4, sfx=,
variant=optimized

Here, the name of the operating system is printed following the os=. If you were to create a file in the devtools/Site directory called site.SunOS.m4, it, too, would be automatically found and used without the need for a -f switch.

If you have defined the environment variable SENDMAIL_SUFFIX, the sfx= will be assigned that value with a dot in front of it. That value can be used to further tune the name of the files in

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Install sendmail

Content preview·Buy reprint rights for this chapter

There are two approaches to installing a new sendmail:

• If you choose to run the new sendmail in place of the original, you first need to create and install a new configuration file. The m4(1) program is used to automate the process of configuration file creation. See Chapter 4 for a full description of this process.
• If you choose to keep the original and install the new sendmail in parallel (until you can test it), you can proceed with the installation and defer configuration files until later. Note that this choice presumes you customized the file locations.

After you have compiled sendmail (and if the configuration file is ready and tested), you can install it as your production version. If you are already running a sendmail and will be overwriting that binary, you will need to kill that version first (Section 1.7.1.2).

For versions prior to V8.12, installing sendmail looks like this:

# ./Build -n install

You use -n to be sure that the installation caused is, in fact, correct for your site. A typical such run, for example, might look like this:

Configuration: pfx=, os=SunOS, rel=4.1.4, rbase=4, rroot=4.1, arch=sun4, sfx=
Making in ../obj.SunOS.4.1.4.sun4/sendmail
if [ ! -d /etc/mail ]; then mkdir -p /etc/mail; fi
install -c -o bin -g bin -m 444 helpfile /etc/mail/helpfile
if [ ! -d /etc/mail ]; then mkdir -p /etc/mail; fi
install -c -o root -g bin -m 644 statistics /etc/mail/statistics
install -c -o root -g bin -m 4555 sendmail /usr/lib
for i in /usr/ucb/newaliases /usr/ucb/mailq /usr/ucb/hoststat /usr/ucb/purgestat; do \
        rm -f $i; \
        ln -s /usr/lib/sendmail $i; \
done
install -c -o bin -g bin -m 444 sendmail.0 /usr/share/man/cat8/sendmail.8
install -c -o bin -g bin -m 444 aliases.0 /usr/share/man/cat5/aliases.5
install -c -o bin -g bin -m 444 mailq.0 /usr/share/man/cat1/mailq.1
install -c -o bin -g bin -m 444 newaliases.0 /usr/share/man/cat1/newaliases.1

If all looks good, you can install sendmail with this command:

# ./Build install

But be aware that the new sendmail might not work properly with your old configuration file. See Chapter 4 for guidance in creating a new configuration file.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Pitfalls

Content preview·Buy reprint rights for this chapter

• Before replacing your current sendmail with a new version, be sure that the queue is empty. The new version might not be able to properly process old (or different) style queued files. After running the new sendmail for the first time, look in the queue directory for filenames that start with an uppercase Q, which can indicate a problem. See Section 11.5 for a description of why these files appear and what to do about them.
• If you change the location of the queue to a different disk, be sure that disk is mounted (in /etc/rc) before the sendmail daemon is started. If sendmail starts first, there is a risk that messages will be queued in the mount point before the disk is mounted. This will result in mysteriously vanishing mail.
• Always save the old sendmail and configuration file. The new version might fail when you first try to run it. If the failure is difficult to diagnose, you might need to run the old version while you fix the new version. But beware that the old version will probably not be able to read the queue files created by the new version.
• Some operating systems allow disks to be mounted such that set-user-id permissions are disallowed. If you relocate sendmail, avoid locating it on such a disk.
• Don't be mistaken in the belief that nis will correctly give you MX (Mail eXchanger) for hosts. If, after compiling and installing sendmail, you find that you cannot send mail to hosts using MX records, you should recompile with NAMED_BIND defined (NAMED_BIND). Also note that a misconfigured service-switch file can also prevent proper MX lookups (ServiceSwitchFile).

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Build m4 Macro Reference

Content preview·Buy reprint rights for this chapter

In this section we list all the current Build macros available for use in your m4 build file. They are listed in alphabetical order and summarized in Table 2-3.

Some of these build macros set values for #define macros. For a description of each of those #define macros see Chapter 3.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

APPENDDEF( )

Content preview·Buy reprint rights for this chapter

APPENDDEF( )

The APPENDDEF( ) m4 directive allows you to append new information to information that was previously defined. To illustrate, consider that the locations of your #include files are sometimes preset in the appropriate devtools/OS directory. For OS/UXPDS.V10, for example, the default is:

-I/usr/include -I/usr/ucbinclude

You can use this APPENDDEF( ) directive to add another directory to this list, without erasing what is already there:

APPENDDEF(`confINCDIRS', `-I/usr/local/include/db')

This causes the new directory to be appended to the declaration in the previous example:

-I/usr/include -I/usr/ucbinclude -I/usr/local/include/db

Even when you are not sure if a macro has been given a value by default, you can safely use this APPENDDEF( ) directive because no harm is caused by appending to an empty definition. See also PREPENDDEF( ).

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

confBEFORE

Content preview·Buy reprint rights for this chapter

confBEFORE

The confBEFORE macro is used to specify the presence of a special header file before compiling. The confBEFORE macro causes an appropriate BEFORE= directive to appear in your Makefile. It is very unlikely that you will ever have to change this from the value that is predefined for you. But if you do, you can do so like this illustration from SunOS 4.0:

define(`confBEFORE', `stdlib.h stddef.h limits.h')
PUSHDIVERT(3)
stddef.h stdlib.h limits.h:
        cp /dev/null $@
POPDIVERT

First, note that the declaration of confBEFORE requires a corresponding section of Makefile code to be inserted between diversions (PUSHDIVERT and POPDIVERT). The first line in this example says that the three files stdlib.h, stddef.h, and limits.h must exist in the obj... directory before sendmail can be compiled. It causes those three header files to be listed with the BEFORE= directive in the resulting Makefile:

BEFORE= stdlib.h stddef.h limits.h
...
sendmail: ${BEFORE} ${OBJS}

The diversion level 3 (in PUSHDIVERT) causes the two lines that follow to be inserted into the Makefile at the appropriate point. The diversion ends with POPDIVERT.

To illustrate further, suppose you want to include your own C-language source and header files with the Build of sendmail. One way to do this might be to add the following lines to your m4 build file:

APPENDDEF(`conf_sendmail_ENVDEF', `-DMYCODE')
APPENDDEF(`confBEFORE', `mycode.h')
APPENDDEF(`confSMOBJADD', `mycode.o')
PUSHDIVERT(3)
mycode.h mycode.c:
       ln -s /usr/local/src/mycode/$@
POPDIVERT

The first line adds -DMYCODE to the ENVDEF= line in Makefile (confENVDEF and conf_prog_ENVDEF). Here, we presume that C-language hooks have been added to the sendmail source, and that they are enabled/disabled by wrapping them in preprocessor conditionals. For example:

# ifdef MYCODE
                if (mycode(e->e_eid) < 0)
                       return FALSE;
# endif

The second line in your m4 file appends mycode.h to this confBEFORE macro. The third line causes the OBJADD= directive in Makefile to be given the value mycode.o (confOBJADD). This automatically adds that object file name to the list of all object files in

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

confBLDVARIANT

Content preview·Buy reprint rights for this chapter

confBLDVARIANT

This confBLDVARIANT Build macro is used to convey to the make program a notion of how the compile should run. The possibilities are:

DEBUG

Sets the confOPTIMIZE Build macro to a value of -g for FreeBSD or to -g -Wall for Linux.

OPTIMIZED

Sets the confOPTIMIZE Build macro to a value of -O for FreeBSD or to -O2 for Linux.

PURIFY

Sets the confOPTIMIZE Build macro to a value of -g for FreeBSD and Linux.

The way you use this confBLDVARIANT Build macro looks like this:

define(`confBLDVARIANT', `DEBUG')
define(`confBLDVARIANT', `OPTIMIZED')
define(`confBLDVARIANT', `PURIFY')

The -v command-line switch (-v) for the Build program uses command-line arguments of debug, optimized, and purify to automatically set this confBLDVARIANT macro.

Note that the arguments used for confBLDVARIANT are all uppercase, while those used for -v are all lowercase.

Variants are available only for FreeBSD and Linux as of V8.12.2 sendmail. If you are on another OS, this macro will silently be ignored. If you attempt to use PURIFY, you will see the following Build-time error:

Sorry, the purify build variant has not been plumbed yet. (Bummer.)

Read the RELEASE_NOTES file supplied with the sendmail source to see if more recent versions support purify and other operating systems.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

confBUILDBIN

Content preview·Buy reprint rights for this chapter

confBUILDBIN

The confBUILDBIN macro is used to define the location of the devtools/bin directory. Normally, this macro will never have to be defined because the default value is correct, but there might be a rare circumstance when you will need to redefine it. If, for example, you need to move the devtools/bin directory to a different path, or rename it, you can do so like this:

define(`confBUILDBIN', `../../OLD_devtools/bin')

Note that the value given to confBUILDBIN must be either an absolute path or a path relative to the obj directory (sendmail is built inside the obj directory).

The confBUILDBIN macro sets the BUILDBIN= line in Makefile. Depending on your operating system, that line might or might not be used. For Solaris 2.5, for example, it is used like this:

INSTALL=${BUILDBIN}/install.sh

One use for confBUILDBIN can occur when you are actively modifying the sendmail code, and it becomes appropriate to maintain the source completely separate from the normal distribution tree.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

confCC

Content preview·Buy reprint rights for this chapter

confCC

The confCC macro is used to specify which C-language compiler to use when building sendmail. The default is probably appropriate for your system, but there might be times when a different compiler is preferred. For example, consider the desire to use Sun's unbundled compiler instead of gcc(1) under Solaris 2.5:

define(`confCC', `/usr/opt/SUNWspro/bin/cc')

The confCC macro might also be used to compile for testing with purify(1):

define(`confCC', `/usr/local/bin/purify cc')

Or you might need to use a specific version of gcc:

define(`confCC', `gcc -V2.7.2.1')

When compiling under Solaris with Sun's unbundled compiler, you will need to declare the following two lines:

define(`confCC', `/opt/SUNWspro/bin/cc')
define(`confDEPEND_TYPE', `Solaris')

Here, a confDEPEND_TYPE of Solaris causes a Makefile to be constructed with correct dependencies for Sun's unbundled compiler (confDEPEND_TYPE).

The confCC macro provides the value used with the CC= Makefile directive. This value is used to compile .o files from .c files, and to ld(1) the final sendmail executable.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

confCCOPTS

Content preview·Buy reprint rights for this chapter

confCCOPTS

When compiling sendmail or its companion programs, you might need to add special command-line flags to the compiler's invocation. One example might be the need to add a -nostdinc switch for gcc. The confCCOPTS macro allows you to do this. The following instructs the gcc compiler to allow traditional K&R instructions:

define(`confCCOPTS', `-traditional')

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

confCCOPTS_SO

Content preview·Buy reprint rights for this chapter

confCCOPTS_SO

Use of this macro is not supported in the open source version of sendmail.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

confCOPY

Content preview·Buy reprint rights for this chapter

confCOPY

The process of building sendmail includes initializing the contents of some associated files. One example is the statistics file. That file should begin as an empty file. The build process creates it with a command line such as this:

cp /dev/null statistics

For safety's sake, especially if you changed the name of the statistics file with the confSTFILE macro (confSTFILE), you might change the copy command's invocation to:

define(`confCOPY', `cp -i')

The -i causes cp(1) to prompt for your OK if the target file already exists.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

confDEPEND_TYPE

Content preview·Buy reprint rights for this chapter

confDEPEND_TYPE

The confDEPEND_TYPE macro defines the method that should be included in your Makefile for use in creating make(1) dependencies. The methods supported are located in the devtools/M4/depend directory. We show them in Table 2-6.

Table 2-6: Build m4 directives

Method	File	How invoked
AIX	devtools/M4/depend/AIX.m4	${CC} -M -E ${COPTS} $$i
BSD	devtools/M4/depend/BSD.m4	mkdep -a -f Makefile ${COPTS} *.c
CC-M	devtools/M4/depend/CC-M.m4	${CC} -M ${COPTS} *.c >> Makefile
generic	devtools/M4/depend/generic.m4	nothing
NCR	devtools/M4/depend/NCR.m4	${CC} -w0 -Hmake ${COPTS} *.c >> Makefile
Solaris	devtools/M4/depend/Solaris.m4	${CC} -xM ${COPTS} *.c >> Makefile
X11	devtools/M4/depend/X11.m4	mak