intro.me

早期freebsd实现

.\" Copyright (c) 1983 Eric P. Allman
.\" Copyright (c) 1988, 1993
.\"	The Regents of the University of California.  All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\"    notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\"    notice, this list of conditions and the following disclaimer in the
.\"    documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\"    must display the following acknowledgement:
.\"	This product includes software developed by the University of
.\"	California, Berkeley and its contributors.
.\" 4. Neither the name of the University nor the names of its contributors
.\"    may be used to endorse or promote products derived from this software
.\"    without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\"
.\"	@(#)intro.me	8.2 (Berkeley) 11/27/93
.\"
.\"	pic -Pxx intro.me | ditroff -me -Pxx
.eh 'SMM:9-%''SENDMAIL \*- An Internetwork Mail Router'
.oh 'SENDMAIL \*- An Internetwork Mail Router''SMM:9-%'
.nr si 3n
.if n .ls 2
.+c
.(l C
.sz 14
SENDMAIL \*- An Internetwork Mail Router
.sz
.sp
Eric Allman*
.sp 0.5
.i
University of California, Berkeley
Mammoth Project
.)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
*A considerable part of this work
was done while under the employ
of the INGRES Project
at the University of California at Berkeley
and at Britton Lee.
.)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 \
\{\
.ie !"\*(.T"" \
\{\
.PS
boxht = 0.5i
boxwid = 1.0i

	down
S:	[
		right
	S1:	box "sender1"
		move
		box "sender2"
		move
	S3:	box "sender3"
	]
	arrow
SM:	box "sendmail" wid 2i ht boxht
	arrow
M:	[
		right
	M1:	box "mailer1"
		move
		box "mailer2"
		move
	M3:	box "mailer3"
	]

	arrow from S.S1.s to 1/2 between SM.nw and SM.n
	arrow from S.S3.s to 1/2 between SM.n and SM.ne

	arrow from 1/2 between SM.sw and SM.s to M.M1.n
	arrow from 1/2 between SM.s and SM.se to M.M3.n
.PE
.\}
.el \
.	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