intro.me

<B>Digital的Unix操作系统VAX 4.2源码</B>

.nr DR 1	\" this is a draft copy
.nr si 3n
.he 'SENDMAIL''%'
.fo 'Version 4.1'DRAFT'Last Mod 7/25/83'
.if n .ls 2
.+c
.(l C
.sz 14
SENDMAIL \*- An Internetwork Mail Router
.sz
.sp
Eric Allman\(dg
.sp 0.5
.i
Britton-Lee, Inc.
1919 Addison Street, Suite 105.
Berkeley, California 94704.
.)l
.sp
.(l F
.ce
ABSTRACT
.sp \n(psu
Routing mail through a heterogenous internet presents many new
problems.  Among the worst of these is that of address mapping.
Historically, this has been handled on an
.i "ad hoc"
basis.  However,
this approach has become unmanageable as internets grow.
.sp \n(psu
Sendmail acts a unified "post office" to which all mail can be
submitted.  Address interpretation is controlled by a production
system, which can parse both domain-based addressing and old-style
.i "ad hoc"
addresses.
The production system is powerful
enough to rewrite addresses in the message header to conform to the
standards of a number of common target networks, including old
(NCP/RFC733) Arpanet, new (TCP/RFC822) Arpanet, UUCP, and Phonenet.
Sendmail also implements an SMTP server, message
queueing, and aliasing.
.)l
.sp 2
.(f
\(dgA considerable part of this work
was done while under the employ
of the INGRES Project
at the University of California at Berkeley.
.)f
.pp
.i Sendmail
implements a general internetwork mail routing facility,
featuring aliasing and forwarding,
automatic routing to network gateways,
and flexible configuration.
.pp
In a simple network,
each node has an address,
and resources can be identified
with a host-resource pair;
in particular,
the mail system can refer to users
using a host-username pair.
Host names and numbers have to be administered by a central authority,
but usernames can be assigned locally to each host.
.pp
In an internet,
multiple networks with different characterstics
and managements
must communicate.
In particular,
the syntax and semantics of resource identification change.
Certain special cases can be handled trivially
by
.i "ad hoc"
techniques,
such as
providing network names that appear local to hosts
on other networks,
as with the Ethernet at Xerox PARC.
However,  the general case is extremely complex.
For example,
some networks require point-to-point routing,
which simplifies the database update problem
since only adjacent hosts must be entered
into the system tables,
while others use end-to-end addressing.
Some networks use a left-associative syntax
and others use a right-associative syntax,
causing ambiguity in mixed addresses.
.pp
Internet standards seek to eliminate these problems.
Initially, these proposed expanding the address pairs
to address triples,
consisting of
{network, host, resource}
triples.
Network numbers must be universally agreed upon,
and hosts can be assigned locally
on each network.
The user-level presentation was quickly expanded
to address domains,
comprised of a local resource identification
and a hierarchical domain specification
with a common static root.
The domain technique
separates the issue of physical versus logical addressing.
For example,
an address of the form
.q "[e-mail]"
describes only the logical
organization of the address space.
.pp
.i Sendmail
is intended to help bridge the gap
between the totally
.i "ad hoc"
world
of networks that know nothing of each other
and the clean, tightly-coupled world
of unique network numbers.
It can accept old arbitrary address syntaxes,
resolving ambiguities using heuristics
specified by the system administrator,
as well as domain-based addressing.
It helps guide the conversion of message formats
between disparate networks.
In short,
.i sendmail
is designed to assist a graceful transition
to consistent internetwork addressing schemes.
.sp
.pp
Section 1 discusses the design goals for
.i sendmail .
Section 2 gives an overview of the basic functions of the system.
In section 3,
details of usage are discussed.
Section 4 compares
.i sendmail
to other internet mail routers,
and an evaluation of
.i sendmail
is given in section 5,
including future plans.
.sh 1 "DESIGN GOALS"
.pp
Design goals for
.i sendmail
include:
.np
Compatibility with the existing mail programs,
including Bell version 6 mail,
Bell version 7 mail
[UNIX83],
Berkeley
.i Mail
[Shoens79],
BerkNet mail
[Schmidt79],
and hopefully UUCP mail
[Nowitz78a, Nowitz78b].
ARPANET mail
[Crocker77a, Postel77]
was also required.
.np
Reliability, in the sense of guaranteeing
that every message is correctly delivered
or at least brought to the attention of a human
for correct disposal;
no message should ever be completely lost.
This goal was considered essential
because of the emphasis on mail in our environment.
It has 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.
For example,
certain sites generate improperly formated addresses,
occasionally
causing error-message loops.
Some hosts use blanks in names,
causing problems with
UNIX mail programs that assume that an address
is one word.
The semantics of some fields
are interpreted slightly differently
by different sites.
In summary,
the obscure features of the ARPANET mail protocol
really
.i are
used and
are difficult to support,
but must be supported.
.np
Existing software to do actual delivery
should be used whenever possible.
This goal derives as much from political and practical considerations
as technical.
.np
Easy expansion to
fairly complex environments,
including multiple
connections to a single network type
(such as with multiple UUCP or Ether nets
[Metcalfe76]).
This goal requires consideration of the contents of an address
as well as its syntax
in order to determine which gateway to use.
For example,
the ARPANET is bringing up the
TCP protocol 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
or a TCP gateway.
.np
Configuration should not be compiled into the code.
A single compiled program should be able to run as is at any site
(barring 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,
many sites like to
.q fiddle
with anything that they will be recompiling anyway.
.np
.i Sendmail
must be able to let various groups maintain their own mailing lists,
and let individuals specify their own forwarding,
without modifying the system alias file.
.np
Each user should be able to specify which mailer to execute
to process mail being delivered for him.
This feature allows users who are using specialized mailers
that use a different format to build their environment
without changing the system,
and facilitates specialized functions
(such as returning an
.q "I am on vacation"
message).
.np
Network traffic should be minimized
by batching addresses to a single host where possible,
without assistance from the user.
.pp
These goals motivated the architecture illustrated in figure 1.
.(z
.hl
.ie t \
.	sp 18
.el \{\
.(c
+---------+   +---------+   +---------+
| sender1 |   | sender2 |   | sender3 |
+---------+   +---------+   +---------+
     |  	   |             |
     +----------+  +  +----------+
		|  |  |
		v  v  v
            +-------------+
            |   sendmail  |
            +-------------+
		|  |  |
     +----------+  +  +----------+
     |  	   |             |
     v             v             v
+---------+   +---------+   +---------+
| mailer1 |   | mailer2 |   | mailer3 |
+---------+   +---------+   +---------+
.)c
.\}

.ce
Figure 1 \*- Sendmail System Structure.
.hl
.)z
The user interacts with a mail generating and sending program.
When the mail is created,
the generator calls
.i sendmail ,
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 clients,
.i sendmail
may be used as an internet mail gateway.
.sh 1 "OVERVIEW"
.sh 2 "System Organization"
.pp
.i Sendmail
neither interfaces with the user
nor does actual mail delivery.
Rather,
it collects a message
generated by a user interface program (UIP)
such as Berkeley
.i Mail ,
MS
[Crocker77b],
or MH
[Borden79],
edits the message as required by the destination network,
and calls appropriate mailers
to do mail delivery or queueing for network transmission\**.
.(f
\**except when mailing to a file,
when
.i sendmail
does the delivery directly.
.)f
This discipline allows the insertion of new mailers
at minimum cost.
In this sense 
.i sendmail
resembles the Message Processing Module (MPM)
of [Postel79b].
.sh 2 "Interfaces to the Outside World"
.pp
There are three ways
.i sendmail
can communicate with the outside world,
both in receiving and in sending mail.
These are using the conventional UNIX
argument vector/return status,
speaking SMTP over a pair of UNIX pipes,
and speaking SMTP over an interprocess(or) channel.
.sh 3 "Argument vector/exit status"
.pp
This technique is the standard UNIX method
for communicating with the process.
A list of recipients is sent in the argument vector,
and the message body is sent on the standard input.
Anything that the mailer prints
is simply collected and sent back to the sender
if there were any problems.
The exit status from the mailer is collected
after the message is sent,
and a diagnostic is printed if appropriate.
.sh 3 "SMTP over pipes"
.pp
The SMTP protocol
[Postel82]
can be used to run an interactive lock-step interface
with the mailer.
A subprocess is still created,
but no recipient addresses are passed to the mailer
via the argument list.
Instead, they are passed one at a time
in commands sent to the processes standard input.
Anything appearing on the standard output
must be a reply code
in a special format.
.sh 3 "SMTP over an IPC connection"
.pp
This technique is similar to the previous technique,
except that it uses a 4.2bsd IPC channel
[UNIX83].
This method is exceptionally flexible
in that the mailer need not reside
on the same machine.
It is normally used to connect to a sendmail process
on another machine.
.sh 2 "Operational Description"
.pp
When a sender wants to send a message,
it issues a request to
.i sendmail
using one of the three methods described above.
.i Sendmail
operates in two distinct phases.
In the first phase,
it collects and stores the message.
In the second phase,
message delivery occurs.
If there were errors during processing
during the second phase,
.i sendmail
creates and returns a new message describing the error
and/or returns an status code
telling what went wrong.
.sh 3 "Argument processing and address parsing"
.pp
If
.i sendmail
is called using one of the two subprocess techniques,
the arguments
are first scanned
and option specifications are processed.
Recipient addresses are then collected,
either from the command line
or from the SMTP
RCPT command,
and a list of recipients is created.
Aliases are expanded at this step,
including mailing lists.
As much validation as possible of the addresses
is done at this step:
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.
.pp
.i Sendmail
appends each address
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 that tells the delivery phase
to ignore this recipient.
This list is kept free from duplicates,
preventing alias loops
and duplicate messages deliverd to the same recipient,
as might occur if a person is in two groups.
.sh 3 "Message collection"
.pp
.i Sendmail
then collects the message.
The message should have a header at the beginning.
No formatting requirements are imposed on the message
except that they must be lines of text
(i.e., binary data is not allowed).
The header is parsed and stored in memory,
and the body of the message is saved
in a temporary file.
.pp
To simplify the program interface,
the message is collected even if no addresses were valid.
The message will be returned with an error.
.sh 3 "Message delivery"
.pp
For each unique mailer and host in the recipient list,
.i sendmail
calls the appropriate mailer.
Each mailer invocation sends to all users receiving the message on one host.
Mailers that only accept one recipient at a time
are handled properly.
.pp
The message is sent to the mailer
using one of the same three interfaces
used to submit a message to sendmail.
Each copy of the message is
prepended by a customized header.
The mailer status code is caught and checked,
and a suitable error message given as appropriate.
The exit code must conform to a system standard
or a generic message
(\c
.q "Service unavailable" )
is given.
.sh 3 "Queueing for retransmission"
.pp
If the mailer returned an status that
indicated that it might be able to handle the mail later,
.i sendmail
will queue the mail and try again later.
.sh 3 "Return to sender"
.pp
If errors occur during processing,
.i sendmail
returns the message to the sender for retransmission.
The letter can be mailed back
or written in the file
.q dead.letter
in the sender's home directory\**.
.(f
\**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,