Remove files no longer in vendor release from vendor branch.

6 files changed, 0 insertions, 3545 deletions

diff --git a/contrib/sendmail/doc/changes/Makefile b/contrib/sendmail/doc/changes/Makefile
deleted file mode 100644
index 76eaa39..0000000
--- a/contrib/sendmail/doc/changes/Makefile
+++ /dev/null
@@ -1,13 +0,0 @@
-#	@(#)Makefile	8.1 (Berkeley) 4/13/1994
-
-DIR=	smm/09.sendmail
-SRCS=	changes.me
-MACROS=	-me
-
-all: changes.ps
-
-changes.ps: ${SRCS}
-	rm -f ${.TARGET}
-	${PIC} ${SRCS} | ${ROFF} > ${.TARGET}
-
-.include <bsd.doc.mk>
diff --git a/contrib/sendmail/doc/changes/changes.me b/contrib/sendmail/doc/changes/changes.me
deleted file mode 100644
index b963396..0000000
--- a/contrib/sendmail/doc/changes/changes.me
+++ /dev/null
@@ -1,975 +0,0 @@
-.\" Copyright (c) 1998 Sendmail, Inc.  All rights reserved.
-.\" Copyright (c) 1994 Eric P. Allman.  All rights reserved.
-.\" Copyright (c) 1988, 1994
-.\"	The Regents of the University of California.  All rights reserved.
-.\"
-.\" By using this file, you agree to the terms and conditions set
-.\" forth in the LICENSE file which can be found at the top level of
-.\" the sendmail distribution.
-.\"
-.\"
-.\"	@(#)changes.me	8.7 (Berkeley) 5/19/1998
-.\"
-.\"	ditroff -me -Pxx changes.me
-.eh '%''Changes in Sendmail Version 8'
-.oh 'Changes in Sendmail Version 8''%'
-.nr si 3n
-.if n .ls 2
-.+c
-.(l C
-.sz 14
-Changes in Sendmail Version 8*
-.sz
-.sp
-Eric Allman
-.sp 0.5
-.i
-University of California, Berkeley
-Mammoth Project
-.)l
-.(f
-*An earlier version of this paper was printed in the
-Proceedings of the 1994 AUUG Queensland Summer Technical Conference,
-Gateway Hotel, Brisbane, March 1994.
-.)f
-.sp
-.(l F
-.ce
-ABSTRACT
-.sp \n(psu
-Version 8 of
-.i sendmail
-includes a number of major changes from previous versions.
-This paper gives a very short history of
-.i sendmail ,
-a summary of the major differences between version 5
-(the last publically available version)
-and version 8,
-and some discussion of future directions.
-.)l
-.sp 2
-.pp
-In 1987, the author stopped major work on
-.i sendmail
-due to other time committments,
-only to return to active work in 1991.
-This paper explores why work resumed
-and what changes have been made.
-.pp
-Section 1 gives a short history of
-.i sendmail
-through version 5 and the motivation behind working on version 8.
-Section 2 has
-a rather detailed description of what has changed
-between version 5 and version 8.
-The paper finishes off with some thoughts
-about what still needs to be done.
-.sh 1 "HISTORY"
-.pp
-As discussed elsewhere,
-[Allman83a, Allman83b, Allman&Amos85]
-sendmail has existed in various forms since 1980.
-It was released under the name
-.i delivermail
-in 4BSD and 4.1BSD, and as
-.i sendmail
-in 4.2BSD.
-.\"4.0BSD	delivermail 1.10
-.\"4.1BSD	delivermail 1.10
-.\"4.2BSD	sendmail 4.12
-.\"4.3BSD	sendmail 5.52
-It quickly became the dominant mail system for networked UNIX systems.
-.pp
-Prior the release of 4.3BSD in November 1986,
-the author had left the University for private industry,
-but continued to do some work on
-.i sendmail
-with activity slowly trailing off
-until effectively stopping after February 1987.
-There was minimal support done by many people for several years,
-until July of 1991 when the original author,
-who had returned the University,
-started active work on it again.
-.pp
-There were several reasons for renewed work on
-.i sendmail .
-There was a desire at Berkeley to convert to a subdomained structure
-so that individuals were identified by their subdomain
-rather than by their individual workstation;
-although possible in the old code, there were some problems,
-and the author was the obvious person to address them.
-The Computer Systems Research Group (CSRG),
-the group that produced the Berkeley Software Distributions,
-was working on 4.4BSD,
-and wanted an update to the mail system.
-Bryan Costales was working on a book on
-.i sendmail
-that was being reviewed by the author,
-which encouraged him to make some revisions.
-And the author wanted to try to unify some of the disparate versions of
-.i sendmail
-that had been permitted to proliferate.
-.pp
-During the 1987\-91 fallow period,
-many vendors and outside volunteers
-had produced variants of
-.i sendmail .
-Perhaps the best known is the IDA version
-[IDA87].
-Originally intended to be a new set of configuration files,
-IDA expanded into a fairly large set of patches for the code.
-Originally produced in Sweden,
-IDA development passed to the University of Illinois,
-and was widely used by the fairly large set of people
-who prefer to get and compile their own source code
-rather than use vendor-supplied binaries.
-.pp
-In about the same time frame,
-attempts were made to clean up and extend the Simple Mail Transport Protocol
-(SMTP)
-[RFC821].
-This involved clarifications of some ambiguities in the protocol,
-and correction of some problem areas
-[RFC1123],
-as well as extensions for additional functionality
-(dubbed Extended Simple Mail Transport Protocol, or ESMTP)
-[RFC1425, RFC1426, RFC1427]
-and a richer set of semantics in the body of messages
-(the Multipurpose Internet Mail Extensions, a.k.a. MIME)
-[RFC1521, RFC1344].
-Neither the IDA group nor most vendors
-were modifying
-.i sendmail
-to conform to these new standards.
-It seemed clear that these were ``good things''
-that should be encouraged.
-However, since no one was working on a publically available version of
-.i sendmail
-with these updates,
-they were unlikely to be widely deployed any time in the near future.
-.pp
-There are, of course, other mail transport agents available,
-such as
-.i MMDF
-.\"[ref],
-.i zmailer
-.\"[ref],
-.i smail
-.\"[ref],
-and
-.i PP
-.\"[ref].
-However, none of these seemed to be gaining the prominence of
-.i sendmail ;
-it appeared that most companies would not convert to another
-mail transport agent any time in the forseeable future.
-However, they might be persuaded to convert to a newer version of
-.i sendmail .
-.pp
-All of these convinced the author
-to work on a updated version of
-.i sendmail
-for public distribution.
-.pp
-The new version of
-.i sendmail
-is referred to as version eight (V8).
-Versions six and seven were skipped
-because of an agreement
-that all files in 4.4BSD would be numbered as
-.q 8.1 .
-Rather than have an external version number
-that differed from the file version numbers,
-.i sendmail
-just jumped directly to V8.
-.sh 1 "CHANGES IN VERSION EIGHT"
-.pp
-The following is a summary of the changes between the last commonly
-available version of sendmail from Berkeley (5.67) and the latest
-version (8.6.6).
-.pp
-Many of these are ideas that had been tried in IDA,
-but many of them were generalized in V8.
-.sh 2 "Performance Enhancements"
-.pp
-Instead of closing SMTP connections immediately, open connections are
-cached for possible future use.  There is a limit to the number of
-simultaneous open connections and the idle time of any individual
-connection.
-.pp
-This is of best help during queue processing (since there is the
-potential of many different messages going to one site), although
-it can also help when processing MX records which aren't handled
-by MX Piggybacking.
-.pp
-If two hosts with different names in a single message happen to
-have the same set of MX hosts, they can be sent in the same
-transaction.  Version 8 notices this and tries to batch the messages.
-.pp
-For example, if two sites ``foo.com'' and ``bar.com'' are both
-served by UUNET, they will have the same set of MX hosts and will
-be sent in one transaction.  UUNET will then split the message
-and send it to the two individual hosts.
-.sh 2 "RFC 1123 Changes"
-.pp
-A number of changes have been made to make sendmail ``conditionally
-compliant'' (that is, it satisfies all of the MUST clauses and most
-but not all of the SHOULD clauses in RFC 1123).
-.pp
-The major areas of change are (numbers are RFC 1123 section numbers):
-.nr ii 0.75i
-.ip \(sc5.2.7
-Response to RCPT command is fast.  Previously, sendmail
-expanded all aliases as far as it could \*- this could
-take a very long time, particularly if there were
-name server delays.  Version 8 only checks for the
-existence of an alias and does the expansion later.
-It does still do a DNS lookup if there is an explicit host name
-in the RCPT command,
-but this time is bounded.
-.ip \(sc5.2.8
-Numeric IP addresses are logged in Received: lines.
-This helps tracing spoofed messages.
-.ip \(sc5.2.17
-Self domain literal is properly handled.  Previously,
-if someone sent to user@[1.2.3.4], where 1.2.3.4 is
-your IP address, the mail would probably be rejected
-with a ``configuration error''.
-Version 8 can handle these addresses.
-.ip \(sc5.3.2
-Better control over individual timeouts.  RFC 821 specified
-no timeouts.  Older versions of sendmail had a single
-timeout, typically set to two hours.  Version 8 allows
-the configuration file to set timeouts for various
-SMTP commands individually.
-.ip \(sc5.3.3
-Error messages are sent as From:<>.  This was urged by
-RFC 821 and reiterated by RFC 1123, but older versions
-of sendmail never really did it properly.  Version 8
-does.  However, some systems cannot handle this
-perfectly legal address; if necessary, you can create
-a special mailer that uses the `g' flag to disable this.
-.ip \(sc5.3.3
-Error messages are never sent to <>.  Previously,
-sendmail was happy to send responses-to-responses which
-sometimes resulted in responses-to-responses-to-responses
-which resulted in ....  you get the idea.
-.ip \(sc5.3.3
-Route-addrs (the ugly ``<@hosta,@hostb:user@hostc>''
-syntax) are pruned.  RFC 821 urged the use of this
-bletcherous syntax.  RFC 1123 has seen the light and
-officially deprecates them, further urging that you
-eliminate all but ``user@hostc'' should you receive
-one of these things.  Version 8 is slightly more generous
-than the standards suggest; instead of stripping off all
-the route addressees, it only strips hosts off up to
-the one before the last one known to DNS, thus allowing
-you to have pseudo-hosts such as foo.BITNET.  The `R'
-option will turn this off.
-.lp
-The areas in which sendmail is not ``unconditionally compliant'' are:
-.ip \(sc5.2.6
-Sendmail does do header munging.
-.ip \(sc5.2.10
-Sendmail doesn't always use the exact SMTP message
-text from RFC 821.  This is a rather silly requirement.
-.ip \(sc5.3.1.1
-Sendmail doesn't guarantee only one connect for each
-host on queue runs.  Connection caching gives you most
-of this, but it does not provide a guarantee.
-.ip \(sc5.3.1.1
-Sendmail doesn't always provide an adequate limit
-on concurrency.  That is, there can be several
-independent sendmails running at once.  My feeling
-is that doing an absolute limit would be a mistake
-(it might result in lost mail).  However, if you use
-the XLA contributed software, most of this will be
-guaranteed (but I don't guarantee the guarantee).
-.sh 2 "Extended SMTP Support
-.pp
-Version 8 includes both sending and receiving support for Extended
-SMTP support as defined by RFC 1425 (basic) and RFC 1427 (SIZE);
-and limited support for RFC 1426 (BODY).
-The body support is minimal because the
-.q 8BITMIME
-body type is not currently advertised.
-Although such a body type will be accepted,
-it will not be correctly converted to 7 bits
-if speaking to a non-8-bit-MIME aware SMTP server.
-.pp
-.i Sendmail
-tries to speak ESMTP if you have the `a' flag set
-in the flags for the mailer descriptor,
-or if the other end advertises the fact that it speaks ESMTP.
-This is a non-standard advertisement:
-.i sendmail
-announces
-.q "ESMTP spoken here"
-during the initial connection message,
-and client sendmails search for this message.
-This creates some problems for some PC-based mailers,
-which do not understand two-line greeting messages
-as required by RFC 821.
-.sh 2 "Eight-Bit Clean
-.pp
-Previous versions of sendmail used the 0200 bit for quoting.  This
-version avoids that use.
-However, you can set option `7' to get seven bit stripping
-for compatibility with RFC 821,
-which is a 7-bit protocol.
-This option says ``strip to 7 bits on input''.
-.pp
-Individual mailers can still produce seven bit out put using the
-`7' mailer flag.
-This flag says ``strip to 7 bits on output''.
-.sh 2 "User Database"
-.pp
-The User Database (UDB) is an as-yet experimental attempt to provide
-unified large-site name support.
-We are installing it at Berkeley;
-future versions may show significant modifications.
-Briefly, UDB contains a database that is intended to contain
-all the per-user information for your workgroup,
-such as people's full names, their .plan information,
-their outgoing mail name, and their mail drop.
-.pp
-The user database allows you to map both incoming and outgoing
-addresses, much like IDA.  However, the interface is still
-better with IDA;
-in particular, the alias file with incoming/outgoing marks
-provides better locality of information.
-.sh 2 "Improved BIND Support"
-.pp
-The BIND support, particularly for MX records, had a number of
-annoying ``features'' which have been removed in this release.  In
-particular, these more tightly bind (pun intended) the name server
-to sendmail, so that the name server resolution rules are incorporated
-directly into sendmail.
-.pp
-The major change has been that the $[ ... $] operator didn't fully
-qualify names that were in DNS as A or MX records.  Version 8 does
-this qualification.
-.pp
-This has proven to be an annoyance in Sun shops,
-who often still run without BIND support.
-However, it is really critical that this be supported,
-since MX records are mandatory.
-In SunOS you can choose either MX support or NIS support,
-but not both.
-This is fixed in Solaris,
-and some
-.i sendmail
-support to allow this in SunOS should be forthcoming in a future release.
-.sh 2 "Keyed Files"
-.pp
-Generalized keyed files is an idea taken directly from IDA sendmail
-(albeit with a completely different implementation).
-They can be useful on large sites.
-.pp
-Version 8 includes the following built-in map classes:
-.ip dbm
-Support for the ndbm(3) library.
-.ip hash
-Support for the ``Hash'' type from the new Berkeley db(3) library.
-this library provides substantially better database support
-than ndbm(3),
-including in-memory caching,
-arbitrarily long keys and values,
-and better disk utilization.
-.ip btree
-Support for the ``B-Tree'' type from the new Berkeley db(3) library.
-B-Trees provide better clustering than Hashed files
-if you are fetching lots of records that have similar keys,
-such as searching a dictionary for words beginning with ``detr''.
-.ip nis
-Support for NIS (a.k.a. YP) maps.
-NIS+ is not supported in this version.
-.ip host
-Support for DNS lookups.
-.ip dequote
-A ``pseudo-map'' (that is, once that does not have any external data)
-that allows a configuration file to break apart a quoted string
-in the address.
-This is necessary primarily for DECnet addresses,
-which often have quoted addresses that need to be unwrapped on gateways.
-.sh 2 "Multi-Word Classes & Macros in Classes"
-.pp
-Classes can now be multiple words.  For example,
-.(b
-CShofmann.CS.Berkeley.EDU
-.)b
-allows you to match the entire string ``hofmann.CS.Berkeley.EDU''
-using the single construct ``$=S''.
-.pp
-Class definitions are now allowed to include macros \*- for example:
-.(b
-Cw$k
-.)b
-is legal.
-.sh 2 "IDENT Protocol Support"
-.pp
-The IDENT protocol as defined in RFC 1413 [RFC1413] is supported.
-However, many systems have a TCP/IP bug that renders this useless,
-and the feature must be turned off.
-Roughly, if one of these system receives a
-.q "No route to host"
-message (ICMP message ICMP_UNREACH_HOST) on
-.i any
-connection, all connections to that host are closed.
-Some firewalls return this error if you try to connect
-to the IDENT port,
-so you can't receive email from these hosts on these systems.
-It's possible that if the firewall used a more specific message
-(such as ICMP_UNREACH_PROTOCOL, ICMP_UNREACH_PORT or ICMP_UNREACH_NET_PROHIB)
-it would work, but this hasn't been verified.
-.pp
-IDENT protocol support cannot be used on
-4.3BSD,
-Apollo DomainOS,
-Apple A/UX,
-ConvexOS,
-Data General DG/UX,
-HP-UX,
-Sequent Dynix,
-or
-Ultrix 4.x, x \(<= 3.
-It seems to work on
-4.4BSD,
-IBM AIX 3.x,
-OSF/1,
-SGI IRIX,
-Solaris,
-SunOS,
-and Ultrix 4.4.
-.sh 2 "Separate Envelope/Header Processing
-.pp
-Since the From: line is passed in separately from the envelope
-sender, these have both been made visible; the $g macro is set to
-the envelope sender during processing of mailer argument vectors
-and the header sender during processing of headers.
-.pp
-It is also possible to specify separate per-mailer envelope and
-header processing.  The SenderRWSet and RecipientRWset arguments
-for mailers can be specified as ``envelope/header'' to give different
-rewritings for envelope versus header addresses.
-.sh 2 "Owner-List Propagates to Envelope
-.pp
-When an alias has an associated owner-list name, that alias is used
-to change the envelope sender address.  This will cause downstream
-errors to be returned to that owner.
-.pp
-Some people find this confusing
-because the envelope sender is what appears in the first
-``From_'' line in UNIX messages
-(that is, the line beginning ``From<space>''
-instead of ``From:'';
-the latter is the header from, which
-.i does
-indicate the sender of the message).
-In previous versions,
-.i sendmail
-has tried to avoid changing the envelope sender
-for back compatibility with UNIX convention;
-at this point that back compatibility is creating too many problems,
-and it is necessary to move forward into the 1980s.
-.sh 2 "Command Line Flags"
-.pp
-The
-.b \-B
-flag has been added to pass in body type information.
-.pp
-The
-.b \-p
-flag has been added to pass in protocol information
-that was previously passed in by defining the
-.b $r
-and
-.b $s
-macros.
-.pp
-The
-.b \-X
-flag has been added to allow logging of all protocol in and
-out of sendmail for debugging.
-You can set
-.q "\-X filename"
-and a complete transcript will be logged in that file.
-This gets big fast: the option is only for debugging.
-.pp
-The
-.b \-q
-flag can limit limit a queue run to specific recipients,
-senders, or queue ids using \-qRsubstring, \-qSsubstring, or
-\-qIsubstring respectively.
-.sh 2 "New Configuration Line Types
-.pp
-The `T' (Trusted users) configuration line has been deleted.  It
-will still be accepted but will be ignored.
-.pp
-The `K' line has been added to declare database maps.
-.pp
-The `V' line has been added to declare the configuration version
-level.
-.pp
-The `M' (mailer) line takes a D= field to specify execution
-directory.
-.sh 2 "New and Extended Options"
-.pp
-Several new options have been added, many to support new features,
-others to allow tuning that was previously available only by
-recompiling.  Briefly:
-.nr ii 0.5i
-.ip A
-The alias file specification can now be a list of alias files.
-Also, the configuration can specify a class of file.
-For example, to search the NIS aliases, use
-.q OAnis:mail.aliases .
-.ip b
-Insist on a minimum number of disk blocks.
-.ip C
-Delivery checkpoint interval.  Checkpoint the queue (to avoid
-duplicate deliveries) every C addresses.
-.ip E
-Default error message.  This message (or the contents of the
-indicated file) are prepended to error messages.
-.ip G
-Enable GECOS matching.  If you can't find a local user name
-and this option is enabled, do a sequential scan of the passwd
-file to match against full names.  Previously a compile option.
-.ip h
-Maximum hop count.  Previously this was compiled in.
-.ip I
-This option has been extended to allow setting of resolver parameters.
-.ip j
-Send errors in MIME-encapsulated format.
-.ip J
-Forward file path.  Where to search for .forward files \*- defaults
-to $HOME/.forward.
-.ip k
-Connection cache size.  The total number of connections that will
-be kept open at any time.
-.ip K
-Connection cache lifetime.  The amount of time any connection
-will be permitted to sit idle.
-.ip l
-Enable Errors-To: header.  These headers violate RFC 1123;
-this option is included to provide back compatibility with
-old versions of sendmail.
-.ip O
-Incoming daemon options (e.g., use alternate SMTP port).
-.ip p
-Privacy options.  These can be used to make your SMTP server
-less friendly.
-.ip r
-This option has been extended to allow finer grained control
-over timeouts.
-For example, you can set the timeout for SMTP commands individually.
-.ip R
-Don't prune route-addrs.  Normally, if version 8 sees an address
-like "<@hostA,@hostB:user@hostC>, sendmail will try to strip off
-as much as it can (up to user@hostC) as suggested by RFC 1123.
-This option disables that behaviour.
-.ip T
-The
-.q "Return To Sender"
-timeout has been extended
-to allow specification of a warning message interval,
-typically something on the order of four hours.
-If a message cannot be delivered in that interval,
-a warning message is sent back to the sender
-but the message continues to be tried.
-.ip U
-User database spec.  This is still experimental.
-.ip V
-Fallback ``MX'' host.  This can be thought of as an MX host
-that applies to all addresses that has a very high preference
-value (that is, use it only if everything else fails).
-.ip w
-If set, assume that if you are the best MX host for a host,
-you should send directly to that host.  This is intended
-for compatibility with UIUC sendmail, and may have some
-use on firewalls.
-.ip 7
-Do not run eight bit clean.  Technically, you have to assert
-this option to be RFC 821 compatible.
-.sh 2 "New Mailer Definitions"
-.ip L=
-Set the allowable line length.  In V5, the L mailer flag implied
-a line length limit of 990 characters; this is now settable to
-an arbitrary value.
-.ip F=a
-Try to use ESMTP.  It will fall back to SMTP if the initial
-EHLO packet is rejected.
-.ip F=b
-Ensure a blank line at the end of messages.  Useful on the
-*file* mailer.
-.ip F=c
-Strip all comments from addresses; this should only be used as
-a last resort when dealing with cranky mailers.
-.ip F=g
-Never use the null sender as the envelope sender, even when
-running SMTP.  This violates RFC 1123.
-.ip F=7
-Strip all output to this mailer to 7 bits.
-.ip F=L
-Used to set the line limit to 990 bytes for SMTP compatibility.
-It now does that only if the L= keyletter is not specified.
-This flag is obsolete and should not be used.
-.sh 2 "New or Changed Pre-Defined Macros"
-.ip $k
-UUCP node name from uname(2).
-.ip $m
-Domain part of our full hostname.
-.ip $_
-RFC 1413-provided sender address.
-.ip $w
-Previously was sometimes the full domain name, sometimes
-just the first word.  Now guaranteed to be the first word
-of the domain name (i.e., the host name).
-.ip $j
-Previously had to be defined \*- it is now predefined to be
-the full domain name, if that can be determined.  That is,
-it is equivalent to $w.$m.
-.sh 2 "New and Changed Classes"
-.ip $=k
-Initialized to contain $k.
-.ip $=w
-Now includes
-.q [1.2.3.4]
-(where 1.2.3.4 is your IP address)
-to allow the configuration file to recognize your own IP address.
-.sh 2 "New Rewriting Tokens"
-.pp
-The
-.b $&
-construct has been adopted from IDA to defer macro evaluation.
-Normally, macros in rulesets are bound when the rule is first parsed
-during startup.
-Some macros change during processing and are uninteresting during startup.
-However, that macro can be referenced using
-.q $&x
-to defer the evaulation of
-$x
-until the rule is processed.
-.pp
-The tokens
-.b $(
-and
-.b $)
-have been added to allow specification of map rewriting.
-.pp
-Version 8 allows
-.b $@
-on the Left Hand Side of an `R' line to match
-zero tokens.
-This is intended to be used to match the null input.
-.sh 2 "Bigger Defaults
-.pp
-Version 8 allows up to 100 rulesets instead of 30.  It is recommended
-that rulesets 0\-9 be reserved for sendmail's dedicated use in future
-releases.
-.pp
-The total number of MX records that can be used has been raised to
-20.
-.pp
-The number of queued messages that can be handled at one time has
-been raised from 600 to 1000.
-.sh 2 "Different Default Tuning Parameters
-.pp
-Version 8 has changed the default parameters for tuning queue costs
-to make the number of recipients more important than the size of
-the message (for small messages).  This is reasonable if you are
-connected with reasonably fast links.
-.sh 2 "Auto-Quoting in Addresses
-.pp
-Previously, the ``Full Name <email address>'' syntax would generate
-incorrect protocol output if ``Full Name'' had special characters
-such as dot.  This version puts quotes around such names.
-.sh 2 "Symbolic Names On Error Mailer
-.pp
-Several names have been built in to the $@ portion of the $#error
-mailer.  For example:
-.(b
-$#error $@NOHOST $: Host unknown
-.)b
-Prints the indicated message
-and sets the exit status of
-.i sendmail
-to
-.sm EX_NOHOST .
-.sh 2 "New Built-In Mailers"
-.pp
-Two new mailers, *file* and *include*, are included to define options
-when mailing to a file or a :include: file respectively.  Previously
-these were overloaded on the local mailer.
-.sh 2 "SMTP VRFY Doesn't Expand
-.pp
-Previous versions of sendmail treated VRFY and EXPN the same.  In
-this version, VRFY doesn't expand aliases or follow .forward files.
-.pp
-As an optimization, if you run with your default delivery mode
-being queue-only, the RCPT command will also not chase aliases and
-\&.forward files.
-It will chase them when it processes the queue.
-This speeds up RCPT processing.
-.sh 2 "[IPC] Mailers Allow Multiple Hosts
-.pp
-When an address resolves to a mailer that has ``[IPC]'' as its
-``Path'', the $@ part (host name) can be a colon-separated list of
-hosts instead of a single hostname.  This asks sendmail to search
-the list for the first entry that is available exactly as though
-it were an MX record.  The intent is to route internal traffic
-through internal networks without publishing an MX record to the
-net.  MX expansion is still done on the individual items.
-.sh 2 "Aliases Extended"
-.pp
-The implementation has been merged with maps.  Among other things,
-this supports multiple alias files and NIS-based aliases.  For
-example:
-.(b
-OA/etc/aliases,nis:mail.aliases
-.)b
-will search first the local database
-.q /etc/aliases
-followed by the NIS map
-
-.sh 2 "Portability and Security Enhancements
-.pp
-A number of internal changes have been made to enhance portability.
-.pp
-Several fixes have been made to increase the paranoia factor.
-.pp
-In particular, the permissions required for .forward and :include:
-files have been tightened up considerably.  V5 would pretty much
-read any file it could get to as root, which exposed some security
-holes.  V8 insists that all directories leading up to the .forward
-or :include: file be searchable ("x" permission) by the controlling
-user" (defined below), that the file itself be readable by the
-controlling user, and that .forward files be owned by the user
-who is being forwarded to or root.
-.pp
-The "controlling user" is the user on whose behalf the mail is
-being delivered.  For example, if you mail to "user1" then the
-controlling user for ~user1/.forward and any mailers invoked
-by that .forward file, including :include: files.
-.pp
-Previously, anyone who had a home directory could create a .forward
-could forward to a program.  Now, sendmail checks to make sure
-that they have an "approved shell", that is, a shell listed in
-the /etc/shells file.
-.sh 2 "Miscellaneous Fixes and Enhancements"
-.pp
-A number of small bugs having to do with things like backslash-escaped
-quotes inside of comments have been fixed.
-.pp
-The fixed size limit on header lines
-(such as
-.q To:
-and
-.q Cc: )
-has been eliminated;
-those buffers are dynamically allocated now.
-.pp
-Sendmail writes a /etc/sendmail.pid file with the current process id
-and the current invocation flags.
-.pp
-Two people using the same program (e.g., submit) are considered
-"different" so that duplicate elimination doesn't delete one of
-them.  For example, two people forwarding their email to
-|submit will be treated as two recipients.
-.pp
-The mailstats program prints mailer names and gets the location of
-the sendmail.st file from /etc/sendmail.cf.
-.pp
-Many minor bugs have been fixed, such as handling of backslashes
-inside of quotes.
-.pp
-A hook has been added to allow rewriting of local addresses after
-aliasing.
-.sh 1 "FUTURE WORK"
-.pp
-The previous section describes
-.i sendmail
-as of version 8.6.6.
-There is still much to be done.
-Some high points are described below.
-This list is by no means exhaustive.
-.sh 2 "Full MIME Support"
-.pp
-Currently
-.i sendmail
-only supports seven bit MIME messages.
-Although it can pass eight bit MIME messages,
-it cannot advertise that fact because the standards say
-that the mail agent must be able to do 8- to 7-bit conversion
-to have full 8-bit support.
-This requires far more extensive modification of the message body
-than is currently supported.
-.pp
-The best way to do this would be to support the general concept
-of an external
-``message filter''
-that could do arbitrary modifications of the message.
-This would allow MIME conversion as well as such things as
-automatic encryption of messages sent over external links.
-This is probably an extremely non-trivial change.
-.sh 2 "Service Switch Abstraction"
-.pp
-Most modern systems include some concept of a
-.q "service switch"
-\*- for example, to look up host names you can try
-DNS, NIS, NIS+, text tables, NetInfo,
-or other services in some arbitrary order.
-This is currently very clumsy in
-.i sendmail ,
-with only limited control of the services provided.
-.sh 2 "More Control of Local Addresses"
-.pp
-Currently some addresses are declared as
-.q local
-and are handled specially \*-
-for example, they may have .forward files,
-may be translated into program calls or file deliveries,
-and so forth.
-These should be broken out into separate flags
-to allow the local system administrator
-to have more fine-grained control over operations.
-.sh 2 "More Run-Time Configuration Options"
-.pp
-There are many options that are configured at compile time,
-such as the method of file locking
-and the use of the IDENT protocol
-[RFC1413].
-These should be transfered to run time
-by adding new options.
-.pp
-Similarly, some options are currently overloaded,
-that is, a single option controls more than one thing.
-These should probably be broken out into separate options.
-.pp
-This implies that options will change from single characters
-to words.
-.sh 2 "More Configuration Control Over Errors"
-.pp
-Currently,
-the configuration file can generate an error message during parsing.
-However,
-it cannot tweak other operations,
-such as issuing a warning message to the system postmaster.
-Similarly,
-some errors should not be triggered if they are in aliases
-during an alias file rebuild,
-but should be triggered if that alias is actually used.
-.sh 2 "Long Term Host State"
-.pp
-Currently,
-.i sendmail
-only remembers host status during a single queue run.
-This should be converted to long term status
-stored on disk
-so it can be shared between instantiations of
-.i sendmail .
-Entries will have to be timestamped
-so they can time out.
-This will allow
-.i sendmail
-to implement exponential backoff on queue runs
-on a per-host basis.
-.sh 2 "Connection Control"
-.pp
-Modern networks have different types of connectivity
-than the past.
-In particular, the rising prominence of dialup IP
-has created certain challenges for automated servers.
-It is not uncommon to try to make a connection to a host
-and have it fail, even though if you tried again it would succeed.
-The connection management could be a bit cleverer
-to try to adapt to such situations.
-.sh 2 "Other Caching"
-.pp
-When you do an MX record lookup,
-the name server automatically returns the IP addresses
-of the associated MX servers.
-This information is currently ignored,
-and another query is done to get this information.
-It should be cached to avoid excess name server traffic.
-.sh 1 "REFERENCES"
-.ip [Allman83a]
-.q "Sendmail \*- An Internetwork Mail Router."
-E. Allman.
-In
-.ul
-Unix Programmers's Manual,
-4.2 Berkeley Software Distribution,
-volume 2C.
-August 1983.
-.ip [Allman83b]
-.q "Mail Systems and Addressing in 4.2BSD."
-E. Allman
-In
-.ul
-UNICOM Conference Proceedings.
-San Diego, California.
-January 1983.
-.ip [Allman&Amos85]
-``Sendmail Revisited.''
-E. Allman and M. Amos.
-In
-.ul
-Usenix Summer 1985 Conference Proceedings.
-Portland, Oregon.
-June 1985.
-.ip [IDA87]
-.ul 3
-Electronic Mail Addressing in Theory and Practice
-with the IDA Sendmail Enhancement Kit
-(or The Postmaster's Last Will and Testament).
-Lennart Lo\*:vstrand.
-Department of Computer and Information Science,
-University of Linko\*:ping,
-Sweden,
-Report no. LiTH-IDA-Ex-8715.
-May 1987.
-.ip [RFC821]
-.ul
-Simple Mail Transport Protocol.
-J. Postel.
-August 1982.
-.ip [RFC1123]
-.ul
-Requirements for Internet Hosts \*- Application and Support.
-Internet Engineering Task Force,
-R. Braden, Editor.
-October 1989.
-.ip [RFC1344]
-.ul
-Implications of MIME for Internet Mail Gateways.
-N. Borenstein.
-June 1992.
-.ip [RFC1413]
-.ul
-Identification Protocol.
-M. St. Johns.
-February 1993.
-.ip [RFC1425]
-.ul
-SMTP Service Extensions.
-J. Klensin, N. Freed, M. Rose, E. Stefferud, and D. Crocker.
-February 1993.
-.ip [RFC1426]
-.ul
-SMTP Service Extension for 8bit-MIMEtransport.
-J. Klensin, N. Freed, M. Rose, E. Stefferud, and D. Crocker.
-February 1993.
-.ip [RFC1427]
-.ul
-SMTP Service Extension for Message Size Declaration.
-J. Klensin, N. Freed, and K. Moore.
-February 1993.
-.ip [RFC1521]
-.ul 3
-MIME (Multipurpose Internet Mail Extensions) Part One:
-Mechanisms for Specifying and Describing
-the Format of Internet Message Bodies.
-N. Borenstein and N. Freed.
-September 1993.
diff --git a/contrib/sendmail/doc/intro/Makefile b/contrib/sendmail/doc/intro/Makefile
deleted file mode 100644
index 6369a4a..0000000
--- a/contrib/sendmail/doc/intro/Makefile
+++ /dev/null
@@ -1,13 +0,0 @@
-#	@(#)Makefile	8.2 (Berkeley) 2/28/1994
-
-DIR=	smm/09.sendmail
-SRCS=	intro.me
-MACROS=	-me
-
-all: intro.ps
-
-intro.ps: ${SRCS}
-	rm -f ${.TARGET}
-	${PIC} ${SRCS} | ${ROFF} > ${.TARGET}
-
-.include <bsd.doc.mk>
diff --git a/contrib/sendmail/doc/intro/intro.me b/contrib/sendmail/doc/intro/intro.me
deleted file mode 100644
index 03cfa33..0000000
--- a/contrib/sendmail/doc/intro/intro.me
+++ /dev/null
@@ -1,1456 +0,0 @@
-.\" Copyright (c) 1998 Sendmail, Inc.  All rights reserved.
-.\" Copyright (c) 1983 Eric P. Allman.  All rights reserved.
-.\" Copyright (c) 1988, 1993
-.\"	The Regents of the University of California.  All rights reserved.
-.\"
-.\" By using this file, you agree to the terms and conditions set
-.\" forth in the LICENSE file which can be found at the top level of
-.\" the sendmail distribution.
-.\"
-.\"
-.\"	@(#)intro.me	8.7 (Berkeley) 5/19/1998
-.\"
-.\"	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.
diff --git a/contrib/sendmail/doc/usenix/Makefile b/contrib/sendmail/doc/usenix/Makefile
deleted file mode 100644
index d2308cb..0000000
--- a/contrib/sendmail/doc/usenix/Makefile
+++ /dev/null
@@ -1,12 +0,0 @@
-#	@(#)Makefile	8.2 (Berkeley) 2/28/1994
-
-SRCS=	usenix.me
-MACROS=	-me
-
-all: usenix.ps
-
-usenix.ps: ${SRCS}
-	rm -f ${.TARGET}
-	${PIC} ${SRCS} | ${ROFF} > ${.TARGET}
-
-.include <bsd.doc.mk>
diff --git a/contrib/sendmail/doc/usenix/usenix.me b/contrib/sendmail/doc/usenix/usenix.me
deleted file mode 100644
index 4f88a94..0000000
--- a/contrib/sendmail/doc/usenix/usenix.me
+++ /dev/null
@@ -1,1076 +0,0 @@
-.nr si 3n
-.he 'Mail Systems and Addressing in 4.2bsd''%'
-.fo 'Version 8.2'USENIX \- Jan 83'Last Mod 11/27/1993'
-.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
-eric@Berkeley.ARPA
-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 "eric@a.cc.berkeley.arpa"
-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 eric@Berkeley.ARPA
-to
-.q eric@bli.UUCP
-or
-.q allman@IIASA.Austria
-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 eric@Berkeley.ARPA
-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
-eric@HostA.BigSite.ARPA
-.)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
-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 eric@ucbvax.UUCP
-(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
-mark@d.cbosg.btl.UUCP
-.)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 \&...@host.UUCP )
-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 eric@a.bli.UUCP
-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.