ACKNOWLEDGEMENTS

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 Worchester 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 made notable contributions:

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.
Karl London
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:

-bx

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

-Btype

Indicate body type.

-Cfile

Use a different configuration file. Sendmail runs as the invoking user (rather than root) when this flag is specified.

-dlevel

Set debugging level.

-f addr

The sender's machine address is addr.

-F\

Sets the full name of this user to name.

-h cnt

Sets the hop count to cnt. This represents the number of times this message has been processed by sendmail (to the extent that it is supported by the underlying networks). Cnt is incremented during processing, and if it reaches MAXHOP (currently 30) sendmail throws away the message with an error.

-n

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 SUCCESS, FAILURE, and DELAY for successful delivery, failure, and a message that is stuck in a queue somewhere. The default is FAILURE,DELAY.

-r addr

An obsolete form of -f.

-oxvalue

Set option x to the specified value. These options are described in Section 5.6.

-Ooption=value

Set option to the specified value (for long form option names). These options are described in Section 5.6.

-Mxvalue

Set macro x to the specified value.

-pprotocol

Set the sending protocol. Programs are encouraged to set this. The protocol field can be in the form protocol : host to set both the sending protocol and sending host. For example, -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.)

-qtime

Try to process the queued up mail. If the time is given, a sendmail will run through the queue at the specified interval to deliver queued mail; otherwise, it only runs once.

-qXstring

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, or S to limit based on sender. A particular queued job is accepted if one of the corresponding addresses contains the indicated string. Multiple -qX flags are permitted, with items with the same key letter or'ed together, and items with different key letters and'ed together.

-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.

-t

Read the header for To:, Cc:, and Bcc: lines, and send to everyone listed in those lists. The Bcc: line will be deleted before sending. Any addresses in the argument vector will be deleted from the send list.

-U

Indicate that this is an initial User Agent submission. In future releases, sendmail may complain about syntactically invalid messages rather than fixing them when this flag is not set.

-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 primitive flags. These are the e, i, m, and v options. Also, the f option may be specified as the -s flag.

This appendix describes the format of the queue files. These files live in the directory defined by the Q option in the sendmail.cf file, usually /var/spool/mqueue or /usr/spool/mqueue.

All queue files have the name xfAAA99999 where AAA99999 is the id for this message and the x is a type. The first letter of the id encodes the hour of the day that the message was received by the system (with A being the hour between midnight and 1:00AM). All files with the same id collectively define one message.

The types are:

d

The data file. The message body (excluding the header) is kept in this file.

q

The queue control file. This file contains the information necessary to process the job.

t

A temporary file. These are an image of the qf file when it is being rebuilt. It should be renamed to a qf file very quickly.

x

A transcript file, existing during the life of a session showing everything that happens during that session.

The qf file is structured as a series of lines each beginning with a code letter. The lines are as follows:

V

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.

H

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.

C

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).

Q

The ``original recipient'', specified by the ORCPT= field in an ESMTP transaction. Used exclusively for Delivery Status Notifications. It applies only to the immediately following `R' line.

R

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, and `P' to declare this as a ``primary'' (command line or SMTP-session) address.

S

The sender address. There may only be one of these lines.

T

The job creation time. This is used to compute when to time out the job.

P

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.

M

A message. This line is printed by the mailq command, and is generally used to store status information. It can contain any text.

F

Flag bits, represented as one letter per flag. Defined flag bits are r indicating that this is a response message and w indicating that a warning message has been sent announcing that the mail has been delayed.

N

The total number of delivery attempts.

K

The time (as seconds since January 1, 1970) of the last delivery attempt.

I

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 (as of this writing, only $r and $s) are passed through to the queue run phase.

B

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 7BIT and 8BITMIME.

O

The original MTS value (from the ESMTP transaction). For Deliver Status Notifications only.

Z

The original envelope id (from the ESMTP transaction). For Deliver Status Notifications only.

As an example, the following is a queue file sent to eric@mammoth.Berkeley.EDU and bostic@okeeffe.CS.Berkeley.EDU [30]:

P835771
T404261372
Seric
Ceric:sendmail@vangogh.CS.Berkeley.EDU
Reric@mammoth.Berkeley.EDU
Rbostic@okeeffe.CS.Berkeley.EDU
H?P?Return-path: <owner-sendmail@vangogh.CS.Berkeley.EDU>
HReceived: by vangogh.CS.Berkeley.EDU (5.108/2.7) id AAA06703;
Fri, 17 Jul 1992 00:28:55 -0700
HReceived: from mail.CS.Berkeley.EDU by vangogh.CS.Berkeley.EDU (5.108/2.7)
id AAA06698; Fri, 17 Jul 1992 00:28:54 -0700
HReceived: from [128.32.31.21] by mail.CS.Berkeley.EDU (5.96/2.5)
id AA22777; Fri, 17 Jul 1992 03:29:14 -0400
HReceived: by foo.bar.baz.de (5.57/Ultrix3.0-C)
id AA22757; Fri, 17 Jul 1992 09:31:25 GMT
H?F?From: eric@foo.bar.baz.de (Eric Allman)
H?x?Full-name: Eric Allman
HMessage-id: <9207170931.AA22757@foo.bar.baz.de>
HTo: sendmail@vangogh.CS.Berkeley.EDU
HSubject: this is an example message

This is a summary of the support files that sendmail creates or generates. Many of these can be changed by editing the sendmail.cf file; check there to find the actual pathnames.

/usr/sbin/sendmail

The binary of sendmail.

/usr/bin/newaliases

A link to /usr/sbin/sendmail; causes the alias database to be rebuilt. Running this program is completely equivalent to giving sendmail the -bi flag.

/usr/bin/mailq

Prints a listing of the mail queue. This program is equivalent to using the -bp flag to sendmail.

/etc/sendmail.cf

The configuration file, in textual form.

/usr/lib/sendmail.hf

The SMTP help file.

/etc/sendmail.st

A statistics file; need not be present.

/etc/sendmail.pid

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.

/etc/aliases

The textual version of the alias file.

/etc/aliases.db

The alias file in hash(3) format.

/etc/aliases.{pag,dir}

The alias file in ndbm(3) format.

/var/spool/mqueue

The directory in which the mail queue and temporary files reside.

/var/spool/mqueue/qf*

Control (queue) files for messages.

/var/spool/mqueue/df*

Data files.

/var/spool/mqueue/tf*

Temporary versions of the qf files, used during queue file rebuild.

/var/spool/mqueue/xf*

A transcript of the current session. \{\