1479 lines
38 KiB
Plaintext
1479 lines
38 KiB
Plaintext
.\" 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 "eric@a.cc.berkeley.arpa"
|
|
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
|
|
(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,
|
|
but they only effect the error message \*- the
|
|
.q "return to sender"
|
|
function is always handled in one of these two ways.
|
|
.)f
|
|
.sh 2 "Message Header Editing"
|
|
.pp
|
|
Certain editing of the message header
|
|
occurs automatically.
|
|
Header lines can be inserted
|
|
under control of the configuration file.
|
|
Some lines can be merged;
|
|
for example,
|
|
a
|
|
.q From:
|
|
line and a
|
|
.q Full-name:
|
|
line can be merged under certain circumstances.
|
|
.sh 2 "Configuration File"
|
|
.pp
|
|
Almost all configuration information is read at runtime
|
|
from an ASCII file,
|
|
encoding
|
|
macro definitions
|
|
(defining the value of macros used internally),
|
|
header declarations
|
|
(telling sendmail the format of header lines that it will process specially,
|
|
i.e., lines that it will add or reformat),
|
|
mailer definitions
|
|
(giving information such as the location and characteristics
|
|
of each mailer),
|
|
and address rewriting rules
|
|
(a limited production system to rewrite addresses
|
|
which is used to parse and rewrite the addresses).
|
|
.pp
|
|
To improve performance when reading the configuration file,
|
|
a memory image can be provided.
|
|
This provides a
|
|
.q compiled
|
|
form of the configuration file.
|
|
.sh 1 "USAGE AND IMPLEMENTATION"
|
|
.sh 2 "Arguments"
|
|
.pp
|
|
Arguments may be flags and addresses.
|
|
Flags set various processing options.
|
|
Following flag arguments,
|
|
address arguments may be given,
|
|
unless we are running in SMTP mode.
|
|
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.
|
|
.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
|
|
.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,
|
|
or the MARS system
|
|
[Sattley78]).
|
|
.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.
|
|
.pp
|
|
Files that have setuid or setgid bits set
|
|
but no execute bits set
|
|
have those bits honored if
|
|
.i sendmail
|
|
is running as root.
|
|
.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 names to address lists using a system-wide file.
|
|
This file is indexed to speed access.
|
|
Only names 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,
|
|
recipients that are local and valid
|
|
are checked for the existence of a
|
|
.q .forward
|
|
file in their home directory.
|
|
If it exists,
|
|
the message is
|
|
.i not
|
|
sent to that user,
|
|
but rather to the list of users 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 [Crocker77a] 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.
|
|
.pp
|
|
The header is formatted 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.
|
|
.pp
|
|
The body is a series of text lines.
|
|
It is completely uninterpreted and untouched,
|
|
except that lines beginning with a dot
|
|
have the dot doubled
|
|
when transmitted over an SMTP channel.
|
|
This extra dot is stripped by the receiver.
|
|
.sh 2 "Message Delivery"
|
|
.pp
|
|
The send queue is ordered by receiving host
|
|
before transmission
|
|
to implement message batching.
|
|
Each address is marked as it is sent
|
|
so rescanning the list is safe.
|
|
An argument list is built as the scan proceeds.
|
|
Mail to files is detected during the scan of the send list.
|
|
The interface to the mailer
|
|
is performed using one of the techniques
|
|
described in section 2.2.
|
|
.pp
|
|
After a connection is established,
|
|
.i sendmail
|
|
makes the per-mailer changes to the header
|
|
and sends the result to the mailer.
|
|
If any mail is rejected by the mailer,
|
|
a flag is set to invoke the return-to-sender function
|
|
after all delivery completes.
|
|
.sh 2 "Queued Messages"
|
|
.pp
|
|
If the mailer returns a
|
|
.q "temporary failure"
|
|
exit status,
|
|
the message is queued.
|
|
A control file is used to describe the recipients to be sent to
|
|
and various other parameters.
|
|
This control file is formatted as a series of lines,
|
|
each describing a sender,
|
|
a recipient,
|
|
the time of submission,
|
|
or some other salient parameter of the message.
|
|
The header of the message is stored
|
|
in the control file,
|
|
so that the associated data file in the queue
|
|
is just the temporary file that was originally collected.
|
|
.sh 2 "Configuration"
|
|
.pp
|
|
Configuration is controlled primarily by a configuration file
|
|
read at startup.
|
|
.i Sendmail
|
|
should not need to be recomplied except
|
|
.np
|
|
To change operating systems
|
|
(V6, V7/32V, 4BSD).
|
|
.np
|
|
To remove or insert the DBM
|
|
(UNIX database)
|
|
library.
|
|
.np
|
|
To change ARPANET reply codes.
|
|
.np
|
|
To add headers fields requiring special processing.
|
|
.lp
|
|
Adding mailers or changing parsing
|
|
(i.e., rewriting)
|
|
or routing information
|
|
does not require recompilation.
|
|
.pp
|
|
If the mail is being sent by a local user,
|
|
and the file
|
|
.q .mailcf
|
|
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 feature is to add header lines.
|
|
.pp
|
|
The configuration file encodes macro definitions,
|
|
header definitions,
|
|
mailer definitions,
|
|
rewriting rules,
|
|
and options.
|
|
.sh 3 Macros
|
|
.pp
|
|
Macros can be used in three ways.
|
|
Certain macros transmit
|
|
unstructured textual information
|
|
into the mail system,
|
|
such as the name
|
|
.i sendmail
|
|
will use to identify itself in error messages.
|
|
Other macros transmit information from
|
|
.i sendmail
|
|
to the configuration file
|
|
for use in creating other fields
|
|
(such as argument vectors to mailers);
|
|
e.g., the name of the sender,
|
|
and the host and user
|
|
of the recipient.
|
|
Other macros are unused internally,
|
|
and can be used as shorthand in the configuration file.
|
|
.sh 3 "Header declarations"
|
|
.pp
|
|
Header declarations inform
|
|
.i sendmail
|
|
of the format of known header lines.
|
|
Knowledge of a few header lines
|
|
is built into
|
|
.i sendmail ,
|
|
such as the
|
|
.q From:
|
|
and
|
|
.q Date:
|
|
lines.
|
|
.pp
|
|
Most configured headers
|
|
will be automatically inserted
|
|
in the outgoing message
|
|
if they don't exist in the incoming message.
|
|
Certain headers are suppressed by some mailers.
|
|
.sh 3 "Mailer declarations"
|
|
.pp
|
|
Mailer declarations tell
|
|
.i sendmail
|
|
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"
|
|
.pp
|
|
The heart of address parsing in
|
|
.i sendmail
|
|
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),
|
|
which are applied to each address.
|
|
The address is rewritten textually until it is either rewritten
|
|
into a special canonical form
|
|
(i.e.,
|
|
a (mailer, host, user)
|
|
3-tuple,
|
|
such as {arpanet, usc-isif, postel}
|
|
representing the address
|
|
.q "postel@usc-isif" ),
|
|
or it falls off the end.
|
|
When a pattern matches,
|
|
the rule is reapplied until it fails.
|
|
.pp
|
|
The configuration file also supports the editing of addresses
|
|
into different formats.
|
|
For example,
|
|
an address of the form:
|
|
.(b
|
|
ucsfcgl!tef
|
|
.)b
|
|
might be mapped into:
|
|
.(b
|
|
tef@ucsfcgl.UUCP
|
|
.)b
|
|
to conform to the domain syntax.
|
|
Translations can also be done in the other direction.
|
|
.sh 3 "Option setting"
|
|
.pp
|
|
There are several options that can be set
|
|
from the configuration file.
|
|
These include the pathnames of various support files,
|
|
timeouts,
|
|
default modes,
|
|
etc.
|
|
.sh 1 "COMPARISON WITH OTHER MAILERS"
|
|
.sh 2 "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.
|
|
.sh 2 "MMDF"
|
|
.pp
|
|
MMDF
|
|
[Crocker79]
|
|
spans a wider problem set than
|
|
.i sendmail .
|
|
For example,
|
|
the domain of
|
|
MMDF includes a
|
|
.q "phone network"
|
|
mailer, whereas
|
|
.i sendmail
|
|
calls on preexisting mailers in most cases.
|
|
.pp
|
|
MMDF and
|
|
.i sendmail
|
|
both support aliasing,
|
|
customized mailers,
|
|
message batching,
|
|
automatic forwarding to gateways,
|
|
queueing,
|
|
and retransmission.
|
|
MMDF supports two-stage timeout,
|
|
which
|
|
.i sendmail
|
|
does not support.
|
|
.pp
|
|
The configuration for MMDF
|
|
is compiled into the code\**.
|
|
.(f
|
|
\**Dynamic configuration tables are currently being considered
|
|
for MMDF;
|
|
allowing the installer to select either compiled
|
|
or dynamic tables.
|
|
.)f
|
|
.pp
|
|
Since MMDF does not consider backwards compatibility
|
|
as a design goal,
|
|
the address parsing is simpler but much less flexible.
|
|
.pp
|
|
It is somewhat harder to integrate a new channel\**
|
|
.(f
|
|
\**The MMDF equivalent of a
|
|
.i sendmail
|
|
.q mailer.
|
|
.)f
|
|
into MMDF.
|
|
In particular,
|
|
MMDF must know the location and format
|
|
of host tables for all channels,
|
|
and the channel must speak a special protocol.
|
|
This allows MMDF to do additional verification
|
|
(such as verifying host names)
|
|
at submission time.
|
|
.pp
|
|
MMDF strictly separates the submission and delivery phases.
|
|
Although
|
|
.i sendmail
|
|
has the concept of each of these stages,
|
|
they are integrated into one program,
|
|
whereas in MMDF they are split into two programs.
|
|
.sh 2 "Message Processing Module"
|
|
.pp
|
|
The Message Processing Module (MPM)
|
|
discussed by Postel [Postel79b]
|
|
matches
|
|
.i sendmail
|
|
closely in terms of its basic architecture.
|
|
However,
|
|
like MMDF,
|
|
the MPM includes the network interface software
|
|
as part of its domain.
|
|
.pp
|
|
MPM also postulates a duplex channel to the receiver,
|
|
as does MMDF,
|
|
thus allowing simpler handling of errors
|
|
by the mailer
|
|
than is possible in
|
|
.i sendmail .
|
|
When a message queued by
|
|
.i sendmail
|
|
is sent,
|
|
any errors must be returned to the sender
|
|
by the mailer itself.
|
|
Both MPM and MMDF mailers
|
|
can return an immediate error response,
|
|
and a single error processor can create an appropriate response.
|
|
.pp
|
|
MPM prefers passing the message as a structured object,
|
|
with type-length-value tuples\**.
|
|
.(f
|
|
\**This is similar to the NBS standard.
|
|
.)f
|
|
Such a convention requires a much higher degree of cooperation
|
|
between mailers than is required by
|
|
.i sendmail .
|
|
MPM also assumes a universally agreed upon internet name space
|
|
(with each address in the form of a net-host-user tuple),
|
|
which
|
|
.i sendmail
|
|
does not.
|
|
.sh 1 "EVALUATIONS AND FUTURE PLANS"
|
|
.pp
|
|
.i Sendmail
|
|
is designed to work in a nonhomogeneous environment.
|
|
Every attempt is made to avoid imposing unnecessary 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]
|
|
and [Postel79b].
|
|
.pp
|
|
A nonuniform address space implies that a path will be specified
|
|
in all addresses,
|
|
either explicitly (as part of the address)
|
|
or implicitly
|
|
(as with implied forwarding to gateways).
|
|
This restriction has the unpleasant effect of making replying to messages
|
|
exceedingly difficult,
|
|
since there is no one
|
|
.q address
|
|
for any person,
|
|
but only a way to get there from wherever you are.
|
|
.pp
|
|
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.
|
|
.pp
|
|
.i Sendmail
|
|
has knowledge of a few difficult environments
|
|
built in.
|
|
It generates ARPANET FTP/SMTP compatible error messages
|
|
(prepended with three-digit numbers
|
|
[Neigus73, Postel74, Postel82])
|
|
as necessary,
|
|
optionally generates UNIX-style
|
|
.q From
|
|
lines on the front of messages for some mailers,
|
|
and knows how to parse the same lines on input.
|
|
Also,
|
|
error handling has an option customized for BerkNet.
|
|
.pp
|
|
The decision to avoid doing any type of delivery where possible
|
|
(even, or perhaps especially, local delivery)
|
|
has turned out to be a good idea.
|
|
Even with local delivery,
|
|
there are issues of the location of the mailbox,
|
|
the format of the mailbox,
|
|
the locking protocol used,
|
|
etc.,
|
|
that are best decided by other programs.
|
|
One surprisingly major annoyance in many internet mailers
|
|
is that the location and format of local mail is built in.
|
|
The feeling seems to be that local mail is so common
|
|
that it should be efficient.
|
|
This feeling is not born out by
|
|
our experience;
|
|
on the contrary,
|
|
the location and format of mailboxes seems to vary widely
|
|
from system to system.
|
|
.pp
|
|
The ability to automatically generate a response to incoming mail
|
|
(by forwarding mail to a program)
|
|
seems useful
|
|
(\c
|
|
.q "I am on vacation until late August...." )
|
|
but can create problems
|
|
such as forwarding loops
|
|
(two people on vacation whose programs send notes back and forth,
|
|
for instance)
|
|
if these programs are not well written.
|
|
A program could be written to do standard tasks correctly,
|
|
but this would solve the general case.
|
|
.pp
|
|
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.
|
|
.pp
|
|
The configuration file is currently practically inscrutable;
|
|
considerable convenience could be realized
|
|
with a higher-level format.
|
|
.pp
|
|
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
|
|
(e.g., [NBS80])
|
|
or to the body of the message itself
|
|
(such as for multimedia messages
|
|
[Postel80]).
|
|
Experience indicates that
|
|
these changes should be relatively trivial to integrate
|
|
into the existing system.
|
|
.pp
|
|
In tightly coupled environments,
|
|
it would be nice to have a name server
|
|
such as Grapvine
|
|
[Birrell82]
|
|
integrated into the mail system.
|
|
This would allow a site such as
|
|
.q Berkeley
|
|
to appear as a single host,
|
|
rather than as a collection of hosts,
|
|
and would allow people to move transparently among machines
|
|
without having to change their addresses.
|
|
Such a facility
|
|
would require an automatically updated database
|
|
and some method of resolving conflicts.
|
|
Ideally this would be effective even without
|
|
all hosts being under
|
|
a single management.
|
|
However,
|
|
it is not clear whether this feature
|
|
should be integrated into the
|
|
aliasing facility
|
|
or should be considered a
|
|
.q "value added"
|
|
feature outside
|
|
.i sendmail
|
|
itself.
|
|
.pp
|
|
As a more interesting case,
|
|
the CSNET name server
|
|
[Solomon81]
|
|
provides an facility that goes beyond a single
|
|
tightly-coupled environment.
|
|
Such a facility would normally exist outside of
|
|
.i sendmail
|
|
however.
|
|
.sh 0 "ACKNOWLEDGEMENTS"
|
|
.pp
|
|
Thanks are due to Kurt Shoens for his continual cheerful
|
|
assistance and good advice,
|
|
Bill Joy for pointing me in the correct direction
|
|
(over and over),
|
|
and Mark Horton for more advice,
|
|
prodding,
|
|
and many of the good ideas.
|
|
Kurt and Eric Schmidt are to be credited
|
|
for using
|
|
.i delivermail
|
|
as a server for their programs
|
|
(\c
|
|
.i Mail
|
|
and BerkNet respectively)
|
|
before any sane person should have,
|
|
and making the necessary modifications
|
|
promptly and happily.
|
|
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
|
|
.i rmail ,
|
|
and was the person who really convinced me
|
|
to put the work into
|
|
.i delivermail
|
|
to turn it into
|
|
.i sendmail .
|
|
Kurt deserves accolades for using
|
|
.i sendmail
|
|
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.
|
|
.pp
|
|
Kurt,
|
|
Mark,
|
|
Kirk McKusick,
|
|
Marvin Solomon,
|
|
and many others have reviewed this paper,
|
|
giving considerable useful advice.
|
|
.pp
|
|
Special thanks are reserved for Mike Stonebraker at Berkeley
|
|
and Bob Epstein at Britton-Lee,
|
|
who both knowingly allowed me to put so much work into this
|
|
project
|
|
when there were so many other things I really should
|
|
have been working on.
|
|
.+c
|
|
.ce
|
|
REFERENCES
|
|
.nr ii 1.5i
|
|
.ip [Birrell82]
|
|
Birrell, A. D.,
|
|
Levin, R.,
|
|
Needham, R. M.,
|
|
and
|
|
Schroeder, M. D.,
|
|
.q "Grapevine: An Exercise in Distributed Computing."
|
|
In
|
|
.ul
|
|
Comm. A.C.M. 25,
|
|
4,
|
|
April 82.
|
|
.ip [Borden79]
|
|
Borden, S.,
|
|
Gaines, R. S.,
|
|
and
|
|
Shapiro, N. Z.,
|
|
.ul
|
|
The MH Message Handling System: Users' Manual.
|
|
R-2367-PAF.
|
|
Rand Corporation.
|
|
October 1979.
|
|
.ip [Crocker77a]
|
|
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 [Crocker77b]
|
|
Crocker, D. H.,
|
|
.ul
|
|
Framework and Functions of the MS Personal Message System.
|
|
R-2134-ARPA,
|
|
Rand Corporation,
|
|
Santa Monica, California.
|
|
1977.
|
|
.ip [Crocker79]
|
|
Crocker, D. H.,
|
|
Szurkowski, E. S.,
|
|
and
|
|
Farber, D. J.,
|
|
.ul
|
|
An Internetwork Memo Distribution Facility \*- MMDF.
|
|
6th Data Communication Symposium,
|
|
Asilomar.
|
|
November 1979.
|
|
.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 [Metcalfe76]
|
|
Metcalfe, R.,
|
|
and
|
|
Boggs, D.,
|
|
.q "Ethernet: Distributed Packet Switching for Local Computer Networks" ,
|
|
.ul
|
|
Communications of the ACM 19,
|
|
7.
|
|
July 1976.
|
|
.ip [Feinler78]
|
|
Feinler, E.,
|
|
and
|
|
Postel, J.
|
|
(eds.),
|
|
.ul
|
|
ARPANET Protocol Handbook.
|
|
NIC 7104,
|
|
Network Information Center,
|
|
SRI International,
|
|
Menlo Park, California.
|
|
1978.
|
|
.ip [NBS80]
|
|
National Bureau of Standards,
|
|
.ul
|
|
Specification of a Draft Message Format Standard.
|
|
Report No. ICST/CBOS 80-2.
|
|
October 1980.
|
|
.ip [Neigus73]
|
|
Neigus, N.,
|
|
.ul
|
|
File Transfer Protocol for the ARPA Network.
|
|
RFC 542, NIC 17759.
|
|
In [Feinler78].
|
|
August, 1973.
|
|
.ip [Nowitz78a]
|
|
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 [Nowitz78b]
|
|
Nowitz, D. A.,
|
|
.ul
|
|
Uucp Implementation Description.
|
|
Bell Laboratories.
|
|
In
|
|
UNIX Programmer's Manual, Seventh Edition,
|
|
Volume 2.
|
|
October, 1978.
|
|
.ip [Postel74]
|
|
Postel, J.,
|
|
and
|
|
Neigus, N.,
|
|
Revised FTP Reply Codes.
|
|
RFC 640, NIC 30843.
|
|
In [Feinler78].
|
|
June, 1974.
|
|
.ip [Postel77]
|
|
Postel, J.,
|
|
.ul
|
|
Mail Protocol.
|
|
NIC 29588.
|
|
In [Feinler78].
|
|
November 1977.
|
|
.ip [Postel79a]
|
|
Postel, J.,
|
|
.ul
|
|
Internet Message Protocol.
|
|
RFC 753,
|
|
IEN 85.
|
|
Network Information Center,
|
|
SRI International,
|
|
Menlo Park, California.
|
|
March 1979.
|
|
.ip [Postel79b]
|
|
Postel, J. B.,
|
|
.ul
|
|
An Internetwork Message Structure.
|
|
In
|
|
.ul
|
|
Proceedings of the Sixth Data Communications Symposium,
|
|
IEEE.
|
|
New York.
|
|
November 1979.
|
|
.ip [Postel80]
|
|
Postel, J. B.,
|
|
.ul
|
|
A Structured Format for Transmission of Multi-Media Documents.
|
|
RFC 767.
|
|
Network Information Center,
|
|
SRI International,
|
|
Menlo Park, California.
|
|
August 1980.
|
|
.ip [Postel82]
|
|
Postel, J. B.,
|
|
.ul
|
|
Simple Mail Transfer Protocol.
|
|
RFC821
|
|
(obsoleting RFC788).
|
|
Network Information Center,
|
|
SRI International,
|
|
Menlo Park, California.
|
|
August 1982.
|
|
.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 [Sluizer81]
|
|
Sluizer, S.,
|
|
and
|
|
Postel, J. B.,
|
|
.ul
|
|
Mail Transfer Protocol.
|
|
RFC 780.
|
|
Network Information Center,
|
|
SRI International,
|
|
Menlo Park, California.
|
|
May 1981.
|
|
.ip [Solomon81]
|
|
Solomon, M., Landweber, L., and Neuhengen, D.,
|
|
.q "The Design of the CSNET Name Server."
|
|
CS-DN-2,
|
|
University of Wisconsin, Madison.
|
|
November 1981.
|
|
.ip [Su82]
|
|
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 [UNIX83]
|
|
.ul
|
|
The UNIX Programmer's Manual, Seventh Edition,
|
|
Virtual VAX-11 Version,
|
|
Volume 1.
|
|
Bell Laboratories,
|
|
modified by the University of California,
|
|
Berkeley, California.
|
|
March, 1983.
|