.nr DR 1 \" this is a draft copy
.if \n(DR .fo '\*-DRAFT\*-'\*(td'\*-DRAFT\*-'
SENDMAIL \*- An Internet Mail Router
Berkeley, California 94720
.if \n(DR Please do not distribute this version without permission
\(dgAuthor's current address:
1919 Addison Street, Suite 105.
Berkeley, California 94704.
implements a general internetwork mail routing facility,
featuring aliasing and forwarding,
automatic routing to network gateways,
and flexible configuration.
In the early days of computer networking,
the problems of identification and communication
were quite simple by today's standards.
and resources could be identified
with a host-resource pair;
the mail system could refer to users
using a host-username pair.
Host names and numbers had to be administered by a central authority,
but usernames could be assigned locally to each host.
One early example is the ARPANET.
However, access to the ARPANET is limited,
and the connection cost is high.
Many alternative networks appeared,
such as the Berkeley Network,
Each network defined its own standards
for resource identification.
Certain special cases could be handled trivially
as when one computer hung off another by a link,
or by providing network names that appeared local to hosts
as with the Ethernet at Xerox PARC.
Internet topology became more complex with time.
and the rapid expansion of networks
created a serious database update problem.
Since all the address syntaxes were created arbitrarily,
considerable confusion reigned.
Some networks required point-to-point routing,
which simplifies the database update problem
since only adjacent hosts must be entered
while others used end-to-end routing.
Some networks used a left-associative syntax
and others used a right-associative syntax:
ambiguity raised its ugly head.
Internet proposals came to the rescue.
Basically, these proposed expanding the address pairs
comprised of network-host-resource.
Network numbers would be universally agreed upon,
and hosts could be assigned in the old way
But these proposals all tended to be far-reaching
and fundamentally incompatible with the old networks.
Protocols and proposals met to do battle.
And there was the issue of assigning network numbers:
there had to be a central clearing house,
and any networks that might ever touch
had to be given their very own number.
Naturally, not everyone who thought they deserved a number
Which brings us to today.
Although it will be nice when everyone everywhere
has a unique network number,
it cannot be expected very soon.
The old, stupid networks take time to die,
and bureaucratic inertia is still the rule.
is intended to help bridge the gap
between the totally ad hoc world
of networks that know nothing of each other
and the clean, tightly-coupled world
of unique network numbers.
It uses old arbitrary address syntaxes
and resolves ambiguities using heuristics
specified by the system administrator
who creates the configuration file.
It helps guide the conversion of message formats
between disparate networks.
is glue that holds the world together
until the new world is ready to be inhabited.
However, it is not unreasonable to expect
escrow to take several years to close on this
Section 1 discusses the design goals for
Section 2 gives an overview of the basic functions of the system.
details of usage are discussed.
A detailed description of the configuration file
including a walkthrough of a specific configuration file.
to other internet mail routers,
a previous incarnation of a UNIX internetwork mail router.
was written relatively quickly.
The first version could only parse addresses based on single
characters embedded in the address,
and had only limited aliasing;
automatic forwarding of messages to another gateway and other features
Compatibility with the existing mail system,
including Bell version 6 mail,
Reliability, in the sense of guaranteeing
that every message is correctly delivered
or at least brought to the attention of a human
no message should ever be completely lost.
This was considered essential
because of the emphasis on mail in our environment.
This turned out to be one of the hardest goals to satisfy,
especially in the face of the many anomalous message formats
produced by various ARPANET sites.
certain sites generate incorrect from addresses
which caused error message loops.
Some hosts use blanks in names,
which created problems with
UNIX mail programs that assume that an address
And at least one person lists his address as
.q "From: the TTY of ..." ,
field with his real address.
the obscure aspects of the ARPANET mail protocol
are difficult to support,
But even obeying the standard is insufficient.
WHARTON changes our host name from
which confused error processing.
Degenerate cases such as this
must be handled gracefully.
There were certain other non-goals in
These resulted from the expectation that
it would only be used at Berkeley,
and probably only at a few sites at Berkeley.
It was fair game to compile configuration information
even to assume that every host was running BerkNet.
The problem of multiple gateways to a single network
all UUCP mail was sent to a single gateway host.
Berkeley has at least three UUCP gateway hosts.
No attempt was made to reduce the volume of mail across a network link
by sending only one copy of a message
to multiple recipients on the same host.
Besides the difficulty of doing this,
we failed to appreciate how much volume there would be.
one of our gateways processed a message approximately
during peak hours, many of which were duplicates.
Existing software to do actual delivery
should be used whenever possible.
This resulted as much from political and practical considerations
This resulted in an architecture illustrated in figure 1.
+---------+ +---------+ +---------+
| sender1 | | sender2 | | sender3 |
+---------+ +---------+ +---------+
+----------+ + +----------+
+----------+ + +----------+
+---------+ +---------+ +---------+
| mailer1 | | mailer2 | | mailer3 |
+---------+ +---------+ +---------+
Figure 1 \*- Delivermail System Structure.
The user interacts with a mail generating and sending program.
When the mail is created,
which routes the message to the correct mailer(s).
Since some of the senders may be network servers
and some of the mailers may be network users,
may be used as an internet mail gateway.
Time was less of a constraint,
but not reimplementing basic mailers
has proven to be a wise move in many ways.
many internet mailers deliver local mail directly.
but builds in the design decisions
and makes it difficult to concentrate
should operate in more complex environments,
connections to a single network type
(such as with multiple UUCP or Ether nets
requiring that the contents of an address
in order to determine the gateway to use.
the ARPANET is bringing up a new protocol
called TCP to replace the old NCP protocol.
No host at Berkeley runs both TCP and NCP,
so it is necessary to look at the ARPANET host name
to determine whether to route mail to an NCP gateway
Configuration should not be compiled into the code.
A single binary should be able to run as is at any site
(modulo such basic changes as the CPU type or the operating system).
We have found this seemingly unimportant goal
to be critical in real life.
Besides the simple problems that occur when any program gets recompiled
in a different environment,
with anything that they will be recompiling anyway.
only knows about one alias file
and per-user forwarding is unsupported.
Berkeley is a sufficiently relaxed environment
that the system alias file can be writable by everyone,
but other environments are not so lax.
must be able to let various groups maintain their own mailing lists,
and let individuals specify their own forwarding,
without writing the system alias file.
Each user should be able to specify the mailer to execute
to process mail being delivered for them.
This allows users who are using specialized mailers
that want to use a different format to build their environment
without changing the system,
and allows specialized functions
Network traffic should be minimized
by batching addresses to a single host where possible,
without assistance by the user.
.sh 2 "System Organization"
neither interfaces with the user
nor does actual mail delivery.
generated by a user interface program (UIP)
edits the message as required by the destination network,
and calls appropriate mailers
to do mail delivery or queueing for network transmission\**.
\**except when mailing to a file,
does the delivery directly.
This discipline allows the insertion of new mailers
resembles the Message Processing Module (MPM)
.sh 2 "Operational Description"
When an agent wants to send a message,
it does a normal program call to
The arguments it passes include flags giving options
and a list of addresses of intended recipients.
It then writes the message to be sent to the standard input
delivers the message if possible,
saving a copy of it if there were errors,
and returns an exit status code
telling what (if anything) went wrong.
The message should have a header at the beginning.
The header is formatted as a series of lines
Field-value can be split across lines by starting the following
lines with a space or a tab.
The header is separated from the body of the message
No formatting requirements are imposed on the message
except that they must be lines of text
(i.e., binary data is not allowed).
.sh 3 "Argument processing and address parsing"
and flag arguments processed.
The remaining arguments are
parsed in turn as addresses,
and a list of recipients is created.
Aliases are expanded at this step.
As much validation as possible of the addresses
syntax is checked, and local addresses are verified,
but detailed checking of host names and addresses
is deferred until delivery.
Forwarding is also performed
as the local addresses are verified.
to the recipient list after parsing.
When a name is aliased or forwarded,
the old name is retained in the list,
and a flag is set in the address header
that tells the delivery phase
to ignore this recipient.
This list is kept without duplicates,
and eliminating people receiving two copies of a message,
as might occur if a person were in two groups.
.sh 3 "Message collection"
then collects the message from the standard input.
The message header is parsed at this point.
The header is stored in memory,
and the body of the message is saved
The message is still collected even if no addresses were valid
to simplify program interface.
The message will be returned with an error.
For each unique mailer and host in the send list,
calls the appropriate mailer.
Each mailer invocation sends to all users receiving the message on one host.
Mailers that only accept one user at a time
The message is sent to the mailer
(which must read its standard input)
prepended by a customized header.
The mailer exit status code is caught and checked,
and a suitable error message given as appropriate.
The exit code must conform to a system standard
.q "Service unavailable" )
.sh 3 "Queueing for retransmission"
If the mailer returned an error status that
indicated that it might be able to handle the mail later,
will queue the mail and try again later.
If errors occurred during processing,
returns the message to the sender for retransmission.
The letter can be mailed back
in the sender's home directory\**.
\**Obviously, if the site giving the error is not the originating
site, the only reasonable option is to mail back to the sender.
Also, there are many more error disposition options,
but they only effect the error message \*- the
function is always handled in one of these two ways.
.sh 2 "Configuration File"
Almost all configuration information is read at runtime
(defining the value of macros used internally),
(telling sendmail the format of header lines that it will process specially,
i.e., lines that it will add or reformat),
(giving information such as the location and characteristics
and address rewriting rules
(a limited production system to rewrite addresses
which is used to effectively parse the addresses).
Macros can be used in three ways.
unstructured textual information
will use to identify itself in error messages.
Other macros transmit information from
to the configuration file
for use in creating other fields
(such as argument vectors to mailers);
e.g., the name of the sender,
Other macros are unused internally,
and can be used as shorthand in the configuration file.
.sh 3 "Header declarations"
Header declarations inform
of the format of known header lines.
Knowledge of a few header lines
will be automatically inserted
if they don't exist in the incoming message.
Certain headers are suppressed by some mailers.
.sh 3 "Mailer declarations"
of the various mailers available to it.
The definition specifies the internal name of the mailer,
the pathname of the program to call,
some flags associated with the mailer,
and an argument vector to be used on the call;
this vector is macro expanded before use.
.sh 3 "Address rewriting rules"
The heart of address parsing in
is a set of rewriting rules.
These are an ordered list of pattern-replacement rules,
(somewhat like a production system,
except that order is critical),
which are applied to each address.
The address is rewritten textually until it is either rewritten
into a special canonical form
such as (arpanet, usc-isif, postel)
the rule is reapplied until it fails.
.sh 2 "Message Header Editing"
Certain editing of the message header
Header lines can be inserted
under control of the configuration file.
Some lines can be merged;
line can be merged under certain circumstances.
.sh 1 "USAGE AND IMPLEMENTATION"
Arguments may be flags and addresses.
The flag arguments are described in Appendix A.
Following flag arguments,
address arguments may be given,
unless we are running in SMTP mode.
These follow the syntax in RFC733
Anything in parentheses is thrown away
Anything in angle brackets (\c
This implements the ARPANET standard that addresses of the form
username <machine-address>
will send to the electronic
backslashes quote characters.
Backslashes are more powerful
in that they will cause otherwise equivalent phrases
to compare differently \*- for example,
is different from either of them.
The rewriting rules control remaining parsing.
(Disclaimer: some special processing is done
after rewriting local names; see below.)
Parentheses, angle brackets, and double quotes
must be properly balanced and nested.
.sh 2 "Simple Mail Transfer Protocol"
The Simple Mail Transfer Protocol
can be used on input by specifying the
to use a verbose protocol on its standard input and output
which is useful over certain types of networks.
no addresses are passed on the command line;
these are sent over the standard input instead.
.sh 2 "Mail to Files and Programs"
Files and programs are legitimate message recipients.
Files provide archival storage of messages,
useful for project administration and history.
Programs are useful as recipients in a variety of situations,
as a public repository of systems messages
Any address passing through the initial parsing algorithm
(i.e, not appearing to be a valid address for another mailer)
is scanned for two special cases.
If prefixed by a vertical bar (\c
the rest of the address is processed as a shell command.
If the user name begins with a slash mark (\c
the name is used as a file name,
Files that have setuid or setgid bits set
have those bits honored if
.sh 2 "Aliasing, Forwarding, Inclusion"
reroutes mail three ways.
Aliasing applies system wide.
Forwarding allows each user to reroute incoming mail
destined for that account.
to read a file for a list of addresses,
in conjunction with aliasing.
Aliasing maps names to address lists using a system-wide file.
This file is inverted to speed access.
Only names that parse as local
this guarantees a unique key.
users that are local and valid
are checked for the existence of a
file in their home directory.
but rather to the list of users in that file.
The expectation is that this will normally
and the use will be for network mail forwarding.
Forwarding also permits a user to specify a private incoming mailer.
"\^|\|/usr/local/newmail myname"
will use a different incoming mailer.
Inclusion is specified in ARPANET syntax:
An address of this form reads the file specified by
and sends to all users listed in that file.
to support direct use of this feature,
but rather to use this as a subset of aliasing.
project: :include:/usr/project/userlist
is a method of letting a project maintain a mailing list
without interaction with the system administration,
even if the alias file is protected.
It is not necessary to rebuild the alias database
when a :include: list is changed.
the recipient list is stored as one list per mailer.
Each mailer list can be scanned trivially
and mail to each host picked out to implement message batching.
Each address is marked as it is sent,
so rescanning the list is safe;
this makes sending to mailers that can only accept one user easy.
An argument list is built as the scan proceeds.
Mail to files is detected during the scan of the send list.
When an argument vector is built,
creates a pipe and subprocess for the mailer.
which makes the per-mailer changes to the header
and sends the result to the mailer;
a different editing function is used for sending error messages
which prepends the error information.
The exit status from the mailer is collected
after the message is sent,
and a diagnostic is printed if appropriate.
If any mail is rejected by the mailer,
a flag is set to invoke the return-to-sender function
after all delivery completes.
defines a set of standard exit status codes
that should be returned by mailers.
These are in turn returned by
A control file is used to describe the recipients to be sent to
and various other parameters.
.sh 2 "Interaction With Other Mailers"
Two examples of how network-specific work is passed to other programs
are the incoming UUCP mailer
and the outgoing ARPANET mailer.
.sh 3 "Incoming UUCP mail"
Mail coming in from the UUCP network
is not guaranteed to have a normal header line,
nor will an argument be passed telling who it is from\**.
it is impossible to verify UUCP sender addresses.
UUCP mail calls the program
program has been modified here to do the special-purpose parsing
necessary to decode UUCP headers
and turn them into a normal UUCP address;
this address is then passed to
.sh 3 "Outgoing ARPANET mail"
The ARPANET imposes many standards that
does not care to enforce.
an arpanet sitename must be on
Certain UNIX sites like to use
which must be translated.
The outgoing ARPANET mailer makes these transformations
before passing the message to the network.
Configuration is controlled primarily by the file
.i /usr/lib/sendmail.cf .
should not need to be recomplied except
To change operating systems
To remove or insert the DBM
To change ARPANET reply codes.
To add headers requiring special processing.
Adding mailers or changing parsing
does not require recompilation.
If the mail is being sent by a local user,
exists in the sender's home directory,
that file is read as a configuration file
after the system configuration file.
The primary use of this is to add header lines.
This could also be used to adjust the full name by
DxEric Allman in Outer Space
.sh 2 "Configuration File Description"
The configuration file is formatted
as a series of text lines,
each beginning with a character describing its semantics.
Blank lines and lines beginning with a sharp sign
F define word class from file
See figure 2 for an example configuration file.
Please note that this is intended as an example only.
##### sendmail configuration file
### local hosts on various nets
# delimiter (operator) characters
H\&Message-Id: <$t.$p.$B@$A>
# list of local host names
# berknet hosts on the arpanet
.ta \w'M\&local 'u +\w'/usr/net/bin/sendberkmail 'u +\w'rlsAmn 'u +\w'$f@$A 'u
M\&local /bin/mail rlsAmn $f ...local\&mail -d $u
M\&prog /bin/csh lA $f ...prog\&mail -fc $u
M\&berk /usr/net/bin/sendberkmail fxs $B:$f ...berk\&mail -m $h -h $c -t $u
M\&arpa /usr/lib/mailers/arpa sAu $f@$A ...arpa\&mail $f $h $u
M\&uucp /usr/bin/uux rsDxmU $U!$f ...uucp\&mail - $h!rmail ($u)
.ta \w'R\&CSVAX:$-h!$+u 'u +\w'$#berk$@ing70$:$+u@$+h 'u
R\&$-.$+ $1:$2 change "." to ":"
R\&$=C:$+@$- $2@$3 delete ing70: on arpanet addresses
R\&$+@$=A ing70:$1 delete local arpa hosts
R\&$+@$- $#berk$@ing70$:$1@$2 send arpa mail to ing70
R\&$+^$+ $1!$2 change "^" to "!"
R\&$-!$=U!$+ csvax:$3 delete uucp loops through csvax
R\&$-!$+ csvax:$1!$2 send uucp mail to csvax
R\&$-:$-:$+ $2:$3 delete multiple berk hosts
R\&$=B:$+ $2 delete local berk hosts
R\&$-:$+ $#berk$@$1$:$2 resolve berk mail
R\&$+ $#local$:$1 resolve local mail
### rewriting rules for from host
R\&ing70:$+@$- $1@$2 arpanet mail is automatic
R\&CSVAX:$-!$+ $1!$2 uucp mail is automatic
### rewriting rules for translated sender
R\&$-x:$-:$+ $2:$3 delete multiple berknet hosts
Figure 2. Sample configuration file.
.sh 3 "D \*- define macro"
This line defines a macro
with the single character name
Macros can be interpolated using the escape
all upper-case letters are unused by
and may be used freely by the user;
all other names are reserved for use by sendmail.
$l UNIX-style \*(lqFrom\*(rq line.
$n My address in error messages.
$o \*(lqOperators\*(rq in addresses.
$q How to write addresses in headers.
wants to insert a UNIX-style
This typically expands to something like:
From sally Wed Aug 12 09:15:13 1981
macro is used as the name of this process
when error messages are being mailed back.
it is wise to include an alias
so that mail to this address will be sent to root.
macro defines the characters
that will separate words when addresses are being broken up.
Each of these becomes a word by itself when scanned.
Blanks and tabs are built-in separators
i.e., are not turned into words.
Ing70: ZRM @ MIT-MC SRI-KL
Is broken up into the six words:
Ing70, :, ZRM, @, MIT-MC, SRI-KL
assuming that colon and at-sign are operators
macro gives the format for addresses
as they should appear in headers.
This will normally be something like:
Which will give the translated from address
followed by the full name if known.
A number of macros are defined by
$a The \*(lqDate:\*(rq line date in ARPANET format.
$b The current date in ARPANET format.
$d The date in UNIX (ctime) format.
$f The sender's (from) address.
$g The sender's address translated by the mailer.
$h The host of the recipient.
$p The process id of sendmail in decimal.
$t The time in seconds in decimal.
$u The user part of the recipient.
$v The version number of sendmail.
$x The full name of the sender.
$y The id of the sender's terminal.
$z The home directory of the recipient.
There are three types of dates that can be used.
macros are in ARPANET format;
is a copy of the time extracted from the
field of the incoming message
is the current date and time \*- used for postmarks.
macro has the date in UNIX
this is extracted from the message if possible
and is otherwise the current date.
macro is the id of the sender
as originally determined;
when mailing to a specific person,
macro is the address of the sender
with respect to the receiver.
This only applies to the first step in the link.
sending to Ing70:drb@bbn-unix,
as above for the transfer to Ing70, but:
for transfer to the ARPANET\**.
\**When this is actually sent to the ARPANET,
The translation of the colon to a period is performed
by the mailer that queues ARPANET mail.
macro is set to the full name of the sender.
This can be determined in several ways.
It can be passed as a flag to
line in the header is the second option,
and the comment portion of the
and if the message is being originated locally,
the full name is looked up in the
macros get set to the user, host, and home directory
The host is only set if the user is not local,
and the home directory is only set if the user is local.
macros are used to create unique strings.
macro is set to the id of the terminal of the sender
some systems like to put this in the
macro is set to the version number of
and can be used in postmarks
A primitive conditional is available during macro expansion.
.sh 3 "H \*- define header"
line looks like a regular header line,
except that the field value is macro expanded
All headers mentioned in this way
are automatically inserted
except for headers mentioned in the compile-time
To get these fields the appropriate flag
for the receiving mailer.
in the sender's home directory is read and processed,
it is possible to add customized header lines.
the .mailcf consisting of:
will add that line to every outgoing message.
.sh 3 "M \*- define mailer"
This line is structured into fields
separated by white space (spaces or tabs).
The internal name of the mailer,
referred to in the rewriting rules.
The pathname of the program to execute for this mailer.
The flags for this mailer,
The macro string to become the
macro (translated sender)
The argument vector passed to the mailer
The flags are a series of characters:
but only if this is a network forward operation
the mailer will give an error
if the executing user does not have special permissions).
Don't print errors \*- the mailer will do it for us.
Don't reset your userid before calling the mailer.
This would be used in a secure environment where
This could be used to prevent
This option is suppressed in
(i.e., user-supplied, either on a
file in the home directory).
This mailer does not want a UNIX-style
so no host will be specified.
the mailer wants special local processing
Strip quote characters off of addresses
before calling the mailer.
This mailer can send to multiple users
Upper case should be preserved in user names.
Upper case should be preserved in host names.
This mailer is expensive,
and it may be desirable to limit usage.
The recipient addresses should be rewritten to be relative to the
receiver, rather than relative to the sender.
This is always done with sender addresses,
but should only be done on recipients
if the host you are sending to knows that it is being done.
Setting this flag makes it easy to do a
command in a user mail program
(since all that must be done is send to all addresses in the message header),
but user mail programs that try to rewrite the addresses
will be completely confused.
This mailer wants an ARPANET standard header
This mailer is a UUCP mailer that wants leading from lines
From sender <date> remote from sysname
instead of the more reasonable:
From sysname!sender <date>
A compilation flag must be on to include this code.
There should always be at least one flag,
since every message should include either a
.sh 3 "S \*- use rewriting set"
There are three sets of rewriting rules.
Set zero is used to rewrite recipient addresses.
Set one is used to rewrite sender addresses.
Set two is applied after evaluating the
i.e., after determining the from address for a particular mailer.
Set one can be used to eliminate implicit links.
if there exists a site on on the BerkNet called
which is an ARPANET gateway,
and we are on a site called
Rewriting set one can rewrite this as:
Set two is used to eliminate anomalies resulting from
a message received at Ing70 from mckusick on the CSVAX will
If this is then forwarded to IngVAX,
sendmail on Ing70 will rewrite the from address as:
From Ing70:CSVAX:mckusick
The extra host reference can be eliminated by ruleset two on Ing70.
When you change to a new set,
the previous content of that set is cleared.
.sh 3 "R \*- rewriting rule"
The rewriting rules drive the address parser.
The rewriting process is essentially textual.
the address to be rewritten is broken up into words.
Words are defined as strings of non-special characters
separated by white space or single special characters
the words are rewritten using simple pattern matching.
Words in the pattern match themselves
unless they begin with dollar sign.
The dollar escapes have the following meanings\**:
\**These dollar escapes have nothing to do with macro expansion.
$+ Match one or more words.
$=c Match any word in class c (see below).
The case of letters is ignored in pattern matching
(including class comparisons).
When a pattern (also called a left hand side or LHS)
the input is rewritten as defined by the right hand side (RHS).
Acceptable escapes in the RHS are:
$n Replace from corresponding match in LHS.
$#mailer Canonical mailer name.
$@host Canonical host name.
$:user Canonical user name.
The substitution from LHS to RHS is done by the index
of indefinite matches on the LHS.
Each pattern reexecutes until it fails.
As soon as the input resolves to a canonical name
.q "$#mailer$@host$:user" ),
the next pattern is tried.
if the mailer does not require a host.
causes the user part to be printed as an error.
.sh 3 "C \*- define word class"
There are twenty six word classes,
on the LHS of a rewriting rule
will match any of these words.
.sh 3 "F \*- define word class from file"
line except that it reads the contents of the class
string which should produce a single string.
.sh 2 "A Detailed Example"
We will now follow the configuration file
This example is from a version of the configuration file
for the IngVAX machine at Berkeley.
IngVAX had no interesting network connections.
Ing70 had an ARPANET connection,
and CSVAX had a UUCP connection.
All of these machines were tied together via BerkNet.
.sh 3 "Macro definitions"
The first three macros are for convenience only,
and are used to define the local host names
on the ARPANET, BerkNet, and the UUCP net
when error messages are sent.
defines what the first line
of a message in UNIX format looks like,
in this case the version 7 standard of:
From sender-name time-of-submission
tells what characters will be distinct from names
dot and colon will be used
to distinguish BerkNet addresses,
at sign for ARPANET addresses,
and exclamation point and caret for UUCP addresses.
.sh 3 "Header definitions"
H\&Message-Id: <$t.$p.$B@$A>
that may be added to a message.
is just the ARPANET idea of the date.
line is the translated version of the sender,
followed by the sender's full name if known.
field is used to transmit the sender's full name
these will normally be mutually exclusive.
field has the time and process id's concatenated
with the BerkNet and ARPANET addresses
is the date in ARPANET format;
in that it is always output as soon as the message enters
and hence indicates the time that the message first enters
.sh 3 "Name classifications"
These commands put the words
the valid names of this site on the ARPANET.
the local names on BerkNet.
the names of the site which has the ARPANET link,
are the UUCP names of our UUCP gateway,
The classes will be used in the patterns of the rewriting rules
.sh 3 "Mailer definitions"
.ta \w'M\&local 'u +\w'/usr/net/bin/sendberkmail 'u +\w'rlsAmn 'u +\w'$f@$A 'u
M\&local /bin/mail rlsAmn $f ...localmail -d $u
M\&prog /bin/csh lA $f ...progmail -fc $u
M\&berk /usr/net/bin/sendberkmail fxs $B:$f ...berkmail -m $h -h $c -t $u
M\&arpa /usr/lib/mailers/arpa sAu $f@$A ...arpamail $f $h $u
M\&uucp /usr/bin/uux rsDxmU $U!$f ...uucpmail - $h!rmail ($u)
Six mailers are known in the configuration file.
be entries for local and program mail.
quote characters are stripped before sending,
takes ARPANET standard headers,
can deliver to multiple recipients at once,
and does not want a UNIX-style
line since it will add one itself.
address is the same as the raw
since no network hops are made.
The argument vector has a program name,
which must be added to /bin/mail),
and the list of recipients \*- one recipient per argument.
Mail piped through programs
is interpreted by /bin/csh.
it can only deal with one user,
and it does want a UNIX-style
but is still local and still wants an ARPANET style header.
BerkNet mail is processed by
/usr/net/bin/sendberkmail.
and wants quotes stripped.
is used here because if it were given as a comment
line the machine address of the sender
would not be modified by later instantiations of
lines were always passed untouched.
When the gateways are converted to
The from address as seen by the receiver is
and it takes a flag-oriented
The ARPANET wants quotes stripped,
ARPANET standard headers,
and wants the user name left with case intact.
It takes a positional command list.
and with multiple users listed.
Since UUCP is a relic of the (not so) distant past,
it requires ugly header lines.
were to be missing from the argument vector for a mailer,
that mailer would be accessed using the SMTP [Postel81]
.sh 3 "Rewriting rules for recipient addresses"
.ta \w'[88] 'u +\w'R\&CSVAX:$-h!$+u 'u +\w'$#berk$@ing70$:$+u@$+h 'u
[1] R\&$-.$+ $1:$2 change "." to ":"
[2] R\&$=C:$+@$- $2@$3 delete ing70: on arpanet addresses
[3] R\&$+@$=A ing70:$1 delete local arpa hosts
[4] R\&$+@$- $#berk$@ing70$:$1@$2 send arpa mail to ing70
[5] R\&$+^$+ $1!$2 change "^" to "!"
[6] R\&$-!$=U!$+ csvax:$3 delete uucp loops through csvax
[7] R\&$-!$+ csvax:$1!$2 send uucp mail to csvax
[8] R\&$-:$-:$+ $2:$3 delete multiple berk hosts
[9] R\&$=B:$+ $2 delete local berk hosts
[10] R\&$-:$+ $#berk$@$1$:$2 resolve berk mail
[11] R\&$+ $#local$:$1 resolve local mail
The first rule translates dots to colons.
Redundant explicit routing to the ARPANET is deleted
Hops out over the ARPANET
back to us are deleted in the third rule \*-
note that the BerkNet host that we would have come in on
Real ARPANET mail is resolved immediately with no further ado \*-
it is sent out over the BerkNet to the ing70,
and further rewriting stops immediately.
Carets are changed to exclamation points
for UUCP addresses in the fifth rule.
The sixth rule deletes loops out into UUCP land
and back to us \*- noting that we will be left on CSVAX.
The seventh rule does forwarding of UUCP mail to the CSVAX.
Multiple BerkNet hosts are deleted in rule eight \*-
this can occur internally quite easily
as a side effect of a rewriting rule.
Rule nine deletes local BerkNet hosts.
The last two rules resolve BerkNet and local mail
by turning them into the canonical form:
$#\fInet\fP$@\fIhost\fP$:\fIuser\fP
Consider the following examples.
The numbers to the left are the rule that is being applied
to make the transformation.
[7] $#berk$@csvax$:research!vax135!dmr
.sh 3 "Rewriting rules for sender addresses"
.ta \w'R\&CSVAX:$-h!$+u 'u +\w'$+u@$+h 'u
R\&ing70:$+@$- $1@$2 arpanet mail is automatic
R\&CSVAX:$-!$+ $1!$2 uucp mail is automatic
line starts putting the rules into set one.
These rules strip off the
from incoming ARPANET mail
off of incoming UUCP mail.
The name classes could be used here,
but using literal strings is safe
because they will always be program-generated.
.sh 1 "COMPARISON WITH OTHER MAILERS"
The primary differences are:
Configuration information is not compiled in.
This simplifies many of the problems
of moving to other machines.
It also allows easy debugging of new mailers.
Address parsing is more flexible.
only supported one gateway to any network,
can be sensitive to host names
and reroute to different gateways.
features eliminate the requirement that the system alias file
(or that an update program be written,
or that the system administration make all changes).
supports message batching across networks
when a message is being sent to multiple recipients.
spans a wider problem set than
calls on preexisting mailers in most cases.
automatic forwarding to gateways,
MMDF supports two-stage timeout,
does not currently support.
.sh 2 "Message Processing Module"
The Message Processing Module (MPM)
discussed by Postel [Postel79b]
closely in terms of its basic architecture.
the MPM includes the network interface software
MPM also postulates a duplex channel to the receiver,
This allows simpler handling of errors
any errors must be returned to the sender
Both MPM and MMDF mailers
can return an immediate error response,
and a single error processor can create an appropriate response.
MPM prefers passing the message as a structured message,
with type-length-value tuples.
This implies a much higher degree of cooperation
between mailers than required by
MPM also assumes a universally agreed upon internet name space
(with each address a net-host-user tuple),
.sh 1 "EVALUATIONS AND FUTURE PLANS"
is designed to work in a nonhomogeneous environment.
Every attempt is made to avoid imposing any constraints
on the underlying mailers.
This goal has driven much of the design.
One of the major problems
has been the lack of a uniform address space,
as postulated in [Postel79a]
A nonuniform address space implies that path will be specified
either explicitly (as part of the address)
(as with implied forwarding to gateways).
This has the unpleasant effect of making replying to messages
but only a way to get there from wherever you are.
Interfacing to mail programs
that were not initially intended to be applied
in an internet environment
has been amazingly successful,
and has reduced the job to a manageable task.
has knowledge of a few difficult environments
It generates ARPANET FTP compatible error messages
(prepended with three-digit numbers
optionally generates UNIX-style
lines on the front of messages for some mailers,
and knows how to parse the same lines on input.
This can be inconvenient to sites which have abandoned UNIX mail,
still adds and understands ARPANET-style
error handling has an option customized for BerkNet.
One surprisingly major annoyance in most internet mailers
is that the location and format of local mail is built in\**.
MMDF puts local mail in the file
\*- useful if you are running version 6.
eliminates all knowledge of location
and can function successfully with different formats.
The ability to automatically generate a response to incoming mail
(by forwarding mail to a program)
.q "I am on vacation until late August...." )
(two people on vacation whose programs send notes back and forth,
if these programs are not well written.
A program should be written to do standard tasks correctly,
but this does not solve the general case.
It might be desirable to implement some form of load limiting.
I am unaware of any mail system that addresses this problem,
nor am I aware of any reasonable solution at this time.
should be modified to run as a daemon,
to receive mail and process it.
This would reduce the cost of sending mail to writing the message
would be modified to have a very different argument structure.
It already has an option to read the recipients
A more palatable technique for giving error messages
would also have to be devised.
The configuration file is currently practically inscrutable;
considerable convenience could be realized
with a higher-level format.
For example, a description might read:
(MAILER name path xlatstring
It seems clear that common protocols will be changing soon
to accommodate changing requirements and environments.
These changes will include modifications to the message header
or to the body of the message itself
(such as for multimedia messages
Other changes will include changes to communication protocols
for example, the changes implied by the new Mail Transfer Protocol
These changes should be relatively trivial to integrate
into the existing system.
Many other nice features could be implemented.
if we were sure that the alias file were writable by the effective user
then the inverted form could be rebuilt automatically when the
However, this appears to be little more than frosting.
Some proposals call for a single address syntax,
such that the host name uniquely determines the network.
There are a number of evident problems with this.
the database update problem becomes considerable,
especially under multiple managements;
this can be solved by a daemon that updates the tables
but it is not clear what the problems are here.
this requires a unique namespace among all networks.
In our current configuration
we have been unable to even find out the names of all the hosts
to hope that on an internet with fifty or more networks
would have no name conflicts is beyond the scope of
Despite the difficulties, however,
this is probably a better long-term solution to the problem
The ambiguities implied by addresses combining
left-associative and right-associative addresses
are impossible to solve without parentheses;
acceptable for mathematical equations,
but absurd for network addresses.
A related problem occurs with the user namespace.
In tightly coupled environments,
it would be nice to have automatic forwarding between machines
on the basis of the user name alone,
without cumbersome aliases.
This would require an automatically updated database
and some method of resolving conflicts.
Ideally this would be effective even with multiple managements.
is working on a facility which may provide the necessary functionality.
a system that understands canonical internet addresses
implemented in a world that understands these addresses
would be an incredible win.
seems to be a useful tool to pull together
the haphazard environment that exists today,
until the better tools permeate the internetwork world.
Thanks are due to Kurt Shoens for his continual cheerful
assistance and good advice,
Bill Joy for pointing me in the correct direction
and Mark Horton for more advice,
and many of the good ideas.
Kurt and Eric Schmidt are to be credited
as a server for their programs
and BerkNet respectively)
before any sane person should have,
and making the necessary modifications
Eric gave me considerable advice about the perils
of network software which saved me an unknown
amount of work and grief.
Mark did the original implementation of the DBM version
of aliasing, installed the VFORK code,
wrote the current version of
and was the person who really convinced me
Kurt deserves accolades for using
when I was myself afraid to take the risk;
how a person can continue to be so enthusiastic
in the face of so much bitter reality is beyond me.
read early copies of this paper,
giving considerable useful advice.
Special thanks are reserved for Mike Stonebraker,
who knowingly allowed me to put so much work into this
when there were so many other things I really should
The MH Message Handling System: Users' Manual.
Standard for the Format of ARPA Network Text Messages.
Framework and Functions of the MS Personal Message System.
Santa Monica, California.
An Internetwork Memo Distribution Facility \*- MMDF.
6th Data Communication Symposium,
.q "Ethernet: Distributed Packet Switching for Local Computer Networks" ,
Communications of the ACM 19,
ARPANET Protocol Handbook.
Network Information Center,
National Bureau of Standards,
Specification of a Draft Message Format Standard.
Report No. ICST/CBOS 80-2.
File Transfer Protocol for the ARPA Network.
A Dial-Up Network of UNIX Systems.
UNIX Programmer's Manual, Seventh Edition,
Uucp Implementation Description.
UNIX Programmer's Manual, Seventh Edition,
Internet Message Protocol.
Network Information Center,
An Internetwork Message Structure.
Proceedings of the Sixth Data Communications Symposium,
A Structured Format for Transmission of Multi-Media Documents.
Network Information Center,
Simple Mail Transfer Protocol.
Network Information Center,
An Introduction to the Berkeley Network.
University of California, Berkeley California.
University of California, Berkeley.
In UNIX Programmer's Manual,
Network Information Center,
The UNIX Programmer's Manual, Seventh Edition,
modified by the University of California,
Arguments must be presented with flags before addresses.
The sender's machine address is
This flag is ignored unless the real user
contains an exclamation point
(because of certain restrictions in UUCP).
This represents the number of times this message has been processed
(to the extent that it is supported by the underlying networks).
is incremented during processing,
throws away the message with an error.
Sets the full name of this user to
Print error messages (default).
Throw away error messages.
The only response is the exit status.
back errors \*- or mail them if the user is not logged in.
Do special error processing for BerkNet.
This involves mailing back the errors
but always returning a zero exit status.
Don't do aliasing or forwarding.
Include me in alias expansions.
if in a group being sent to.
Assume that the headers are already in new format,
there are commas between names and spaces are to be preserved.
If this flag is not given,
an adaptive algorithm is used:
if any recipient address contains a comma, parenthesis,
it will be assumed that commas already exist.
This flag is required in certain rare cases.
Headers are always output with commas between the names.
Don't take a dot to end a message.
lines, and send to everyone listed in those lists.
line will be deleted before sending.
Any addresses in the argument vector will be deleted
Do special processing for the
This includes reading the
line from the header to find the sender,
(preceded by three digit reply codes for compatibility with
[Neigus73, Postel74, Postel77]),
and ending lines of error messages with <CRLF>.
Take input over an SMTP connection on standard input and output.
This does everything the \-a flag does also.
lines at the beginning of headers.
Normally they are assumed redundant
Give a blow-by-blow description of function.
This gives information of interest to the user
aliases are printed as expanded
and mailer functions are printed as they run.
If this mailer is marked as being expensive,
don't connect immediately.
This requires that queueing be compiled in,
since it will depend on a sender process to
Try to execute the queued up mail.
a sendmail will run through the queue at the specified interval
otherwise, it only runs once.
Verify as much about the addresses and message as possible
and then politely run in background.
This should always be used with the
as it runs on the SMTP port.
Set timeout interval for mail that cannot be sent.
Select directory in which mail will be queued.
Typically for debugging only.
Use a different configuration file.
Use a different alias file.
Initialize the DBM version
no delivery is attempted.
The DBM version will be rebuilt automatically if the DBM files
or if they are owned by the effective userid.
Verify the addresses only.
Only partial verification is done:
syntax is checked, and local names are verified,
but no checking normally done by the mailer is attempted.
.+c "OTHER CONFIGURATION"
There are some configuration changes that can be made by
Some of these are changes to compilation flags:
this will compile a version 6 system,
single character tty id's,
a version 7 system is assumed.
(see DBM(3X) in [UNIX80]).
a much less efficient algorithm for processing aliases is used.
Set if your system has the experimental
See vfork(2) in [UNIX80].
This option improves performance.
If set, debugging information is compiled in.
To actually get the debugging output,
routine in use at some sites is used.
This makes an informational log record
for each message processed,
and makes a higher priority log record
for internal system errors.
This flag should be set to compile in the queueing code.
mailers must accept the mail immediately
or it will be returned to the sender.
the code to handle user and server SMTP will be compiled in.
This is only necessary if your machine has some mailer
If you have a UUCP host adjacent to you which is not running
you will have to set this flag to include the
Otherwise, UUCP gets confused about where the mail came from.
may opt for a more secure,
but probably less convenient environment.
it is not possible to specify a program as an address directly;
this can only be done with an alias.
If you are using a non-UNIX mail format,
you can set this flag to turn off special processing
Not all header semantics are defined in the configuration file.
Header lines that should only be included by certain mailers
(as well as other more obscure semantics)
This table contains the header name
(which should be in all lower case),
a set of header control flags (described below),
and a set of mailer flags,
used by some of the header flags.
Check the flags for the receiving mailer
against the third field in the
If the mailer has any of those bits set,
otherwise, do not send this field to that mailer.
If the field was in the message originally, however,
(i.e., this only applies to headers being added by
except that it even applies to headers that were in the
if this bit is set and the mailer does not have flag bits set
that intersect with the third field in this
If this header field is set,
treat it like a blank line,
it will signal the end of the header
and the beginning of the message text.
even if one existed in the message before.
If a header entry does not have this bit set,
will not add another header line if a header line
of this name already existed.
This would normally be used to stamp the message
by everyone who handled it.
this field contains recipient addresses.
flag to determine who to send to
when it is collecting recipients from the message.
This flag indicates that this field
contains addresses that should be rewritten
.ta 4n +\w'"received-from", 'u +\w'H_ADDR|H_ACHECK, 'u
struct hdrinfo HdrInfo[] =
"date", H_CHECK, M_NEEDDATE,
"from", H_CHECK, M_NEEDFROM,
"original-from", H_ACHECK, 0,
"full-name", H_ACHECK, M_FULLNAME,
"bcc", H_ADDR|H_ACHECK, 0,
"message-id", H_CHECK, M_MSGID,
"received-date", H_CHECK, M_LOCAL,
"received-from", H_CHECK, M_LOCAL,
This specification says that the
must be requested by the mailer to be inserted.
if they were in the message as received by
field, on the other hand,
will be deleted even if it was specified before,
unless the mailer wants it.
fields will be deleted unconditionally
(since it is never possible for a mailer's flags
is in fact used internally,
and will be reinserted by ad hoc code,
but only if it differs from the
line that would otherwise be inserted.
all specify recipient addresses.
fields will terminate the header;
these are specified in new protocols
or used by random dissenters around the network world.
field will always be added,
and can be used to trace messages.
field is used internally,
although no cliched special processing occurs.
There are a number of important points here.
header fields are not added automatically just because they are in the
they must be specified in the configuration file
in order to be added to the message.
Any header fields mentioned in the configuration file but not
structure have default processing performed;
they are added unless they were in the message already.
structure only specifies cliched processing;
certain headers are processed specially by ad hoc code
regardless of the status specified in
fields are always scanned on ARPANET mail
this is used to perform the
fields are used to determine the full name of the sender
this is stored in the macro
and used in a number of ways.
field is specified to be deleted in
it is added automatically if the
field that would be generated internally
field that was specified in the message;
also contains the specification of ARPANET reply codes.
There are six classifications these fall into:
.ta \w'char 'u +\w'Arpa_Usrerr[] = 'u +\w'"888"; 'u
char Arpa_Info[] = "050"; /* arbitrary info */
char Arpa_Enter[] = "350"; /* start mail input */
char Arpa_Mmsg[] = "256"; /* mail successful (MAIL cmd) */
char Arpa_Fmsg[] = "250"; /* mail successful (MLFL cmd) */
char Arpa_Syserr[] = "455"; /* some (transient) system error */
char Arpa_Usrerr[] = "450"; /* some (fatal) user error */
is for any information that is not required by the protocol,
such as forwarding information.
wants to start receiving the mail.
are given if the mail is successfully delivered;
the selection of message number depends on the FTP command given
(which is communicated via the
typically, this occurs when something has gone wrong at the
with the assumption that it is a transient condition.
is the result of a user error
these are generated when the user has specified something wrong,
and hence the error is permanent,
it will not work simply by resubmitting the request.
If it is necessary to restrict mail through a gateway,
This routine is called for every recipient address.
to indicate that the address is acceptable
and mail processing will continue,
to print an error message
saying why the message is rejected.
if (MsgSize > 50000 && to->q_mailer != MN_LOCAL)
usrerr("Message too large for non-local delivery");
This would reject messages greater than 50000 bytes
The actual use of this routine is highly dependent on the
and use should be limited.
projects / unix-history / blob