These have been removed from the sendmail distribution so move them here.

2 files changed, 1469 insertions, 0 deletions

diff --git a/share/doc/smm/09.sendmail/Makefile b/share/doc/smm/09.sendmail/Makefile
new file mode 100644
index 00000000000..6369a4a0fec
--- /dev/null
+++ b/share/doc/smm/09.sendmail/Makefile
@@ -0,0 +1,13 @@
+#	@(#)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/share/doc/smm/09.sendmail/intro.me b/share/doc/smm/09.sendmail/intro.me
new file mode 100644
index 00000000000..03cfa336994
--- /dev/null
+++ b/share/doc/smm/09.sendmail/intro.me
@@ -0,0 +1,1456 @@
+.\" 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.