SYBEX Sample Chapter

Linux Sendmail Administration

(Craig Hunt Linux Library)
Craig Hunt

Chapter 3: Running Sendmail

Copyright 2001 SYBEX Inc., 1151 Marina Village Parkway, Alameda, CA 94501. World rights reserved. No part of this publication
may be stored in a retrieval system, transmitted, or reproduced in any way, including but not limited to photocopy, photograph,
magnetic or other record, without the prior agreement and written permission of the publisher.
ISBN: 0-7821-2737-1
SYBEX and the SYBEX logo are either registered trademarks or trademarks of SYBEX Inc. in the USA and other countries.
TRADEMARKS: Sybex has attempted throughout this book to distinguish proprietary trademarks from descriptive terms by following
the capitalization style used by the manufacturer. Copyrights and trademarks of all products and services listed or described herein
are property of their respective owners and companies. All rules and laws pertaining to said copyrights and trademarks are inferred.
This document may contain images, text, trademarks, logos, and/or other material owned by third parties. All rights reserved. Such
material may not be copied, distributed, transmitted, or stored without the express, prior, written consent of the owner.
The author and publisher have made their best efforts to prepare this book, and the content is based upon final release software
whenever possible. Portions of the manuscript may be based upon pre-release versions supplied by software manufacturers. The
author and the publisher make no representation or warranties of any kind with regard to the completeness or accuracy of the
contents herein and accept no liability of any kind including but not limited to performance, merchantability, fitness for any particular
purpose, or any losses or damages of any kind caused or alleged to be caused directly or indirectly from this book.

3
Running Sendmail
C

hapter 2, Understanding E-Mail Architecture, illustrates the importance of

Sendmail for a Linux system. Sendmail implements the SMTP protocol for Linux systems.
It sends and receives SMTP mail for the system, and it acts as an interface between the
users mail program and the Internet. These vital tasks make Sendmail a basic component
of most Linux systems.
Sendmail is such an essential part of a Linux system that it is usually installed by default
and run at start-up. If it is not installed on your system, you need to know how to install
it. Additionally, you need to know how to compile the Sendmail program for those times
when you want to install the latest source code distribution of Sendmail on an existing
Linux system. This chapter covers both of those topics. It also examines how and why the
Sendmail process runs at start-up, and youll look at the tools used to control whether or
not starting the Sendmail daemon is part of the Linux boot process on your system.

Running Sendmail at Start-Up

Sendmail runs in two distinct modes: real-time mode for outbound mail delivery and daemon mode for collecting inbound mail and queue processing. When a mail user agent
(MUA) has mail to send, it creates an instantiation of the Sendmail program to deliver
that piece of mail. The instantiation of Sendmail lives long enough to deliver that one
piece of mail. If it cannot successfully deliver the mail, it writes the mail to the mail queue
and terminates. Most Sendmail processes have a very short life. The Sendmail daemon, on

52

Chapter 3 Running Sendmail

the other hand, runs the entire time the system is running, constantly listening for
inbound mail and periodically processing the queue to deliver undelivered mail. The
Sendmail daemon, like most other daemons, is started at boot time.
The ps command reveals whether or not Sendmail is running on your system:
[root]# ps -C sendmail
PID TTY
542 ?

TIME CMD
00:00:36 sendmail

The low process ID (PID) shows that this process was started during the boot. Running
this ps command on most Linux systems will show that Sendmail is running because, generally, Sendmail becomes part of the boot process when you first install Linux.
Many systems are running the Sendmail daemon unnecessarily. It is not necessary to run
Sendmail as a daemon in order to send mail. Running the sendmail command with the
-bd option is required only if your system directly receives SMTP mail. A Linux mail client
can collect inbound mail from the mailbox server using POP or IMAP and can relay outbound mail through the mail relay server without running the Sendmail daemon. Deciding which systems should run the Sendmail daemon is part of the process of planning your
e-mail architecture. Unneeded daemons consume system resources and provide holes
through which network intruders can slither. Take care when selecting which systems
really need any daemon, including Sendmail.
It is possible to enable or disable Sendmail after the system is installed, and there are several tools to do this. These tools vary depending on the type of start-up procedures used.
Some Linux systems use BSD-style start-up procedures, while others use System Vstyle
procedures.
On Linux distributions that use System Vstyle boot procedures, the script that starts
Sendmail is usually found in the /etc/rc.d/init.d directory, where it is stored under a
name such as sendmail, mail, or mta. On distributions that use BSD-style boot procedures, the commands that start Sendmail are stored in one of the rc scripts. For example,
on Slackware 4.0, the commands to start Sendmail are found in the rc.M script located
in the /etc/rc.d directory. Regardless of the name of the script used for this purpose,
some start-up script is used to start Sendmail at boot time.
TIP To locate the Sendmail start-up script on your Linux system, go to the directory that holds start-up scripts and run the command grep sendmail * to search
every file for references to Sendmail. Not sure where the start-up scripts are
stored? Go to /etc and look for files or directories that begin with the string rc.
Those are start-up files and directories.

53

On a BSD-Style Linux System

Linux systems such as Slackware that use BSD-style boot procedures start Sendmail by
executing the sendmail command directly from one of the main start-up files. The code
that runs the Sendmail daemon in the Slackware Linux /etc/rc.d/rc.M start-up script is
very straightforward, as shown in Listing 3.1.
Listing 3.1

Starting Sendmail from a Slackware Boot Script

# Start the sendmail daemon:

if [ -x /usr/sbin/sendmail ]; then
echo "Starting sendmail daemon"
/usr/sbin/sendmail -bd -q 15m
fi

Listing 3.1 shows a Slackware system ready to run Sendmail. The first line is a comment,
as indicated by the fact that it starts with a pound sign (#). The next lines are an if statement that checks whether or not the sendmail command is available. If the command is
found, a message is displayed on the console indicating that Sendmail is starting and then
the sendmail command is run.
The code in Listing 3.1 runs the sendmail command with the -bd and the -q options. In
addition to listening for inbound mail, the Sendmail daemon periodically checks to see
whether there is mail waiting to be delivered. Its possible that a Sendmail process that
was started to send a message was not able to successfully deliver the mail. In that case,
the process writes the message to the mail queue and counts on the daemon to deliver it
at a later time. The -q option tells the Sendmail daemon how often to check the undelivered mail queue. In the Slackware example, the queue is processed every 15 minutes
(-q15m).
To prevent Slackware from starting Sendmail at boot time, comment the lines shown in
Listing 3.1 out of the rc.M script by placing a pound sign at the beginning of each line.
To restore Sendmail to the boot process, remove the pound signs. These techniques are
easy and they work, but they are far from elegant.
Directly editing a start-up script is easy, but dangerous. Most system administrators
worry that an editing error will have a major negative impact on the next boot. I have
never really had a major boot problem cause by an editing error, but I understand the
fear. Distributions that use System Vstyle start-up procedures alleviate this fear by making it unnecessary to directly edit the start-up file.

How Things Work

Running Sendmail at Start-Up

PART 1

54

Chapter 3 Running Sendmail

On a System VStyle Linux System

Most Linux distributions use a System Vstyle boot process that allows the system to be
initialized in different ways depending on the runlevel. All of the service initialization
scripts are located in a single directory, usually called /etc/rc.d/init.d on Linux systems that use this style of start-up. The initialization scripts are indirectly invoked by links
contained in directories assigned to each runlevel. Caldera and Red Hat are good examples of System Vstyle Linux systems.
NOTE A detailed description of the Linux boot process is beyond the scope of
this book. To learn more about the boot process, runlevels, and start-up scripts,
see Linux Network Servers 24seven by Craig Hunt (Sybex, 1999).

The code that Caldera and Red Hat use to start the Sendmail daemon is found in the
/etc/rc.d/init.d/sendmail script. It is more complex than the code used by Slackware,
because Red Hat and Caldera use script variables read from an external file to set the
command-line options. The file they read is /etc/sysconfig/sendmail, which normally
contains these two lines:
DAEMON=yes
QUEUE=1h

Changing the values in the /etc/sysconfig/sendmail file controls the daemon configuration. The QUEUE variable sets the time value of the -q option. In this case, it is one hour
(1h), which is a value that I like even more than the 15 minutes used in Slackware configuration. Dont 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.
If the variable DAEMON is equal to yes, the sendmail command is run with the -bd
option. If you are configuring a mail client and dont want to run Sendmail as a daemon,
you could directly edit the /etc/sysconfig/sendmail file to set DAEMON=no.
TIP While changing the DAEMON value is one way to do this, it is generally a better idea to remove the sendmail script from the start-up as described below than
it is to edit the contents of a script.

With System Vstyle start-up, you dont have to directly edit start-up files. One of the
advantages of the System Vstyle boot procedure is that major services have their own
start-up scripts and those scripts are indirectly invoked, which makes it possible to control whether or not a service is started at boot time by controlling whether or not the

script is invoked. The sendmail script is invoked indirectly from the runlevel directories
by the S80sendmail script (see Listing 3.2). An examination of that script shows that it
is just a symbolic link to the real sendmail script.
Listing 3.2

The Sendmail Link for Runlevel 3

[craig]$ cd /etc/rc.d/rc3.d
[craig]$ ls -l S80sendmail
lrwxrwxrwx 1 root root 18 Dec 26 1999 S80sendmail -> ../init.d/sendmail

To enable or disable the sendmail start-up script for a specific runlevel, simply add or
remove the symbolic link in that runlevels directory. In and of itself this would be simple
enough, but Linux systems make it even easier by providing tools to manage the runlevel
directories.
Enabling Sendmail with tksysv
tksysv is an X Windows tool provided for the purpose of controlling scripts started at
each runlevel. Figure 3.1 shows the main tksysv screen.
Figure 3.1

Enabling Sendmail with tksysv

55

How Things Work

Running Sendmail at Start-Up

PART 1

56

Chapter 3 Running Sendmail

All of the scripts that can be controlled by tksysv are listed on the left-hand side of the
screen. On the right are the services that are started and stopped for runlevels 2, 3, 4, and
5. To disable a service for a specific runlevel, simply highlight the service in the Start list
for that runlevel and click the Remove button. For example, to remove Sendmail from
runlevel 5, which is traditionally used as the runlevel for dedicated X Windows workstations, click sendmail in the Start list under runlevel 5 and then click Remove. After that,
Sendmail will no longer start when the system boots under runlevel 5.
To add Sendmail to a runlevel, highlight sendmail in the Available list and click Add.
Youll be asked to select a runlevel. An example might be runlevel 3, which is traditionally
the default runlevel for multiuser servers. Select the runlevel and click Done. Youre then
asked to select a script number. Use the default, which is 80 for the sendmail script. Click
Add and the script is added to the start-up. The next time the system reboots under runlevel 3, Sendmail will be started.
TIP Of course you dont want to reboot your system just to run the sendmail
start-up script. Use the Execute button to run the sendmail script immediately.

tksysv has a couple of nice features. First, it comes bundled with different versions of

Linux. It runs just as well on Caldera as it does on Red Hat, and it runs just as well under
Red Hat 6 as it does under Red Hat 7. Second, a clone of tksysv called ntsysv runs in
text mode and therefore doesnt require X Windows. A dedicated e-mail server might not
be running X Windows. In that case, you want a tool like ntsysv that runs in text mode.
Enabling Sendmail with ntsysv
ntsysv is even easier to use because it doesnt bother you with lots of questions about runlevels. It assumes the current runlevel as a default unless it is run with the --level argument. ntsysv presents you with a list of services that can be automatically started at boot

time. One of these is Sendmail. The start-up script for every item in the list that has an
asterisk next to it will be run during the next boot. Use the arrow keys to scroll down to
the sendmail entry in the list and then use the space bar to select or deselect sendmail.
When the settings are just what you want, tab over to the OK button and press Enter.
Thats all there is to it. Figure 3.2 shows the main ntsysv screen.

Running Sendmail at Start-Up

Enabling Sendmail with ntsysv

How Things Work

Figure 3.2

57

PART 1

Enabling Sendmail with linuxconf

Another tool that is popular on Red Hat systems is linuxconf. linuxconf is a generalpurpose system administration tool. One of the features it provides is a way to manage
the start-up scripts. Figure 3.3 shows the linuxconf screen.
Figure 3.3

Enabling Sendmail with linuxconf

58

Chapter 3 Running Sendmail

From the menu on the left-hand side of the linuxconf window, select Control  Control
Panel  Control Service Activity. A list of services appears on the right-hand side of the
window; it is the same list of services displayed by ntsysv. Again, as with ntsysv, you
dont have to worry about runlevels. Simply enable or disable the sendmail script by
selecting the appropriate button next to the sendmail entry.
Enabling Sendmail with chkconfig
One final tool that can be used to control the scripts that are run at boot time is
chkconfig. This is a command-line tool based on the chkconfig program from the Silicon Graphics IRIX version of Unix. The Linux version has some enhancements, such as
the ability to control which runlevels the scripts run under. The --list option of the
chkconfig command displays the current settings:
[craig]$ chkconfig --list sendmail
sendmail 0:off 1:off 2:on 3:on 4:on 5:on 6:off

To enable or disable a script for a specific runlevel, specify the runlevel with the --level
option, followed by the name of the script you wish to control and the action you wish
to take, either on to enable the script or off to disable it. For example, to disable sendmail
for runlevel 2, enter the command shown in Listing 3.3.
Listing 3.3

Controlling Sendmail with chkconfig

[root]# chkconfig --level 2 sendmail off

[root]# chkconfig --list sendmail
sendmail 0:off 1:off 2:off 3:on 4:on 5:on 6:off

Manually Running the Start-Up Script

The previous sections discussed several different ways to do essentially the same thing
enable or disable Sendmail at boot time. All of these approaches work. Choose the one
that is compatible with the version of Linux youre running and that suits your tastes. But
remember, most of the time you will install and enable Sendmail during the initial system
configuration and will never again need to fiddle with the boot files.
It is far more likely that you will need to stop or restart a Sendmail process that is already
running on your system. On most systems, this can be done by manually invoking the
boot scripts. The sendmail start-up script on a Red Hat system accepts five arguments:
stop
start

terminates the current Sendmail daemon process.

starts a new Sendmail daemon if one is not currently running.

terminates the current Sendmail daemon and starts a new one. An alternate name for the same command is reload.

restart

Running Sendmail at Start-Up

59

checks first to see if Sendmail is running. If one is running, it terminates the current Sendmail daemon and starts a new one. If Sendmail is not currently
running, it starts Sendmail.
status

displays the process ID of the current Sendmail daemon.

Listing 3.4 is an example of restarting the Sendmail daemon on a Red Hat system.

How Things Work

condrestart

PART 1

Listing 3.4

Restarting Sendmail with the Start-Up Script

[root]# /etc/rc.d/init.d/sendmail restart

Shutting down sendmail:
Starting sendmail:

[
[

OK
OK

]
]

NOTE If youre running Red Hat 6.0 or higher, an alternative to specifying the
full path name of the sendmail start-up script is to enter service sendmail restart.
On other versions of Red Hat, use the full pathname.

The primary limitation of the start-up scripts is that they all start the Sendmail daemon
with only the -bd and the -q options. This is correct more than 99 percent of the time. But
there are a few occasions when additional command-line arguments are needed. If the
occasion is a test, it is simple enough to run Sendmail from the command line. If you need
additional command-line arguments for every boot, the only option is to edit the start-up
scripts or create your own start-up script to include the arguments you need. See Appendix B, The sendmail Command, for a complete listing and description of the many
command-line arguments that are available for the sendmail command.

Controlling Sendmail with Signals

Not every Linux system has a script that can be used to start, stop, and restart Sendmail.
But on all systems, Sendmail can be controlled through signals. The Sendmail process
handles three different signals. Well, four, if you count the fact that SIGTERM aborts
Sendmail just as it does most other processesbut there are three signals that have a special meaning to Sendmail. These three signals are:
SIGHUP The SIGHUP signal causes the Sendmail daemon to restart and reread its
configuration file. The most common use of SIGHUP is to force Sendmail to reload
its configuration after the configuration file has been updated. SIGHUP can even be
used to terminate the current copy of Sendmail and run a new one after the Sendmail
program has been updated because SIGHUP causes a true restart, not just a reread
of the configuration file.

60

Chapter 3 Running Sendmail

SIGINT The SIGINT signal causes Sendmail to do a graceful shutdown. When

Sendmail receives SIGINT, it removes the lock files if it is currently processing the
queue, it switches back to the user ID that it started under to create a clean log entry,
and then it exits without errors. Like most processes, Sendmail can be terminated by
the kill signal, SIGTERM. However, SIGINT is a cleaner way to shut down Sendmail
because, unlike SIGTERM, SIGINT will not leave unresolved log entries or unused
lock files lying around.
SIGUSR1 Use the SIGUSR1 signal to cause Sendmail to write out its current status
via syslogd. Details of Sendmail logging are covered in Chapter 12, Testing Sendmail Security. For now, it is sufficient to understand that SIGUSR1 causes Sendmail
to display information about the open file descriptors, information about its host
connection cache, and output from the debug_dumpstate ruleset, if one is defined in
your configuration. None of this output is of particular interest to a system
administrator.
Listing 3.5 shows an example of passing a signal to Sendmail. In the example, the signal
is SIGHUP but the same technique can be used to send any of the signals to Sendmail.
Listing 3.5

Restarting Sendmail with SIGHUP

[root]# ps -ax | grep

542 ?
S
[root]# kill -HUP 542
[root]# ps -ax | grep
773 ?
S

sendmail
0:00 sendmail: accepting connections
sendmail
0:00 sendmail: accepting connections

Listing 3.5 illustrates the effect of the SIGHUP signal by showing that the process ID of
Sendmail changes after Sendmail is sent the signal. Clearly, a process must be terminated
and restarted to change process IDs. The kill command used in this example is explained
in the next section.
The kill Command
The kill command is used to send a signal to a running process. As the name implies, by
default it sends the kill signal (SIGTERM). To use it to send a different signal, specify the
signal on the command line. For example, specify -INT to send the SIGINT signal. The
PID is usually provided on the kill command line to ensure that the signal is sent to the
correct process.
As usual, there is more than one way to do something on a Linux system. You can learn
the PID of Sendmail using the ps command:
[root]# ps -ax | grep sendmail
542 ?

0:00 sendmail: accepting connections

Installing Sendmail

61

[root]# head -1 /var/run/sendmail.pid

542

Combining the last command with kill, you can send a signal directly to Sendmail. For
example, to restart Sendmail you could enter the following command:
kill HUP head -1 /var/run/sendmail.pid

The head -1 /var/run/sendmail.pid command that is enclosed in single quotes is processed by the shell first. On our sample Linux system, the first line of the sendmail.pid
file contains the PID 542. That is combined with the shells kill command and then is
processed as kill -HUP 542.
Signals, boot scripts, and everything else in this section has assumed that you have Sendmail already installed in your system. In the next section, we look at how to install Sendmail
if you dont already have it or if you want to upgrade to the latest release.

Installing Sendmail
Sendmail is delivered with every major Linux distribution, and it is normally installed as
part of the initial Linux installation. If it is not installed at that time, it can easily be added
later using one of the package-management systems available for Linux.
To simplify the task of adding and deleting software on a running server, most Linux vendors have developed package-management systems. Slackware installs software from
traditional tar files, but Debian and Red Hat have developed full-blown packagemanagement systems. Debian and systems such as Corel that are based on Debian use the
dpkg system. Most other Linux distributions use the Red Hat Package Manager (RPM).
RPM is the most widely used package manager and the one this book covers in greatest
detail. But before getting into RPM, lets take a quick look at the Debian package
manager.

Installing Sendmail with dpkg

Locating a binary package in the correct format is the first step in installing a new software package with any package manager. Debian packages are found at www.debian
.org/distrib/packages. These packages are intended for installation on the current
Debian distribution but will usually work on any Debian-based release, such as Corel
Linux.

How Things Work

You can also learn the PID by displaying the sendmail.pid file:

PART 1

62

Chapter 3 Running Sendmail

After locating the upgrade package, use the dpkg command to remove the old software.
Remove the currently installed Sendmail package with the following command:
[root]# dpkg -r sendmail

Next, use the dpkg command to install the new Debian package. For example, to install
Sendmail 8.9.3 you would enter the following:
[root]# dpkg -i sendmail-wide_8.9.3+3.2W-20.deb

NOTE As of this writing, 8.9.3 is the most recent version of Sendmail available
as a Debian package.

These dpkg examples are simple and clean. As well see in the discussion of RPM, package
installations are not always this simple.

Locating RPM Software

To install Sendmail with RPM, you need to locate an updated Sendmail RPM package.
If you failed to install Sendmail during the initial Linux installation and you just want to
correct that oversight, youll find the Sendmail RPM on the Linux CD-ROM. If you want
to upgrade an existing installation, you need to search for the latest RPM packages.
www.sendmail.org provides the source code distribution of Sendmail, but RPM packages
are not available from www.sendmail.org. To find RPM packages, go to your Linux vendor and to www.rpmfind.net.

Searching a Vendor Web Site

Because e-mail service is so important, all of the major Linux vendors make an effort to
update their version of Sendmail when a critical bug is fixed or a major new feature is
added. So a good place to start looking for updates is at your vendors Web site.
Figure 3.4 shows the Red Hat Web site. Just like the Debian site, it contains a search page
that lets you search for a binary package. In Figure 3.4, we ask Red Hat to list all of the
available Sendmail RPM packages.
The search produces several matches. At this writing, the latest version of Sendmail available as an RPM is 8.11.0, which is the version of Sendmail used in the rest of this chapter.
The packages returned by a search can be downloaded simply by clicking the name of the
package and selecting an appropriate mirror server.
Searching the vendor site will probably provide the RPM package you need. However, I
prefer a wider search that checks all of the sources of RPM packages to ensure that I dont
miss the newest updates.

Installing Sendmail

The Red Hat RPM search engine

How Things Work

Figure 3.4

63

PART 1

Using rpmfind.net to Locate Sendmail Software

Vendors are not the only ones who make RPM packages available on the Net. To search
a wide variety of RPM sources, go to www.rpmfind.net. Figure 3.5 shows the
www.rpmfind.net Web site, which lists several Sendmail RPM packages.
The Web page in Figure 3.5 is the RPM repository database indexed alphabetically by
name. The database is also indexed by distribution, by vendor, and by time of creation,
if those things are helpful for your particular search. In this case, we are looking for Sendmail, so we just jump to s in the alphabetic listing.
Our sample Linux system is running Sendmail 8.9.3. Figure 3.5 shows that there are several newer Sendmail RPM packages available, with the newest being Sendmail 8.11.0-1.
This particular Sendmail update contains three RPM packages:

sendmail-cf-8.11.0-1 contains the Sendmail configuration files, including the cf

directory used extensively in this text.

sendmail-doc-8.11.0-1 contains the Sendmail documentation.

sendmail-8.11.0-1 is the heart of the system, including the Sendmail program.

64

Chapter 3 Running Sendmail

Figure 3.5

The rpmfind Web site

Following the links from the page shown in Figure 3.5 will lead you to detailed information about each package and a link from which the package can be downloaded. All three
of the packages should be downloaded. These are the RPM packages that youll install
later in this chapter.
WARNING Installing an RPM from an unknown source could compromise
your systems security. Only use RPMs from sources you trust, such as the Linux
vendor.

Using Anonymous FTP to Download an RPM

RPM packages are also available via anonymous FTP. I prefer the Web because I can
search through many packages stored at a wide variety of locations, but if you know
where the package you want is located, FTP can be faster. The same packages shown in
Figure 3.5 can be retrieved via anonymous FTP using the procedure shown in Listing 3.6.

Installing Sendmail

Downloading the Sendmail RPM File

[craig]$ ftp rpmfind.net

Connected to rpmfind.net.
220 rpmfind.net FTP server ready.
User (rpmfind.net:(craig)): anonymous
331 Anonymous login ok, use your complete e-mail address as password.
Password:
230 Anonymous access granted, restrictions apply.
ftp> cd linux/contrib/libc6/i386
250 CWD command successful.
ftp> bin
200 Type set to I.
ftp> mget sendmail*8.11.0-1*
200 Type set to I.
mget sendmail-8.11.0-1.i386.rpm? y
200 PORT command successful.
150 Opening BINARY connection for sendmail-8.11.0-1.i386.rpm (259698 bytes)
226 Transfer complete.
ftp: 259698 bytes received in 2.63Seconds 98.74Kbytes/sec.
mget sendmail-cf-8.11.0-1.i386.rpm? y
200 PORT command successful.
150 Opening BINARY connection for sendmail-cf-8.11.0-1.i386.rpm
(221066 bytes)
226 Transfer complete.
ftp: 221066 bytes received in 1.76Seconds 125.61Kbytes/sec.
mget sendmail-doc-8.11.0-1.i386.rpm? y
200 PORT command successful.
150 Opening BINARY connection for sendmail-doc-8.11.0-1.i386.rpm
(482213 bytes)
226 Transfer complete.
ftp: 482213 bytes received in 4.56Seconds 105.75Kbytes/sec.
ftp> quit
221 Goodbye.

In this example, user input is shown in bold. The example has been edited to better fit on
a book page, but is essentially what you would see if you performed this download.
In Listing 3.6 we log on to rpmfind.net with FTP. In this particular case, the files we
want are in the linux/contrib/libc6/i386 directory. The FTP mget command is used
to retrieve all three files relating to Sendmail 8.11. Quick and easybut only if you know
where the files are located and exactly what RPM files youre looking for.

How Things Work

Listing 3.6

65

PART 1

66

Chapter 3 Running Sendmail

Installing Sendmail with RPM

Once the package is located, it can be installed using the rpm command. The rpm command is similar to the Debian dpkg command. It allows you to check the status of
installed packages, remove outdated packages, and install updates.
Use the rpm command with the -q option or the --query option to check what packages
are already installed in the system.
[craig]$ rpm --query sendmail
sendmail-8.9.3-10

This example queries rpm for the string sendmail. The response shows that Sendmail version 8.9.3 is installed on our sample system. At the time of this writing, the latest RPM
version of Sendmail available from www.rpmfind.net and www.redhat.com is 8.11, so we
decide to upgrade the sample system.
Before installing a new version of an RPM package, you can remove the old one by running rpm with the --erase option. (See the section Cleaning Up After RPM later in this
chapter for an example of this.) Removing the old Sendmail RPM package is probably a
good idea if you plan to compile and install the Sendmail program from the source code
distribution. But if you plan to install a new RPM version of Sendmail, removing the old
package is unnecessary. Use the -U option with the rpm command, as shown in Listing 3.7,
to update an existing RPM installation with a newer package.
Listing 3.7

Updating Sendmail with RPM

[root]# rpm -U sendmail-doc-8.11.0-1.i386.rpm

[root]# rpm -U sendmail-cf-8.11.0-1.i386.rpm
[root]# rpm -U sendmail-8.11.0-1.i386.rpm
error: failed dependencies:
openssl is needed by sendmail-8.11.0-1
libsfio is needed by sendmail-8.11.0-1
libcrypto.so.0 is needed by sendmail-8.11.0-1
libsasl.so.7 is needed by sendmail-8.11.0-1
libsfio.so is needed by sendmail-8.11.0-1
libssl.so.0 is needed by sendmail-8.11.0-1

The Sendmail 8.11 package is composed of three components: the documents, the configuration files, and Sendmail itself. In Listing 3.7 the documents and configuration file
components install without a hitch. The third component, however, fails to install. RPM
informs us that several pieces of software required by Sendmail 8.11 are not available on
this sample system. RPM calls required software dependencies. Sometimes other software
depends on the package youre installing or removing, and sometimes the software youre
installing depends on other software.

67

This is the worst-case scenario. We had hoped everything would be easy sailing. Now we
need to track down all of the packages needed by Sendmail 8.11, install those packages,
and then attempt to install sendmail-8.11.0-1.i386.rpm all over again. This bit of
unpleasantness is a blessing in disguise. If we installed Sendmail 8.11 from source code
and did not know that openssl and libsfio are required, some of the features of Sendmail would not work as advertised. It could take a long time tracking down the underlying problem. RPM makes sure that we know about the problem right from the start. We
could force RPM to install sendmail-8.11.0-1.i386.rpm without the dependencies by
adding the --nodeps argument to the rpm command line. But thats just asking for trouble.
The best thing to do is track down and install the required packages.
A search of www.rpmfind.net informs us that we need three different RPM packages to
fix the six dependencies: openssl-0.9.5a-1.i386.rpm, libsfio-1999-1.i386.rpm, and
cyrus-sasl-1.5.11-2.i386.rpm. The first two packages, openssl and libsfio, are
pretty obvious because RPM lists them as the first two dependencies needed by
sendmail-8.11.0-1.i386.rpm. An examination of the list of files provided by each package shows that they provide every dependency except libsasl.so.7. A search for
libsasl.so.7 tells us that it is found in cyrus-sasl-1.5.11-2.i386.rpm. We download
the three packages and install them as shown in Listing 3.8.
Listing 3.8

Fixing Dependency Problems for Sendmail 8.11

[root]# rpm -i openssl-0.9.5a-1.i386.rpm

error: file /usr/man/man1/passwd.1 from install of openssl-0.9.5a-1
conflicts with file from package passwd-0.58-1
[root]# rpm -i --replacefiles openssl-0.9.5a-1.i386.rpm
[root]# rpm -i libsfio-1999-1.i386.rpm
[root]# rpm -i cyrus-sasl-1.5.11-2.i386.rpm
[root]# rpm -U sendmail-8.11.0-1.i386.rpm
[root]# rpm -q sendmail
sendmail-8.11.0-1

Even this installation didnt go completely perfectly. The openssl-0.9.5a-1.i386.rpm

package creates a new passwd man page. The problem is, it doesnt own the old page.
That page was put on the system by the passwd-0.58-1.i386.rpm package. RPM wont
let a new package change a file that belongs to another package unless you tell it to. In
this case, we want the new passwd documentation so we use the --replacefiles
argument with the rpm command to replace the old passwd documentation with the
new documentation.

How Things Work

Installing Sendmail

PART 1

68

Chapter 3 Running Sendmail

All of the other installations run smoothly. Once the dependencies are resolved,
sendmail-8.11.0-1.i386.rpm installs without complaint. A quick query to RPM shows
that the new package is in place.
Next, restart Sendmail to make sure that the newly installed daemon is running, and run
a quick test to make sure the new daemon is alive and servicing the SMTP port. Listing
3.9 shows these two commands.
Listing 3.9

Restarting and Testing Sendmail

[root]# /etc/rc.d/init.d/sendmail restart

Shutting down sendmail:
Starting sendmail:
[root]# telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 wren.foobirds.org ESMTP Sendmail 8.11.0/8.11.0;
Sun, 13 Aug 2000 18:00:03 -0400
quit
221 2.0.0 wren.foobirds.org closing connection
Connection closed by foreign host.

[
[

OK
OK

]
]

As Listing 3.9 shows, Sendmail 8.11 is installed and running. Despite all of the problems
encountered in this installation, Sendmail is upgraded and running after fewer than a
dozen commands. Linux package managers have done much to simplify upgrades.
NOTE I have never had a problem with dependencies upgrading Sendmail
before version 8.11. This just turned out to be a lucky break. Normally, things go
so smoothly when preparing examples for Linux books that problems have to be
described without actual examples. This time we were lucky enough to have a
real problem. You might never see dependency problems when installing Sendmail yourself, but it is good to know how they are resolved.

X Tools for Installing Sendmail

In the previous section, we used the command-line version of rpm. It is easy to use, easy
to explain, and it runs on most Linux systemseven those that dont have X Windows
running. But if you are using X Windows, there are some graphical tools for running the
Red Hat Package Manager. Several systems use a tool named glint. Systems with the
KDE desktop environment use a tool named kpackage, and systems with the GNOME

desktop environment use a tool called gnorpm. Figure 3.6 shows gnorpm running on a Red
Hat 6 system.
Figure 3.6

Installing Sendmail with gnorpm

69

How Things Work

Installing Sendmail

PART 1

Understanding gnorpm is easy once you understand the rpm command. The icons near the
top of the window clearly parallel the -U (upgrade), -q (query), -V (verify), and -e (uninstall) command-line options. Simply highlight the package youre interested in and select
the action you want to take. Figure 3.6 shows the test system after Sendmail was
upgraded.
Even without GUI tools, it is simpler to upgrade an existing RPM package with a new one
than it is to delete the package and replace it with software you compile yourself, for a
couple of reasons:

First, using the rpm command is easier than compiling software.

Second, the features of rpm, such as pointing out dependencies and verifying the
integrity of the software, are unavailable if you dont use rpm.

But the latest software is not always available as a binary package. The Debian example
in this chapter illustrates that. Sometimes you must compile your own version of Sendmail from the source code to get the latest release. Compiling Sendmail is the next topic
of this chapter.

Cleaning Up After RPM

We need to digress for a moment from the basics of upgrading with RPM. If you have
RPM and your current Sendmail was installed via RPM, you should upgrade with RPM.

70

Chapter 3 Running Sendmail

Take advantage of the tools your Linux system offers. However, if you are forced to
upgrade with source code a system that was originally installed via RPM, you should
clean out the RPM installation before upgrading.
The next section describes downloading and compiling the latest Sendmail source code.
Before installing a new version of Sendmail that you have downloaded and compiled,
remove the old RPM version with the --erase option, as in this example:
[root]# rpm --erase --nodeps sendmail-cf-8.9.3-1
[root]# rpm --erase --nodeps sendmail-8.9.3-1

The --nodeps option is added to this command line to force rpm to erase the Sendmail
software, even though other packages are dependent on it. Attempting to erase Sendmail
without using the --nodeps option displays an error message stating that other software
depends on Sendmail, and it is not removed, as shown below.
[root]# rpm --erase sendmail
removing these packages would break dependencies:
sendmail is needed by sendmail-cf-8.9.3-1

Failing to remove the Sendmail RPM package before installing a non-RPM version, such
as a version that you compile yourself, means that the system will still think the old RPM
version is installed. An rpm --query will continue to report the old Sendmail version
number. If the -V option is used to verify the Sendmail RPM package, it may report false
and misleading errors. Here is an example of what can happen when the components of
Sendmail are changed or upgraded without using RPM and then are verified by the rpm
command:
[craig]$ rpm -V sendmail
S.5....Tc

/etc/aliases

missing

/etc/rc.d/rc2.d/S80sendmail

S.5....T

/var/log/sendmail.st

The -V option prints out a line for each file in the package that fails verification. Values
are printed at the beginning of the line to indicate which tests were failed. Each letter or
number indicates a failure and each dot indicates a test that was passed. The possible values are as follows:
S

indicates that the file has the wrong file size.

indicates that the file is assigned the wrong file permissions or file type.

indicates that the file has an incorrect MD5 checksum.

indicates that the file is located on the wrong device.

indicates that the file is improperly a symbolic link.

indicates that the file has the wrong user ID (UID) assigned.

indicates that the file has the wrong group ID (GID) assigned.

indicates that the file has the wrong file creation time.

indicates that the file is a configuration file that is expected to change.

71

In the previous example, two files have the wrong checksum and the wrong creation date,
and they are the wrong size. These are all things you would expect because these are not
the original files. They are files that were installed over the original files. The file that is
missing is the S80sendmail script we deleted in Listing 3.3. All of the other files associated
with the Sendmail RPM check out fine. But even these three errors might set off alarm
bells with the systems computer security officer. For this reason, clean out the RPM
installation before installing Sendmail from source code as described in the following section.

Downloading and Compiling Sendmail

Even if your Linux system comes with its own version of Sendmail, obtaining the latest
Sendmail source code distribution provides useful documentation, tools, and sample configuration files. Additionally, there are times when you need a security fix or update and
the latest version of Sendmail has not yet been posted as an RPM or other binary distribution.
The latest Sendmail distribution is available via anonymous FTP from ftp.sendmail.org,
where it is stored in the pub/sendmail directory. When you change to that directory, an
informational message is displayed that tells you about the latest version of Sendmail.
New releases are constantly being created. The following examples are based on Sendmail
V8.11.0.
NOTE Remember that things will change for future releases, so always review
the readme files and installation documents that come with new software before
beginning an installation.

To compile the Sendmail program, download the compressed tar file as a binary file and
then uncompress and extract it with the tar command, as shown in Listing 3.10.
Listing 3.10

Downloading the Sendmail Source Code

[craig]$ ftp ftp.sendmail.org

Connected to ftp.sendmail.org.

How Things Work

Downloading and Compiling Sendmail

PART 1

72

Chapter 3 Running Sendmail

220 pub2.pa.vix.com FTP server ready.

Name (ftp.sendmail.org:craig): anonymous
331 Guest login ok, send your e-mail address as password.
Password:
230 Guest login ok, access restrictions apply.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> cd pub/sendmail
ftp> get sendmail.8.11.0.tar.gz
local: sendmail.8.11.0.tar.gz remote: sendmail.8.11.0.tar.gz
200 PORT command successful.
150 Opening BINARY mode data connection for sendmail.8.11.0.tar.gz
(1307858 bytes).
226 Transfer complete.
1307858 bytes received in 26 secs (50 Kbytes/sec)
ftp> quit
221-You have transferred 1307858 bytes in 1 files.
221-Thank you for using the FTP service on pub2.pa.vix.com.
221 Goodbye.
[craig]$ cd /usr/local/src
[craig]$ tar -zxvf /home/craig/sendmail.8.11.0.tar.gz

Next, change to the sendmail-8.11.0 directory created by the tar file, and use the Build
script to compile the new Sendmail program, as shown in Listing 3.11.
Listing 3.11

Compiling Sendmail with the Build Command

[craig]$ cd sendmail-8.11.0
[craig]$ ./Build
Making all in:
/usr/local/src/sendmail-8.11.0/libsmutil
Configuration: pfx=, os=Linux, rel=2.2.10, rbase=2, rroot=2.2,
arch=i586, sfx=, variant=optimized
Using M4=/usr/bin/m4
Creating ../obj.Linux.2.2.10.i586/libsmutil using ../devtools/OS/Linux
Making dependencies in ../obj.Linux.2.2.10.i586/libsmutil
make[1]: Entering directory
`/usr/local/src/sendmail-8.11.0/obj.Linux.2.2.10.i586/libsmutil'
cc -M -I. -I../../sendmail -I../../include -DNEWDB
-DNOT_SENDMAIL debug.c
errstring.c lockfile.c safefile.c snprintf.c strl.c
>> Makefile
make[1]: Leaving directory
`/usr/local/src/sendmail-8.11.0/obj.Linux.2.2.10.i586/libsmutil'

73

Making in ../obj.Linux.2.2.10.i586/libsmutil
make[1]: Entering directory
`/usr/local/src/sendmail-8.11.0/obj.Linux.2.2.10.i586/libsmutil'
cc -O -I. -I../../sendmail -I../../include -DNEWDB
-DNOT_SENDMAIL -c debug.c -o debug.o
cc -O -I. -I../../sendmail -I../../include -DNEWDB
-DNOT_SENDMAIL -c errstring.c -o errstring.o
... Many, many, many lines deleted...
cc -O -I. -I../../sendmail -I../../include -DNEWDB
-DNOT_SENDMAIL -c vacation.c -o vacation.o
cc -o vacation
vacation.o ../libsmdb/libsmdb.a
../libsmutil/libsmutil.a -ldb -lresolv -lcrypt -lnsl -ldl
groff -Tascii -man vacation.1 > vacation.0 ||
cp vacation.0.dist vacation.0
make[1]: Leaving directory
`/usr/local/src/sendmail-8.11.0/obj.Linux.2.2.10.i586/vacation'

Build detects the architecture of the system and builds the correct Makefile for your system. It then compiles Sendmail using the newly created Makefile.

According to the documentation, running Build is all you need to do on most systems to
compile Sendmail. It certainly works on Caldera Linux systems, as this example illustrates. However, the installation notes warn of several possible problems that can occur
with some Linux systems, which are described in the next section, Known Problems.
Once Sendmail compiles, it is installed by using the Build command with the install
option (see Listing 3.12).
Listing 3.12

Installing the New Sendmail Binaries

# ./Build install
Making all in:
/usr/local/src/sendmail-8.11.0/libsmutil
Configuration: pfx=, os=Linux, rel=2.2.10, rbase=2, rroot=2.2,
arch=i586, sfx=, variant=optimized
Making in ../obj.Linux.2.2.10.i586/libsmutil
make[1]: Entering directory
`/usr/local/src/sendmail-8.11.0/obj.Linux.2.2.10.i586/libsmutil'
... Many, many, many lines deleted...
Making in ../obj.Linux.2.2.10.i586/vacation
make[1]: Entering directory
`/usr/local/src/sendmail-8.11.0/obj.Linux.2.2.10.i586/vacation'
install -c -o bin -g bin -m 555 vacation /usr/bin

How Things Work

Downloading and Compiling Sendmail

PART 1

74

Chapter 3 Running Sendmail

install -c -o bin -g bin -m 444 vacation.0 /usr/man/man1/vacation.1

make[1]: Leaving directory
`/usr/local/src/sendmail-8.11.0/obj.Linux.2.2.10.i586/vacation'

The Build command installs the man pages in the /usr/man directory and the executables
in /usr/sbin and /usr/bin. It installs the help file (sendmail.hf) and the status file
(sendmail.st) in /etc/mail.

Known Problems
The Sendmail documentation lists some problems that are known to affect compilation
on Linux systems. The problems fall into several categories ranging from compiler problems to kernel problems.
Two problems relate to GNU tools that are commonly used on Linux systems. One is an
incompatibility detected between GDBM and Sendmail 8.8. Later versions of Sendmail
improved the heuristic to detect GDBM so that the Sendmail code can adapt to GDBM.
The Sendmail release notes suggest using Berkeley DB instead of GDBM.
The other GNU problem is with the gcc compiler. Old versions of gcc, versions 2.4 and
2.5, cannot be used to compile Sendmail with the compiler optimization (-O) option set.
This was fixed when version 2.6 was released. The Caldera system used to generate the
example in Listing 3.10 uses the Experimental GNU Compiler Suite version 2.91, which
is a follow-on to gcc.
Several problems are described that existed with very old kernels (preversion 1.0), very
old versions of libc (preversion 4.7), and a very old version of the BIND domain name
software (version 4.9.3). No one should currently be running any of this old software.
The Sendmail documentation also reports problems that relate to having previously compiled BIND on your system. The symptoms of this problem are unresolved references during the link phase of the Sendmail compile. If you have compiled BIND from source code
on your system and BIND wrote header files in /usr/local/lib and /usr/local/
include, these files may cause problems when Sendmail is compiled. The documentation
suggests adding -lresolv to LIBS in the Sendmail Makefile to avoid this problem.
Finally, the documentation mentions problems with Linux kernel 2.2.0. This is the most
worrisome of the problems reported because the documentation does not provide a
workaround for this problem. I have never personally seen this problem, but if I did, I
would upgrade the Linux kernel to the highest patch.
Frankly, none of the problems described in the Sendmail installation notes has ever
struck any Linux system that I have worked with. A far more common occurrence is

75

for something to change in the new distribution that makes your old configuration obsolete. We look at that challenge next.

Configuration Compatibility
New versions of Sendmail can change things that make the old configuration incompatible with the new Sendmail program. Watch for these changes and adjust the configuration when they arise.
The /etc/mail directory is a new default location used by Sendmail version 8.11. The
Build install command placed the help file and the status file in this new directory, but
the help file and the status file locations are also defined in the Sendmail configuration
file. If the files are not in the locations your mail server configuration expects, you can do
one of two things:

Simply move the files to the locations that you desire.

Change the Sendmail configuration to point to /etc/mail for these files. This is the
default location expected by Sendmail 8.11, so using these locations actually means
removing the define macros that point to the non-standard locations for these
files. Using the default locations means that you will have a simpler configuration
file. See Chapter 5, Understanding a Vendors Configuration, for more information about the define macros used to specify file locations.

Regardless of what you do, the physical location of the files and the location of the files
defined in the configuration must agree.
Sendmail 8.11 has also changed the location of the Sendmail configuration file
(sendmail.cf). Traditionally, the file was located in the /etc directory, and that is where
it is found on most Linux systems. Sendmail 8.11 uses the new /etc/mail directory for
the sendmail.cf file. Attempting to run the newly compiled Sendmail binary on the sample system will fail, because Caldera keeps the sendmail.cf file in the /etc directory and
Sendmail 8.11 is looking for it in the /etc/mail directory. A simple test shows this:
[root]# sendmail -v -t
/etc/mail/sendmail.cf: line 0: cannot open: No such file or directory

This needs to be fixed, and again you can either move the file or change the configuration.
To change the configuration, provide the sendmail command with the correct path to the
configuration file by using the -C command-line optionfor example, sendmail -C/
etc/sendmail.cf . The Sendmail start-up script must also be edited to insert this
command-line option so that the correct configuration file is used every time the system
reboots. Frankly, this is more trouble than it is worth. Just move the sendmail.cf file to
/etc/mail. It is simpler and better because other newly installed mail tools might be looking for the sendmail.cf file at the new default location.

How Things Work

Downloading and Compiling Sendmail

PART 1

76

Chapter 3 Running Sendmail

One other thing that should be checked before declaring the installation complete is the
sendmail.cf file. New versions of Sendmail may add new configuration syntax that
makes the older configuration files incompatible with the new release. The Sendmail program checks the version (V) command inside the sendmail.cf file to indicate the level of
the configuration syntax. The easiest way to check compatibility is to use the sendmail
command to send a piece of test mail:
[root]# sendmail -v -t -C/etc/sendmail.cf
Warning: .cf file is out of date: sendmail 8.11.0 supports
version 9, .cf file is version 8
^D
No recipient addresses found in header

Running sendmail with the -v option tells the program to provide verbose messages,
which is just what you want when youre testing. The -t option tells Sendmail that the
mail will be typed in at the console. In this case, I immediately terminate the session with
a Ctrl+D (which is what the ^D illustrates), because I dont want to send mail, I just want
to see the warning message. The new Sendmail program complains about the version level
of the configuration file. In this particular case, mail would not be delivered successfully
because too much has changed between Sendmail 8.9 and 8.11. This is not always the
case. Sometimes you can force mail through an old configuration. But you shouldnt.
This example shows that this configuration is not compatible with the new release. To
solve this incompatibility, you need to rebuild your configuration. Understanding basic
Sendmail configuration and building your own custom configuration is the topic of Part 2 of
this book.

In Sum
Sendmail runs in two different modes to handle outbound and inbound mail. Sendmail is
started in real time to handle individual pieces of outbound mail, but runs as a daemon
to collect inbound mail. There are several tools that help you control which systems run
the Sendmail daemon as part of their start-up.
Before the Sendmail program can be run, it must be properly installed. Sendmail can be
installed using a Linux package manager or compiled from source. Despite the complexity of Sendmail, it is installed in the same manner as all other Linux packages, and the
same tools are used to control the Sendmail start-up process as are used with any other
Linux start-up process. Installing and running Sendmail are two tasks that dont have any

special complexity. If you know how to install and run Linux processes, you know how
to install and run Sendmail on a Linux system.
Once installed, Sendmail must be configured. Configuring Sendmail is the topic of Part 2,
which starts with Chapter 4, Creating a Basic Sendmail Configuration.

77

How Things Work

In Sum

PART 1