usenix.me

早期freebsd实现

HostA.
Eventually the mail would arrive at
HostA,
which would then do final delivery
to user
.q eric.
.sh 2 "Mail to Files and Programs"
.pp
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,
for example,
to maintain a public repository of systems messages
(such as the Berkeley
.i msgs
program).
.pp
Any address passing through the initial parsing algorithm
as a local address
(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
.q \^|\^ )
the rest of the address is processed as a shell command.
If the user name begins with a slash mark (\c
.q /\^ )
the name is used as a file name,
instead of a login name.
.sh 2 "Aliasing, Forwarding, Inclusion"
.pp
.i Sendmail
reroutes mail three ways.
Aliasing applies system wide.
Forwarding allows each user to reroute incoming mail
destined for that account.
Inclusion directs
.i sendmail
to read a file for a list of addresses,
and is normally used
in conjunction with aliasing.
.sh 3 "Aliasing"
.pp
Aliasing maps local addresses to address lists using a system-wide file.
This file is hashed to speed access.
Only addresses that parse as local
are allowed as aliases;
this guarantees a unique key
(since there are no nicknames for the local host).
.sh 3 "Forwarding"
.pp
After aliasing,
if an recipient address specifies a local user
.i sendmail
searches for a
.q .forward
file in the recipient's home directory.
If it exists,
the message is
.i not
sent to that user,
but rather to the list of addresses in that file.
Often
this list will contain only one address,
and the feature will be used for network mail forwarding.
.pp
Forwarding also permits a user to specify a private incoming mailer.
For example,
forwarding to:
.(b
"\^|\|/usr/local/newmail myname"
.)b
will use a different incoming mailer.
.sh 3 "Inclusion"
.pp
Inclusion is specified in RFC 733 [Crocker77] syntax:
.(b
:Include: pathname
.)b
An address of this form reads the file specified by
.i pathname
and sends to all users listed in that file.
.pp
The intent is
.i not
to support direct use of this feature,
but rather to use this as a subset of aliasing.
For example,
an alias of the form:
.(b
project: :include:/usr/project/userlist
.)b
is a method of letting a project maintain a mailing list
without interaction with the system administration,
even if the alias file is protected.
.pp
It is not necessary to rebuild the index on the alias database
when a :include: list is changed.
.sh 2 "Message Collection"
.pp
Once all recipient addresses are parsed and verified,
the message is collected.
The message comes in two parts:
a message header and a message body,
separated by a blank line.
The body is an uninterpreted
sequence of text lines.
.pp
The header is formated as a series of lines
of the form
.(b
	field-name: field-value
.)b
Field-value can be split across lines by starting the following
lines with a space or a tab.
Some header fields have special internal meaning,
and have appropriate special processing.
Other headers are simply passed through.
Some header fields may be added automatically,
such as time stamps.
.sh 1 "THE UUCP PROBLEM"
.pp
Of particular interest
is the UUCP network.
The explicit routing
used in the UUCP environment
causes a number of serious problems.
First,
giving out an address
is impossible
without knowing the address of your potential correspondent.
This is typically handled
by specifying the address
relative to some
.q "well-known"
host
(e.g.,
ucbvax or decvax).
Second,
it is often difficult to compute
the set of addresses
to reply to
without some knowledge
of the topology of the network.
Although it may be easy for a human being
to do this
under many circumstances,
a program does not have equally sophisticated heuristics
built in.
Third,
certain addresses will become painfully and unnecessarily long,
as when a message is routed through many hosts in the USENET.
And finally,
certain
.q "mixed domain"
addresses
are impossible to parse unambiguously \*-
e.g.,
.(l
decvax!ucbvax!lbl-h!user@LBL-CSAM
.)l
might have many possible resolutions,
depending on whether the message was first routed
to decvax
or to LBL-CSAM.
.pp
To solve this problem,
the UUCP syntax
would have to be changed to use addresses
rather than routes.
For example,
the address
.q decvax!ucbvax!eric
might be expressed as
.q [e-mail]
(with the hop through decvax implied).
This address would itself be a domain-based address;
for example,
an address might be of the form:
.(l
[e-mail]
.)l
Hosts outside of Bell Telephone Laboratories
would then only need to know
how to get to a designated BTL relay,
and the BTL topology
would only be maintained inside Bell.
.pp
There are three major problems
associated with turning UUCP addresses
into something reasonable:
defining the namespace,
creating and propagating the necessary software,
and building and maintaining the database.
.sh 2 "Defining the Namespace"
.pp
Putting all UUCP hosts into a flat namespace
(e.g.,
.q \&[e-mail] )
is not practical for a number of reasons.
First,
with over 1600 sites already,
and (with the increasing availability of inexpensive microcomputers
and autodialers)
several thousand more coming within a few years,
the database update problem
is simply intractable
if the namespace is flat.
Second,
there are almost certainly name conflicts today.
Third,
as the number of sites grow
the names become ever less mnemonic.
.pp
It seems inevitable
that there be some sort of naming authority
for the set of top level names
in the UUCP domain,
as unpleasant a possibility
as that may seem.
It will simply not be possible
to have one host resolving all names.
It may however be possible
to handle this
in a fashion similar to that of assigning names of newsgroups
in USENET.
However,
it will be essential to encourage everyone
to become subdomains of an existing domain
whenever possible \*-
even though this will certainly bruise some egos.
For example,
if a new host named
.q blid
were to be added to the UUCP network,
it would probably actually be addressed as
.q d.bli.UUCP
(i.e.,
as host
.q d
in the pseudo-domain
.q bli
rather than as host
.q blid
in the UUCP domain).
.sh 2 "Creating and Propagating the Software"
.pp
The software required to implement a consistent namespace
is relatively trivial.
Two modules are needed,
one to handle incoming mail
and one to handle outgoing mail.
.pp
The incoming module
must be prepared to handle either old or new style addresses.
New-style addresses
can be passed through unchanged.
Old style addresses
must be turned into new style addresses
where possible.
.pp
The outgoing module
is slightly trickier.
It must do a database lookup on the recipient addresses
(passed on the command line)
to determine what hosts to send the message to.
If those hosts do not accept new-style addresses,
it must transform all addresses in the header of the message
into old style using the database lookup.
.pp
Both of these modules
are straightforward
except for the issue of modifying the header.
It seems prudent to choose one format
for the message headers.
For a number of reasons,
Berkeley has elected to use the ARPANET protocols
for message formats.
However,
this protocol is somewhat difficult to parse.
.pp
Propagation is somewhat more difficult.
There are a large number of hosts
connected to UUCP
that will want to run completely standard systems
(for very good reasons).
The strategy is not to convert the entire network \*-
only enough of it it alleviate the problem.
.sh 2 "Building and Maintaining the Database"
.pp
This is by far the most difficult problem.
A prototype for this database
already exists,
but it is maintained by hand
and does not pretend to be complete.
.pp
This problem will be reduced considerably
if people choose to group their hosts
into subdomains.
This would require a global update
only when a new top level domain
joined the network.
A message to a host in a subdomain
could simply be routed to a known domain gateway
for further processing.
For example,
the address
.q [e-mail]
might be routed to the
.q bli
gateway
for redistribution;
new hosts could be added
within BLI
without notifying the rest of the world.
Of course,
other hosts
.i could
be notified as an efficiency measure.
.pp
There may be more than one domain gateway.
A domain such as BTL,
for instance,
might have a dozen gateways to the outside world;
a non-BTL site
could choose the closest gateway.
The only restriction
would be that all gateways
maintain a consistent view of the domain
they represent.
.sh 2 "Logical Structure"
.pp
Logically,
domains are organized into a tree.
There need not be a host actually associated
with each level in the tree \*-
for example,
there will be no host associated with the name
.q UUCP.
Similarly,
an organization might group names together for administrative reasons;
for example,
the name
.(l
CAD.research.BigCorp.UUCP
.)l
might not actually have a host representing
.q research.
.pp
However,
it may frequently be convenient to have a host
or hosts
that
.q represent
a domain.
For example,
if a single host exists that
represents
Berkeley,
then mail from outside Berkeley
can forward mail to that host
for further resolution
without knowing Berkeley's
(rather volatile)
topology.
This is not unlike the operation
of the telephone network.
.pp
This may also be useful
inside certain large domains.
For example,
at Berkeley it may be presumed
that most hosts know about other hosts
inside the Berkeley domain.
But if they process an address
that is unknown,
they can pass it
.q upstairs
for further examination.
Thus as new hosts are added
only one host
(the domain master)
.i must
be updated immediately;
other hosts can be updated as convenient.
.pp
Ideally this name resolution process
would be performed by a name server
(e.g., [Su82b])
to avoid unnecessary copying
of the message.
However,
in a batch network
such as UUCP
this could result in unnecessary delays.
.sh 1 "COMPARISON WITH DELIVERMAIL"
.pp
.i Sendmail
is an outgrowth of
.i delivermail .
The primary differences are:
.np
Configuration information is not compiled in.
This change simplifies many of the problems
of moving to other machines.
It also allows easy debugging of new mailers.
.np
Address parsing is more flexible.
For example,
.i delivermail
only supported one gateway to any network,
whereas
.i sendmail
can be sensitive to host names
and reroute to different gateways.
.np
Forwarding and
:include:
features eliminate the requirement that the system alias file
be writable by any user
(or that an update program be written,
or that the system administration make all changes).
.np
.i Sendmail
supports message batching across networks
when a message is being sent to multiple recipients.
.np
A mail queue is provided in
.i sendmail.
Mail that cannot be delivered immediately
but can potentially be delivered later
is stored in this queue for a later retry.
The queue also provides a buffer against system crashes;
after the message has been collected
it may be reliably redelivered
even if the system crashes during the initial delivery.
.np
.i Sendmail
uses the networking support provided by 4.2BSD
to provide a direct interface networks such as the ARPANET
and/or Ethernet
using SMTP (the Simple Mail Transfer Protocol)
over a TCP/IP connection.
.+c
.ce
REFERENCES
.nr ii 1.5i
.ip [Crocker77]
Crocker, D. H.,
Vittal, J. J.,
Pogran, K. T.,
and
Henderson, D. A. Jr.,
.ul
Standard for the Format of ARPA Network Text Messages.
RFC 733,
NIC 41952.
In [Feinler78].
November 1977.
.ip [Crocker82]
Crocker, D. H.,
.ul
Standard for the Format of Arpa Internet Text Messages.
RFC 822.
Network Information Center,
SRI International,
Menlo Park, California.
August 1982.
.ip [Feinler78]
Feinler, E.,
and
Postel, J.
(eds.),
.ul
ARPANET Protocol Handbook.
NIC 7104,
Network Information Center,
SRI International,
Menlo Park, California.
1978.
.ip [Nowitz78]
Nowitz, D. A.,
and
Lesk, M. E.,
.ul
A Dial-Up Network of UNIX Systems.
Bell Laboratories.
In
UNIX Programmer's Manual, Seventh Edition,
Volume 2.
August, 1978.
.ip [Schmidt79]
Schmidt, E.,
.ul
An Introduction to the Berkeley Network.
University of California, Berkeley California.
1979.
.ip [Shoens79]
Shoens, K.,
.ul
Mail Reference Manual.
University of California, Berkeley.
In UNIX Programmer's Manual,
Seventh Edition,
Volume 2C.
December 1979.
.ip [Solomon81]
Solomon, M.,
Landweber, L.,
and
Neuhengen, D.,
.ul
The Design of the CSNET Name Server.
CS-DN-2.
University of Wisconsin,
Madison.
October 1981.
.ip [Su82a]
Su, Zaw-Sing,
and
Postel, Jon,
.ul
The Domain Naming Convention for Internet User Applications.
RFC819.
Network Information Center,
SRI International,
Menlo Park, California.
August 1982.
.ip [Su82b]
Su, Zaw-Sing,
.ul
A Distributed System for Internet Name Service.
RFC830.
Network Information Center,
SRI International,
Menlo Park, California.
October 1982.