usenix.me

早期freebsd实现

.nr si 3n
.he 'Mail Systems and Addressing in 4.2bsd''%'
.fo 'Version 8.2'USENIX \- Jan 83'Last Mod 11/27/93'
.if n .ls 2
.+c
.(l C
.sz 14
Mail Systems and Addressing
in 4.2bsd
.sz
.sp
Eric Allman*
.sp 0.5
.i
Britton-Lee, Inc.
1919 Addison Street, Suite 105.
Berkeley, California 94704.
.sp 0.5
.r
[e-mail]
ucbvax!eric
.)l
.sp
.(l F
.ce
ABSTRACT
.sp \n(psu
Routing mail through a heterogeneous internet presents many new
problems.
Among the worst of these is that of address mapping.
Historically, this has been handled on an ad hoc basis.
However,
this approach has become unmanageable as internets grow.
.sp \n(psu
Sendmail acts a unified
.q "post office"
to which all mail can be
submitted.
Address interpretation is controlled by a production
system,
which can parse both old and new format addresses.
The
new format is
.q "domain-based,"
a flexible technique that can
handle many common situations.
Sendmail is not intended to perform
user interface functions.
.sp \n(psu
Sendmail will replace delivermail in the Berkeley 4.2 distribution.
Several major hosts are now or will soon be running sendmail.
This change will affect any users that route mail through a sendmail
gateway.
The changes that will be user visible are emphasized.
.)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.
.)f
.pp
The mail system to appear in 4.2bsd
will contain a number of changes.
Most of these changes are based on the replacement of
.i delivermail
with a new module called
.i sendmail.
.i Sendmail
implements a general internetwork mail routing facility,
featuring aliasing and forwarding,
automatic routing to network gateways,
and flexible configuration.
Of key interest to the mail system user
will be the changes in the network addressing structure.
.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 characteristics
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 that the route the message takes
be explicitly specified by the sender,
simplifying the database update problem
since only adjacent hosts must be entered
into the system tables,
while others use logical addressing,
where the sender specifies the location of the recipient
but not how to get there.
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, username}
triples.
Network numbers must be universally agreed upon,
and hosts can be assigned locally
on each network.
The user-level presentation was changed
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 the logical
organization of the address space
(user
.q eric
on host
.q a
in the Computer Center
at Berkeley)
but not the physical networks used
(for example, this could go over different networks
depending on whether
.q a
were on an ethernet
or a store-and-forward network).
.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 defines some of the terms
frequently left fuzzy
when working in mail systems.
Section 2 discusses the design goals for
.i sendmail .
In section 3,
the new address formats
and basic features of
.i sendmail
are described.
Section 4 discusses some of the special problems
of the UUCP network.
The differences between
.i sendmail
and
.i delivermail
are presented in section 5.
.sp
.(l F
.b DISCLAIMER:
A number of examples
in this paper
use names of actual people
and organizations.
This is not intended
to imply a commitment
or even an intellectual agreement
on the part of these people or organizations.
In particular,
Bell Telephone Laboratories (BTL),
Digital Equipment Corporation (DEC),
Lawrence Berkeley Laboratories (LBL),
Britton-Lee Incorporated (BLI),
and the University of California at Berkeley
are not committed to any of these proposals at this time.
Much of this paper
represents no more than
the personal opinions of the author.
.)l
.sh 1 "DEFINITIONS"
.pp
There are four basic concepts
that must be clearly distinguished
when dealing with mail systems:
the user (or the user's agent),
the user's identification,
the user's address,
and the route.
These are distinguished primarily by their position independence.
.sh 2 "User and Identification"
.pp
The user is the being
(a person or program)
that is creating or receiving a message.
An
.i agent
is an entity operating on behalf of the user \*-
such as a secretary who handles my mail.
or a program that automatically returns a
message such as
.q "I am at the UNICOM conference."
.pp
The identification is the tag
that goes along with the particular user.
This tag is completely independent of location.
For example,
my identification is the string
.q "Eric Allman,"
and this identification does not change
whether I am located at U.C. Berkeley,
at Britton-Lee,
or at a scientific institute in Austria.
.pp
Since the identification is frequently ambiguous
(e.g., there are two
.q "Robert Henry" s
at Berkeley)
it is common to add other disambiguating information
that is not strictly part of the identification
(e.g.,
Robert
.q "Code Generator"
Henry
versus
Robert
.q "System Administrator"
Henry).
.sh 2 "Address"
.pp
The address specifies a location.
As I move around,
my address changes.
For example,
my address might change from
.q [e-mail]
to
.q [e-mail]
or
.q [e-mail]
depending on my current affiliation.
.pp
However,
an address is independent of the location of anyone else.
That is,
my address remains the same to everyone who might be sending me mail.
For example,
a person at MIT and a person at USC
could both send to
.q [e-mail]
and have it arrive to the same mailbox.
.pp
Ideally a
.q "white pages"
service would be provided to map user identifications
into addresses
(for example, see
[Solomon81]).
Currently this is handled by passing around
scraps of paper
or by calling people on the telephone
to find out their address.
.sh 2 "Route"
.pp
While an address specifies
.i where
to find a mailbox,
a route specifies
.i how
to find the mailbox.
Specifically,
it specifies a path
from sender to receiver.
As such, the route is potentially different
for every pair of people in the electronic universe.
.pp
Normally the route is hidden from the user
by the software.
However,
some networks put the burden of determining the route
onto the sender.
Although this simplifies the software,
it also greatly impairs the usability
for most users.
The UUCP network is an example of such a network.
.sh 1 "DESIGN GOALS"
.pp
Design goals for
.i sendmail \**
.(f
\**This section makes no distinction between
.i delivermail
and
.i sendmail.
.)f
include:
.np
Compatibility with the existing mail programs,
including Bell version 6 mail,
Bell version 7 mail,
Berkeley
.i Mail
[Shoens79],
BerkNet mail
[Schmidt79],
and hopefully UUCP mail
[Nowitz78].
ARPANET mail
[Crocker82]
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
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 Ethernets).
This goal requires consideration of the contents of an address
as well as its syntax
in order to determine which gateway to use.
.np
Configuration information 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 "USAGE"
.sh 2 "Address Formats"
.pp
Arguments may be flags or addresses.
Flags set various processing options.
Following flag arguments,
address arguments may be given.
Addresses follow the syntax in RFC822
[Crocker82]
for ARPANET
address formats.
In brief, the format is:
.np
Anything in parentheses is thrown away
(as a comment).
.np
Anything in angle brackets (\c
.q "<\|>" )
is preferred
over anything else.
This rule implements the ARPANET standard that addresses of the form
.(b
user name <machine-address>
.)b
will send to the electronic
.q machine-address
rather than the human
.q "user name."
.np
Double quotes
(\ "\ )
quote phrases;
backslashes quote characters.
Backslashes are more powerful
in that they will cause otherwise equivalent phrases
to compare differently \*- for example,
.i user
and
.i
"user"
.r
are equivalent,
but
.i \euser
is different from either of them.
This might be used
to avoid normal aliasing
or duplicate suppression algorithms.
.pp
Parentheses, angle brackets, and double quotes
must be properly balanced and nested.
The rewriting rules control remaining parsing\**.
.(f
\**Disclaimer: Some special processing is done
after rewriting local names; see below.
.)f
.pp
Although old style addresses are still accepted
in most cases,
the preferred address format
is based on ARPANET-style domain-based addresses
[Su82a].
These addresses are based on a hierarchical, logical decomposition
of the address space.
The addresses are hierarchical in a sense
similar to the U.S. postal addresses:
the messages may first be routed to the correct state,
with no initial consideration of the city
or other addressing details.
The addresses are logical
in that each step in the hierarchy
corresponds to a set of
.q "naming authorities"
rather than a physical network.
.pp
For example,
the address:
.(l
[e-mail]
.)l
would first look up the domain
BigSite
in the namespace administrated by
ARPA.
A query could then be sent to
BigSite
for interpretation of