Email客户端

开发平台：

Unix_Linux

op.me：源码内容

."
." By using this file, you agree to the terms and conditions set
." forth in the LICENSE file which can be found at the top level of
." the sendmail distribution.
."
."
." $Id: op.me,v 8.293 1999/12/09 21:48:40 gshapiro Exp $
."
." eqn op.me | pic | troff -me
.eh 'SMM:08-%''Sendmail Installation and Operation Guide'
.oh 'Sendmail Installation and Operation Guide''SMM:08-%'
." SD is lib if sendmail is installed in /usr/lib, sbin if in /usr/sbin
.ds SD sbin
." SB is bin if newaliases/mailq are installed in /usr/bin, ucb if in /usr/ucb
.ds SB bin
.nr si 3n
.de $0
.(x
.in \$3u*3n
.ti -3n
\$2. \$1
.)x
..
.de $C
.(x
.in 0
\$1 \$2. \$3
.)x
..
.sc
.+c
.(l C
.sz 16
.b SENDMAILus-6TMs0d
.sz 12
.sp
.b "INSTALLATION AND OPERATION GUIDE"
.sz 10
.sp
.r
Eric Allman
Sendmail, Inc.
eric@Sendmail.COM
.sp
.de Ve
Version \$2
..
.Ve $Revision: 8.293 $
.rm Ve
.sp
For Sendmail Version 8.10
.)l
.(f
Sendmail is a trademark of Sendmail, Inc.
.)f
.sp 2
.pp
.i Sendmail us-2TMs0d
implements a general purpose internetwork mail routing facility
under the UNIX(rg
operating system.
It is not tied to any one transport protocol *-
its function may be likened to a crossbar switch,
relaying messages from one domain into another.
In the process,
it can do a limited amount of message header editing
to put the message into a format that is appropriate
for the receiving domain.
All of this is done under the control of a configuration file.
.pp
Due to the requirements of flexibility
for
.i sendmail ,
the configuration file can seem somewhat unapproachable.
However, there are only a few basic configurations
for most sites,
for which standard configuration files have been supplied.
Most other configurations
can be built by adjusting an existing configuration file
incrementally.
.pp
.i Sendmail
is based on
RFC821 (Simple Mail Transport Protocol),
RFC822 (Internet Mail Headers Format),
RFC1123 (Internet Host Requirements),
RFC2045 (MIME),
RFC1869 (SMTP Service Extensions),
RFC1652 (SMTP 8BITMIME Extension),
RFC1870 (SMTP SIZE Extension),
RFC1891 (SMTP Delivery Status Notifications),
RFC1892 (Multipart/Report),
RFC1893 (Mail System Status Codes),
RFC1894 (Delivery Status Notifications),
RFC1985 (SMTP Service Extension for Remote Message Queue Starting),
RFC2033 (Local Message Transmission Protocol),
RFC2476 (Message Submission),
and
RFC2554 (SMTP Service Extension for Authentication).
However, since
.i sendmail
is designed to work in a wider world,
in many cases it can be configured to exceed these protocols.
These cases are described herein.
.pp
Although
.i sendmail
is intended to run
without the need for monitoring,
it has a number of features
that may be used to monitor or adjust the operation
under unusual circumstances.
These features are described.
.pp
Section one describes how to do a basic
.i sendmail
installation.
Section two
explains the day-to-day information you should know
to maintain your mail system.
If you have a relatively normal site,
these two sections should contain sufficient information
for you to install
.i sendmail
and keep it happy.
Section three
describes some parameters that may be safely tweaked.
Section four
has information regarding the command line arguments.
Section five
contains the nitty-gritty information about the configuration
file.
This section is for masochists
and people who must write their own configuration file.
Section six
describes configuration that can be done at compile time.
The appendixes give a brief
but detailed explanation of a number of features
not described in the rest of the paper.
.pp
."XXX
.b DISCLAIMER:
This documentation is under modification.
.bp
.rs
.sp |4i
.ce 2
This page intentionally left blank;
replace it with a blank sheet for double-sided output.
.bp 7
.sh 1 "BASIC INSTALLATION"
.pp
There are two basic steps to installing
.i sendmail .
First, you have to compile and install the binary.
If
.i 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
.i 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.
.pp
The remainder of this section will describe the installation of
.i 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
.i sendmail
subtree,
normally
.i /usr/src/usr.*(SD/sendmail
on 4.4BSD.
.pp
If you are loading this off the tape,
continue with the next section.
If you have a running binary already on your system,
you should probably skip to section 1.2.
.sh 2 "Compiling Sendmail"
.pp
All
.i sendmail
source is in the
.i sendmail
subdirectory.
To compile sendmail,
.q cd
into the
.i sendmail
directory and type
.(b
&./Build
.)b
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.
.sh 3 "Tweaking the Build Invocation"
.pp
You can give parameters on the
.i Build
command.
In most cases these are only used when the
.i obj.*
directory is first created.
These commands include:
.nr ii 0.5i
.ip "-L fIlibdirsfP"
A list of directories to search for libraries.
.ip "-I fIincdirsfP"
A list of directories to search for include files.
.ip "-E fIenvarfP=fIvaluefP"
Set an environment variable to an indicated
.i value
before compiling.
.ip "-c"
Create a new
.i obj.*
tree before running.
.ip "-f fIsiteconfigfP"
Read the indicated site configuration file.
If this parameter is not specified,
.i Build
includes
.i all
of the files
.i $BUILDTOOLS/Site/site.$oscf.m4
and
.i $BUILDTOOLS/Site/site.config.m4 ,
where $BUILDTOOLS is normally
.i &../devtools
and $oscf is the same name as used on the
.i obj.*
directory.
See below for a description of the site configuration file.
.ip "-S"
Skip auto-configuration.
.i Build
will avoid auto-detecting libraries if this is set.
All libraries and map definitions must be specified
in the site configuration file.
.lp
Any other parameters are passed to the
.i make
program.
.sh 3 "Creating a Site Configuration File"
."XXX
.pp
(This section is not yet complete.
For now, see the file devtools/README for details.)
.sh 3 "Tweaking the Makefile"
.pp
." .b "XXX This should all be in the Site Configuration File section."
.i Sendmail
supports two different formats
for the local (on disk) version of databases,
notably the
.i aliases
database.
At least one of these should be defined if at all possible.
.nr ii 1i
.ip 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.
.ip 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
.sm 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
.q /yp/ ,
.i sendmail
will create both new and old versions of the alias file
during a
.i 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.
.lp
If neither of these are defined,
.i 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:
.ip NIS
Sun's Network Information Services (formerly YP).
.ip NISPLUS
Sun's NIS+ services.
.ip NETINFO
NeXT's NetInfo service.
.ip HESIOD
Hesiod service (from Athena).
.lp
Other compilation flags are set in conf.h
and should be predefined for you
unless you are porting to a new environment.
.sh 3 "Compilation and installation"
.pp
After making the local system configuration described above,
You should be able to compile and install the system.
The script
.q Build
is the best approach on most systems:
.(b
&./Build
.)b
This will use
.i uname (1)
to create a custom Makefile for your environment.
.pp
If you are installing in the standard places,
you should be able to install using
.(b
&./Build install
.)b
This should install the binary in
/usr/*(SD
and create links from
/usr/*(SB/newaliases
and
/usr/*(SB/mailq
to
/usr/*(SD/sendmail.
On 4.4BSD systems it will also format and install man pages.
.sh 2 "Configuration Files"
.pp
.i 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.
.pp
The
.i 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.
.pp
These configuration files are simpler than old versions
largely because the world has become simpler;
in particular,
text-based host files are officially eliminated,
obviating the need to
.q hide
hosts behind a registered internet gateway.
.pp
These files also assume that most of your neighbors
use domain-based UUCP addressing;
that is,
instead of naming hosts as
.q host!user
they will use
.q host.domain!user .
The configuration files can be customized to work around this,
but it is more complex.
.pp
Our configuration files are processed by
.i m4
to facilitate local customization;
the directory
.i cf
of the
.i sendmail
distribution directory
contains the source files.
This directory contains several subdirectories:
.nr ii 1i
.ip cf
Both site-dependent and site-independent descriptions of hosts.
These can be literal host names
(e.g.,
.q ucbvax.mc )
when the hosts are gateways
or more general descriptions
(such as
.q "generic-solaris2.mc"
as a general description of an SMTP-connected host
running Solaris 2.x.
Files ending
.b &.mc
(``Master Configuration'')
are the input descriptions;
the output is in the corresponding
.b &.cf
file.
The general structure of these files is described below.
.ip domain
Site-dependent subdomain descriptions.
These are tied to the way your organization wants to do addressing.
For example,
.b domain/CS.Berkeley.EDU.m4
is our description for hosts in the CS.Berkeley.EDU subdomain.
These are referenced using the
.sm DOMAIN
.b m4
macro in the
.b &.mc
file.
.ip feature
Definitions of specific features that some particular host in your site
might want.
These are referenced using the
.sm FEATURE
.b m4
macro.
An example feature is
use_cw_file
(which tells
.i sendmail
to read an /etc/mail/local-host-names file on startup
to find the set of local names).
.ip hack
Local hacks, referenced using the
.sm HACK
.b m4
macro.
Try to avoid these.
The point of having them here is to make it clear that they smell.
.ip m4
Site-independent
.i m4 (1)
include files that have information common to all configuration files.
This can be thought of as a
.q #include
directory.
.ip mailer
Definitions of mailers,
referenced using the
.sm MAILER
.b 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
.q MAILER(uucp) .
.ip ostype
Definitions describing various operating system environments
(such as the location of support files).
These are referenced using the
.sm OSTYPE
.b m4
macro.
.ip sh
Shell files used by the
.b m4
build process.
You shouldn't have to mess with these.
.ip 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.
.pp
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.
.pp
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.
.pp
You will have to use or create
.b &.mc
files in the
.i cf/cf
subdirectory for your hosts.
This is detailed in the
cf/README
file.
.sh 2 "Details of Installation Files"
.pp
This subsection describes the files that
comprise the
.i sendmail
installation.
.sh 3 "/usr/*(SD/sendmail"
.pp
The binary for
.i sendmail
is located in /usr/*(SD**.
.(f
**This is usually
/usr/sbin
on 4.4BSD and newer systems;
many systems install it in
/usr/lib.
I understand it is in /usr/ucblib
on System V Release 4.
.)f
It should be setuid root.
For security reasons,
/, /usr, and /usr/*(SD
should be owned by root, mode 755**.
.(f
**Some vendors ship them owned by bin;
this creates a security hole that is not actually related to
.i sendmail .
Other important directories that should have restrictive ownerships
and permissions are
/bin, /usr/bin, /etc, /etc/mail, /usr/etc, /lib, and /usr/lib.
.)f
.sh 3 "/etc/mail/sendmail.cf"
.pp
This is the configuration file for
.i sendmail **.
.(f
**Actually, the pathname varies depending on the operating system;
/etc/mail is the preferred directory.
Some older systems install it in
.b /usr/lib/sendmail.cf ,
and I've also seen it in
.b /usr/ucblib .
If you want to move this file,
add -D_PATH_SENDMAILCF=e"/file/namee"
to the flags passed to the C compiler.
Moving this file is not recommended:
other programs and scripts know of this location.
.)f
This is the only non-library file name compiled into
.i sendmail **.
.(f
**The system libraries can reference other files;
in particular, system library subroutines that
.i sendmail
calls probably reference
.i /etc/passwd
and
.i /etc/resolv.conf .
.)f
.pp
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.
.sh 3 "/usr/*(SB/newaliases"
.pp
The
.i newaliases
command should just be a link to
.i sendmail :
.(b
rm -f /usr/*(SB/newaliases
ln -s /usr/*(SD/sendmail /usr/*(SB/newaliases
.)b
This can be installed in whatever search path you prefer
for your system.
.sh 3 "/usr/*(SB/hoststat"
.pp
The
.i hoststat
command should just be a link to
.i sendmail ,
in a fashion similar to
.i newaliases .
This command lists the status of the last mail transaction
with all remote hosts. The
.b -v
flag will prevent the status display from being truncated.
It functions only when the
.b HostStatusDirectory
option is set.
.sh 3 "/usr/*(SB/purgestat"
.pp
This command is also a link to
.i sendmail .
It flushes all information that is stored in the
.b HostStatusDirectory
tree.
.sh 3 "/var/spool/mqueue"
.pp
The directory
.i /var/spool/mqueue
should be created to hold the mail queue.
This directory should be mode 700
and owned by root.
.pp
The actual path of this directory
is defined in the
.b Q
option of the
.i sendmail.cf
file.
To use multiple queues,
supply a value ending with an asterisk.
For example,
.i /var/spool/mqueue/q*
will use all of the directories or symbolic links to directories
beginning with `q' in
.i /var/spool/mqueue
as queue directories.
Do not change the queue directory structure
while sendmail is running.
.pp
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.
.sh 3 "/var/spool/mqueue/.hoststat"
.pp
This is a typical value for the
.b HostStatusDirectory
option,
containing one file per host
that this sendmail has chatted with recently.
It is normally a subdirectory of
.i mqueue .
.sh 3 "/etc/mail/aliases*"
.pp
The system aliases are held in
.q /etc/mail/aliases .
A sample is given in
.q sendmail/aliases
which includes some aliases which
.i must
be defined:
.(b
cp lib/aliases /etc/mail/aliases
.i "edit /etc/mail/aliases"
.)b
You should extend this file with any aliases that are apropos to your system.
.pp
Normally
.i sendmail
looks at a database version of the files,
stored either in
.q /etc/mail/aliases.dir
and
.q /etc/mail/aliases.pag
or
.q /etc/mail/aliases.db
depending on which database package you are using.
The actual path of this file
is defined in the
.b AliasFile
option of the
.i sendmail.cf
file.
.sh 3 "/etc/rc or /etc/init.d/sendmail"
.pp
It will be necessary to start up the
.i 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.
.pp
Add the following lines to
.q /etc/rc
(or
.q /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
.q /etc/init.d/sendmail :
.(b
if [ -f /usr/*(SD/sendmail -a -f /etc/mail/sendmail.cf ]; then
(cd /var/spool/mqueue; rm -f [lnx]f*)
/usr/*(SD/sendmail -bd -q30m &
echo -n ' sendmail' >/dev/console
fi
.)b
The
.q cd
and
.q rm
commands insure that all lock files have been removed;
extraneous lock files may be left around
if the system goes down in the middle of processing a message.
The line that actually invokes
.i sendmail
has two flags:
.q -bd
causes it to listen on the SMTP port,
and
.q -q30m
causes it to run the queue every half hour.
.pp
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.
.(z
.hl
#!/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
.sp
.ce
Figure 1 (em A complex startup script
.hl
.)z
.pp
If you are not running a version of UNIX
that supports Berkeley TCP/IP,
do not include the
.b -bd
flag.
.sh 3 "/etc/mail/helpfile"
.pp
This is the help file used by the SMTP
.b HELP
command.
It should be copied from
.q sendmail/helpfile :
.(b
cp sendmail/helpfile /etc/mail/helpfile
.)b
The actual path of this file
is defined in the
.b HelpFile
option of the
.i sendmail.cf
file.
.sh 3 "/etc/mail/statistics"
.pp
If you wish to collect statistics
about your mail traffic,
you should create the file
.q /etc/mail/statistics :
.(b
cp /dev/null /etc/mail/statistics
chmod 644 /etc/mail/statistics
.)b
This file does not grow.
It is printed with the program
.q mailstats/mailstats.c.
The actual path of this file
is defined in the
.b S
option of the
.i sendmail.cf
file.
.sh 3 "/usr/*(SB/mailq"
.pp
If
.i sendmail
is invoked as
.q mailq,
it will simulate the
.b -bp
flag
(i.e.,
.i sendmail
will print the contents of the mail queue;
see below).
This should be a link to /usr/*(SD/sendmail.
.sh 1 "NORMAL OPERATIONS"
.sh 2 "The System Log"
.pp
The system log is supported by the
.i syslogd |(8)
program.
All messages from
.i sendmail
are logged under the
.sm LOG_MAIL
facility**.
.(f
**Except on Ultrix,
which does not support facilities in the syslog.
.)f
.sh 3 "Format"
.pp
Each line in the system log
consists of a timestamp,
the name of the machine that generated it
(for logging from several machines
over the local area network),
the word
.q sendmail: ,
and a message**.
.(f
**This format may vary slightly if your vendor has changed
the syntax.
.)f
Most messages are a sequence of
.i name c
=c
.i value
pairs.
.pp
The two most common lines are logged when a message is processed.
The first logs the receipt of a message;
there will be exactly one of these per message.
Some fields may be omitted if they do not contain interesting information.
Fields are:
.ip from
The envelope sender address.
.ip size
The size of the message in bytes.
.ip class
The class (i.e., numeric precedence) of the message.
.ip pri
The initial message priority (used for queue sorting).
.ip nrcpts
The number of envelope recipients for this message
(after aliasing and forwarding).
.ip msgid
The message id of the message (from the header).
.ip proto
The protocol used to receive this message (e.g., ESMTP or UUCP)
.ip relay
The machine from which it was received.
.lp
There is also one line logged per delivery attempt
(so there can be several per message if delivery is deferred
or there are multiple recipients).
Fields are:
.ip to
A comma-separated list of the recipients to this mailer.
.ip ctladdr
The ``controlling user'', that is, the name of the user
whose credentials we use for delivery.
.ip delay
The total delay between the time this message was received
and the time it was delivered.
.ip xdelay
The amount of time needed in this delivery attempt
(normally indicative of the speed of the connection).
.ip mailer
The name of the mailer used to deliver to this recipient.
.ip relay
The name of the host that actually accepted (or rejected) this recipient.
.ip stat
The delivery status.
.lp
Not all fields are present in all messages;
for example, the relay is not listed for local deliveries.
.sh 3 "Levels"
.pp
If you have
.i syslogd |(8)
or an equivalent installed,
you will be able to do logging.
There is a large amount of information that can be logged.
The log is arranged as a succession of levels.
At the lowest level
only extremely strange situations are logged.
At the highest level,
even the most mundane and uninteresting events
are recorded for posterity.
As a convention,
log levels under ten
are considered generally
.q useful;
log levels above 64
are reserved for debugging purposes.
Levels from 11-64 are reserved for verbose information
that some sites might want.
.pp
A complete description of the log levels
is given in section
." XREF
4.6.
.sh 2 "Dumping State"
.pp
You can ask
.i sendmail
to log a dump of the open files
and the connection cache
by sending it a
.sm SIGUSR1
signal.
The results are logged at
.sm LOG_DEBUG
priority.
.sh 2 "The Mail Queue"
.pp
Sometimes a host cannot handle a message immediately.
For example, it may be down or overloaded, causing it to refuse connections.
The sending host is then expected to save this message in
its mail queue
and attempt to deliver it later.
.pp
Under normal conditions the mail queue will be processed transparently.
However, you may find that manual intervention is sometimes necessary.
For example,
if a major host is down for a period of time
the queue may become clogged.
Although
.i sendmail
ought to recover gracefully when the host comes up,
you may find performance unacceptably bad in the meantime.
.sh 3 "Printing the queue"
.pp
The contents of the queue can be printed
using the
.i mailq
command
(or by specifying the
.b -bp
flag to
.i sendmail ):
.(b
mailq
.)b
This will produce a listing of the queue id's,
the size of the message,
the date the message entered the queue,
and the sender and recipients.
.sh 3 "Forcing the queue"
.pp
.i Sendmail
should run the queue automatically
at intervals.
When using multiple queues,
a separate process will be created to
run each of the queues
unless the queue run is initiated by a user
with the verbose flag.
The algorithm is to read and sort the queue,
and then to attempt to process all jobs in order.
When it attempts to run the job,
.i sendmail
first checks to see if the job is locked.
If so, it ignores the job.
.pp
There is no attempt to insure that only one queue processor
exists at any time,
since there is no guarantee that a job cannot take forever
to process
(however,
.i sendmail
does include heuristics to try to abort jobs
that are taking absurd amounts of time;
technically, this violates RFC 821, but is blessed by RFC 1123).
Due to the locking algorithm,
it is impossible for one job to freeze the entire queue.
However,
an uncooperative recipient host
or a program recipient
that never returns
can accumulate many processes in your system.
Unfortunately,
there is no completely general way to solve this.
.pp
In some cases,
you may find that a major host going down
for a couple of days
may create a prohibitively large queue.
This will result in
.i sendmail
spending an inordinate amount of time
sorting the queue.
This situation can be fixed by moving the queue to a temporary place
and creating a new queue.
The old queue can be run later when the offending host returns to service.
.pp
To do this,
it is acceptable to move the entire queue directory:
.(b
cd /var/spool
mv mqueue omqueue; mkdir mqueue; chmod 700 mqueue
.)b
You should then kill the existing daemon
(since it will still be processing in the old queue directory)
and create a new daemon.
.pp
To run the old mail queue,
run the following command:
.(b
/usr/*(SD/sendmail -oQ/var/spool/omqueue -q
.)b
The
.b -oQ
flag specifies an alternate queue directory
and the
.b -q
flag says to just run every job in the queue.
If you have a tendency toward voyeurism,
you can use the
.b -v
flag to watch what is going on.
.pp
When the queue is finally emptied,
you can remove the directory:
.(b
rmdir /var/spool/omqueue
.)b
.sh 2 "Disk Based Connection Information"
.pp
.i Sendmail
stores a large amount of information about each remote system it
has connected to in memory. It is now possible to preserve some
of this information on disk as well, by using the
.b HostStatusDirectory
option, so that it may be shared between several invocations of
.i sendmail .
This allows mail to be queued immediately or skipped during a queue run if
there has been a recent failure in connecting to a remote machine.
.pp
Additionally enabling
.b SingleThreadDelivery
has the added effect of single-threading mail delivery to a destination.
This can be quite helpful
if the remote machine is running an SMTP server that is easily overloaded
or cannot accept more than a single connection at a time,
but can cause some messages to be punted to a future queue run.
It also applies to
.i all
hosts, so setting this because you have one machine on site
that runs some software that is easily overrun
can cause mail to other hosts to be slowed down.
If this option is set,
you probably want to set the
.b MinQueueAge
option as well and run the queue fairly frequently;
this way jobs that are skipped because another
.i sendmail
is talking to the same host will be tried again quickly
rather than being delayed for a long time.
.pp
The disk based host information is stored in a subdirectory of the
.b mqueue
directory called
.b &.hoststat **.
.(f
**This is the usual value of the
.b HostStatusDirectory
option;
it can, of course, go anywhere you like in your filesystem.
.)f
Removing this directory and its subdirectories has an effect similar to
the
.i purgestat
command and is completely safe.
The information in these directories can
be perused with the
.i hoststat
command, which will indicate the host name, the last access, and the
status of that access.
An asterisk in the left most column indicates that a
.i sendmail
process currently has the host locked for mail delivery.
.pp
The disk based connection information is treated the same way as memory based
connection information for the purpose of timeouts.
By default, information about host failures is valid for 30 minutes.
This can be adjusted with
the
.b Timeout.hoststatus
option.
.pp
The connection information stored on disk may be purged at any time
with the
.i purgestat
command or by invoking sendmail with the
.b -bH
switch.
The connection information may be viewed with the
.i hoststat
command or by invoking sendmail with the
.b -bh
switch.
.sh 2 "The Service Switch"
.pp
The implementation of certain system services
such as host and user name lookup
is controlled by the service switch.
If the host operating system supports such a switch
.i sendmail
will use the native version.
Ultrix, Solaris, and DEC OSF/1 are examples of such systems**.
.(f
**HP-UX 10 has service switch support,
but since the APIs are apparently not available in the libraries
.i sendmail
does not use the native service switch in this release.
.)f
.pp
If the underlying operating system does not support a service switch
(e.g., SunOS 4.X, HP-UX, BSD)
then
.i sendmail
will provide a stub implementation.
The
.b ServiceSwitchFile
option points to the name of a file that has the service definitions.
Each line has the name of a service
and the possible implementations of that service.
For example, the file:
.(b
hosts dns files nis
aliases files nis
.)b
will ask
.i sendmail
to look for hosts in the Domain Name System first.
If the requested host name is not found,
it tries local files,
and if that fails it tries NIS.
Similarly,
when looking for aliases
it will try the local files first
followed by NIS.
.pp
Service switches are not completely integrated.
For example, despite the fact that the host entry listed in the above example
specifies to look in NIS,
on SunOS this won't happen because the system implementation of
.i gethostbyname |(3)
doesn't understand this.
If there is enough demand
.i sendmail
may reimplement
.i gethostbyname |(3),
.i gethostbyaddr |(3),
.i getpwent |(3),
and the other system routines that would be necessary
to make this work seamlessly.
.sh 2 "The Alias Database"
.pp
After recipient addresses are read from the SMTP connection
or command line
they are parsed by ruleset 0,
which must resolve to a
{c
.i mailer ,
.i host ,
.i address }
triple.
If the flags selected by the
.i mailer
include the
.b A
(aliasable) flag,
the
.i address
part of the triple is looked up as the key
(i.e., the left hand side)
into the alias database.
If there is a match, the address is deleted from the send queue
and all addresses on the right hand side of the alias
are added in place of the alias that was found.
This is a recursive operation,
so aliases found in the right hand side of the alias
are similarly expanded.
.pp
The alias database exists in two forms.
One is a text form,
maintained in the file
.i /etc/mail/aliases.
The aliases are of the form
.(b
name: name1, name2, ...
.)b
Only local names may be aliased;
e.g.,
.(b
eric@prep.ai.MIT.EDU: eric@CS.Berkeley.EDU
.)b
will not have the desired effect
(except on prep.ai.MIT.EDU,
and they probably don't want me)**.
.(f
**Actually, any mailer that has the `A' mailer flag set
will permit aliasing;
this is normally limited to the local mailer.
.)f
Aliases may be continued by starting any continuation lines
with a space or a tab or by putting a backslash directly before
the newline.
Blank lines and lines beginning with a sharp sign
(c
.q # )
are comments.
.pp
The second form is processed by the
.i ndbm |(3)**
.(f
**The
.i gdbm
package does not work.
.)f
or the Berkeley DB library.
This form is in the file
.i /etc/mail/aliases.db
(if using NEWDB)
or
.i /etc/mail/aliases.dir
and
.i /etc/mail/aliases.pag
(if using NDBM).
This is the form that
.i sendmail
actually uses to resolve aliases.
This technique is used to improve performance.
.pp
The control of search order is actually set by the service switch.
Essentially, the entry
.(b
O AliasFile=switch:aliases
.)b
is always added as the first alias entry;
also, the first alias file name without a class
(e.g., without
.q nis:
on the front)
will be used as the name of the file for a ``files'' entry
in the aliases switch.
For example, if the configuration file contains
.(b
O AliasFile=/etc/mail/aliases
.)b
and the service switch contains
.(b
aliases nis files nisplus
.)b
then aliases will first be searched in the NIS database,
then in /etc/mail/aliases,
then in the NIS+ database.
.pp
You can also use
.sm NIS -based
alias files.
For example, the specification:
.(b
O AliasFile=/etc/mail/aliases
O AliasFile=nis:mail.aliases@my.nis.domain
.)b
will first search the /etc/mail/aliases file
and then the map named
.q mail.aliases
in
.q my.nis.domain .
Warning: if you build your own
.sm NIS -based
alias files,
be sure to provide the
.b -l
flag to
.i makedbm (8)
to map upper case letters in the keys to lower case;
otherwise, aliases with upper case letters in their names
won't match incoming addresses.
.pp
Additional flags can be added after the colon
exactly like a
.b K
line (em for example:
.(b
O AliasFile=nis:-N mail.aliases@my.nis.domain
.)b
will search the appropriate NIS map and always include null bytes in the key.
Also:
.(b
O AliasFile=nis:-f mail.aliases@my.nis.domain
.)b
will prevent sendmail from downcasing the key before the alias lookup.
.sh 3 "Rebuilding the alias database"
.pp
The
.i hash
or
.i dbm
version of the database
may be rebuilt explicitly by executing the command
.(b
newaliases
.)b
This is equivalent to giving
.i sendmail
the
.b -bi
flag:
.(b
/usr/*(SD/sendmail -bi
.)b
.pp
If the
.b RebuildAliases
(old
.b D )
option is specified in the configuration,
.i sendmail
will rebuild the alias database automatically
if possible
when it is out of date.
Auto-rebuild can be dangerous
on heavily loaded machines
with large alias files;
if it might take more than the rebuild timeout
(option
.b AliasWait ,
old
.b a ,
which is normally five minutes)
to rebuild the database,
there is a chance that several processes will start the rebuild process
simultaneously.
.pp
If you have multiple aliases databases specified,
the
.b -bi
flag rebuilds all the database types it understands
(for example, it can rebuild NDBM databases but not NIS databases).
.sh 3 "Potential problems"
.pp
There are a number of problems that can occur
with the alias database.
They all result from a
.i sendmail
process accessing the DBM version
while it is only partially built.
This can happen under two circumstances:
One process accesses the database
while another process is rebuilding it,
or the process rebuilding the database dies
(due to being killed or a system crash)
before completing the rebuild.
.pp
Sendmail has three techniques to try to relieve these problems.
First, it ignores interrupts while rebuilding the database;
this avoids the problem of someone aborting the process
leaving a partially rebuilt database.
Second,
it locks the database source file during the rebuild (em
but that may not work over NFS or if the file is unwritable.
Third,
at the end of the rebuild
it adds an alias of the form
.(b
@: @
.)b
(which is not normally legal).
Before
.i sendmail
will access the database,
it checks to insure that this entry exists**.
.(f
**The
.b AliasWait
option is required in the configuration
for this action to occur.
This should normally be specified.
.)f
.sh 3 "List owners"
.pp
If an error occurs on sending to a certain address,
say
.q fIxfP ,
.i sendmail
will look for an alias
of the form
.q owner-fIxfP
to receive the errors.
This is typically useful
for a mailing list
where the submitter of the list
has no control over the maintenance of the list itself;
in this case the list maintainer would be the owner of the list.
For example:
.(b
unix-wizards: eric@ucbarpa, wnj@monet, nosuchuser,
sam@matisse
owner-unix-wizards: unix-wizards-request
unix-wizards-request: eric@ucbarpa
.)b
would cause
.q eric@ucbarpa
to get the error that will occur
when someone sends to
unix-wizards
due to the inclusion of
.q nosuchuser
on the list.
.pp
List owners also cause the envelope sender address to be modified.
The contents of the owner alias are used if they point to a single user,
otherwise the name of the alias itself is used.
For this reason, and to obey Internet conventions,
the
.q owner-
address normally points at the
.q -request
address; this causes messages to go out with the typical Internet convention
of using ``c
.i list -request''
as the return address.
.sh 2 "User Information Database"
.pp
If you have a version of
.i sendmail
with the user information database
compiled in,
and you have specified one or more databases using the
.b U
option,
the databases will be searched for a
.i user :maildrop
entry.
If found, the mail will be sent to the specified address.
.sh 2 "Per-User Forwarding (.forward Files)"
.pp
As an alternative to the alias database,
any user may put a file with the name
.q .forward
in his or her home directory.
If this file exists,
.i sendmail
redirects mail for that user
to the list of addresses listed in the .forward file.
For example, if the home directory for user
.q mckusick
has a .forward file with contents:
.(b
mckusick@ernie
kirk@calder
.)b
then any mail arriving for
.q mckusick
will be redirected to the specified accounts.
.pp
Actually, the configuration file defines a sequence of filenames to check.
By default, this is the user's .forward file,
but can be defined to be more generally using the
.b ForwardPath
option.
If you change this,
you will have to inform your user base of the change;
&.forward is pretty well incorporated into the collective subconscious.
.sh 2 "Special Header Lines"
.pp
Several header lines have special interpretations
defined by the configuration file.
Others have interpretations built into
.i sendmail
that cannot be changed without changing the code.
These builtins are described here.
.sh 3 "Errors-To:"
.pp
If errors occur anywhere during processing,
this header will cause error messages to go to
the listed addresses.
This is intended for mailing lists.
.pp
The Errors-To: header was created in the bad old days
when UUCP didn't understand the distinction between an envelope and a header;
this was a hack to provide what should now be passed
as the envelope sender address.
It should go away.
It is only used if the
.b UseErrorsTo
option is set.
.pp
The Errors-To: header is officially deprecated
and will go away in a future release.
.sh 3 "Apparently-To:"
.pp
RFC 822 requires at least one recipient field
(To:, Cc:, or Bcc: line)
in every message.
If a message comes in with no recipients listed in the message
then
.i sendmail
will adjust the header based on the
.q NoRecipientAction
option.
One of the possible actions is to add an
.q "Apparently-To:"
header line for any recipients it is aware of.
.pp
The Apparently-To: header is non-standard
and is deprecated.
.sh 3 "Precedence"
.pp
The Precedence: header can be used as a crude control of message priority.
It tweaks the sort order in the queue
and can be configured to change the message timeout values.
.sh 2 "IDENT Protocol Support"
.pp
.i Sendmail
supports the IDENT protocol as defined in RFC 1413.
Although this enhances identification
of the author of an email message
by doing a ``call back'' to the originating system to include
the owner of a particular TCP connection
in the audit trail
it is in no sense perfect;
a determined forger can easily spoof the IDENT protocol.
The following description is excerpted from RFC 1413:
.ba +5
.lp
6. Security Considerations
.lp
The information returned by this protocol is at most as trustworthy
as the host providing it OR the organization operating the host. For
example, a PC in an open lab has few if any controls on it to prevent
a user from having this protocol return any identifier the user
wants. Likewise, if the host has been compromised the information
returned may be completely erroneous and misleading.
.lp
The Identification Protocol is not intended as an authorization or
access control protocol. At best, it provides some additional
auditing information with respect to TCP connections. At worst, it
can provide misleading, incorrect, or maliciously incorrect
information.
.lp
The use of the information returned by this protocol for other than
auditing is strongly discouraged. Specifically, using Identification
Protocol information to make access control decisions - either as the
primary method (i.e., no other checks) or as an adjunct to other
methods may result in a weakening of normal host security.
.lp
An Identification server may reveal information about users,
entities, objects or processes which might normally be considered
private. An Identification server provides service which is a rough
analog of the CallerID services provided by some phone companies and
many of the same privacy considerations and arguments that apply to
the CallerID service apply to Identification. If you wouldn't run a
"finger" server due to privacy considerations you may not want to run
this protocol.
.ba
.lp
In some cases your system may not work properly with IDENT support
due to a bug in the TCP/IP implementation.
The symptoms will be that for some hosts
the SMTP connection will be closed
almost immediately.
If this is true or if you do not want to use IDENT,
you should set the IDENT timeout to zero;
this will disable the IDENT protocol.
.sh 1 "ARGUMENTS"
.pp
The complete list of arguments to
.i sendmail
is described in detail in Appendix A.
Some important arguments are described here.
.sh 2 "Queue Interval"
.pp
The amount of time between forking a process
to run through the queue
is defined by the
.b -q
flag.
If you run with delivery mode set to
.b i
or
.b b
this can be relatively large,
since it will only be relevant
when a host that was down comes back up.
If you run in
.b q
mode
it should be relatively short,
since it defines the maximum amount of time that a message
may sit in the queue.
(See also the MinQueueAge option.)
.pp
RFC 1123 section 5.3.1.1 says that this value should be at least 30 minutes
(although that probably doesn't make sense if you use ``queue-only'' mode).
.sh 2 "Daemon Mode"
.pp
If you allow incoming mail over an IPC connection,
you should have a daemon running.
This should be set by your
.i /etc/rc
file using the
.b -bd
flag.
The
.b -bd
flag and the
.b -q
flag may be combined in one call:
.(b
/usr/*(SD/sendmail -bd -q30m
.)b
.pp
An alternative approach is to invoke sendmail from
.i inetd (8)
(use the
.b -bs
flag to ask sendmail to speak SMTP on its standard input and output).
This works and allows you to wrap
.i sendmail
in a TCP wrapper program,
but may be a bit slower since the configuration file
has to be re-read on every message that comes in.
If you do this, you still need to have a
.i sendmail
running to flush the queue:
.(b
/usr/*(SD/sendmail -q30m
.)b
.sh 2 "Forcing the Queue"
.pp
In some cases you may find that the queue has gotten clogged for some reason.
You can force a queue run
using the
.b -q
flag (with no value).
It is entertaining to use the
.b -v
flag (verbose)
when this is done to watch what happens:
.(b
/usr/*(SD/sendmail -q -v
.)b
.pp
You can also limit the jobs to those with a particular queue identifier,
sender, or recipient
using one of the queue modifiers.
For example,
.q -qRberkeley
restricts the queue run to jobs that have the string
.q berkeley
somewhere in one of the recipient addresses.
Similarly,
.q -qSstring
limits the run to particular senders and
.q -qIstring
limits it to particular queue identifiers.
.sh 2 "Debugging"
.pp
There are a fairly large number of debug flags
built into
.i sendmail .
Each debug flag has a number and a level,
where higher levels means to print out more information.
The convention is that levels greater than nine are
.q absurd,
i.e.,
they print out so much information that you wouldn't normally
want to see them except for debugging that particular piece of code.
Debug flags are set using the
.b -d
option;
the syntax is:
.(b
.ta w'debug-option 'u
debug-flag: fB-dfP debug-list
debug-list: debug-option [ , debug-option ]*
debug-option: debug-range [ . debug-level ]
debug-range: integer | integer - integer
debug-level: integer
.)b
where spaces are for reading ease only.
For example,
.(b
-d12 Set flag 12 to level 1
-d12.3 Set flag 12 to level 3
-d3-17 Set flags 3 through 17 to level 1
-d3-17.4 Set flags 3 through 17 to level 4
.)b
For a complete list of the available debug flags
you will have to look at the code
(they are too dynamic to keep this documentation up to date).
.sh 2 "Changing the Values of Options"
.pp
Options can be overridden using the
.b -o
or
.b -O
command line flags.
For example,
.(b
/usr/*(SD/sendmail -oT2m
.)b
sets the
.b T
(timeout) option to two minutes
for this run only;
the equivalent line using the long option name is
.(b
/usr/*(SD/sendmail -OTimeout.queuereturn=2m
.)b
.pp
Some options have security implications.
Sendmail allows you to set these,
but relinquishes its setuid root permissions thereafter**.
.(f
**That is, it sets its effective uid to the real uid;
thus, if you are executing as root,
as from root's crontab file or during system startup
the root permissions will still be honored.
.)f
.sh 2 "Trying a Different Configuration File"
.pp
An alternative configuration file
can be specified using the
.b -C
flag; for example,
.(b
/usr/*(SD/sendmail -Ctest.cf -oQ/tmp/mqueue
.)b
uses the configuration file
.i test.cf
instead of the default
.i /etc/mail/sendmail.cf.
If the
.b -C
flag has no value
it defaults to
.i sendmail.cf
in the current directory.
.pp
.i Sendmail
gives up its setuid root permissions
when you use this flag, so it is common to use a publicly writable directory
(such as /tmp)
as the spool directory (QueueDirectory or Q option) while testing.
.sh 2 "Logging Traffic"
.pp
Many SMTP implementations do not fully implement the protocol.
For example, some personal computer based SMTPs
do not understand continuation lines in reply codes.
These can be very hard to trace.
If you suspect such a problem, you can set traffic logging using the
.b -X
flag.
For example,
.(b
/usr/*(SD/sendmail -X /tmp/traffic -bd
.)b
will log all traffic in the file
.i /tmp/traffic .
.pp
This logs a lot of data very quickly and should
.b NEVER
be used
during normal operations.
After starting up such a daemon,
force the errant implementation to send a message to your host.
All message traffic in and out of
.i sendmail ,
including the incoming SMTP traffic,
will be logged in this file.
.sh 2 "Testing Configuration Files"
.pp
When you build a configuration table,
you can do a certain amount of testing
using the
.q "test mode"
of
.i sendmail .
For example,
you could invoke
.i sendmail
as:
.(b
sendmail -bt -Ctest.cf
.)b
which would read the configuration file
.q test.cf
and enter test mode.
In this mode,
you enter lines of the form:
.(b
rwset address
.)b
where
.i rwset
is the rewriting set you want to use
and
.i address
is an address to apply the set to.
Test mode shows you the steps it takes
as it proceeds,
finally showing you the address it ends up with.
You may use a comma separated list of rwsets
for sequential application of rules to an input.
For example:
.(b
3,1,21,4 monet:bollard
.)b
first applies ruleset three to the input
.q monet:bollard.
Ruleset one is then applied to the output of ruleset three,
followed similarly by rulesets twenty-one and four.
.pp
If you need more detail,
you can also use the
.q -d21
flag to turn on more debugging.
For example,
.(b
sendmail -bt -d21.99
.)b
turns on an incredible amount of information;
a single word address
is probably going to print out several pages worth of information.
.pp
You should be warned that internally,
.i sendmail
applies ruleset 3 to all addresses.
In test mode
you will have to do that manually.
For example, older versions allowed you to use
.(b
0 bruce@broadcast.sony.com
.)b
This version requires that you use:
.(b
3,0 bruce@broadcast.sony.com
.)b
.pp
As of version 8.7,
some other syntaxes are available in test mode:
.bu
&.D|x|value
defines macro
.i x
to have the indicated
.i value .
This is useful when debugging rules that use the
.b $& c
.i x
syntax.
.bu
&.C|c|value
adds the indicated
.i value
to class
.i c .
.bu
&.S|ruleset
dumps the contents of the indicated ruleset.
.bu
-d|debug-spec
is equivalent to the command-line flag.
.sh 2 "Persistent Host Status Information"
.pp
When
.b HostStatusDirectory
is enabled,
information about the status of hosts is maintained on disk
and can thus be shared between different instantiations of
.i sendmail .
The status of the last connection with each remote host
may be viewed with the command:
.(b
sendmail -bh
.)b
This information may be flushed with the command:
.(b
sendmail -bH
.)b
Flushing the information prevents new
.i sendmail
processes from loading it,
but does not prevent existing processes from using the status information
that they already have.
.sh 1 "TUNING"
.pp
There are a number of configuration parameters
you may want to change,
depending on the requirements of your site.
Most of these are set
using an option in the configuration file.
For example,
the line
.q "O Timeout.queuereturn=5d"
sets option
.q Timeout.queuereturn
to the value
.q 5d
(five days).
.pp
Most of these options have appropriate defaults for most sites.
However,
sites having very high mail loads may find they need to tune them
as appropriate for their mail load.
In particular,
sites experiencing a large number of small messages,
many of which are delivered to many recipients,
may find that they need to adjust the parameters
dealing with queue priorities.
.pp
All versions of
.i sendmail
prior to 8.7
had single character option names.
As of 8.7,
options have long (multi-character names).
Although old short names are still accepted,
most new options do not have short equivalents.
.pp
This section only describes the options you are most likely
to want to tweak;
read section
."XREF
5
for more details.
.sh 2 "Timeouts"
.pp
All time intervals are set
using a scaled syntax.
For example,
.q 10m
represents ten minutes, whereas
.q 2h30m
represents two and a half hours.
The full set of scales is:
.(b
.ta 4n
s seconds
m minutes
h hours
d days
w weeks
.)b
.sh 3 "Queue interval"
.pp
The argument to the
.b -q
flag
specifies how often a sub-daemon will run the queue.
This is typically set to between fifteen minutes
and one hour.
RFC 1123 section 5.3.1.1 recommends that this be at least 30 minutes.
.sh 3 "Read timeouts"
.pp
Timeouts all have option names
.q Timeout.fIsuboptionfP .
The recognized
.i suboption s,
their default values, and the minimum values
allowed by RFC 1123 section 5.3.2 are:
.nr ii 1i
.ip connect
The time to wait for an SMTP connection to open
(the
.i connect (2)
system call)
[0, unspecified].
If zero, uses the kernel default.
In no case can this option extend the timeout
longer than the kernel provides, but it can shorten it.
This is to get around kernels that provide an absurdly long connection timeout
(90 minutes in one case).
.ip iconnect
The same as
.i connect,
except it applies only to the initial attempt to connect to a host
for a given message
[0, unspecified].
The concept is that this should be very short (a few seconds);
hosts that are well connected and responsive will thus be serviced immediately.
Hosts that are slow will not hold up other deliveries in the initial
delivery attempt.
.ip initial
The wait for the initial 220 greeting message
[5m, 5m].
.ip helo
The wait for a reply from a HELO or EHLO command
[5m, unspecified].
This may require a host name lookup, so
five minutes is probably a reasonable minimum.
.ip mail(dg
The wait for a reply from a MAIL command
[10m, 5m].
.ip rcpt(dg
The wait for a reply from a RCPT command
[1h, 5m].
This should be long
because it could be pointing at a list
that takes a long time to expand
(see below).
.ip datainit(dg
The wait for a reply from a DATA command
[5m, 2m].
.ip datablock(dg(dd
The wait for reading a data block
(that is, the body of the message).
[1h, 3m].
This should be long because it also applies to programs
piping input to
.i sendmail
which have no guarantee of promptness.
.ip datafinal(dg
The wait for a reply from the dot terminating a message.
[1h, 10m].
If this is shorter than the time actually needed
for the receiver to deliver the message,
duplicates will be generated.
This is discussed in RFC 1047.
.ip rset
The wait for a reply from a RSET command
[5m, unspecified].
.ip quit
The wait for a reply from a QUIT command
[2m, unspecified].
.ip misc
The wait for a reply from miscellaneous (but short) commands
such as NOOP (no-operation) and VERB (go into verbose mode).
[2m, unspecified].
.ip command(dg(dd
In server SMTP,
the time to wait for another command.
[1h, 5m].
.ip ident(dd
The timeout waiting for a reply to an IDENT query
[30s**, unspecified].
.(f
**On some systems the default is zero to turn the protocol off entirely.
.)f
.ip fileopen(dd
The timeout for opening .forward and :include: files [60s, none].
.ip control(dd
The timeout for a complete control socket transaction to complete [2m, none].
.ip hoststatus(dd
How long status information about a host
(e.g., host down)
will be cached before it is considered stale
[30m, unspecified].
.ip resolver.retrans
The resolver's
retransmission time interval
(in seconds)
[varies].
Sets both
.i Timeout.resolver.retrans.first
and
.i Timeout.resolver.retrans.normal .
.ip resolver.retrans.first
The resolver's
retransmission time interval
(in seconds)
for the first attempt to
deliver a message
[varies].
.ip resolver.retrans.normal
The resolver's
retransmission time interval
(in seconds)
for all resolver lookups
except the first delivery attempt
[varies].
.ip resolver.retry
The number of times
to retransmit a resolver query.
Sets both
.i Timeout.resolver.retry.first
and
.i Timeout.resolver.retry.normal
[varies].
.ip resolver.retry.first
The number of times
to retransmit a resolver query
for the first attempt
to deliver a message
[varies].
.ip resolver.retry.normal
The number of times
to retransmit a resolver query
for all resolver lookups
except the first delivery attempt
[varies].
.lp
For compatibility with old configuration files,
if no
.i suboption
is specified,
all the timeouts marked with a dagger ((dg) are set to the indicated value.
All but those marked with a double dagger ((dd) apply to client SMTP.
.pp
Many of the RFC 1123 minimum values
may well be too short.
.i Sendmail
was designed to the RFC 822 protocols,
which did not specify read timeouts;
hence, versions of
.i sendmail
prior to version 8.1 did not guarantee to reply to messages promptly.
In particular, a
.q RCPT
command specifying a mailing list
will expand and verify the entire list;
a large list on a slow system
may easily take more than five minutes**.
.(f
**This verification includes looking up every address
with the name server;
this involves network delays,
and can in some cases can be considerable.
.)f
I recommend a one hour timeout *-
since a communications failure during the RCPT phase is rare,
a long timeout is not onerous
and may ultimately help reduce network load
and duplicated messages.
.pp
For example, the lines:
.(b
O Timeout.command=25m
O Timeout.datablock=3h
.)b
sets the server SMTP command timeout to 25 minutes
and the input data block timeout to three hours.
.sh 3 "Message timeouts"
.pp
After sitting in the queue for a few days,
a message will time out.
This is to insure that at least the sender is aware
of the inability to send a message.
The timeout is typically set to five days.
It is sometimes considered convenient to also send a warning message
if the message is in the queue longer than a few hours
(assuming you normally have good connectivity;
if your messages normally took several hours to send
you wouldn't want to do this because it wouldn't be an unusual event).
These timeouts are set using the
.b Timeout.queuereturn
and
.b Timeout.queuewarn
options in the configuration file
(previously both were set using the
.b T
option).
.pp
If the message is submitted using the
.sm NOTIFY
.sm SMTP
extension,
warning messages will only be sent if
.sm NOTIFY=DELAY
is specified.
The queuereturn and queuewarn timeouts
can be further qualified with a tag based on the Precedence: field
in the message;
they must be one of
.q urgent
(indicating a positive non-zero precedence)
.q normal
(indicating a zero precedence), or
.q non-urgent
(indicating negative precedences).
For example, setting
.q Timeout.queuewarn.urgent=1h
sets the warning timeout for urgent messages only
to one hour.
The default if no precedence is indicated
is to set the timeout for all precedences.
The value "now" can be used for
-O Timeout.queuereturn
to return entries immediately during a queue run,
e.g., to bounce messages independent of their time in the queue.
.pp
Since these options are global,
and since you can not know
.i "a priori"
how long another host outside your domain will be down,
a five day timeout is recommended.
This allows a recipient to fix the problem even if it occurs
at the beginning of a long weekend.
RFC 1123 section 5.3.1.1 says that this parameter
should be ``at least 4-5 days''.
.pp
The
.b Timeout.queuewarn
value can be piggybacked on the
.b T
option by indicating a time after which
a warning message should be sent;
the two timeouts are separated by a slash.
For example, the line
.(b
OT5d/4h
.)b
causes email to fail after five days,
but a warning message will be sent after four hours.
This should be large enough that the message will have been tried
several times.
.sh 2 "Forking During Queue Runs"
.pp
By setting the
.b ForkEachJob
(c
.b Y )
option,
.i sendmail
will fork before each individual message
while running the queue.
This will prevent
.i sendmail
from consuming large amounts of memory,
so it may be useful in memory-poor environments.
However, if the
.b ForkEachJob
option is not set,
.i sendmail
will keep track of hosts that are down during a queue run,
which can improve performance dramatically.
.pp
If the
.b ForkEachJob
option is set,
.i sendmail
can not use connection caching.
.sh 2 "Queue Priorities"
.pp
Every message is assigned a priority when it is first instantiated,
consisting of the message size (in bytes)
offset by the message class
(which is determined from the Precedence: header)
times the
.q "work class factor"
and the number of recipients times the
.q "work recipient factor."
The priority is used to order the queue.
Higher numbers for the priority mean that the message will be processed later
when running the queue.
.pp
The message size is included so that large messages are penalized
relative to small messages.
The message class allows users to send
.q "high priority"
messages by including a
.q Precedence:
field in their message;
the value of this field is looked up in the
.b P
lines of the configuration file.
Since the number of recipients affects the amount of load a message presents
to the system,
this is also included into the priority.
.pp
The recipient and class factors
can be set in the configuration file using the
.b RecipientFactor
(c
.b y )
and
.b ClassFactor
(c
.b z )
options respectively.
They default to 30000 (for the recipient factor)
and 1800
(for the class factor).
The initial priority is:
.EQ
pri = msgsize - (class times bold ClassFactor) + (nrcpt times bold RecipientFactor)
.EN
(Remember, higher values for this parameter actually mean
that the job will be treated with lower priority.)
.pp
The priority of a job can also be adjusted each time it is processed
(that is, each time an attempt is made to deliver it)
using the
.q "work time factor,"
set by the
.b RetryFactor
(c
.b Z )
option.
This is added to the priority,
so it normally decreases the precedence of the job,
on the grounds that jobs that have failed many times
will tend to fail again in the future.
The
.b RetryFactor
option defaults to 90000.
.sh 2 "Load Limiting"
.pp
.i Sendmail
can be asked to queue (but not deliver)
mail if the system load average gets too high
using the
.b QueueLA
(c
.b x )
option.
When the load average exceeds the value of the
.b QueueLA
option,
the delivery mode is set to
.b q
(queue only)
if the
.b QueueFactor
(c
.b q )
option divided by the difference in the current load average and the
.b QueueLA
option
plus one
exceeds the priority of the message (em
that is, the message is queued iff:
.EQ
pri > { bold QueueFactor } over { LA - { bold QueueLA } + 1 }
.EN
The
.b QueueFactor
option defaults to 600000,
so each point of load average is worth 600000
priority points
(as described above).
.pp
For drastic cases,
the
.b RefuseLA
(c
.b X )
option defines a load average at which
.i sendmail
will refuse
to accept network connections.
Locally generated mail
(including incoming UUCP mail)
is still accepted.
.sh 2 "Delivery Mode"
.pp
There are a number of delivery modes that
.i sendmail
can operate in,
set by the
.b DeliveryMode
(c
.b d )
configuration option.
These modes
specify how quickly mail will be delivered.
Legal modes are:
.(b
.ta 4n
i deliver interactively (synchronously)
b deliver in background (asynchronously)
q queue only (don't deliver)
d defer delvery attempts (don't deliver)
.)b
There are tradeoffs.
Mode
.q i
gives the sender the quickest feedback,
but may slow down some mailers and
is hardly ever necessary.
Mode
.q b
delivers promptly but
can cause large numbers of processes
if you have a mailer that takes a long time to deliver a message.
Mode
.q q
minimizes the load on your machine,
but means that delivery may be delayed for up to the queue interval.
Mode
.q d
is identical to mode
.q q
except that it also prevents all the early map lookups from working;
it is intended for ``dial on demand'' sites where DNS lookups
might cost real money.
Some simple error messages
(e.g., host unknown during the SMTP protocol)
will be delayed using this mode.
Mode
.q b
is the usual default.
.pp
If you run in mode
.q q
(queue only),
.q d
(defer),
or
.q b
(deliver in background)
.i sendmail
will not expand aliases and follow .forward files
upon initial receipt of the mail.
This speeds up the response to RCPT commands.
Mode
.q i
cannot be used by the SMTP server.
.sh 2 "Log Level"
.pp
The level of logging can be set for
.i sendmail .
The default using a standard configuration table is level 9.
The levels are as follows:
.nr ii 0.5i
.ip 0
Minimal logging.
.ip 1
Serious system failures and potential security problems.
.ip 2
Lost communications (network problems) and protocol failures.
.ip 3
Other serious failures, malformed addresses, transient forward/include
errors, connection timeouts.
.ip 4
Minor failures, out of date alias databases, connection rejections
via check_ rulesets.
.ip 5
Message collection statistics.
.ip 6
Creation of error messages,
VRFY and EXPN commands.
.ip 7
Delivery failures (host or user unknown, etc.).
.ip 8
Successful deliveries and alias database rebuilds.
.ip 9
Messages being deferred
(due to a host being down, etc.).
.ip 10
Database expansion (alias, forward, and userdb lookups).
.ip 11
NIS errors and end of job processing.
.ip 12
Logs all SMTP connections.
.ip 13
Log bad user shells, files with improper permissions, and other
questionable situations.
.ip 14
Logs refused connections.
.ip 15
Log all incoming and outgoing SMTP commands.
.ip 20
Logs attempts to run locked queue files.
These are not errors,
but can be useful to note if your queue appears to be clogged.
.ip 30
Lost locks (only if using lockf instead of flock).
.lp
Additionally,
values above 64 are reserved for extremely verbose debugging output.
No normal site would ever set these.
.sh 2 "File Modes"
.pp
The modes used for files depend on what functionality you want
and the level of security you require.
In many cases
.i sendmail
does careful checking of the modes
of files and directories
to avoid accidental compromise;
if you want to make it possible to have group-writable support files
you may need to use the
.b DontBlameSendmail
option to turn off some of these checks.
.sh 3 "To suid or not to suid?"
.pp
.i Sendmail
is normally installed
setuid to root.
At the point where it is about to
.i exec |(2)
a mailer,
it checks to see if the userid is zero (root);
if so,
it resets the userid and groupid to a default
(set by the
.b U=
equate in the mailer line;
if that is not set, the
.b DefaultUser
option is used).
This can be overridden
by setting the
.b S
flag to the mailer
for mailers that are trusted
and must be called as root.
However,
this will cause mail processing
to be accounted
(using
.i sa |(8))
to root
rather than to the user sending the mail.
.pp
If you don't make
.i sendmail
setuid to root, it will still run but you lose a lot of functionality
and a lot of privacy, since you'll have to make the queue directory
world readable.
You could also make
.i sendmail
setuid to some pseudo-user
(e.g., create a user called
.q sendmail
and make
.i sendmail
setuid to that)
which will fix the privacy problems
but not the functionality issues.
Also, this isn't a guarantee of security:
for example,
root occasionally sends mail,
and the daemon often runs as root.
Note however that
.i sendmail
must run as root or the trusted user in order to create the SMTP listener
socket.
.pp
A middle ground is to make
.i sendmail
setuid to root,
but set the
.b RunAsUser
option.
This causes
.i sendmail
to become the indicated user as soon as it has done the startup
that requires root privileges
(primarily, opening the
.sm SMTP
socket).
If you use
.b RunAsUser ,
the queue directory
(normally
.i /var/spool/mqueue )
should be owned by that user,
and all files and databases
(including user
.i &.forward
files,
alias files,
:include: files,
and external databases)
must be readable by that user.
Also, since sendmail will not be able to change it's uid,
delivery to programs or files will be marked as unsafe,
e.g., undeliverable,
in
.i &.forward ,
aliases,
and :include: files.
Administrators can override this by setting the
.b DontBlameSendmail
option to the setting
.b NonRootSafeAddr .
.b RunAsUser
is probably best suited for firewall configurations
that don't have regular user logins.
.sh 3 "Turning off security checks"
.pp
.i Sendmail
is very particular about the modes of files that it reads or writes.
For example, by default it will refuse to read most files
that are group writable
on the grounds that they might have been tampered with
by someone other than the owner;
it will even refuse to read files in group writable directories.
.pp
If you are
.i quite
sure that your configuration is safe and you want
.i sendmail
to avoid these security checks,
you can turn off certain checks using the
.b DontBlameSendmail
option.
This option takes one or more names that disable checks.
In the descriptions that follow,
.q "unsafe directory"
means a directory that is writable by anyone other than the owner.
The values are:
.nr ii 0.5i
.ip Safe
No special handling.
.ip AssumeSafeChown
Assume that the
.i chown
system call is restricted to root.
Since some versions of Unix permit regular users
to give away their files to other users on some filesystems,
.i sendmail
often cannot assume that a given file was created by the owner,
particularly when it is in a writable directory.
You can set this flag if you know that file giveaway is restricted
on your system.
.ip ClassFileInUnsafeDirPath
When reading class files (using the
.b F
line in the configuration file),
allow files that are in unsafe directories.
.ip DontWarnForwardFileInUnsafeDirPath
Prevent logging of
unsafe directory path warnings
for non-existent forward files.
.ip ErrorHeaderInUnsafeDirPath
Allow the file named in the
.b ErrorHeader
option to be in an unsafe directory.
.ip GroupWritableDirPathSafe
Change the definition of
.q "unsafe directory"
to consider group-writable directories to be safe.
World-writable directories are always unsafe.
.ip GroupWritableForwardFileSafe
Accept group-writable
.i &.forward
files.
.ip GroupWritableIncludeFileSafe
Accept group-writable
.i :include:
files.
.ip GroupWritableAliasFile
Allow group-writable alias files.
.ip HelpFileInUnsafeDirPath
Allow the file named in the
.b HelpFile
option to be in an unsafe directory.
.ip WorldWritableAliasFile
Accept world-writable alias files.
.ip ForwardFileInGroupWritableDirPath
Allow
.i &.forward
files in group writable directories.
.ip IncludeFileInGroupWritableDirPath
Allow
.i :include:
files in group writable directories.
.ip ForwardFileInUnsafeDirPath
Allow
.i &.forward
files in unsafe directories.
.ip IncludeFileInUnsafeDirPath
Allow
.i :include:
files in unsafe directories.
.ip ForwardFileInUnsafeDirPathSafe
Allow a
.i &.forward
file that is in an unsafe directory to include references
to program and files.
.ip IncludeFileInUnsafeDirPathSafe
Allow a
.i :include:
file that is in an unsafe directory to include references
to program and files.
.ip MapInUnsafeDirPath
Allow maps (e.g.,
.i hash ,
.i btree ,
and
.i dbm
files)
in unsafe directories.
.ip LinkedAliasFileInWritableDir
Allow an alias file that is a link in a writable directory.
.ip LinkedClassFileInWritableDir
Allow class files that are links in writable directories.
.ip LinkedForwardFileInWritableDir
Allow
.i &.forward
files that are links in writable directories.
.ip LinkedIncludeFileInWritableDir
Allow
.i :include:
files that are links in writable directories.
.ip LinkedMapInWritableDir
Allow map files that are links in writable directories.
.ip LinkedServiceSwitchFileInWritableDir
Allow the service switch file to be a link
even if the directory is writable.
.ip FileDeliveryToHardLink
Allow delivery to files that are hard links.
.ip FileDeliveryToSymLink
Allow delivery to files that are symbolic links.
.ip RunProgramInUnsafeDirPath
Go ahead and run programs that are in writable directories.
.ip RunWritableProgram
Go ahead and run programs that are group- or world-writable.
.ip WriteMapToHardLink
Allow writes to maps that are hard links.
.ip WriteMapToSymLink
Allow writes to maps that are symbolic links.
.ip WriteStatsToHardLink
Allow the status file to be a hard link.
.ip WriteStatsToSymLink
Allow the status file to be a symbolic link.
.ip TrustStickyBit
Allow group or world writable directories
if the sticky bit is set on the directory.
Do not set this on systems which do not honor
the sticky bit on directories.
.ip NonRootSafeAddr
Do not mark file and program deliveries as unsafe
if sendmail is not running with root privileges.
.sh 2 "Connection Caching"
.pp
When processing the queue,
.i sendmail
will try to keep the last few open connections open
to avoid startup and shutdown costs.
This only applies to IPC connections.
.pp
When trying to open a connection
the cache is first searched.
If an open connection is found, it is probed to see if it is still active
by sending a
.sm RSET
command.
It is not an error if this fails;
instead, the connection is closed and reopened.
.pp
Two parameters control the connection cache.
The
.b ConnectionCacheSize
(c
.b k )
option defines the number of simultaneous open connections
that will be permitted.
If it is set to zero,
connections will be closed as quickly as possible.
The default is one.
This should be set as appropriate for your system size;
it will limit the amount of system resources that
.i sendmail
will use during queue runs.
Never set this higher than 4.
.pp
The
.b ConnectionCacheTimeout
(c
.b K )
option specifies the maximum time that any cached connection
will be permitted to idle.
When the idle time exceeds this value
the connection is closed.
This number should be small
(under ten minutes)
to prevent you from grabbing too many resources
from other hosts.
The default is five minutes.
.sh 2 "Name Server Access"
.pp
Control of host address lookups is set by the
.b hosts
service entry in your service switch file.
If you are on a system that has built-in service switch support
(e.g., Ultrix, Solaris, or DEC OSF/1)
then your system is probably configured properly already.
Otherwise,
.i sendmail
will consult the file
.b /etc/mail/service.switch ,
which should be created.
.i Sendmail
only uses two entries:
.b hosts
and
.b aliases ,
although system routines may use other services
(notably the
.b passwd
service for user name lookups by
.i getpwname ).
.pp
However, some systems (such as SunOS 4.X)
will do DNS lookups
regardless of the setting of the service switch entry.
In particular, the system routine
.i gethostbyname (3)
is used to look up host names,
and many vendor versions try some combination of DNS, NIS,
and file lookup in /etc/hosts
without consulting a service switch.
.i Sendmail
makes no attempt to work around this problem,
and the DNS lookup will be done anyway.
If you do not have a nameserver configured at all,
such as at a UUCP-only site,
.i sendmail
will get a
.q "connection refused"
message when it tries to connect to the name server.
If the
.b hosts
switch entry has the service
.q dns
listed somewhere in the list,
.i sendmail
will interpret this to mean a temporary failure
and will queue the mail for later processing;
otherwise, it ignores the name server data.
.pp
The same technique is used to decide whether to do MX lookups.
If you want MX support, you
.i must
have
.q dns
listed as a service in the
.b hosts
switch entry.
.pp
The
.b ResolverOptions
(c
.b I )
option allows you to tweak name server options.
The command line takes a series of flags as documented in
.i resolver (3)
(with the leading
.q RES_
deleted).
Each can be preceded by an optional `+' or `(mi'.
For example, the line
.(b
O ResolverOptions=+AAONLY (miDNSRCH
.)b
turns on the AAONLY (accept authoritative answers only)
and turns off the DNSRCH (search the domain path) options.
Most resolver libraries default DNSRCH, DEFNAMES, and RECURSE
flags on and all others off.
You can also include
.q HasWildcardMX
to specify that there is a wildcard MX record matching your domain;
this turns off MX matching when canonifying names,
which can lead to inappropriate canonifications.
.pp
Version level 1 configurations
turn DNSRCH and DEFNAMES off when doing delivery lookups,
but leave them on everywhere else.
Version 8 of
.i sendmail
ignores them when doing canonification lookups
(that is, when using $[ ... $]),
and always does the search.
If you don't want to do automatic name extension,
don't call $[ ... $].
.pp
The search rules for $[ ... $] are somewhat different than usual.
If the name being looked up
has at least one dot, it always tries the unmodified name first.
If that fails, it tries the reduced search path,
and lastly tries the unmodified name
(but only for names without a dot,
since names with a dot have already been tried).
This allows names such as
``utc.CS''
to match the site in Czechoslovakia
rather than the site in your local Computer Science department.
It also prefers A and CNAME records over MX records *-
that is, if it finds an MX record it makes note of it,
but keeps looking.
This way, if you have a wildcard MX record matching your domain,
it will not assume that all names match.
.pp
To completely turn off all name server access
on systems without service switch support
(such as SunOS 4.X)
you will have to recompile with
-DNAMED_BIND=0
and remove -lresolv from the list of libraries to be searched
when linking.
.sh 2 "Moving the Per-User Forward Files"
.pp
Some sites mount each user's home directory
from a local disk on their workstation,
so that local access is fast.
However, the result is that .forward file lookups are slow.
In some cases,
mail can even be delivered on machines inappropriately
because of a file server being down.
The performance can be especially bad if you run the automounter.
.pp
The
.b ForwardPath
(c
.b J )
option allows you to set a path of forward files.
For example, the config file line
.(b
O ForwardPath=/var/forward/$u:$z/.forward.$w
.)b
would first look for a file with the same name as the user's login
in /var/forward;
if that is not found (or is inaccessible)
the file
``.forward.c
.i machinename ''
in the user's home directory is searched.
A truly perverse site could also search by sender
by using $r, $s, or $f.
.pp
If you create a directory such as /var/forward,
it should be mode 1777
(that is, the sticky bit should be set).
Users should create the files mode 644.
Note that you must use the
forwardfileinunsafedirpath and
forwardfileinunsafedirpathsafe
flags with the DontBlameSendmail option
to allow forward files in a world
writable directory.
This might also be used as a
denial of service
attack (users could create forward files for other users);
a better approach might be to create
/var/forward
mode 755
and create empty files for each user,
owned by that user,
mode 644.
If you do this, you don't have to set the DontBlameSendmail options
indicated above.
.sh 2 "Free Space"
.pp
On systems that have one of the system calls in the
.i statfs (2)
family
(including
.i statvfs
and
.i ustat ),
you can specify a minimum number of free blocks on the queue filesystem
using the
.b MinFreeBlocks
(c
.b b )
option.
If there are fewer than the indicated number of blocks free
on the filesystem on which the queue is mounted
the SMTP server will reject mail
with the
452 error code.
This invites the SMTP client to try again later.
.pp
Beware of setting this option too high;
it can cause rejection of email
when that mail would be processed without difficulty.
.sh 2 "Maximum Message Size"
.pp
To avoid overflowing your system with a large message,
the
.b MaxMessageSize
option can be set to set an absolute limit
on the size of any one message.
This will be advertised in the ESMTP dialogue
and checked during message collection.
.sh 2 "Privacy Flags"
.pp
The
.b PrivacyOptions
(c
.b p )
option allows you to set certain
``privacy''
flags.
Actually, many of them don't give you any extra privacy,
rather just insisting that client SMTP servers
use the HELO command
before using certain commands
or adding extra headers to indicate possible spoof attempts.
.pp
The option takes a series of flag names;
the final privacy is the inclusive or of those flags.
For example:
.(b
O PrivacyOptions=needmailhelo, noexpn
.)b
insists that the HELO or EHLO command be used before a MAIL command is accepted
and disables the EXPN command.
.pp
The flags are detailed in section
."XREF
5.6.
.sh 2 "Send to Me Too"
.pp
Beginning with version 8.10,
.i sendmail
includes by default the (envelope) sender in any list expansions.
For example, if
.q matt
sends to a list that contains
.q matt
as one of the members he will get a copy of the message.
If the
.b MeToo
option is set to
.sm FALSE
(in the configuration file or via the command line),
this behavior is changed, i.e.,
the (envelope) sender is excluded in list expansions.
.sh 1 "THE WHOLE SCOOP ON THE CONFIGURATION FILE"
.pp
This section describes the configuration file
in detail.
.pp
There is one point that should be made clear immediately:
the syntax of the configuration file
is designed to be reasonably easy to parse,
since this is done every time
.i sendmail
starts up,
rather than easy for a human to read or write.
On the
.q "future project"
list is a
configuration-file compiler.
.pp
The configuration file is organized as a series of lines,
each of which begins with a single character
defining the semantics for the rest of the line.
Lines beginning with a space or a tab
are continuation lines
(although the semantics are not well defined in many places).
Blank lines and lines beginning with a sharp symbol
(`#')
are comments.
.sh 2 "R and S *- Rewriting Rules"
.pp
The core of address parsing
are the rewriting rules.
These are an ordered production system.
.i Sendmail
scans through the set of rewriting rules
looking for a match on the left hand side
(LHS)
of the rule.
When a rule matches,
the address is replaced by the right hand side
(RHS)
of the rule.
.pp
There are several sets of rewriting rules.
Some of the rewriting sets are used internally
and must have specific semantics.
Other rewriting sets
do not have specifically assigned semantics,
and may be referenced by the mailer definitions
or by other rewriting sets.
.pp
The syntax of these two commands are:
.(b F
.b S c
.i n
.)b
Sets the current ruleset being collected to
.i n .
If you begin a ruleset more than once
it appends to the old definition.
.(b F
.b R c
.i lhs
.i rhs
.i comments
.)b
The
fields must be separated
by at least one tab character;
there may be embedded spaces
in the fields.
The
.i lhs
is a pattern that is applied to the input.
If it matches,
the input is rewritten to the
.i rhs .
The
.i comments
are ignored.
.pp
Macro expansions of the form
.b $ c
.i x
are performed when the configuration file is read.
Expansions of the form
.b $& c
.i x
are performed at run time using a somewhat less general algorithm.
This is intended only for referencing internally defined macros
such as
.b $h
that are changed at runtime.
.sh 3 "The left hand side"
.pp
The left hand side of rewriting rules contains a pattern.
Normal words are simply matched directly.
Metasyntax is introduced using a dollar sign.
The metasymbols are:
.(b
.ta w'fB$=fPfIxfP 'u
fB$*fP Match zero or more tokens
fB$+fP Match one or more tokens
fB$-fP Match exactly one token
fB$=fPfIxfP Match any phrase in class fIxfP
fB$~fPfIxfP Match any word not in class fIxfP
.)b
If any of these match,
they are assigned to the symbol
.b $ c
.i n
for replacement on the right hand side,
where
.i n
is the index in the LHS.
For example,
if the LHS:
.(b
$-:$+
.)b
is applied to the input:
.(b
UCBARPA:eric
.)b
the rule will match, and the values passed to the RHS will be:
.(b
.ta 4n
$1 UCBARPA
$2 eric
.)b
.pp
Additionally, the LHS can include
.b $@
to match zero tokens.
This is
.i not
bound to a
.b $ c
.i n
on the RHS, and is normally only used when it stands alone
in order to match the null input.
.sh 3 "The right hand side"
.pp
When the left hand side of a rewriting rule matches,
the input is deleted and replaced by the right hand side.
Tokens are copied directly from the RHS
unless they begin with a dollar sign.
Metasymbols are:
.(b
.ta w'$#mailer'u
fB$fPfInfP Substitute indefinite token fInfP from LHS
fB$[fPfInamefPfB$]fP Canonicalize fInamefP
fB$(fPfImap keyfP fB$@fPfIargumentsfP fB$:fPfIdefaultfP fB$)fP
Generalized keyed mapping function
fB$>fPfInfP *(lqCall*(rq ruleset fInfP
fB$#fPfImailerfP Resolve to fImailerfP
fB$@fPfIhostfP Specify fIhostfP
fB$:fPfIuserfP Specify fIuserfP
.)b
.pp
The
.b $ c
.i n
syntax substitutes the corresponding value from a
.b $+ ,
.b $- ,
.b $* ,
.b $= ,
or
.b $~
match on the LHS.
It may be used anywhere.
.pp
A host name enclosed between
.b $[
and
.b $]
is looked up in the host database(s)
and replaced by the canonical name**.
.(f
**This is actually
completely equivalent
to $(host fIhostnamefP$).
In particular, a
.b $:
default can be used.
.)f
For example,
.q $[ftp$]
might become
.q ftp.CS.Berkeley.EDU
and
.q $[[128.32.130.2]$]
would become
.q vangogh.CS.Berkeley.EDU.
.i Sendmail
recognizes its numeric IP address
without calling the name server
and replaces it with its canonical name.
.pp
The
.b $(
&...
.b $)
syntax is a more general form of lookup;
it uses a named map instead of an implicit map.
If no lookup is found, the indicated
.i default
is inserted;
if no default is specified and no lookup matches,
the value is left unchanged.
The
.i arguments
are passed to the map for possible use.
.pp
The
.b $> c
.i n
syntax
causes the remainder of the line to be substituted as usual
and then passed as the argument to ruleset
.i n .
The final value of ruleset
.i n
then becomes
the substitution for this rule.
The
.b $>
syntax expands everything after the ruleset name
to the end of the replacement string
and then passes that as the initial input to the ruleset.
Recursive calls are allowed.
For example,
.(b
$>0 $>3 $1
.)b
expands $1, passes that to ruleset 3, and then passes the result
of ruleset 3 to ruleset 0.
.pp
The
.b $#
syntax should
.i only
be used in ruleset zero
or a subroutine of ruleset zero.
It causes evaluation of the ruleset to terminate immediately,
and signals to
.i sendmail
that the address has completely resolved.
The complete syntax is:
.(b
fB$#fPfImailerfP fB$@fPfIhostfP fB$:fPfIuserfP
.)b
This specifies the
{mailer, host, user}
3-tuple necessary to direct the mailer.
If the mailer is local
the host part may be omitted**.
.(f
**You may want to use it for special
.q "per user"
extensions.
For example, in the address
.q jgm+foo@CMU.EDU ;
the
.q +foo
part is not part of the user name,
and is passed to the local mailer for local use.
.)f
The
.i mailer
must be a single word,
but the
.i host
and
.i user
may be multi-part.
If the
.i mailer
is the builtin IPC mailer,
the
.i host
may be a colon-separated list of hosts
that are searched in order for the first working address
(exactly like MX records).
The
.i user
is later rewritten by the mailer-specific envelope rewriting set
and assigned to the
.b $u
macro.
As a special case, if the mailer specified has the
.b F=@
flag specified
and the first character of the
.b $:
value is
.q @ ,
the
.q @
is stripped off, and a flag is set in the address descriptor
that causes sendmail to not do ruleset 5 processing.
.pp
Normally, a rule that matches is retried,
that is,
the rule loops until it fails.
A RHS may also be preceded by a
.b $@
or a
.b $:
to change this behavior.
A
.b $@
prefix causes the ruleset to return with the remainder of the RHS
as the value.
A
.b $:
prefix causes the rule to terminate immediately,
but the ruleset to continue;
this can be used to avoid continued application of a rule.
The prefix is stripped before continuing.
.pp
The
.b $@
and
.b $:
prefixes may precede a
.b $>
spec;
for example:
.(b
.ta 8n
R$+ $: $>7 $1
.)b
matches anything,
passes that to ruleset seven,
and continues;
the
.b $:
is necessary to avoid an infinite loop.
.pp
Substitution occurs in the order described,
that is,
parameters from the LHS are substituted,
hostnames are canonicalized,
.q subroutines
are called,
and finally
.b $# ,
.b $@ ,
and
.b $:
are processed.
.sh 3 "Semantics of rewriting rule sets"
.pp
There are six rewriting sets
that have specific semantics.
Five of these are related as depicted by figure 1.
.(z
.hl
.ie n {
.(c
+---+
-->| 0 |-->resolved address
/ +---+
/ +---+ +---+
/ ---->| 1 |-->| S |--
+---+ / +---+ / +---+ +---+ e +---+
addr-->| 3 |-->| D |-- --->| 4 |-->msg
+---+ +---+ e +---+ +---+ / +---+
--->| 2 |-->| R |--
+---+ +---+
.)c
.}
.el .ie !"*(.T""
{
.PS
boxwid = 0.3i
boxht = 0.3i
movewid = 0.3i
moveht = 0.3i
linewid = 0.3i
lineht = 0.3i
box invis "addr"; arrow
Box3: box "3"
A1: arrow
BoxD: box "D"; line; L1: Here
C: [
C1: arrow; box "1"; arrow; box "S"; line; E1: Here
move to C1 down 0.5; right
C2: arrow; box "2"; arrow; box "R"; line; E2: Here
] with .w at L1 + (0.5, 0)
move to C.e right 0.5
L4: arrow; box "4"; arrow; box invis "msg"
line from L1 to C.C1
line from L1 to C.C2
line from C.E1 to L4
line from C.E2 to L4
move to BoxD.n up 0.6; right
Box0: arrow; box "0"
arrow; box invis "resolved address" width 1.3
line from 1/3 of the way between A1 and BoxD.w to Box0
.PE
.}
.el .sp 2i
.ce
Figure 1 *- Rewriting set semantics
.(c
D *- sender domain addition
S *- mailer-specific sender rewriting
R *- mailer-specific recipient rewriting
.)c
.hl
.)z
.pp
Ruleset three
should turn the address into
.q "canonical form."
This form should have the basic syntax:
.(b
local-part@host-domain-spec
.)b
Ruleset three
is applied by
.i sendmail
before doing anything with any address.
.pp
If no
.q @
sign is specified,
then the
host-domain-spec
.i may
be appended (box
.q D
in Figure 1)
from the
sender address
(if the
.b C
flag is set in the mailer definition
corresponding to the
.i sending
mailer).
.pp
Ruleset zero
is applied after ruleset three
to addresses that are going to actually specify recipients.
It must resolve to a
.i "{mailer, host, address}"
triple.
The
.i mailer
must be defined in the mailer definitions
from the configuration file.
The
.i host
is defined into the
.b $h
macro
for use in the argv expansion of the specified mailer.
.pp
Rulesets one and two
are applied to all sender and recipient addresses respectively.
They are applied before any specification
in the mailer definition.
They must never resolve.
.pp
Ruleset four is applied to all addresses
in the message.
It is typically used
to translate internal to external form.
.pp
In addition,
ruleset 5 is applied to all local addresses
(specifically, those that resolve to a mailer with the `F=5'
flag set)
that do not have aliases.
This allows a last minute hook for local names.
.sh 3 "Ruleset hooks"
.pp
A few extra rulesets are defined as
.q hooks
that can be defined to get special features.
They are all named rulesets.
The
.q check_*
forms all give accept/reject status;
falling off the end or returning normally is an accept,
and resolving to
.b $#error
is a reject.
Many of these can also resolve to the special mailer
.b $#discard ;
this accepts the message as though it were successful
but then discards it without delivery.
.sh 4 "check_relay"
.pp
The
.i check_relay
ruleset is called after a connection is accepted.
It is passed
.(b
client.host.name $| client.host.address
.)b
where
.b $|
is a metacharacter separating the two parts.
This ruleset can reject connections from various locations.
.sh 4 "check_mail"
.pp
The
.i check_mail
ruleset is passed the user name parameter of the
.sm "SMTP MAIL"
command.
It can accept or reject the address.
.sh 4 "check_rcpt"
.pp
The
.i check_rcpt
ruleset is passed the user name parameter of the
.sm "SMTP RCPT"
command.
It can accept or reject the address.
.sh 4 "check_compat"
.pp
The
.i check_compat
ruleset is passed
.(b
sender-address $| recipient-address
.)b
where
.b $|
is a metacharacter separating the addresses.
It can accept or reject mail transfer between these two addresses
much like the
.i checkcompat()
function.
.sh 4 "check_eoh"
.pp
The
.i check_eoh
ruleset is passed
.(b
number-of-headers $| size-of-headers
.)b
where
.b $|
is a metacharacter separating the numbers.
These numbers can be used for size comparisons with the
.b arith
map.
The ruleset is triggered after
all of the headers have been read.
It can be used to correlate information gathered
from those headers using the
.b macro
storage map.
One possible use is to check for a missing header.
For example:
.(b
.ta 1.5i
Kstorage macro
HMessage-Id: $>CheckMessageId
SCheckMessageId
# Record the presence of the header
R$* $: $(storage {MessageIdCheck} $@ OK $) $1
R< $+ @ $+ > $@ OK
R$* $#error $: 553 Header Error
Scheck_eoh
# Check the macro
R$* $: < $&{MessageIdCheck} >
# Clear the macro for the next message
R$* $: $(storage {MessageIdCheck} $) $1
# Has a Message-Id: header
R< $+ > $@ OK
# Allow missing Message-Id: from local mail
R$* $: < $&{client_name} >
R< > $@ OK
R< $=w > $@ OK
# Otherwise, reject the mail
R$* $#error $: 553 Header Error
.)b
Keep in mind the Message-Id: header is not a required header and
is not a guaranteed spam indicator.
This ruleset is an example and
should probably not be used in production.
.sh 4 "check_etrn"
.pp
The
.i check_etrn
ruleset is passed the parameter of the
.sm "SMTP ETRN"
command.
It can accept or reject the command.
.sh 4 "check_expn"
.pp
The
.i check_expn
ruleset is passed the user name parameter of the
.sm "SMTP EXPN"
command.
It can accept or reject the address.
.sh 4 "check_vrfy"
.pp
The
.i check_vrfy
ruleset is passed the user name parameter of the
.sm "SMTP VRFY"
command.
It can accept or reject the command.
.sh 4 "trust_auth"
.pp
The
.i trust_auth
ruleset is passed the AUTH= parameter of the
.sm "SMTP MAIL"
command.
It is used to determine whether this value should be
trusted. In order to make this decision, the ruleset
may make use of the various
.b ${auth_*}
macros.
If the ruleset does resolve to the
.q error
mailer the AUTH= parameter is not trusted and hence
not passed on to the next relay.
.sh 3 "IPC mailers"
.pp
Some special processing occurs
if the ruleset zero resolves to an IPC mailer
(that is, a mailer that has
.q [IPC]
listed as the Path in the
.b M
configuration line.
The host name passed after
.q $@
has MX expansion performed;
this looks the name up in DNS to find alternate delivery sites.
.pp
The host name can also be provided as a dotted quad in square brackets;
for example:
.(b
[128.32.149.78]
.)b
This causes direct conversion of the numeric value
to an IP host address.
.pp
The host name passed in after the
.q $@
may also be a colon-separated list of hosts.
Each is separately MX expanded and the results are concatenated
to make (essentially) one long MX list.
The intent here is to create
.q fake
MX records that are not published in DNS
for private internal networks.
.pp
As a final special case, the host name can be passed in
as a text string
in square brackets:
.(b
[ucbvax.berkeley.edu]
.)b
This form avoids the MX mapping.
.b N.B.:
.i
This is intended only for situations where you have a network firewall
or other host that will do special processing for all your mail,
so that your MX record points to a gateway machine;
this machine could then do direct delivery to machines
within your local domain.
Use of this feature directly violates RFC 1123 section 5.3.5:
it should not be used lightly.
.r
.sh 2 "D *- Define Macro"
.pp
Macros are named with a single character
or with a word in {braces}.
Single character names may be selected from the entire ASCII set,
but user-defined macros
should be selected from the set of upper case letters only.
Lower case letters
and special symbols
are used internally.
Long names beginning with a lower case letter or a punctuation character
are reserved for use by sendmail,
so user-defined long macro names should begin with an upper case letter.
.pp
The syntax for macro definitions is:
.(b F
.b D c
.i x|val
.)b
where
.i x
is the name of the macro
(which may be a single character
or a word in braces)
and
.i val
is the value it should have.
There should be no spaces given
that do not actually belong in the macro value.
.pp
Macros are interpolated
using the construct
.b $ c
.i x ,
where
.i x
is the name of the macro to be interpolated.
This interpolation is done when the configuration file is read,
except in
.b M
lines.
The special construct
.b $& c
.i x
can be used in
.b R
lines to get deferred interpolation.
.pp
Conditionals can be specified using the syntax:
.(b
$?x text1 $| text2 $.
.)b
This interpolates
.i text1
if the macro
.b $x
is set and non-null,
and
.i text2
otherwise.
The
.q else
(c
.b $| )
clause may be omitted.
.pp
Lower case macro names are reserved to have
special semantics,
used to pass information in or out of
.i sendmail ,
and special characters are reserved to
provide conditionals, etc.
Upper case names
(that is,
.b $A
through
.b $Z )
are specifically reserved for configuration file authors.
.pp
The following macros are defined and/or used internally by
.i sendmail
for interpolation into argv's for mailers
or for other contexts.
The ones marked (dg are information passed into sendmail**,
.(f
**As of version 8.6,
all of these macros have reasonable defaults.
Previous versions required that they be defined.
.)f
the ones marked (dd are information passed both in and out of sendmail,
and the unmarked macros are passed out of sendmail
but are not otherwise used internally.
These macros are:
.nr ii 5n
.ip $a
The origination date in RFC 822 format.
This is extracted from the Date: line.
.ip $b
The current date in RFC 822 format.
.ip $c
The hop count.
This is a count of the number of Received: lines
plus the value of the
.b -h
command line flag.
.ip $d
The current date in UNIX (ctime) format.
.ip $e(dg
(Obsolete; use SmtpGreetingMessage option instead.)
The SMTP entry message.
This is printed out when SMTP starts up.
The first word must be the
.b $j
macro as specified by RFC821.
Defaults to
.q "$j Sendmail $v ready at $b" .
Commonly redefined to include the configuration version number, e.g.,
.q "$j Sendmail $v/$Z ready at $b"
.ip $f
The envelope sender (from) address.
.ip $g
The sender address relative to the recipient.
For example, if
.b $f
is
.q foo ,
.b $g
will be
.q host!foo ,
.q foo@host.domain ,
or whatever is appropriate for the receiving mailer.
.ip $h
The recipient host.
This is set in ruleset 0 from the $@ field of a parsed address.
.ip $i
The queue id,
e.g.,
.q HAA12345 .
.ip $j(dd
The *(lqofficial*(rq domain name for this site.
This is fully qualified if the full qualification can be found.
It
.i must
be redefined to be the fully qualified domain name
if your system is not configured so that information can find
it automatically.
.ip $k
The UUCP node name (from the uname system call).
.ip $l(dg
(Obsolete; use UnixFromLine option instead.)
The format of the UNIX from line.
Unless you have changed the UNIX mailbox format,
you should not change the default,
which is
.q "From $g $d" .
.ip $m
The domain part of the fIgethostnamefP return value.
Under normal circumstances,
.b $j
is equivalent to
.b $w.$m .
.ip $n(dg
The name of the daemon (for error messages).
Defaults to
.q MAILER-DAEMON .
.ip $o(dg
(Obsolete: use OperatorChars option instead.)
The set of *(lqoperators*(rq in addresses.
A list of characters
which will be considered tokens
and which will separate tokens
when doing parsing.
For example, if
.q @
were in the
.b $o
macro, then the input
.q a@b
would be scanned as three tokens:
.q a,
.q @,
and
.q b.
Defaults to
.q ".:@[]" ,
which is the minimum set necessary to do RFC 822 parsing;
a richer set of operators is
.q ".:%@!/[]" ,
which adds support for UUCP, the %-hack, and X.400 addresses.
.ip $p
Sendmail's process id.
.ip $q(dg
Default format of sender address.
The
.b $q
macro specifies how an address should appear in a message
when it is defaulted.
Defaults to
.q "<$g>" .
It is commonly redefined to be
.q "$?x$x <$g>$|$g$."
or
.q "$g$?x ($x)$." ,
corresponding to the following two formats:
.(b
Eric Allman <eric@CS.Berkeley.EDU>
eric@CS.Berkeley.EDU (Eric Allman)
.)b
.i Sendmail
properly quotes names that have special characters
if the first form is used.
.ip $r
Protocol used to receive the message.
Set from the
.b -p
command line flag or by the SMTP server code.
.ip $s
Sender's host name.
Set from the
.b -p
command line flag or by the SMTP server code.
.ip $t
A numeric representation of the current time.
.ip $u
The recipient user.
.ip $v
The version number of the
.i sendmail
binary.
.ip $w(dd
The hostname of this site.
This is the root name of this host (but see below for caveats).
.ip $x
The full name of the sender.
.ip $z
The home directory of the recipient.
.ip $_
The validated sender address.
.ip ${auth_authen}
The client's authentication credentials as determined by authentication
(only set if successful).
.ip ${auth_author}
The authorization identity, i.e. the AUTH= parameter of the
.sm "SMTP MAIL"
command if supplied.
.ip ${auth_type}
The mechanism used for authentication
(only set if successful).
.ip ${bodytype}
The message body type
(7BIT or 8BITMIME),
as determined from the envelope.
.ip ${client_addr}
The IP address of the SMTP client.
Defined in the SMTP server only.
.ip ${client_name}
The host name of the SMTP client.
This may be the client's bracketed IP address
in the form [ nnn.nnn.nnn.nnn ] if the client's
IP address is not resolvable, or if the resolved
name doesn't match ${client_name}.
Defined in the SMTP server only.
.ip ${client_port}
The port number of the SMTP client.
Defined in the SMTP server only.
.ip ${client_resolve}
Holds the result of the resolve call for
.b ${client_name}
: OK, FAIL, FORGED, TEMP.
Defined in the SMTP server only.
.ip ${currHeader}
Header value as quoted string
(possibly truncated to
.b MAXNAME ).
.ip ${daemon_addr}
The IP address the daemon is listening on for connections.
Unless
.b DaemonPortOptions
is set, this will be
.q 0.0.0.0 .
.ip ${daemon_family}
The network family
if the daemon is accepting network connections.
Possible values include
.q inet ,
.q inet6 ,
.q iso ,
.q ns ,
.q x.25
.ip ${daemon_flags}
The flags for the daemon as specified by the
Modifier= part of
.b DaemonPortOptions
whereby the flags are separated from each other by spaces,
and upper case flags are doubled.
That is,
Modifier=Ea
will be represented as
"EE a" in
.b ${daemon_flags} ,
which is required for testing the flags in rulesets.
.ip ${daemon_info}
Some information about a daemon as a text string.
For example,
.q SMTP+queueing@00:30:00 .
.ip ${daemon_name}
The name of the daemon from
.b DaemonPortOptions
Name= suboption.
If this suboption is not set,
"Daemon#",
where # is the daemon number,
is used.
.ip ${daemon_port}
The port the daemon is accepting connection on.
Unless
.b DaemonPortOptions
is set, this will most likely be
.q 25 .
.ip ${deliveryMode}
The current delivery mode sendmail is using.
It is initially set to the value of the
.b DeliveryMode
option.
.ip ${envid}
The envelope id passed to sendmail as part of the envelope.
.ip ${hdrlen}
The length of the header value which is stored in
${currHeader} (before possible truncation).
If this value is greater than or equal
.b MAXNAME
the header has been truncated.
.ip ${hdr_name}
The name of the header field for which the current header
check ruleset has been called.
This is useful for a default header check ruleset to get
the name of the header.
.ip ${if_addr}
The IP address of the interface of an incoming connection
unless it is in the loopback net.
.ip ${if_name}
The name of the interface of an incoming connection.
This macro can be used for
SmtpGreetingMessage and HReceived for virtual hosting.
For example:
O SmtpGreetingMessage=$?{if_name}${if_name}$|$j$. Sendmail $v/$Z; $b
.ip ${mail_addr}
The address part of the resolved triple of the address given for the
.sm "SMTP MAIL"
command.
Defined in the SMTP server only.
.ip ${mail_host}
The host from the resolved triple of the address given for the
.sm "SMTP MAIL"
command.
Defined in the SMTP server only.
.ip ${mail_mailer}
The mailer from the resolved triple of the address given for the
.sm "SMTP MAIL"
command.
Defined in the SMTP server only.
.ip ${ntries}
The number of delivery attempts.
.ip ${opMode}
The current operation mode (from the
.b -b
flag).
.ip ${queue_interval}
The queue run interval given by the
.b -q
flag.
For example,
.b -q30m
would set
.b ${queue_interval}
to
.q 00:30:00 .
.ip ${rcpt_addr}
The address part of the resolved triple of the address given for the
.sm "SMTP RCPT"
command.
Defined in the SMTP server only.
.ip ${rcpt_host}
The host from the resolved triple of the address given for the
.sm "SMTP RCPT"
command.
Defined in the SMTP server only.
.ip ${rcpt_mailer}
The mailer from the resolved triple of the address given for the
.sm "SMTP RCPT"
command.
Defined in the SMTP server only.
.pp
There are three types of dates that can be used.
The
.b $a
and
.b $b
macros are in RFC 822 format;
.b $a
is the time as extracted from the
.q Date:
line of the message
(if there was one),
and
.b $b
is the current date and time
(used for postmarks).
If no
.q Date:
line is found in the incoming message,
.b $a
is set to the current time also.
The
.b $d
macro is equivalent to the
.b $b
macro in UNIX
(ctime)
format.
.pp
The macros
.b $w ,
.b $j ,
and
.b $m
are set to the identity of this host.
.i Sendmail
tries to find the fully qualified name of the host
if at all possible;
it does this by calling
.i gethostname (2)
to get the current hostname
and then passing that to
.i gethostbyname (3)
which is supposed to return the canonical version of that host name.**
.(f
**For example, on some systems
.i gethostname
might return
.q foo
which would be mapped to
.q foo.bar.com
by
.i gethostbyname .
.)f
Assuming this is successful,
.b $j
is set to the fully qualified name
and
.b $m
is set to the domain part of the name
(everything after the first dot).
The
.b $w
macro is set to the first word
(everything before the first dot)
if you have a level 5 or higher configuration file;
otherwise, it is set to the same value as
.b $j .
If the canonification is not successful,
it is imperative that the config file set
.b $j
to the fully qualified domain name**.
.(f
**Older versions of sendmail didn't pre-define
.b $j
at all, so up until 8.6,
config files
.i always
had to define
.b $j .
.)f
.pp
The
.b $f
macro is the id of the sender
as originally determined;
when mailing to a specific host
the
.b $g
macro is set to the address of the sender
.ul
relative to the recipient.
For example,
if I send to
.q bollard@matisse.CS.Berkeley.EDU
from the machine
.q vangogh.CS.Berkeley.EDU
the
.b $f
macro will be
.q eric
and the
.b $g
macro will be
.q eric@vangogh.CS.Berkeley.EDU.
.pp
The
.b $x
macro is set to the full name of the sender.
This can be determined in several ways.
It can be passed as flag to
.i sendmail .
It can be defined in the
.sm NAME
environment variable.
The third choice is the value of the
.q Full-Name:
line in the header if it exists,
and the fourth choice is the comment field
of a
.q From:
line.
If all of these fail,
and if the message is being originated locally,
the full name is looked up in the
.i /etc/passwd
file.
.pp
When sending,
the
.b $h ,
.b $u ,
and
.b $z
macros get set to the host, user, and home directory
(if local)
of the recipient.
The first two are set from the
.b $@
and
.b $:
part of the rewriting rules, respectively.
.pp
The
.b $p
and
.b $t
macros are used to create unique strings
(e.g., for the
.q Message-Id:
field).
The
.b $i
macro is set to the queue id on this host;
if put into the timestamp line
it can be extremely useful for tracking messages.
The
.b $v
macro is set to be the version number of
.i sendmail ;
this is normally put in timestamps
and has been proven extremely useful for debugging.
.pp
The
.b $c
field is set to the
.q "hop count,"
i.e., the number of times this message has been processed.
This can be determined
by the
.b -h
flag on the command line
or by counting the timestamps in the message.
.pp
The
.b $r
and
.b $s
fields are set to the protocol used to communicate with
.i sendmail
and the sending hostname.
They can be set together using the
.b -p
command line flag or separately using the
.b -M
or
.b -oM
flags.
.pp
The
.b $_
is set to a validated sender host name.
If the sender is running an RFC 1413 compliant IDENT server
and the receiver has the IDENT protocol turned on,
it will include the user name on that host.
.pp
The
.b ${client_name} ,
.b ${client_addr} ,
and
.b ${client_port}
macros
are set to the name, address, and port number of the SMTP client
who is invoking
.i sendmail
as a server.
These can be used in the
.i check_*
rulesets (using the
.b $&
deferred evaluation form, of course!).
.sh 2 "C and F *- Define Classes"
.pp
Classes of phrases may be defined
to match on the left hand side of rewriting rules,
where a
.q phrase
is a sequence of characters that does not contain space characters.
For example
a class of all local names for this site
might be created
so that attempts to send to oneself
can be eliminated.
These can either be defined directly in the configuration file
or read in from another file.
Classes are named as a single letter or a word in {braces}.
Class names beginning with lower case letters
and special characters are reserved for system use.
Classes defined in config files may be given names
from the set of upper case letters for short names
or beginning with an upper case letter for long names.
.pp
The syntax is:
.(b F
.b C c
.i c|phrase1
.i phrase2...
.br
.b F c
.i c|file
.)b
The first form defines the class
.i c
to match any of the named words.
If
.i phrase1
or
.i phrase2
is another class,
e.g.,
.i $=S ,
the contents of class
.i S
are added to class
.i c .
It is permissible to split them among multiple lines;
for example, the two forms:
.(b
CHmonet ucbmonet
.)b
and
.(b
CHmonet
CHucbmonet
.)b
are equivalent.
The ``F'' form
reads the elements of the class
.i c
from the named
.i file .
.pp
Elements of classes can be accessed in rules using
.b $=
or
.b $~ .
The
.b $~
(match entries not in class)
only matches a single word;
multi-word entries in the class are ignored in this context.
.pp
Some classes have internal meaning to
.i sendmail :
.nr ii 0.5i
.".ip $=b
."A set of Content-Types that will not have the newline character
."translated to CR-LF before encoding into base64 MIME.
."The class can have major times
."(e.g.,
.".q image )
."or full types
."(such as
.".q application/octet-stream ).
."The class is initialized with
.".q application/octet-stream ,
.".q image ,
.".q audio ,
."and
.".q video .
.ip $=e
contains the Content-Transfer-Encodings that can be 8(->7 bit encoded.
It is predefined to contain
.q 7bit ,
.q 8bit ,
and
.q binary .
.ip $=k
set to be the same as
.b $k ,
that is, the UUCP node name.
.ip $=m
set to the set of domains by which this host is known,
initially just
.b $m .
.ip $=n
can be set to the set of MIME body types
that can never be eight to seven bit encoded.
It defaults to
.q multipart/signed .
Message types
.q message/*
and
.q multipart/*
are never encoded directly.
Multipart messages are always handled recursively.
The handling of message/* messages
are controlled by class
.b $=s .
.ip $=q
A set of Content-Types that will never be encoded as base64
(if they have to be encoded, they will be encoded as quoted-printable).
It can have primary types
(e.g.,
.q text )
or full types
(such as
.q text/plain ).
The class is initialized to have
.q text/plain
only.
.ip $=s
contains the set of subtypes of message that can be treated recursively.
By default it contains only
.q rfc822 .
Other
.q message/*
types cannot be 8(->7 bit encoded.
If a message containing eight bit data is sent to a seven bit host,
and that message cannot be encoded into seven bits,
it will be stripped to 7 bits.
.ip $=t
set to the set of trusted users by the
.b T
configuration line.
If you want to read trusted users from a file, use
.b Ft c
.i /file/name .
.ip $=w
set to be the set of all names
this host is known by.
This can be used to match local hostnames.
.ip $={persistentMacros}
set to the macros would should be saved across queue runs.
Care should be taken when adding macro names to this class.
.pp
.i Sendmail
can be compiled to allow a
.i scanf (3)
string on the
.b F
line.
This lets you do simplistic parsing of text files.
For example, to read all the user names in your system
.i /etc/passwd
file into a class, use
.(b
FL/etc/passwd %[^:]
.)b
which reads every line up to the first colon.
.sh 2 "M *- Define Mailer"
.pp
Programs and interfaces to mailers
are defined in this line.
The format is:
.(b F
.b M c
.i name ,
{c
.i field =c
.i value |}*
.)b
where
.i name
is the name of the mailer
(used internally only)
and the
.q field=name
pairs define attributes of the mailer.
Fields are:
.(b
.ta 1i