BASIC INSTALLATION

There are two basic steps to installing sendmail. First, you have to compile and install the binary. If sendmail has already been ported to your operating system that should be simple. Second, you must build a run-time configuration file. This is a file that sendmail reads when it starts up that describes the mailers it knows about, how to parse addresses, how to rewrite the message header, and the settings of various options. Although the configuration file can be quite complex, a configuration can usually be built using an M4-based configuration language. Assuming you have the standard sendmail distribution, see cf/README for further information.

The remainder of this section will describe the installation of sendmail assuming you can use one of the existing configurations and that the standard installation parameters are acceptable. All pathnames and examples are given from the root of the sendmail subtree, normally /usr/src/usr.sbin/sendmail on 4.4BSD-based systems.

Continue with the next section if you need/want to compile sendmail yourself. If you have a running binary already on your system, you should probably skip to section 1.2.

Compiling Sendmail

All sendmail source is in the sendmail subdirectory. To compile sendmail, cd into the sendmail directory and type

./Build
This will leave the binary in an appropriately named subdirectory, e.g., obj.BSD-OS.2.1.i386. It works for multiple object versions compiled out of the same directory.

Tweaking the Build Invocation

You can give parameters on the Build command. In most cases these are only used when the obj.* directory is first created. To restart from scratch, use -c. These commands include:

-L libdirs
A list of directories to search for libraries.
-I incdirs
A list of directories to search for include files.
-E envar=value
Set an environment variable to an indicated value before compiling.
-c
Create a new obj.* tree before running.
-f siteconfig
Read the indicated site configuration file. If this parameter is not specified, Build includes all of the files $BUILDTOOLS/Site/site.$oscf.m4 and $BUILDTOOLS/Site/site.config.m4, where $BUILDTOOLS is normally ../devtools and $oscf is the same name as used on the obj.* directory. See below for a description of the site configuration file.
-S
Skip auto-configuration. Build will avoid auto-detecting libraries if this is set. All libraries and map definitions must be specified in the site configuration file.

Most other parameters are passed to the make program; for details see $BUILDTOOLS/README.

Creating a Site Configuration File

(This section is not yet complete. For now, see the file devtools/README for details.) See sendmail/README for various compilation flags that can be set.

Notes About Some Configuration Settings

Not all configuration setting are critical to getting sendmail to run correctly. Note that "correctly" does not directly imply highest performance immediately.

Sendmail uses the functions strlcat(3) and strlcpy(3) which, at the time of writing, are not widely available. Further, for those systems where these functions are available they are new enough that performance tuning has not yet occurred. Sendmail includes in its sm library (aka libsm) these functions with an sm_ prefix. By default sendmail uses the libsm versions of these functions as performance tuning has occurred. A performance testing program libsm/b-strl.c can be used to evaluate which versions of the functions are faster: libsm or the system's libc. If you decide to use the libc versions then add

-DSM_CONF_STRL=0
as compile time option, see $BUILDTOOLS/README for details.

Tweaking the Makefile

Sendmail supports two different formats for the local (on disk) version of databases, notably the aliases database. At least one of these should be defined if at all possible.

NDBM
The ``new DBM'' format, available on nearly all systems around today. This was the preferred format prior to 4.4BSD. It allows such complex things as multiple databases and closing a currently open database.
NEWDB
The Berkeley DB package. If you have this, use it. It allows long records, multiple open databases, real in-memory caching, and so forth. You can define this in conjunction with NDBM; if you do, old alias databases are read, but when a new database is created it will be in NEWDB format. As a nasty hack, if you have NEWDB, NDBM, and NIS defined, and if the alias file name includes the substring /yp/, sendmail will create both new and old versions of the alias file during a newalias command. This is required because the Sun NIS/YP system reads the DBM version of the alias file. It's ugly as sin, but it works.

If neither of these are defined, sendmail reads the alias file into memory on every invocation. This can be slow and should be avoided. There are also several methods for remote database access:

LDAP
Lightweight Directory Access Protocol.
NIS
Sun's Network Information Services (formerly YP).
NISPLUS
Sun's NIS+ services.
NETINFO
NeXT's NetInfo service.
HESIOD
Hesiod service (from Athena).

Other compilation flags are set in conf.h and should be predefined for you unless you are porting to a new environment. For more options see sendmail/README.

Compilation and installation

After making the local system configuration described above, You should be able to compile and install the system. The script Build is the best approach on most systems:

./Build
This will use uname(1) to create a custom Makefile for your environment.

If you are installing in the standard places, you should be able to install using

./Build install
This should install the binary in /usr/sbin and create links from /usr/bin/newaliases and /usr/bin/mailq to /usr/sbin/sendmail. On most systems it will also format and install man pages. Notice: as of version 8.12 sendmail will no longer be installed set-user-ID root by default. If you really want to use the old method, you can specify it as target:
./Build install-set-user-id

Configuration Files

Sendmail cannot operate without a configuration file. The configuration defines the mail delivery mechanisms understood at this site, how to access them, how to forward email to remote mail systems, and a number of tuning parameters. This configuration file is detailed in the later portion of this document.

The sendmail configuration can be daunting at first. The world is complex, and the mail configuration reflects that. The distribution includes an m4-based configuration package that hides a lot of the complexity. See cf/README for details.

Our configuration files are processed by m4 to facilitate local customization; the directory cf of the sendmail distribution directory contains the source files. This directory contains several subdirectories:

cf
Both site-dependent and site-independent descriptions of hosts. These can be literal host names (e.g., ucbvax.mc) when the hosts are gateways or more general descriptions (such as generic-solaris2.mc as a general description of an SMTP-connected host running Solaris 2.x. Files ending .mc (``M4 Configuration'') are the input descriptions; the output is in the corresponding .cf file. The general structure of these files is described below.
domain
Site-dependent subdomain descriptions. These are tied to the way your organization wants to do addressing. For example, domain/CS.Berkeley.EDU.m4 is our description for hosts in the CS.Berkeley.EDU subdomain. These are referenced using the DOMAIN m4 macro in the .mc file.
feature
Definitions of specific features that some particular host in your site might want. These are referenced using the FEATURE m4 macro. An example feature is use_cw_file (which tells sendmail to read an /etc/mail/local-host-names file on startup to find the set of local names).
hack
Local hacks, referenced using the HACK m4 macro. Try to avoid these. The point of having them here is to make it clear that they smell.
m4
Site-independent m4(1) include files that have information common to all configuration files. This can be thought of as a #include directory.
mailer
Definitions of mailers, referenced using the MAILER m4 macro. The mailer types that are known in this distribution are fax, local, smtp, uucp, and usenet. For example, to include support for the UUCP-based mailers, use MAILER(uucp).
ostype
Definitions describing various operating system environments (such as the location of support files). These are referenced using the OSTYPE m4 macro.
sh
Shell files used by the m4 build process. You shouldn't have to mess with these.
siteconfig
Local UUCP connectivity information. This directory has been supplanted by the mailertable feature; any new configurations should use that feature to do UUCP (and other) routing. The use of this directory is deprecated.

If you are in a new domain (e.g., a company), you will probably want to create a cf/domain file for your domain. This consists primarily of relay definitions and features you want enabled site-wide: for example, Berkeley's domain definition defines relays for BitNET and UUCP. These are specific to Berkeley, and should be fully-qualified internet-style domain names. Please check to make certain they are reasonable for your domain.

Subdomains at Berkeley are also represented in the cf/domain directory. For example, the domain CS.Berkeley.EDU is the Computer Science subdomain, EECS.Berkeley.EDU is the Electrical Engineering and Computer Sciences subdomain, and S2K.Berkeley.EDU is the Sequoia 2000 subdomain. You will probably have to add an entry to this directory to be appropriate for your domain.

You will have to use or create .mc files in the cf/cf subdirectory for your hosts. This is detailed in the cf/README file.

Details of Installation Files

This subsection describes the files that comprise the sendmail installation.

/usr/sbin/sendmail

The binary for sendmail is located in /usr/sbin[3]. It should be set-group-ID smmsp as described in sendmail/SECURITY. For security reasons, /, /usr, and /usr/sbin should be owned by root, mode 755[4].

/etc/mail/sendmail.cf

This is the main configuration file for sendmail [5]. This is one of the two non-library file names compiled into sendmail [6], the other is /etc/mail/submit.cf.

The configuration file is normally created using the distribution files described above. If you have a particularly unusual system configuration you may need to create a special version. The format of this file is detailed in later sections of this document.

/etc/mail/submit.cf

This is the configuration file for sendmail when it is used for initial mail submission, in which case it is also called ``Mail Submission Program'' (MSP) in contrast to ``Mail Transfer Agent'' (MTA). Starting with version 8.12, sendmail uses one of two different configuration files based on its operation mode (or the new -A option). For initial mail submission, i.e., if one of the options -bm (default), -bs, or -t is specified, submit.cf is used (if available), for other operations sendmail.cf is used. Details can be found in sendmail/SECURITY. submit.cf is shipped with sendmail (in cf/cf/) and is installed by default. If changes to the configuration need to be made, start with cf/cf/submit.mc and follow the instruction in cf/README.

/usr/bin/newaliases

The newaliases command should just be a link to sendmail:

rm -f /usr/bin/newaliases
ln -s /usr/sbin/sendmail /usr/bin/newaliases
This can be installed in whatever search path you prefer for your system.

/usr/bin/hoststat

The hoststat command should just be a link to sendmail, in a fashion similar to newaliases. This command lists the status of the last mail transaction with all remote hosts. The -v flag will prevent the status display from being truncated. It functions only when the HostStatusDirectory option is set.

/usr/bin/purgestat

This command is also a link to sendmail. It flushes expired (Timeout.hoststatus) information that is stored in the HostStatusDirectory tree.

/var/spool/mqueue

The directory /var/spool/mqueue should be created to hold the mail queue. This directory should be mode 700 and owned by root.

The actual path of this directory is defined by the QueueDirectory option of the sendmail.cf file. To use multiple queues, supply a value ending with an asterisk. For example, /var/spool/mqueue/qd* will use all of the directories or symbolic links to directories beginning with `qd' in /var/spool/mqueue as queue directories. Do not change the queue directory structure while sendmail is running.

If these directories have subdirectories or symbolic links to directories named `qf', `df', and `xf', then these will be used for the different queue file types. That is, the data files are stored in the `df' subdirectory, the transcript files are stored in the `xf' subdirectory, and all others are stored in the `qf' subdirectory.

If shared memory support is compiled in, sendmail stores the available diskspace in a shared memory segment to make the values readily available to all children without incurring system overhead. In this case, only the daemon updates the data; i.e., the sendmail daemon creates the shared memory segment and deletes it if it is terminated. To use this, sendmail must have been compiled with support for shared memory (-DSM_CONF_SHM) and the option SharedMemoryKey must be set. Notice: do not use the same key for sendmail invocations with different queue directories or different queue group declarations.

/var/spool/clientmqueue

The directory /var/spool/clientmqueue should be created to hold the mail queue. This directory should be mode 770 and owned by user smmsp, group smmsp.

The actual path of this directory is defined by the QueueDirectory option of the submit.cf file.

/var/spool/mqueue/.hoststat

This is a typical value for the HostStatusDirectory option, containing one file per host that this sendmail has chatted with recently. It is normally a subdirectory of mqueue.

/etc/mail/aliases*

The system aliases are held in /etc/mail/aliases. A sample is given in sendmail/aliases which includes some aliases which must be defined:

cp sendmail/aliases /etc/mail/aliases
edit /etc/mail/aliases
You should extend this file with any aliases that are apropos to your system.

Normally sendmail looks at a database version of the files, stored either in /etc/mail/aliases.dir and /etc/mail/aliases.pag or /etc/mail/aliases.db depending on which database package you are using. The actual path of this file is defined in the AliasFile option of the sendmail.cf file.

/etc/rc or /etc/init.d/sendmail

It will be necessary to start up the sendmail daemon when your system reboots. This daemon performs two functions: it listens on the SMTP socket for connections (to receive mail from a remote system) and it processes the queue periodically to insure that mail gets delivered when hosts come up.

If necessary, add the following lines to /etc/rc (or /etc/rc.local as appropriate) in the area where it is starting up the daemons on a BSD-base system, or on a System-V-based system in one of the startup files, typically /etc/init.d/sendmail:

if [ -f /usr/sbin/sendmail -a -f /etc/mail/sendmail.cf ]; then
(cd /var/spool/mqueue; rm -f xf*)
/usr/sbin/sendmail -bd -q30m &
echo -n ' sendmail' >/dev/console
fi
The cd and rm commands insure that all transcript files have been removed; extraneous transcript files may be left around if the system goes down in the middle of processing a message. The line that actually invokes sendmail has two flags: -bd causes it to listen on the SMTP port, and -q30m causes it to run the queue every half hour.

Some people use a more complex startup script, removing zero length qf files and df files for which there is no qf file. For example, see Figure 1 for an example of a complex script which does this clean up.



#!/bin/sh
# remove zero length qf files
for qffile in qf*
do
if [ -r $qffile ]
then
if [ ! -s $qffile ]
then
echo -n " <zero: $qffile>" > /dev/console
rm -f $qffile
fi
fi
done
# rename tf files to be qf if the qf does not exist
for tffile in tf*
do
qffile=`echo $tffile | sed 's/t/q/'`
if [ -r $tffile -a ! -f $qffile ]
then
echo -n " <recovering: $tffile>" > /dev/console
mv $tffile $qffile
else
if [ -f $tffile ]
then
echo -n " <extra: $tffile>" > /dev/console
rm -f $tffile
fi
fi
done
# remove df files with no corresponding qf files
for dffile in df*
do
qffile=`echo $dffile | sed 's/d/q/'`
if [ -r $dffile -a ! -f $qffile ]
then
echo -n " <incomplete: $dffile>" > /dev/console
mv $dffile `echo $dffile | sed 's/d/D/'`
fi
done
# announce files that have been saved during disaster recovery
for xffile in [A-Z]f*
do
if [ -f $xffile ]
then
echo -n " <panic: $xffile>" > /dev/console
fi
done


Figure 1 -- A complex startup script



/etc/mail/helpfile

This is the help file used by the SMTP HELP command. It should be copied from sendmail/helpfile:

cp sendmail/helpfile /etc/mail/helpfile
The actual path of this file is defined in the HelpFile option of the sendmail.cf file.

/etc/mail/statistics

If you wish to collect statistics about your mail traffic, you should create the file /etc/mail/statistics:

cp /dev/null /etc/mail/statistics
chmod 644 /etc/mail/statistics
This file does not grow. It is printed with the program mailstats/mailstats.c. The actual path of this file is defined in the S option of the sendmail.cf file.

/usr/bin/mailq

If sendmail is invoked as mailq, it will simulate the -bp flag (i.e., sendmail will print the contents of the mail queue; see below). This should be a link to /usr/sbin/sendmail.


[Contents] [Previous] [Next]
This document was translated by troff2html v0.21 on October 10, 2001.


Claus Aßmann Please send comments to: <ca at sendmail.org>