.nr DR 1 \" this is a draft copy
.if \n(DR .fo 'For Your Eyes Only'\*-DRAFT\*-'\*(td'
SENDMAIL \*- An Internet Mail Router
Berkeley, California 94720
.if \n(DR Please do not distribute this version without permission
implements a general internetwork mail routing facility,
featuring aliasing and forwarding,
automatic routing to network gateways,
and flexible configuration.
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 only knew about taking apart addresses
automatic forwarding and other features
Compatibility with the existing mail system,
including Bell version 6 mail,
and the difference in format
influenced the decision to put all such formatting
into the low-level mailer.
Because of time constraints,
utilize as much existing software as possible.
The changes to the existing software were minimal:
UUCP, and the ARPANET FTP server
as their server instead of
(or in the case of the ARPANET,
writing the mail into a file
which has no meaning to standard UNIX mailers).
The only major modifications
which was maintained both as a user interface sender
calls it in turn to do local delivery,
flag was added to avoid loops.
Reliability 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.
MIT and CMU allow mail from people who are not logged in
(and which have meaningless from addresses),
which caused error message loops.
CMU also puts blanks in names,
which created amazing problems,
since many UNIX mail programs 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 non-goals in
Many of 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 they were running BerkNet.
The problem of multiple connections to a single network
on a host with no UUCP connection,
all UUCP mail was sent to a single host.
Berkeley is running UUCP on at least three hosts.
No attempt was made to reduce the volume of mail across a network link.
Besides the difficulty of doing this,
we failed to appreciate how much volume there would be.
Existing software to do actual delivery
should be used whenever possible.
This resulted as much from political and practical considerations
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 a host field
as well as just the syntax of an address,
in order to determine the gateway to use.
This results both from a desire to simplify use by other sites,
and to anticipate the environment Berkeley is moving towards.
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 open environment
that this 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 individuals their own forwarding,
without writing the system alias file.
Customized incoming mailers should be supported.
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
(the exception is when mailing to a file).
This discipline allows the insertion of new mailers
resembles the Message Processing Module (MPM)
+----------+ + +----------+
+---------+ +---------+ +---------+
| mailer1 | | mailer2 | | mailer3 |
+---------+ +---------+ +---------+
Figure 1 \*- System Structure.
.sh 2 "Operational Description"
.sh 3 "Argument processing and address parsing"
The arguments are first scanned,
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 of the addresses as possible
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
Collection occurs 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 call contains the users on that host.
Mailers that only accept one recipient at a time
The message is sent to the mailer
(which must read its standard input)
prepended by a customized header.
The mailer exit 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" )
Delivery to files executes directly.
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
and address rewriting rules.
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.
Each address is applied successively to these rules
being rewritten into a different (textual) form
until it resolves into a canonical address
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.
These follow the syntax in RFC733
Anything in parentheses is thrown away
Anything in angle brackets (\ <>\ ) is preferred
backslashes quote characters.
Backslashes are more powerful \*- 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 "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 contains slash marks (\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.
The inverted form of the file
must be recreated when the text copy is changed.
Under certain circumstances,
will do this automatically;
an option can force rebuilding.
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.
An exit status is returned that corresponds to the system standard
used by the other mailers.
.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 library.
To change ARPANET reply codes.
To add headers requiring special processing.
Adding mailers or changing parsing or routing information
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.
.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
See figure 2 for an example configuration file.
##########################################
# sendmail configuration file
# @(#)sendmail.cf 3.6 8/17/81
##########################################
### 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
# local mail -- must be zero
M\&local /bin/mail rlsAmn $f ...local\&mail -d $u
# program mail -- must be one
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 rsDxm $U!$f ...uucp\&mail - $h!rmail ($u)
.ta \w'R\&CSVAX:$-h!$+u 'u +\w'$#berk$@ing70$:$+u@$+h 'u
R\&$-h.$+u $+h:$+u change "." to ":"
R\&$=C:$+u@$-h $+u@$+h delete ing70: on arpanet addresses
R\&$+u@$=A ing70:$+u delete local arpa hosts
R\&$+u@$-h $#berk$@ing70$:$+u@$+h send arpa mail to ing70
R\&$+h^$+u $+h!$+u change "^" to "!"
R\&$-x!$=U!$+y csvax:$+y delete uucp loops through csvax
R\&$-h!$+u csvax:$+h!$+u send uucp mail to csvax
R\&$-x:$-h:$+u $+h:$+u delete multiple berk hosts
R\&$=B:$+u $+u delete local berk hosts
R\&$-h:$+u $#berk$@$+h$:$+u resolve berk mail
R\&$+u $#local$:$+u resolve local mail
### rewriting rules for from host
R\&ing70:$+u@$-h $+u@$+h arpanet mail is automatic
R\&CSVAX:$-h!$+u $+h!$+u uucp mail is automatic
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.
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
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.
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 wants an ARPANET standard header
.sh 3 "S \*- use rewriting set"
There are two sets of rewriting rules.
Set zero is used to rewrite recipient addresses.
Set one is used to rewrite sender addresses.
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:
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.
$-x Match a single word (and call it x).
$+x Match one or more words (and call them x).
$=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:
$+x Replace from corresponding match in LHS.
$#mailer Canonical mailer name.
$@host Canonical host name.
$:user Canonical user name.
The replacement from the LHS to the RHS does not use macros,
and there are no name conflicts.
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 2 "A Detailed Example"
We will now follow the configuration file
.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 rsDxm $U!$f ...uucpmail - $h!rmail ($u)
Five mailers are known in the configuration file.
be for local and program mail,
and must come as the first and second mailers respectively.
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.
The translated from address is the same as the raw from address,
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.
.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\&$-h.$+u $+h:$+u change "." to ":"
[2] R\&$=C:$+u@$-h $+u@$+h delete ing70: on arpanet addresses
[3] R\&$+u@$=A ing70:$+u delete local arpa hosts
[4] R\&$+u@$-h $#berk$@ing70$:$+u@$+h send arpa mail to ing70
[5] R\&$+h^$+u $+h!$+u change "^" to "!"
[6] R\&$-x!$=U!$+y csvax:$+y delete uucp loops through csvax
[7] R\&$-h!$+u csvax:$+h!$+u send uucp mail to csvax
[8] R\&$-x:$-h:$+u $+h:$+u delete multiple berk hosts
[9] R\&$=B:$+u $+u delete local berk hosts
[10] R\&$-h:$+u $#berk$@$+h$:$+u resolve berk mail
[11] R\&$+u $#local$:$+u 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.
Multiple BerkNet hosts are deleted in rule seven \*-
this can occur internally quite easily
as a side effect of a rewriting rule.
Rule eight deletes local BerkNet hosts.
The last two rules resolve BerkNet and local mail.
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:$+u@$-h $+u@$+h arpanet mail is automatic
R\&CSVAX:$-h!$+u $+h!$+u 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 much wider problem set than
calls on preexisting mailers in most cases.
is approximately equivalent to the
SUBMIT and DELIVER phases of MMDF.
Because of this difference in design goals,
some of the important features of MMDF
(queueing, retransmission, and two-phase timeout)
and automatic forwarding to gateways.
.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.
many of these mailers implement their own queueing and retransmission.
In networks that support store-and-forward file transfer,
such as BerkNet and UUCP,
this feature must be supplied already.
networks that transfer in real time,
such as the ARPANET or an Ether-based network
generally do not provide these features.
networks which provide these generally do not understand
timeouts or returning the text of the message on error,
both highly desirable features\**.
\**We have implemented an ARPANET mailer which
returns the message on error and does one-stage timeout
(returning the message after three days).
Such queueing, retransmission, and two-phase timeout
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
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,
The MH Message Handling System: Users' Manual.
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,
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.
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>.
except print out message numbers appropriate for the MLFL command
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.
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 Berkeley sites is used.
This logs an informational log record
for each message processed,
and logs a higher priority log record
for internal system errors.
If set, the ARPANET reply codes for
reply codes for the old, unrevised
If you want to use reply codes for the Mail Transfer Protocol
you may find it necessary to make some code modifications.
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
If you want to enable special processing of other headers,
you will have to add them to the
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.
.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.