I've worked on
sendmail for many years,
and many employers have been remarkably patient
about letting me work on a large project
that was not part of my official job.
This includes time on the INGRES Project at
the University of California at Berkeley,
at Britton Lee,
and again on the Mammoth and Titan Projects at Berkeley.
Much of the second wave of improvements
resulting in version 8.1
should be credited to Bryan Costales of the
International Computer Science Institute.
As he passed me drafts of his book on
sendmail I was inspired to start working on things again.
Bryan was also available to bounce ideas off of.
Gregory Neil Shapiro
of Worcester Polytechnic Institute
has become instrumental in all phases of
sendmail support and development,
and was largely responsible for getting versions 8.8 and 8.9
out the door.
Many, many people contributed chunks of code and ideas to
sendmail. It has proven to be a group network effort.
Version 8 in particular was a group project.
The following people and organizations made notable contributions:
I apologize for anyone I have omitted, misspelled, misattributed, or
At this point, I suspect that at least a hundred people
have contributed code,
and many more have contributed ideas, comments, and encouragement.
I've tried to list them in the RELEASE_NOTES in the distribution directory.
I appreciate their contribution as well.
- Claus Assmann
John Beck, Hewlett-Packard & Sun Microsystems
Keith Bostic, CSRG, University of California, Berkeley
Andrew Cheng, Sun Microsystems
Michael J. Corrigan, University of California, San Diego
Bryan Costales, International Computer Science Institute & InfoBeat
Pär (Pell) Emanuelsson
Craig Everhart, Transarc Corporation
Per Hedeland, Ericsson
Tom Ivar Helbekkmo, Norwegian School of Economics
Kari Hurtta, Finnish Meteorological Institute
Allan E. Johannesen, WPI
Jonathan Kamens, OpenVision Technologies, Inc.
Takahiro Kanbe, Fuji Xerox Information Systems Co., Ltd.
Brian Kantor, University of California, San Diego
John Kennedy, Cal State University, Chico
Murray S. Kucherawy, HookUp Communication Corp.
Bruce Lilly, Sony U.S.
Motonori Nakamura, Ritsumeikan University & Kyoto University
John Gardiner Myers, Carnegie Mellon University
Neil Rickert, Northern Illinois University
Gregory Neil Shapiro, WPI
Eric Schnoebelen, Convex Computer Corp.
Eric Wassenaar, National Institute for Nuclear and High Energy Physics, Amsterdam
Randall Winchester, University of Maryland
Christophe Wolfhugel, Pasteur Institute & Herve Schauer Consultants (Paris)
Special thanks are reserved for Michael Corrigan and Christophe Wolfhugel,
who besides being wonderful guinea pigs and contributors
have also consented to be added to the ``sendmail@Sendmail.ORG'' list
and, by answering the bulk of the questions sent to that list,
have freed me up to do other work.
Arguments must be presented with flags before addresses.
The flags are:
- Select an alternative .cf file which is either
-Ac. By default the .cf file is chosen based on the operation mode.
-t it is
submit.cf if it exists, for all others it is
- Set operation mode to
x. Operation modes are:
m Deliver mail (default)
s Speak SMTP on input side
a* ``Arpanet'' mode (get envelope sender information from header)
d Run as a daemon in background
D Run as a daemon in foreground
t Run in test mode
v Just verify addresses, don't collect or deliver
i Initialize the alias database
p Print the mail queue
P Print overview over the mail queue (requires shared memory)
h Print the persistent host status database
H Purge expired entries from the persistent host status database
- Indicate body type.
- Use a different configuration file.
Sendmail runs as the invoking user (rather than root)
when this flag is specified.
- Set debugging level.
- -f addr
- The envelope sender address is set to
addr. This address may also be used in the From: header
if that header is missing during initial submission.
The envelope sender address is used as the recipient
for delivery status notifications
and may also appear in a Return-Path: header.
- Sets the full name of this user to
- When accepting messages via the command line,
indicate that they are for relay (gateway) submission.
sendmail may complain about syntactically invalid messages,
e.g., unqualified host names,
rather than fixing them when this flag is set.
sendmail will not do any canonicalization in this mode.
- -h cnt
- Sets the
hop count to
cnt. This represents the number of times this message has been processed
sendmail (to the extent that it is supported by the underlying networks).
Cnt is incremented during processing,
and if it reaches
sendmail throws away the message with an error.
- -L tag
- Sets the identifier used for syslog.
Note that this identifier is set
as early as possible.
sendmail may be used
if problems arise
before the command line arguments
- Don't do aliasing or forwarding.
- -N notifications
- Tag all addresses being sent as wanting the indicated
notifications, which consists of the word
NEVER or a comma-separated list of
DELAY for successful delivery,
and a message that is stuck in a queue somewhere.
The default is
- -r addr
- An obsolete form of
- Set option
x to the specified
value. These options are described in Section 5.6.
option to the specified
value (for long form option names).
These options are described in Section 5.6.
- Set macro
x to the specified
- Set the sending protocol.
Programs are encouraged to set this.
The protocol field can be in the form
host to set both the sending protocol and sending host.
-pUUCP:uunet sets the sending protocol to UUCP
and the sending host to uunet.
(Some existing programs use -oM to set the r and s macros;
this is equivalent to using -p.)
- Try to process the queued up mail.
If the time is given,
sendmail will start one or more processes to run through the queue(s) at the specified
time interval to deliver queued mail; otherwise, it only runs once.
Each of these processes acts on a workgroup.
These processes are also known as workgroup processes or WGP's for short.
Each workgroup is responsible for controlling the processing of one or
more queues; workgroups help manage the use of system resources by sendmail.
Each workgroup may have one or more children concurrently processing
queues depending on the setting of MaxQueueChildren.
- Similar to -q with a time argument,
except that instead of periodically starting WGP's
sendmail starts persistent WGP's
that alternate between processing queues and sleeping.
The sleep time is specified by the time argument; it defaults to 1 second,
except that a WGP always sleeps at least 5 seconds if their queues were
empty in the previous run.
Persistent processes are managed by a queue control process (QCP).
The QCP is the parent process of the WGP's.
Typically the QCP will be the sendmail daemon (when started with -bd or -bD)
or a special process (named Queue control) (when started without -bd or -bD).
If a persistent WGP ceases to be active for some reason
another WGP will be started by the QCP for the same workgroup
in most cases. When a persistent WGP has core dumped, the debug flag
no_persistent_restart is set or the specific persistent WGP has been
restarted too many times already then the WGP will not be started again
and a message will be logged to this effect.
To stop (SIGTERM) or restart (SIGHUP) persistent WGP's the appropriate
signal should be sent to the QCP. The QCP will propagate the signal to all of
the WGP's and if appropriate restart the persistent WGP's.
- Run the jobs in the queue group
- Run the queue once,
limiting the jobs to those matching
Xstring. The key letter
X can be
I to limit based on queue identifier,
R to limit based on recipient,
S to limit based on sender.
A particular queued job is accepted if one of the corresponding addresses
contains the indicated
string. The optional ! character negates the condition tested.
-qX flags are permitted,
with items with the same key letter
or'ed together, and items with different key letters
- -R ret
- What information you want returned if the message bounces;
ret can be
HDRS for headers only or
FULL for headers plus body.
This is a request only;
the other end is not required to honor the parameter.
HDRS is specified local bounces also return only the headers.
- Read the header for
Bcc: lines, and send to everyone listed in those lists.
Bcc: line will be deleted before sending.
Any addresses in the argument vector will be deleted
from the send list.
- -V envid
- The indicated
envid is passed with the envelope of the message
and returned if the message bounces.
- -X logfile
- Log all traffic in and out of
sendmail in the indicated
logfile for debugging mailer problems.
This produces a lot of data very quickly and should be used sparingly.
There are a number of options that may be specified as
These are the e, i, m, and v options.
the f option
may be specified as the
The DSN related options
-V have no effects on
sendmail running as daemon.
This appendix describes the format of the queue files.
These files live in a queue directory.
The individual qf, df, and xf files
may be stored in separate
if they are present in the queue directory.
All queue files have the name
YMDhmsNNppppp is the
id for this message
tt is a type.
The individual letters in the
- Encoded year
- Encoded month
- Encoded day
- Encoded hour
- Encoded minute
- Encoded second
- Encoded envelope number
- At least five decimal digits of the process ID
All files with the same id collectively define one message.
Due to the use of memory-buffered files,
some of these files may never appear on disk.
The types are:
- The queue control file.
This file contains the information necessary to process the job.
- The data file.
The message body (excluding the header) is kept in this file.
Sometimes the df file is not stored in the same directory as the qf file;
in this case,
the qf file contains a `d' record which names the queue directory
that contains the df file.
- A temporary file.
This is an image of the
qf file when it is being rebuilt.
It should be renamed to a
qf file very quickly.
- A transcript file,
existing during the life of a session
showing everything that happens
during that session.
Sometimes the xf file must be generated before a queue group has been selected;
in this case,
the xf file will be stored in a directory of the default queue group.
qf file is structured as a series of lines
each beginning with a code letter.
The lines are as follows:
- The version number of the queue file format,
used to allow new
sendmail binaries to read queue files created by older versions.
Defaults to version zero.
Must be the first line of the file if present.
For 8.12 the version number is 6.
- The information given by the AUTH= parameter of the
MAIL FROM: command or $f@$j
if sendmail has been called directly.
- A header definition.
There may be any number of these lines.
The order is important:
they represent the order in the final message.
These use the same syntax
as header definitions in the configuration file.
- The controlling address.
The syntax is
localuser:aliasname. Recipient addresses following this line
will be flagged so that deliveries will be run as the
localuser (a user name from the /etc/passwd file);
aliasname is the name of the alias that expanded to this address
(used for printing messages).
- The ``original recipient'',
specified by the ORCPT= field in an ESMTP transaction.
Used exclusively for Delivery Status Notifications.
It applies only to the following `R' line.
- The ``final recipient''
used for Delivery Status Notifications.
It applies only to the following `R' line.
- A recipient address.
This will normally be completely aliased,
but is actually realiased when the job is processed.
There will be one line for each recipient.
Version 1 qf files
also include a leading colon-terminated list of flags,
which can be
`S' to return a message on successful final delivery,
`F' to return a message on failure,
`D' to return a message if the message is delayed,
`B' to indicate that the body should be returned,
`N' to suppress returning the body,
`P' to declare this as a ``primary'' (command line or SMTP-session) address.
- The sender address.
There may only be one of these lines.
- The job creation time.
This is used to compute when to time out the job.
- The current message priority.
This is used to order the queue.
Higher numbers mean lower priorities.
The priority changes
as the message sits in the queue.
The initial priority depends on the message class
and the size of the message.
- A message.
This line is printed by the
and is generally used to store status information.
It can contain any text.
- Flag bits, represented as one letter per flag.
Defined flag bits are
r indicating that this is a response message
w indicating that a warning message has been sent
announcing that the mail has been delayed.
- The total number of delivery attempts.
- The time (as seconds since January 1, 1970)
of the last delivery attempt.
- If the df file is in a different directory than the qf file,
then a `d' record is present,
specifying the directory in which the df file resides.
- The i-number of the data file;
this can be used to recover your mail queue
after a disastrous disk crash.
- A macro definition.
The values of certain macros
are passed through to the queue run phase.
- The body type.
The remainder of the line is a text string defining the body type.
If this field is missing,
the body type is assumed to be
undefined and no special processing is attempted.
Legal values are
- The original envelope id (from the ESMTP transaction).
For Deliver Status Notifications only.
As an example,
the following is a queue file sent to
the person who sent the message,
the submission time
(in seconds since January 1, 1970),
the message priority,
the message class,
and the headers for the message.
H??Received: by vangogh.CS.Berkeley.EDU (5.108/2.7) id AAA06703;
Fri, 17 Jul 1992 00:28:55 -0700
H??Received: from mail.CS.Berkeley.EDU by vangogh.CS.Berkeley.EDU (5.108/2.7)
id AAA06698; Fri, 17 Jul 1992 00:28:54 -0700
H??Received: from [126.96.36.199] by mail.CS.Berkeley.EDU (5.96/2.5)
id AA22777; Fri, 17 Jul 1992 03:29:14 -0400
H??Received: by foo.bar.baz.de (5.57/Ultrix3.0-C)
id AA22757; Fri, 17 Jul 1992 09:31:25 GMT
H?F?From: firstname.lastname@example.org (Eric Allman)
H?x?Full-name: Eric Allman
H??Subject: this is an example message
This is a summary of the support files
sendmail creates or generates.
Many of these can be changed by editing the sendmail.cf file;
check there to find the actual pathnames.
- The binary of
- A link to /usr/sbin/sendmail;
causes the alias database to be rebuilt.
Running this program is completely equivalent to giving
- Prints a listing of the mail queue.
This program is equivalent to using the
-bp flag to
- The configuration file,
in textual form.
- The SMTP help file.
- A statistics file; need not be present.
- Created in daemon mode;
it contains the process id of the current SMTP daemon.
If you use this in scripts;
use ``head -1'' to get just the first line;
the second line contains the command line used to invoke the daemon,
and later versions of
sendmail may add more information to subsequent lines.
- The textual version of the alias file.
- The alias file in
- The alias file in
- The directory in which the mail queue(s)
and temporary files reside.
- Control (queue) files for messages.
- Data files.
- Temporary versions of the qf files,
used during queue file rebuild.
- A transcript of the current session.
TABLE OF CONTENTS
[Contents] [Previous] [Next]
This document was translated by troff2html v0.21 on October 10, 2001.
Please send comments to:
<ca at sendmail.org>