split documentation into two

[unix-history] / usr / src / usr.sbin / sendmail / doc / intro / intro.me

diff --git a/usr/src/usr.sbin/sendmail/doc/intro/intro.me b/usr/src/usr.sbin/sendmail/doc/intro/intro.me
index f29df9c..2918409 100644 (file)
--- a/usr/src/usr.sbin/sendmail/doc/intro/intro.me
+++ b/usr/src/usr.sbin/sendmail/doc/intro/intro.me
@@ -1,198 +1,240 @@
 .nr DR 1       \" this is a draft copy
 .nr si 3n
 .he 'SENDMAIL''%'
 .nr DR 1       \" this is a draft copy
 .nr si 3n
 .he 'SENDMAIL''%'

-.if \n(DR .fo 'For Your Eyes Only'\*-DRAFT\*-'\*(td'
+.if \n(DR .fo '\*-DRAFT\*-'\*(td'\*-DRAFT\*-'

 .ls 2
 .+c
 .(l C
 .ls 2
 .+c
 .(l C

-.sz 12
-SENDMAIL \*- An Internet Mail Router
+.sz 14
+SENDMAIL \*- An Internetwork Mail Router

 .sz
 .sp
 .sz
 .sp

-Eric Allman
+Eric Allman\(dg
+.sp 0.5

 .i
 Project INGRES
 Electronics Research Lab
 University of California
 Berkeley, California  94720
 .)l
 .i
 Project INGRES
 Electronics Research Lab
 University of California
 Berkeley, California  94720
 .)l

+.sp
+.(l F
+.ce
+ABSTRACT
+
+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 ad hoc basis.  However,
+this approach has become unmanageable as internets grow.
+
+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
+ad hoc addresses.  Mail is then dispatched to an outgoing mailer.
+This system can expand trivially.  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 is not intended to perform user interface functions or
+final delivery.  Sendmail also implements an SMTP server, message
+queueing, and aliasing.
+
+This is approach is unique in that it allows external compatibility
+with the old practices, and tries to make the mail system conform to
+the user instead of the other way around.  Although sendmail is not
+intended to circumvent new standards, it is intended to make the
+transition less painful.  Sendmail does require certain base-level
+standards on target mailers such as the basic semantics of certain
+headers and the surface syntax of messages.  New mailers can be added
+trivially; for example, a Purduenet channel was brought up in twenty
+minutes.
+.)l
+.sp 2

 .(f
 This is
 .if \n(DR draft
 .(f
 This is
 .if \n(DR draft

-version 3.3,
+version 3.20,

 last modified on %G%.
 .if \n(DR Please do not distribute this version without permission
 .if \n(DR of the author.
 .)f
 last modified on %G%.
 .if \n(DR Please do not distribute this version without permission
 .if \n(DR of the author.
 .)f

-.sp 2
+.(f
+\(dgAuthor's current address:
+Britton-Lee, Inc.
+1919 Addison Street, Suite 105.
+Berkeley, California 94704.
+.)f

 .pp
 .i Sendmail
 .pp
 .i Sendmail

-implements a general internetwork mail routing facility.
-Features include aliasing and forwarding,
+implements a general internetwork mail routing facility,
+featuring aliasing and forwarding,

 automatic routing to network gateways,
 and flexible configuration.
 .pp
 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,
+management is distributed.
+In particular,
+the syntax and semantics of resource identification change.
+Certain special cases can be handled trivially
+by 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 addresses.
+.pp
+A new set of 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 can 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,
+whereas the physical structure is implied.
+.pp
+.i Sendmail
+is intended to help bridge the gap
+between the totally 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 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.

-A detailed description of the configuration file
-is given in section 4,
-including a walkthrough of a specific configuration file.
-Section 5 compares
+Section 4 compares

 .i sendmail
 to other internet mail routers,
 and an evaluation of
 .i sendmail
 .i sendmail
 to other internet mail routers,
 and an evaluation of
 .i sendmail

-is given in section 6,
+is given in section 5,

 including future plans.
 .sh 1 "DESIGN GOALS"
 .pp
 including future plans.
 .sh 1 "DESIGN GOALS"
 .pp

-.i Sendmail
-was an outgrowth of
-.i delivermail,
-a previous incarnation of a UNIX internetwork mail router.
-.i Delivermail
-was written relatively quickly.
-The first version only knew about taking apart addresses
-for explicit forwarding
-and limited aliasing;
-automatic forwarding and other features
-came later.
-.pp

 Design goals for
 Design goals for

-.i delivermail
-included:
+.i sendmail
+include:

 .np
 Compatibility with the existing mail system,
 including Bell version 6 mail,
 .np
 Compatibility with the existing mail system,
 including Bell version 6 mail,

-Bell version 7 mail,
-Berkeley mail,
+Bell version 7 mail
+[UNIX80],
+Berkeley
+.i Mail
+[Shoens79],

 BerkNet mail
 BerkNet mail

-[Schmidt99],
+[Schmidt79],

 and hopefully UUCP mail
 [Nowitz78a, Nowitz78b].
 ARPANET mail
 [Crocker77a, Postel77]
 and hopefully UUCP mail
 [Nowitz78a, Nowitz78b].
 ARPANET mail
 [Crocker77a, Postel77]

-was also required,
-and the difference in format
-influenced the decision to put all such formatting
-into the low-level mailer.
+was also required.

 .np
 .np

-Because of time constraints,
-utilize as much existing software as possible.
-The changes to the existing software were minimal:
-Berkeley mail,
-BerkNet,
-UUCP, and the ARPANET FTP server
-had to be modified to call
-.i delivermail
-as their server instead of
-/bin/mail
-(or in the case of the ARPANET,
-instead of
-writing the mail into a file
-which has no meaning to standard UNIX mailers).
-The only major modifications
-were to /bin/mail,
-which was maintained both as a user interface sender
-and as a
-.i delivermail
-mailer.
-As a sender,
-it calls
-.i delivermail .
-.i Delivermail
-calls it in turn to do local delivery,
-so a
-.b \-d
-flag was added to avoid loops.
-.np
-Reliability was considered essential
+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 was considered essential

 because of the emphasis on mail in our environment.
 This 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,
 because of the emphasis on mail in our environment.
 This 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,

-MIT and CMU allow mail from people who are not logged in
-(and which have meaningless from addresses),
+certain sites generate incorrect from addresses

 which caused error message loops.
 which caused error message loops.

-CMU also puts blanks in names,
-which created amazing problems,
-since many UNIX mail programs assume that an address
+Some hosts use blanks in names,
+which created problems with
+UNIX mail programs that assume that an address

 is one word.
 is one word.

-And at least one person lists his address as
-.q "From: the TTY of ..." ,
-giving a
-.q Sender:
-field with his real address.
+The semantics of some fields
+are interpreted slightly differently
+by different sites.

 In summary,
 the obscure aspects of the ARPANET mail protocol
 In summary,
 the obscure aspects of the ARPANET mail protocol

-really are used and
+really
+.i are
+used and

 are difficult to support,
 but must be supported.
 But even obeying the standard is insufficient.
 For example,
 are difficult to support,
 but must be supported.
 But even obeying the standard is insufficient.
 For example,

-WHARTON changes our host name from
+Wharton changed our host name from

 .q BERKELEY
 to
 .q BERKEL- ,
 which confused error processing.
 .q BERKELEY
 to
 .q BERKEL- ,
 which confused error processing.

-Degenerate cases such as this
+Cases such as this

 must be handled gracefully.
 must be handled gracefully.

-.pp
-There were certain non-goals in
-.i delivermail
-also.
-Many of these resulted from the expectation that
-it would only be used at Berkeley,
-and probably only at a few sites at Berkeley.
-.np
-It was fair game to compile configuration information
-into the code,
-even to assume that they were running BerkNet.
-.np
-The problem of multiple connections to a single network
-was not foreseen.
-For example,
-on a host with no UUCP connection,
-all UUCP mail was sent to a single host.
-In fact,
-Berkeley is running UUCP on at least three hosts.

 .np
 .np

-No attempt was made to reduce the volume of mail across a network link.
-Besides the difficulty of doing this,
-we failed to appreciate how much volume there would be.
-.pp
-.i Sendmail
-maintained the goals of
-.i delivermail.
-Time was less of a constraint,
-but not reimplementing basic mailers
-has proven to be a wise move in many ways.
-For example,
-many internet mailers deliver local mail directly.
-This is more efficient,
-but builds in the design decisions
-of the local mailer,
-and makes it difficult to concentrate
-on the
-.q "real problems"
-(such as locking).
-Other design goals were:
+Existing software to do actual delivery
+should be used whenever possible.
+This resulted as much from political and practical considerations
+as technical.

 .np
 .i Sendmail
 .np
 .i Sendmail

-should operate in more complex environments,
+should allow fairly complex environments,

 including multiple
 connections to a single network type
 including multiple
 connections to a single network type

-(such as with multiple UUCP or Ether nets),
-requiring that the contents of a host field
-be considered,
-as well as just the syntax of an address,
+(such as with multiple UUCP or Ether nets
+[Metcalfe76]),
+requiring that the contents of an address
+be considered
+as well as the syntax,

 in order to determine the gateway to use.
 in order to determine the gateway to use.

-This results both from a desire to simplify use by other sites,
-and to anticipate the environment Berkeley is moving towards.
+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 binary should be able to run as is at any site
 .np
 Configuration should not be compiled into the code.
 A single binary should be able to run as is at any site


@@ -205,18 +247,13 @@ many sites like to
 .q fiddle
 with anything that they will be recompiling anyway.
 .np
 .q fiddle
 with anything that they will be recompiling anyway.
 .np

-.i Delivermail
-only knows about one alias file.
-Berkeley is a sufficiently open environment
-that this can be writable by everyone,
-but other environments are not so lax.
-Thus,
-.i sendmail
+.i Sendmail

 must be able to let various groups maintain their own mailing lists,
 must be able to let various groups maintain their own mailing lists,

-and individuals their own forwarding,
+and let individuals specify their own forwarding,

 without writing the system alias file.
 .np
 without writing the system alias file.
 .np

-Customized incoming mailers should be supported.
+Each user should be able to specify the mailer to execute
+to process mail being delivered for them.

 This allows users who are using specialized mailers
 that want to use a different format to build their environment
 without changing the system,
 This allows users who are using specialized mailers
 that want to use a different format to build their environment
 without changing the system,


@@ -228,51 +265,28 @@ message).
 Network traffic should be minimized
 by batching addresses to a single host where possible,
 without assistance by the user.
 Network traffic should be minimized
 by batching addresses to a single host where possible,
 without assistance by the user.

-.sh 1 "OVERVIEW"
-.sh 2 "System Organization"

 .pp
 .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
-[Schoens79],
-MS
-[Crocker77b],
-or MH
-[MH99]
-does editing as required by the destination network,
-and calls appropriate mailers
-to do mail delivery or queueing for network transmission
-(the exception is when mailing to a file).
-This discipline allows the insertion of new mailers
-at minimum cost.
-In this sense it is like the Message Processing Module (MPM)
-of [Postel79b].
-See Figure 1.
+This resulted in an architecture illustrated in figure 1.

 .(z
 .hl
 .ie t \
 .(z
 .hl
 .ie t \

-.      .sp 18
+.      sp 18

 .el \{\
 .(c
 .el \{\
 .(c

-              +-------+
-              | user  |
-              +-------+
-                  |
-               +-----+
-               | UIP |
-               +-----+
-                  |
-             +-----------+
-             | sendmail  |
-             +-----------+
++---------+   +---------+   +---------+
+| sender1 |   | sender2 |   | sender3 |
++---------+   +---------+   +---------+
+     |            |             |
+     +----------+  +  +----------+
+               |  |  |
+               v  v  v
+            +-------------+
+            |   sendmail  |
+            +-------------+

                |  |  |
      +----------+  +  +----------+
      |            |             |
                |  |  |
      +----------+  +  +----------+
      |            |             |

+     v             v             v

 +---------+   +---------+   +---------+
 | mailer1 |   | mailer2 |   | mailer3 |
 +---------+   +---------+   +---------+
 +---------+   +---------+   +---------+
 | mailer1 |   | mailer2 |   | mailer3 |
 +---------+   +---------+   +---------+


@@ -280,75 +294,190 @@ See Figure 1.
 .\}
 
 .ce
 .\}
 
 .ce

-Figure 1 \*- System Structure.
+Figure 1 \*- Sendmail System Structure.

 .hl
 .)z
 .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.
+All recipients are sent in the argument vector,
+and the message is sent on the standard input.
+Anything that the mailer prints
+is simply connected and sent back to the user
+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 recipients are passed to the mailer.
+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 almost like the previous technique,
+except that it uses a 4.2bsd IPC channel
+[ref?].
+This method is exceptionally flexible
+in that the mailer need not reside
+on the same machine.
+This is normally used to connect to a sendmail process
+on another machine.

 .sh 2 "Operational Description"
 .sh 2 "Operational Description"

+.pp
+When an agent 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,
+.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
 .sh 3 "Argument processing and address parsing"
 .pp

-The arguments are first scanned,
-and flag arguments are processed.
-The remaining arguments are addresses.
-They are parsed in turn,
+If
+.i sendmail
+is called using one of the two subprocess techniques,
+the arguments
+are first scanned,
+and flag arguments processed.
+Recipient addresses are then collected,
+either from the command line
+or from the SMTP
+RCPT command,

 and a list of recipients is created.
 and a list of recipients is created.

-Aliasing is done at this step.
-As much validity checking of the addresses as possible
-is done at this step.
-Syntax is checked, and local addresses can be verified,
+Aliases are expanded at this step.
+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
 but detailed checking of host names and addresses

-is not checked until later.
-Forwarding is also done
+is deferred until delivery.
+Forwarding is also performed

 as the local addresses are verified.
 .pp
 as the local addresses are verified.
 .pp

-As each address is parsed,
-it is appended to the recipient list.
+.i Sendmail
+appends each address
+to the recipient list after parsing.

 When a name is aliased or forwarded,
 When a name is aliased or forwarded,

-the old name is not removed from the list,
-but a flag is set in the address header
-that tells the delivery phase
-to not actually deliver the message to this recipient.
+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 without duplicates,
 preventing alias loops
 and eliminating people receiving two copies of a message,
 This list is kept without duplicates,
 preventing alias loops
 and eliminating people receiving two copies of a message,

-as might happen if a person were in two groups.
+as might occur if a person were in two groups.

 .sh 3 "Message collection"
 .pp
 .sh 3 "Message collection"
 .pp

-The message is then collected from the standard input.
-Parsing of the message header is done at this point.
-The header is stored in memory,
+.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
 and the body of the message is saved
 in a temporary file.
 .pp

-Collection occurs even if no addresses were valid
+The message is still collected even if no addresses were valid

 to simplify program interface.
 The message will be returned with an error.
 .sh 3 "Message delivery"
 .pp
 to simplify program interface.
 The message will be returned with an error.
 .sh 3 "Message delivery"
 .pp

-For each unique mailer and host,
-a call is made to the mailer.
-Each call contains the users on that host.
-Mailers that only accept one recipient at a time
+For each unique mailer and host in the send 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 user at a time

 are handled properly.
 .pp
 are handled properly.
 .pp

-.i Sendmail
-forks a process for each mailer
-with a non-empty send list.
-The message is then sent to the mailer
-(which must read its standard input)
+The message is sent to the mailer
+using one of the same three interfaces
+used to submit a message to sendmail.
+Each instantiation of the message is

 prepended by a customized header.
 prepended by a customized header.

-The exit code is caught and checked,
+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 meaningless message
 (\c
 .q "Service unavailable" )
 is given.
 and a suitable error message given as appropriate.
 The exit code must conform to a system standard
 or a meaningless message
 (\c
 .q "Service unavailable" )
 is given.

+.sh 3 "Queueing for retransmission"

 .pp
 .pp

-Delivery to files is handled directly.
+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 occurred during processing,
 .sh 3 "Return to sender"
 .pp
 If errors occurred during processing,

-the message is returned to the sender for retransmission.
+.i sendmail
+returns the message to the sender for retransmission.

 The letter can be mailed back
 or written in the file
 .q dead.letter
 The letter can be mailed back
 or written in the file
 .q dead.letter


@@ -364,12 +493,19 @@ function is always handled in one of these two ways.
 .sh 2 "Configuration File"
 .pp
 Almost all configuration information is read at runtime
 .sh 2 "Configuration File"
 .pp
 Almost all configuration information is read at runtime

-from an ASCII file.
-Information encoded in this file includes
-macro definitions,
-header declarations,
-mailer definitions,
-and address rewriting rules.
+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 effectively parse the addresses).

 .sh 3 Macros
 .pp
 Macros can be used in three ways.
 .sh 3 Macros
 .pp
 Macros can be used in three ways.


@@ -384,15 +520,16 @@ Other macros transmit information from
 to the configuration file
 for use in creating other fields
 (such as argument vectors to mailers);
 to the configuration file
 for use in creating other fields
 (such as argument vectors to mailers);

-examples of these are the name of the sender and the host and user
+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
 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 declare to
+Header declarations inform

 .i sendmail
 .i sendmail

-the set of known header lines.
+of the format of known header lines.

 Knowledge of a few header lines
 is built into
 .i sendmail ,
 Knowledge of a few header lines
 is built into
 .i sendmail ,


@@ -402,7 +539,7 @@ and
 .q Date:
 lines.
 .pp
 .q Date:
 lines.
 .pp

-Most headers declared in the configuration file
+Most configured headers

 will be automatically inserted
 in the outgoing message
 if they don't exist in the incoming message.
 will be automatically inserted
 in the outgoing message
 if they don't exist in the incoming message.


@@ -412,7 +549,7 @@ Certain headers are suppressed by some mailers.
 Mailer declarations tell
 .i sendmail
 of the various mailers available to it.
 Mailer declarations tell
 .i sendmail
 of the various mailers available to it.

-The definition includes the internal name of the mailer,
+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;
 the pathname of the program to call,
 some flags associated with the mailer,
 and an argument vector to be used on the call;


@@ -421,19 +558,37 @@ this vector is macro expanded before use.
 .pp
 The heart of address parsing in
 .i sendmail
 .pp
 The heart of address parsing in
 .i sendmail

-is the rewriting rules.
+is a set of rewriting rules.

 These are an ordered list of pattern-replacement rules,
 These are an ordered list of pattern-replacement rules,

-somewhat like a production system,
-except that order is critical.
-Each address is applied successively to these rules
-being rewritten into a different (textual) form
-until it resolves into a canonical address
+(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.,
 (i.e.,

-a [mailer, host, user]
-3-tuple),
+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.
 or it falls off the end.
 When a pattern matches,
 the rule is reapplied until it fails.

+.sh 3 "Option setting"
+.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 2 "Message Header Editing"
 .pp
 Certain editing of the message header
 .sh 2 "Message Header Editing"
 .pp
 Certain editing of the message header


@@ -451,11 +606,12 @@ line can be merged under certain circumstances.
 .sh 2 "Arguments"
 .pp
 Arguments may be flags and addresses.
 .sh 2 "Arguments"
 .pp
 Arguments may be flags and addresses.

-The flag arguments are described in Appendix A.
+Flags set various processing options.

 Following flag arguments,
 Following flag arguments,

-address arguments may be given.
-These follow the syntax in RFC733
-[Crocker77a]
+address arguments may be given,
+unless we are running in SMTP mode.
+These follow the syntax in RFC822
+[Crocker82]

 for ARPANET
 address formats.
 In brief, the format is:
 for ARPANET
 address formats.
 In brief, the format is:


@@ -463,14 +619,26 @@ In brief, the format is:
 Anything in parentheses is thrown away
 (as a comment).
 .np
 Anything in parentheses is thrown away
 (as a comment).
 .np

-Anything in angle brackets (\ <>\ ) is preferred
+Anything in angle brackets (\c
+.q "<>" )
+is preferred

 over anything else.
 over anything else.

+This 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.
 .np
 Double quotes
 (\ "\ )
 quote phrases;
 backslashes quote characters.

-Backslashes are more powerful \*- for example,
+Backslashes are more powerful
+in that they will cause otherwise equivalent phrases
+to compare differently \*- for example,

 .i user
 and
 .i
 .i user
 and
 .i


@@ -481,17 +649,15 @@ but
 .i \euser
 is different from either of them.
 .pp
 .i \euser
 is different from either of them.
 .pp

-All other processing is controlled by the rewriting rules
-(disclaimer: some special processing is done
-after rewriting local names).
+The rewriting rules control remaining parsing.
+(Disclaimer: some special processing is done
+after rewriting local names; see below.)

 Parentheses, angle brackets, and double quotes
 must be properly balanced and nested.
 .sh 2 "Mail to Files and Programs"
 .pp
 Parentheses, angle brackets, and double quotes
 must be properly balanced and nested.
 .sh 2 "Mail to Files and Programs"
 .pp

-It is not always the case that a message recipient
-should be a user.
-Files and programs should be valid message recipients.
-Files are needed as archival storage of messages,
+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,
 useful for project administration and history.
 Programs are useful as recipients in a variety of situations,
 for example,


@@ -502,56 +668,46 @@ program,
 or the MARS system
 [Sattley78]).
 .pp
 or the MARS system
 [Sattley78]).
 .pp

-Any address that passes through the initial parsing algorithm
+Any address passing through the initial parsing algorithm

 as a local address
 as a local address

-(i.e, does not appear to be a valid address for another mailer)
+(i.e, not appearing to be a valid address for another mailer)

 is scanned for two special cases.
 is scanned for two special cases.

-If the first character is a vertical bar (\c
+If prefixed by a vertical bar (\c

 .q \^|\^ )
 the rest of the address is processed as a shell command.
 .q \^|\^ )
 the rest of the address is processed as a shell command.

-If the user name contains slash marks (\c
+If the user name begins with a slash mark (\c

 .q /\^ )
 the name is used as a file name,
 instead of a login name.
 .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
 .sh 2 "Aliasing, Forwarding, Inclusion"
 .pp
 .i Sendmail

-supports three methods for implicitly rerouting mail.
+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,
 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 would normal be used
+and is normally used

 in conjunction with aliasing.
 .sh 3 "Aliasing"
 .pp
 in conjunction with aliasing.
 .sh 3 "Aliasing"
 .pp

-Aliasing uses a system-wide file
-mapping names to address lists.
+Aliasing maps names to address lists using a system-wide file.

 This file is inverted to speed access.
 This file is inverted to speed access.

-Only names that appear to be local
+Only names that parse as local

 are allowed as aliases;
 this guarantees a unique key.
 are allowed as aliases;
 this guarantees a unique key.

-.pp
-The inverted form of the file
-must be recreated when the text copy is changed.
-The
-.b \-I
-option to
-.i sendmail
-rebuilds the database\**.
-.(f
-\**This could be done automatically if
-.i sendmail
-could be guaranteed to be running as the owner of the
-alias file.
-In some environments this is not the case.
-.)f

 .sh 3 "Forwarding"
 .pp
 After aliasing,
 .sh 3 "Forwarding"
 .pp
 After aliasing,

-users that are found to be local and valid
+users that are local and valid

 are checked for the existence of a
 .q .forward
 file in their home directory.
 are checked for the existence of a
 .q .forward
 file in their home directory.


@@ -573,7 +729,7 @@ forwarding to:
 will use a different incoming mailer.
 .sh 3 "Inclusion"
 .pp
 will use a different incoming mailer.
 .sh 3 "Inclusion"
 .pp

-Inclusion is specified in ARPANET syntax:
+Inclusion is specified in RFC 733 [Crocker77a] syntax:

 .(b
 :Include: pathname
 .)b
 .(b
 :Include: pathname
 .)b


@@ -596,11 +752,72 @@ even if the alias file is protected.
 .pp
 It is not necessary to rebuild the alias database
 when a :include: list is changed.
 .pp
 It is not necessary to rebuild the alias database
 when a :include: list is changed.

-.sh 2 "Exit Status"
+.sh 2 "Message Collection"
+.pp
+Once all recipients are collected and verified,
+the message is collected either from the input.
+The message comes in two parts:
+a message header and a message body,
+separated by a blank line.

 .pp
 .pp

-An exit status is returned that corresponds to the system standard
-used by the other mailers.
-.sh 2 "Interaction With Other Mailers"
+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.
+A number of 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 at the other end.
+.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;
+this makes sending to mailers that can only accept one user easy.
+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 the following section.
+.pp
+After the interface is created,
+.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 gave 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 "Examples of Interactions With Other Mailers"

 .pp
 Two examples of how network-specific work is passed to other programs
 are the incoming UUCP mailer
 .pp
 Two examples of how network-specific work is passed to other programs
 are the incoming UUCP mailer


@@ -611,7 +828,7 @@ and the outgoing ARPANET mailer.
 .pp
 Mail coming in from the UUCP network
 is not guaranteed to have a normal header line,
 .pp
 Mail coming in from the UUCP network
 is not guaranteed to have a normal header line,

-nor will at argument be passed telling who it is from\**.
+nor will an argument be passed telling who it is from\**.

 .(f
 \**As a result of this,
 it is impossible to verify UUCP sender addresses.
 .(f
 \**As a result of this,
 it is impossible to verify UUCP sender addresses.


@@ -629,10 +846,7 @@ program has been modified here to do the special-purpose parsing
 necessary to decode UUCP headers
 and turn them into a normal UUCP address;
 this address is then passed to
 necessary to decode UUCP headers
 and turn them into a normal UUCP address;
 this address is then passed to

-.i sendmail
-via a
-.b \-f
-flag.
+.i sendmail .

 .sh 3 "Outgoing ARPANET mail"
 .pp
 The ARPANET imposes many standards that
 .sh 3 "Outgoing ARPANET mail"
 .pp
 The ARPANET imposes many standards that


@@ -652,23 +866,27 @@ as an alternative to
 which must be translated.
 The outgoing ARPANET mailer makes these transformations
 before passing the message to the network.
 which must be translated.
 The outgoing ARPANET mailer makes these transformations
 before passing the message to the network.

-.sh 1 CONFIGURATION
+.sh 2 "Configuration"

 .pp
 .pp

-Configuration is controlled primarily by the file
-.i /usr/lib/sendmail.cf .
+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
 .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 library.
+To remove or insert the DBM
+(UNIX database)
+library.

 .np
 To change ARPANET reply codes.
 .np
 To add headers requiring special processing.
 .lp
 .np
 To change ARPANET reply codes.
 .np
 To add headers requiring special processing.
 .lp

-Adding mailers or changing parsing or routing information
+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,
 does not require recompilation.
 .pp
 If the mail is being sent by a local user,


@@ -678,786 +896,6 @@ 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 is to add header lines.
 that file is read as a configuration file
 after the system configuration file.
 The primary use of this is to add header lines.

-.sh 2 "Configuration File Description"
-.pp
-The configuration file is formatted
-as a series of text lines,
-each beginning with a character describing its semantics.
-Blank lines and lines beginning with a sharp sign
-(#)
-are ignored.
-Other lines are:
-.(b
-.ta 3n
-D      define macro
-H      define header
-M      define mailer
-S      use rewriting set
-C      define word class
-R      specify rewriting rule
-.)b
-.pp
-See figure 2 for an example configuration file.
-.(z
-.hl
-.sz -2
-.re
-##########################################
-# sendmail configuration file
-#      @(#)sendmail.cf 3.6     8/17/81
-##########################################
-
-### local hosts on various nets
-DABerkeley
-DBIngVAX
-DUucbvax
-
-### special macros
-# my name
-D\&n\&MAILER-DAEMON
-# UNIX header format
-D\&l\&From $g  $d
-# delimiter (operator) characters
-D\&o\&.:@!^
-
-### format of headers:
-H\&Date: $a
-H\&From: $g$?x ($x)$.
-H\&Full-Name: $x
-H\&Message-Id: <$t.$p.$B@$A>
-H\&Posted-Date: $a
-
-### name classifications
-# arpanet hostnames
-C\&A\&ucb berkeley
-# list of local host names
-C\&B\&j IngVax
-# berknet hosts on the arpanet
-C\&C\&i ingres ing70
-# uucp hostnames
-C\&U\&ucbvax ernie
-
-.ta \w'M\&local  'u +\w'/usr/net/bin/sendberkmail  'u +\w'rlsAmn  'u +\w'$f@$A  'u
-###  mailers
-# local mail -- must be zero
-M\&local       /bin/mail       rlsAmn  $f      ...local\&mail -d $u
-# program mail -- must be one
-M\&prog        /bin/csh        lA      $f      ...prog\&mail -fc $u
-# berkeley net mail
-M\&berk        /usr/net/bin/sendberkmail       fxs     $B:$f   ...berk\&mail -m $h -h $c -t $u
-# arpanet mail
-M\&arpa        /usr/lib/mailers/arpa   sAu     $f@$A   ...arpa\&mail $f $h $u
-# uucp mail
-M\&uucp        /usr/bin/uux    rsDxm   $U!$f   ...uucp\&mail - $h!rmail ($u)
-
-### rewriting rules
-.ta \w'R\&CSVAX:$-h!$+u  'u +\w'$#berk$@ing70$:$+u@$+h  'u
-R\&$-h.$+u     $+h:$+u change "." to ":"
-R\&$=C:$+u@$-h $+u@$+h delete ing70: on arpanet addresses
-R\&$+u@$=A     ing70:$+u       delete local arpa hosts
-R\&$+u@$-h     $#berk$@ing70$:$+u@$+h  send arpa mail to ing70
-R\&$+h^$+u     $+h!$+u change "^" to "!"
-R\&$-x!$=U!$+y csvax:$+y       delete uucp loops through csvax
-R\&$-h!$+u     csvax:$+h!$+u   send uucp mail to csvax
-R\&$-x:$-h:$+u $+h:$+u delete multiple berk hosts
-R\&$=B:$+u     $+u     delete local berk hosts
-R\&$-h:$+u     $#berk$@$+h$:$+u        resolve berk mail
-R\&$+u $#local$:$+u    resolve local mail
-
-### rewriting rules for from host
-S\&1
-R\&ing70:$+u@$-h       $+u@$+h arpanet mail is automatic
-R\&CSVAX:$-h!$+u       $+h!$+u uucp mail is automatic
-.sz
-.sp 2
-.ce
-Figure 2.  Sample configuration file.
-.sp
-.hl
-.)z
-.sh 3 "D \*- define macro"
-.pp
-This line defines a macro.
-Macros have single character names.
-They can be interpolated using the escape
-.b $\c
-.i x ,
-where
-.i x
-is the macro name.
-By convention,
-all upper-case letters are unused by
-.i sendmail
-and may be used freely by the user;
-all other names are reserved for use by sendmail.
-Certain macros
-.i must
-be defined,
-and are used internally.
-These are:
-.(b
-.ta 4n
-$l     UNIX-style \*(lqFrom\*(rq line.
-$n     My address in error messages.
-$o     \*(lqOperators\*(rq in addresses.
-.)b
-The
-.b $l
-macro is expanded when
-.i sendmail
-wants to insert a UNIX-style
-.q From
-line on messages.
-This typically expands to something like:
-.(b
-From joe  Wed Aug 12 09:15:13 1981
-.)b
-The
-.b $n
-macro is used as the name of this process
-when error messages are being mailed back.
-Typically,
-it is wise to include an alias
-so that mail to this address will be sent to root.
-The
-.b $o
-macro defines the characters
-that will separate words when addresses are being broken up.
-Each of these becomes a word by itself when scanned.
-Blanks and tabs are built-in separators
-but are ignored,
-i.e., are not turned into words.
-For example, the input:
-.(b
-Ing70:ZRM @ MIT-MC SRI-KL
-.)b
-Is broken up into the six words:
-.(b
-Ing70, :, ZRM, @, MIT-MC, SRI-KL
-.)b
-assuming that colon and at-sign are operators
-(but hyphen is not).
-.pp
-A number of macros are defined by
-.i sendmail
-for use as primitives.
-These are:
-.(l
-.ta 4n
-$a     The date in ARPANET format.
-$c     The hop count.
-$d     The date in UNIX (ctime) format.
-$f     The sender's (from) address.
-$g     The sender's address translated by the mailer.
-$h     The host of the recipient.
-$p     The process id of sendmail in decimal.
-$t     The time in seconds in decimal.
-$u     The user part of the recipient.
-$v     The version number of sendmail.
-$x     The full name of the sender.
-$y     The id of the sender's terminal.
-$z     The home directory of the recipient.
-.)l
-.pp
-The
-.b $p
-and
-.b $t
-macros are used to create unique strings.
-The
-.b $f
-macro is the id of the sender
-as originally determined;
-when mailing to a specific person,
-the
-.b $g
-macro is the address of the sender
-with respect to the receiver.
-For example,
-if I send to
-.q csvax:samwise
-the
-.b $f
-and
-.b $g
-macros are:
-.(b
-.ta 4n
-$f     eric
-$g     IngVAX:eric
-.)b
-This only applies to the first step in the link.
-For example,
-sending to Ing70:drb@bbn-unix,
-we have
-.b $f
-and
-.b $g
-as above for the transfer to Ing70, but:
-.(b
-$f     IngVAX:eric
-$g     IngVAX:eric@Berkeley
-.)b
-for transfer to the ARPANET.
-When sending, the
-.b $u ,
-.b $h ,
-and
-.b $z
-macros get set to the user, host, and home directory
-(respectively)
-of the receiver.
-The host is only set if the user is not local,
-and the home directory is only set if the user is local.
-.pp
-A primitive conditional is available during macro expansion.
-The construct:
-.(b
-$?x text1 $: text2 $.
-.)b
-tests if macro
-.b $\c
-.i x
-is defined.
-If it is,
-text1 is interpolated;
-otherwise,
-text2 is interpolated.
-.sh 3 "H \*- define header"
-.pp
-The remainder of the
-.b H
-line looks like a regular header line,
-except that the field value is macro expanded
-before use.
-All headers mentioned in this way
-are automatically inserted
-into every message
-except for headers mentioned in the compile-time
-configuration file
-.i conf.c .
-These headers are
-Date,
-From,
-Full-Name,
-Message-Id,
-and
-Received-Date.
-To get these fields the appropriate flag
-must be specified
-for the receiving mailer.
-.pp
-Since the file
-.q ".mailcf"
-in the sender's home directory is read and processed,
-it is possible to add customized header lines.
-For example,
-the .mailcf consisting of:
-.(b
-H\&Phone: (415) 888-9990
-.)b
-will add that line to every outgoing message.
-.sh 3 "M \*- define mailer"
-.pp
-This line is structured into fields
-separated by white space (spaces or tabs).
-The fields are:
-.np
-The internal name of the mailer,
-referred to in the rewriting rules.
-.np
-The pathname of the program to execute for this mailer.
-.np
-The flags for this mailer,
-described below.
-.np
-The macro string to become the
-.b $g
-macro (translated sender)
-for this mailer.
-.np
-The argument vector passed to the mailer
-(macro expanded).
-.pp
-The flags are a series of characters:
-.ls 1
-.ip f
-The mailer wants a
-.b \-f
-.i from
-flag,
-but only if this is a network forward operation
-(i.e.,
-the mailer will give an error
-if the executing user does not have special permissions).
-.ip r
-Same as
-.b f ,
-but sends a
-.b \-r
-flag.
-.ip q
-Don't print errors \*- the mailer will do it for us.
-.ip S
-Don't reset your userid before calling the mailer.
-This would be used in a secure environment where
-.i sendmail
-ran as a special user.
-This could be used to prevent
-(or at least complicate)
-forged addresses.
-This option is suppressed in
-.q unsafe
-configuration files
-(i.e., user-supplied, either on a
-.b \-C
-option, or in the
-.i \&.mailcf
-file in the home directory).
-.ip n
-This mailer does not want a UNIX-style
-.q From
-line on the message.
-.ip l
-This mailer is local,
-so no host will be specified.
-.ip s
-Strip quote characters off of addresses
-before calling the mailer.
-.ip m
-This mailer can send to multiple users
-(on the same host)
-in one call.
-.ip F
-This mailer wants a
-.q From:
-header line.
-.ip D
-This mailer wants a
-.q Date:
-header line.
-.ip M
-This mailer wants a
-.q Message-Id:
-header line.
-.ip x
-This mailer wants a
-.q Full-Name:
-header line.
-.ip u
-Upper case should be preserved in user names.
-.ip h
-Upper case should be preserved in host names.
-.ip A
-This mailer wants an ARPANET standard header
-(equivalent to the
-.b F
-and
-.b D
-flags).
-.ls
-.sh 3 "S \*- use rewriting set"
-.pp
-There are two sets of rewriting rules.
-Set zero is used to rewrite recipient addresses.
-Set one is used to rewrite sender addresses.
-Set one can be used to eliminate implicit links.
-For example,
-if there exists a site on on the BerkNet called
-.q Ing70
-which is an ARPANET gateway,
-and we are on a site called
-.q IngVAX ,
-ARPANET mail coming into
-.q Ing70
-for someone on
-.q IngVAX
-will read:
-.(b
-From: Ing70:auser@ahost
-.)b
-Rewriting set one can rewrite this as:
-.(b
-From: auser@ahost
-.)b
-since
-.q Ing70
-will be implied.
-.pp
-When you change to a new set,
-the previous content of that set is cleared.
-.sh 3 "R \*- rewriting rule"
-.pp
-The heart of parsing is the rewriting rules.
-The process is essentially textual.
-First,
-the address to be rewritten is broken up into words.
-Words are defined as strings of non-special characters
-separated by white space or single special characters
-as defined by the
-.b $o
-macro.
-Then,
-the words are rewritten using simple pattern matching.
-Words in the pattern match themselves
-unless they begin with dollar sign.
-The dollar escapes have the following meanings\**:
-.(f
-\**These dollar escapes have nothing to do with macro expansion.
-.)f
-.(b
-.ta 4n
-$-x    Match a single word (and call it x).
-$+x    Match one or more words (and call them x).
-$=c    Match any word in class c (see below).
-.)b
-The case of letters is ignored in pattern matching
-(including class comparisons).
-.pp
-When a pattern (also called a left hand side or LHS)
-matches,
-the input is rewritten as defined by the right hand side (RHS).
-Acceptable escapes in the RHS are:
-.(b
-.ta \w'$#mailer  'u
-$+x    Replace from corresponding match in LHS.
-$#mailer       Canonical mailer name.
-$@host Canonical host name.
-$:user Canonical user name.
-.)b
-The replacement from the LHS to the RHS does not use macros,
-and there are no name conflicts.
-Patterns are reexecuted until it either resolves to
-a canonical name
-(i.e.,
-.q "$#mailer$@host$:user" )
-or fails.
-As soon as the input resolves to a canonical name,
-matching ends;
-otherwise,
-the next pattern is tried.
-The
-.q "$@host"
-part is not needed
-if the mailer does not require a host.
-The special mailer
-.q error
-causes the user part to be printed as an error.
-.sh 3 "C \*- define word class"
-.pp
-There are twenty six word classes,
-represented as
-.q A
-through
-.q Z .
-For example:
-.(b
-CVcsvax ingvax esvax
-.)b
-defines the words
-.q csvax ,
-.q ingvax ,
-and
-.q esvax
-to all be in class
-.q V ,
-so that
-.q $=V
-on the LHS of a rewriting rule
-will match any of these words.
-.sh 2 "A Detailed Example"
-.pp
-We will now follow the configuration file
-in figure 2
-through in detail.
-.sh 3 "Macro definitions"
-.(b
-DABerkeley
-DBIngVAX
-DUucbvax
-DnMAILER-DAEMON
-DlFrom $g  $d
-Do.:@!^
-.)b
-The first three macros are for convenience only,
-and are used to define the local host names
-on the ARPANET, BerkNet, and the UUCP net
-respectively.
-.pp
-Macro
-.b n
-defines the name of this entity
-when error messages are sent.
-Macro
-.b l
-defines what the first line
-of a message in UNIX format looks like,
-in this case the version 7 standard of:
-.(b
-From sender-name  time-of-submission
-.)b
-The
-.b o
-macro
-tells what characters will be distinct from names
-when scanning addresses.
-In this case,
-dot and colon will be used
-to distinguish BerkNet addresses,
-at sign for ARPANET addresses,
-and exclamation point and caret for UUCP addresses.
-.sh 3 "Header definitions"
-.(b
-H\&Date: $a
-H\&From: $g$?x ($x)$.
-H\&Full-Name: $x
-H\&Message-Id: <$t.$p.$B@$A>
-H\&Posted-Date: $a
-.)b
-These define the headers
-that may be added to a message.
-The
-.q Date:
-is just the ARPANET idea of the date.
-The
-.q From:
-line is the translated version of the sender,
-followed by the sender's full name if known.
-The
-.q Message-Id:
-field has the time and process id's concatenated
-with the BerkNet and ARPANET addresses
-to make a unique string.
-Finally, the
-.q Posted-Date:
-is the date in ARPANET format;
-it differs from
-.q Date:
-in that it is always output as soon as the message enters
-.i sendmail 's
-domain,
-and hence indicates the time that the message first enters
-the mail delivery system
-[NBS80].
-.sh 3 "Name classifications"
-.(b
-C\&A\&ucb berkeley
-C\&B\&j IngVax
-C\&C\&i ingres ing70
-C\&U\&ucbvax ernie
-.)b
-These commands put the words
-.q ucb
-and
-.q berkeley
-into class
-.q A ,
-the valid names of this site on the ARPANET.
-Words
-.q j
-and
-.q ingvax
-are in class
-.q B ,
-the local names on BerkNet.
-Class
-.q C ,
-the names of the site which has the ARPANET link,
-has the words
-.q i ,
-.q ingres ,
-and
-.q ing70 .
-Finally,
-.q ucbvax
-and
-.q ernie
-are the UUCP names of our UUCP gateway,
-and are in class
-.q U .
-.pp
-The classes will be used in the patterns of the rewriting rules
-as described below.
-.sh 3 "Mailer definitions"
-.(b
-.sz -2
-.ta \w'M\&local  'u +\w'/usr/net/bin/sendberkmail  'u +\w'rlsAmn  'u +\w'$f@$A  'u
-M\&local       /bin/mail       rlsAmn  $f      ...localmail -d $u
-M\&prog        /bin/csh        lA      $f      ...progmail -fc $u
-M\&berk        /usr/net/bin/sendberkmail       fxs     $B:$f   ...berkmail -m $h -h $c -t $u
-M\&arpa        /usr/lib/mailers/arpa   sAu     $f@$A   ...arpamail $f $h $u
-M\&uucp        /usr/bin/uux    rsDxm   $U!$f   ...uucpmail - $h!rmail ($u)
-.sz
-.)b
-Five mailers are known in the configuration file.
-The first two
-.i must
-be for local and program mail,
-and must come as the first and second mailers respectively.
-.pp
-Local mail is sent using
-/bin/mail.
-It takes a
-.b \-r
-flag,
-is local,
-quote characters are stripped before sending,
-takes ARPANET standard headers,
-can deliver to multiple recipients at once,
-and does not want a UNIX-style
-.q From
-line since it will add one itself.
-The translated from address is the same as the raw from address,
-since no network hops are made.
-The argument vector has a program name,
-a
-.b \-d
-flag (\c
-.q "really deliver" ,
-which must be added to /bin/mail),
-and the list of recipients \*- one recipient per argument.
-.pp
-Mail piped through programs
-is interpreted by /bin/csh.
-It does not take a
-.b \-r
-flag,
-quotes should be left,
-it can only deal with one user,
-and it does want a UNIX-style
-.q From
-line,
-but is still local and still wants an ARPANET style header.
-.pp
-BerkNet mail is processed by
-/usr/net/bin/sendberkmail.
-It takes a
-.b \-f
-flag,
-wants a
-.q Full-Name:
-header line,
-and wants quotes stripped.
-The
-.q Full-Name:
-is used here because if it were given as a comment
-in a
-.q From:
-line it might be discarded by later instantiations of
-.i sendmail .
-The from address as seen by the receiver is
-.q IngVAX:sender ,
-and it takes a flag-oriented
-rather than a positional
-command list.
-.pp
-The ARPANET wants quotes stripped,
-ARPANET standard headers,
-and wants the user name left with case intact.
-It takes a positional command list.
-.pp
-UUCP mail calls
-.i uux
-with a
-.b \-r
-flag,
-quotes stripped,
-a
-.q Date:
-line,
-a
-.q Full-Name:
-line,
-and with multiple users listed.
-.sh 3 "Rewriting rules for recipient addresses"
-.(b
-.sz -2
-.ta \w'[99]  'u +\w'R\&CSVAX:$-h!$+u  'u +\w'$#berk$@ing70$:$+u@$+h  'u
-[1]    R\&$-h.$+u      $+h:$+u change "." to ":"
-[2]    R\&$=C:$+u@$-h  $+u@$+h delete ing70: on arpanet addresses
-[3]    R\&$+u@$=A      ing70:$+u       delete local arpa hosts
-[4]    R\&$+u@$-h      $#berk$@ing70$:$+u@$+h  send arpa mail to ing70
-[5]    R\&$+h^$+u      $+h!$+u change "^" to "!"
-[6]    R\&$-x!$=U!$+y  csvax:$+y       delete uucp loops through csvax
-[7]    R\&$-h!$+u      csvax:$+h!$+u   send uucp mail to csvax
-[8]    R\&$-x:$-h:$+u  $+h:$+u delete multiple berk hosts
-[9]    R\&$=B:$+u      $+u     delete local berk hosts
-[10]   R\&$-h:$+u      $#berk$@$+h$:$+u        resolve berk mail
-[11]   R\&$+u  $#local$:$+u    resolve local mail
-.sz
-.)b
-Dots in addresses are translated to colons
-in the first rule.
-Redundant explicit routing to the ARPANET is deleted
-in the second rule.
-Hops out over the ARPANET
-back to us are deleted in the third rule \*-
-note that the host that we would have come in on
-is inserted.
-Real ARPANET mail is resolved immediately with no further ado \*-
-it is sent out over the BerkNet to the ing70,
-and further rewriting stops immediately.
-.pp
-Carets are changed to exclamation points
-for UUCP addresses in the fifth rule.
-The sixth rule deletes loops out into UUCP land
-and back to us \*- noting that we will be left on CSVAX.
-Multiple BerkNet hosts are deleted in rule seven \*-
-this can occur internally quite easily
-as a side effect of a rewriting rule.
-Rule eight deletes local BerkNet hosts.
-The last two rules resolve BerkNet and local mail.
-.pp
-Consider the following examples.
-The numbers to the left are the rule that is being applied
-to make the transformation.
-.(b
-.re
-       esvax.asa
-[1]    esvax:asa
-[10]   $#berk$@esvax$:asa
-.)b
-.(b
-       research^vax135^dmr
-[5]    research!vax135^dmr
-[5]    research!vax135!dmr
-[7]    $#berk$@csvax$:research!vax135!dmr
-.)b
-.(b
-       research!ucbvax!j:eric
-[6]    csvax:j:eric
-[8]    j:eric
-[9]    eric
-[11]   $#local$:eric
-.)b
-.(b
-       ing70:wnj@Berkeley
-[2]    wnj@Berkeley
-[3]    ing70:wnj
-[10]   $#berk$@ing70$:wnj
-.)b
-.sh 3 "Rewriting rules for sender addresses"
-.(b
-.sz -2
-.ta \w'R\&CSVAX:$-h!$+u  'u +\w'$+u@$+h  'u
-S\&1
-R\&ing70:$+u@$-h       $+u@$+h arpanet mail is automatic
-R\&CSVAX:$-h!$+u       $+h!$+u uucp mail is automatic
-.sz
-.)b
-The
-.b S
-line starts putting the rules into set one.
-These rules strip off the
-.q ing70:
-from incoming ARPANET mail
-and the
-.q CSVAX:
-off of incoming UUCP mail.
-.pp
-The name classes could be used here,
-but using literal strings is safe
-because they will always be program-generated.

 .sh 1 "COMPARISON WITH OTHER MAILERS"
 .sh 2 "Delivermail"
 .pp
 .sh 1 "COMPARISON WITH OTHER MAILERS"
 .sh 2 "Delivermail"
 .pp


@@ -1482,7 +920,7 @@ and reroute to different gateways.
 .np
 Forwarding and
 :include:
 .np
 Forwarding and
 :include:

-support eliminate the requirement that the system alias file
+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).
 be writable by any user
 (or that an update program be written,
 or that the system administration make all changes).


@@ -1494,29 +932,54 @@ when a message is being sent to multiple recipients.
 .pp
 MMDF
 [Crocker79]
 .pp
 MMDF
 [Crocker79]

-spans a much wider problem set than
+spans a wider problem set than

 .i sendmail .
 For example,
 .i sendmail .
 For example,

+the domain of

 MMDF includes a
 .q "phone network"
 mailer, whereas
 .i sendmail
 calls on preexisting mailers in most cases.
 MMDF includes a
 .q "phone network"
 mailer, whereas
 .i sendmail
 calls on preexisting mailers in most cases.

-.i Sendmail
-is approximately equivalent to the
-SUBMIT and DELIVER phases of MMDF.
-Because of this difference in design goals,
-some of the important features of MMDF
-(queueing, retransmission, and two-phase timeout)
-are unimplemented by
-.i sendmail .

 .pp
 MMDF and
 .i sendmail
 both support aliasing,
 customized mailers,
 message batching,
 .pp
 MMDF and
 .i sendmail
 both support aliasing,
 customized mailers,
 message batching,

-and automatic forwarding to gateways.
+automatic forwarding to gateways,
+queueing,
+and retransmission.
+MMDF supports two-stage timeout,
+which
+.i sendmail
+does not currently support.
+.pp
+The configuration for MMDF
+is completely compiled into the code\**.
+.(f
+\**Dynamic configuration tables are currently being considered
+for MMDF;
+this would allow the installer to select either compiled
+or dynamic tables.
+.)f
+Since MMDF does not consider backwards compatibility
+as a design goal,
+the address parsing is much less flexible.
+It is slightly harder to integrate a new mailer
+(\c
+.q channel,
+in MMDF parlance)
+into MMDF,
+both systems are designed to accept this,
+and the difference does not seem to be significant.
+.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)
 .sh 2 "Message Processing Module"
 .pp
 The Message Processing Module (MPM)


@@ -1584,36 +1047,12 @@ in an internet environment
 has been amazingly successful,
 and has reduced the job to a manageable task.
 .pp
 has been amazingly successful,
 and has reduced the job to a manageable task.
 .pp

-However,
-many of these mailers implement their own queueing and retransmission.
-In networks that support store-and-forward file transfer,
-such as BerkNet and UUCP,
-this feature must be supplied already.
-However,
-networks that transfer in real time,
-such as the ARPANET or an Ether-based network
-[Ether99],
-generally do not provide these features.
-Also,
-networks which provide these generally do not understand
-timeouts or returning the text of the message on error,
-both highly desirable features\**.
-.(f
-\**We have implemented an ARPANET mailer which
-returns the message on error and does one-stage timeout
-(returning the message after three days).
-.)f
-Such queueing, retransmission, and two-phase timeout
-may be integrated into
-.i sendmail
-if it seems desirable.
-.pp

 .i Sendmail
 has knowledge of a few difficult environments
 built in.
 .i Sendmail
 has knowledge of a few difficult environments
 built in.

-It generates ARPANET FTP compatible error messages
+It generates ARPANET FTP/SMTP compatible error messages

 (prepended with three-digit numbers
 (prepended with three-digit numbers

-[Neigus78, FTP2])
+[Neigus73, Postel74, Postel82])

 as necessary,
 optionally generates UNIX-style
 .q From
 as necessary,
 optionally generates UNIX-style
 .q From


@@ -1628,18 +1067,23 @@ lines.
 Also,
 error handling has an option customized for BerkNet.
 .pp
 Also,
 error handling has an option customized for BerkNet.
 .pp

-One surprisingly major annoyance in most internet mailers
-(such as MMDF)
-is that the location and format of local mail is built in\**.
-.(f
-\**For example,
-MMDF puts local mail in the file
-.q .mail
-\*- useful if you are running version 6.
-.)f
-.i Sendmail
-eliminates all knowledge of location
-and can function successfully with different formats.
+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 does not match 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)
 .pp
 The ability to automatically generate a response to incoming mail
 (by forwarding mail to a program)


@@ -1657,37 +1101,9 @@ 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
 I am unaware of any mail system that addresses this problem,
 nor am I aware of any reasonable solution at this time.
 .pp

-.i Sendmail
-should be modified to run as a daemon,
-reading an MPX file
-(or other IPC scheme)
-to receive mail and process it.
-This would reduce the cost of sending mail to writing the message
-into a known file.
-.i Sendmail
-would be modified to have a very different argument structure.
-It already has an option to read the recipients
-from the message header.
-A more palatable technique for giving error messages
-would also have to be devised.
-.pp

 The configuration file is currently practically inscrutable;
 considerable convenience could be realized
 with a higher-level format.
 The configuration file is currently practically inscrutable;
 considerable convenience could be realized
 with a higher-level format.

-For example, a description might read:
-.(b
-.re
-(MACRO name value)
-(HEADER name value
-       (OPTION option) ...
-       (NEEDS option) ... )
-(MAILER name path xlatstring
-       (OPTION option) ...
-       (ARGV arg ... ))
-(CLASS name word ...)
-(REWRITE setname
-       (RULE lhs rhs) ... )
-.)b

 .pp
 It seems clear that common protocols will be changing soon
 to accommodate changing requirements and environments.
 .pp
 It seems clear that common protocols will be changing soon
 to accommodate changing requirements and environments.


@@ -1696,65 +1112,32 @@ These changes will include modifications to the message header
 or to the body of the message itself
 (such as for multimedia messages
 [Postel80]).
 or to the body of the message itself
 (such as for multimedia messages
 [Postel80]).

-Other changes will include changes to communication protocols
-which may effect
-.i sendmail ;
-for example, the changes implied by the new Mail Transfer Protocol
-[Sluizer81].
-These changes should be relatively trivial to integrate
+Experience indicates that
+these changes should be relatively trivial to integrate

 into the existing system.
 .pp
 into the existing system.
 .pp

-Many other nice features could be implemented.
-For example,
-if we were sure that the alias file were writable by the effective user
-(i.e., if
-.i sendmail
-were to run setuid)
-then the inverted form could be rebuilt automatically when the
-text copy was changed.
-However, this appears to be little more than frosting.
-must be properly balanced and nested.
-.pp
-Some proposals call for a single address syntax,
-such that the host name uniquely determines the network.
-There are a number of evident problems with this.
-In a large internet,
-the database update problem becomes considerable,
-especially under multiple managements;
-this can be solved by a daemon that updates the tables
-dynamically,
-but it is not clear what the problems are here.
-More to the point,
-this requires a unique namespace among all networks.
-In our current configuration
-we have been unable to even find out the names of all the hosts
-on the UUCP network;
-to hope that on an internet with fifty or more networks
-would have no name conflicts is beyond the scope of
-.i sendmail .
-Despite the difficulties, however,
-this is probably a better long-term solution to the problem
-of internet addressing.
-The ambiguities implied by addresses combining
-left-associative and right-associative addresses
-are impossible to solve without parentheses;
-acceptable for mathematical equations,
-but absurd for network addresses.
-.pp
-A related problem occurs with the user namespace.

 In tightly coupled environments,
 In tightly coupled environments,

-it would be nice to have automatic forwarding between machines
-on the basis of the user name alone,
-without cumbersome aliases.
+it would be nice to have a name server integrated into the mail system.
+This would allow a domain such as
+.q Berkeley
+to appear as a homogenous host,
+rather than as a collection of hosts,
+and would allow people to move transparently among machines
+without having to change their addresses.

 This would require an automatically updated database
 and some method of resolving conflicts.
 Ideally this would be effective even with multiple managements.
 This would require an automatically updated database
 and some method of resolving conflicts.
 Ideally this would be effective even with multiple managements.

-A student at Berkeley,
-Allan Biocca,
-is working on a facility which may provide the necessary functionality.
-.uh "ACKNOWLEDGEMENTS"
+However,
+it is not clear whether this should be integrated into the
+aliasing feature
+or should be considered a
+.q "value added"
+feature outside
+.i sendmail
+itself.
+.sh 0 "ACKNOWLEDGEMENTS"

 .pp
 .pp

-Thanks are due to Kurt Schoens for his continual cheerful
+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),
 assistance and good advice,
 Bill Joy for pointing me in the correct direction
 (over and over),


@@ -1789,18 +1172,28 @@ 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
 how a person can continue to be so enthusiastic
 in the face of so much bitter reality is beyond me.
 .pp

-Kurt, Bill, and Kirk McKusick
+Kurt and Kirk McKusick

 read early copies of this paper,
 giving considerable useful advice.
 .pp
 read early copies of this paper,
 giving considerable useful advice.
 .pp

-Special thanks are reserved for Mike Stonebraker,
-who knowingly allowed me to put so much work into this
+Special thanks are reserved for Mike Stonebraker and Bob Epstein,
+who both knowingly allowed me to put so much work into this

 when there were so many other things I really should
 have been working on.
 .+c
 .ce
 REFERENCES
 .nr ii 1.5i
 when there were so many other things I really should
 have been working on.
 .+c
 .ce
 REFERENCES
 .nr ii 1.5i

+.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.,
 .ip [Crocker77a]
 Crocker, D. H.,
 Vittal, J. J.,


@@ -1808,7 +1201,7 @@ Pogran, K. T.,
 and
 Henderson, D. A. Jr.,
 .ul
 and
 Henderson, D. A. Jr.,
 .ul

-Standard for the Format of ARPA Network Text Messages,
+Standard for the Format of ARPA Network Text Messages.

 RFC 733,
 NIC 41952.
 In [Feinler78].
 RFC 733,
 NIC 41952.
 In [Feinler78].


@@ -1816,7 +1209,7 @@ November 1977.
 .ip [Crocker77b]
 Crocker, D. H.,
 .ul
 .ip [Crocker77b]
 Crocker, D. H.,
 .ul

-Framework and Functions of the MS Personal Message System,
+Framework and Functions of the MS Personal Message System.

 R-2134-ARPA,
 Rand Corporation,
 Santa Monica, California.
 R-2134-ARPA,
 Rand Corporation,
 Santa Monica, California.


@@ -1827,75 +1220,92 @@ Szurkowski, E. S.,
 and
 Farber, D. J.,
 .ul
 and
 Farber, D. J.,
 .ul

-An Internetwork Memo Distribution Facility \*- MMDF,
+An Internetwork Memo Distribution Facility \*- MMDF.

 6th Data Communication Symposium,
 Asilomar.
 November 1979.
 6th Data Communication Symposium,
 Asilomar.
 November 1979.

-.ip [Ether99]
+.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.,
 Boggs, D.,

-and who???
+.q "Ethernet: Distributed Packet Switching for Local Computer Networks" ,

 .ul
 .ul

-Ethernet....
+Communications of the ACM 19,
+7.
+July 1976.

 .ip [Feinler78]
 Feinler, E.,
 and
 Postel, J.
 (eds.),
 .ul
 .ip [Feinler78]
 Feinler, E.,
 and
 Postel, J.
 (eds.),
 .ul

-ARPANET Protocol Handbook,
+ARPANET Protocol Handbook.

 NIC 7104,
 Network Information Center,
 SRI International,
 Menlo Park, California.
 1978.
 NIC 7104,
 Network Information Center,
 SRI International,
 Menlo Park, California.
 1978.

-.ip [FTP2]
-Revised FTP Reply Codes.
-.ip [MH99]
-MH.

 .ip [NBS80]
 National Bureau of Standards,
 .ul
 .ip [NBS80]
 National Bureau of Standards,
 .ul

-Specification of a Draft Message Format Standard,
-Report No. ICST/CBOS 80-2,
+Specification of a Draft Message Format Standard.
+Report No. ICST/CBOS 80-2.

 October 1980.
 October 1980.

-.ip [Neigus78]
+.ip [Neigus73]

 Neigus, N.,
 .ul
 Neigus, N.,
 .ul

-File Transfer Protocol for the ARPA Network,
-RFC xxxx,
-in [Feinler78].
-1978.
+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
 .ip [Nowitz78a]
 Nowitz, D. A.,
 and
 Lesk, M. E.,
 .ul

-A Dial-Up Network of UNIX Systems,
+A Dial-Up Network of UNIX Systems.

 Bell Laboratories.
 Bell Laboratories.

-August, 1978.

 In
 UNIX Programmer's Manual, Seventh Edition,
 Volume 2.
 In
 UNIX Programmer's Manual, Seventh Edition,
 Volume 2.

+August, 1978.

 .ip [Nowitz78b]
 Nowitz, D. A.,
 .ul
 .ip [Nowitz78b]
 Nowitz, D. A.,
 .ul

-Uucp Implementation Description,
+Uucp Implementation Description.

 Bell Laboratories.
 Bell Laboratories.

-October, 1978.

 In
 UNIX Programmer's Manual, Seventh Edition,
 Volume 2.
 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
 .ip [Postel77]
 Postel, J.,
 .ul

-Mail Protocol,
+Mail Protocol.

 NIC 29588.
 In [Feinler78].
 November 1977.
 .ip [Postel79a]
 Postel, J.,
 .ul
 NIC 29588.
 In [Feinler78].
 November 1977.
 .ip [Postel79a]
 Postel, J.,
 .ul

-Internet Message Protocol,
+Internet Message Protocol.

 RFC 753,
 IEN 85.
 Network Information Center,
 RFC 753,
 IEN 85.
 Network Information Center,


@@ -1905,45 +1315,69 @@ March 1979.
 .ip [Postel79b]
 Postel, J. B.,
 .ul
 .ip [Postel79b]
 Postel, J. B.,
 .ul

-An Internetwork Message Structure,
-1979.
+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.
 .ip [Postel80]
 Postel, J. B.,
 .ul
 A Structured Format for Transmission of Multi-Media Documents.

-RFC 767,
+RFC 767.

 Network Information Center,
 SRI International,
 Menlo Park, California.
 August 1980.
 Network Information Center,
 SRI International,
 Menlo Park, California.
 August 1980.

-.ip [Schmidt99]
+.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
 Schmidt, E.,
 .ul

-The Berkeley Network.
-University of California, Berkeley California.
-1999.
-.ip [Schoens79]
+An Introduction to the Berkeley Network.

 University of California, Berkeley California.
 University of California, Berkeley California.

-1999.
-Schoens, K.,
+1979.
+.ip [Shoens79]
+Shoens, K.,

 .ul
 .ul

-Mail Reference Manual,
-UNIX Programmer's Manual,
+Mail Reference Manual.
+University of California, Berkeley.
+In UNIX Programmer's Manual,

 Seventh Edition,
 Volume 2C.
 Seventh Edition,
 Volume 2C.

-University of California, Berkeley.

 December 1979.
 .ip [Sluizer81]
 Sluizer, S.,
 and
 Postel, J. B.,
 .ul
 December 1979.
 .ip [Sluizer81]
 Sluizer, S.,
 and
 Postel, J. B.,
 .ul

-Mail Transfer Protocol,
-RFC 780,
+Mail Transfer Protocol.
+RFC 780.

 Network Information Center,
 SRI International,
 Menlo Park, California.
 May 1981.
 Network Information Center,
 SRI International,
 Menlo Park, California.
 May 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 [UNIX80]
 .ul
 The UNIX Programmer's Manual, Seventh Edition,
 .ip [UNIX80]
 .ul
 The UNIX Programmer's Manual, Seventh Edition,


@@ -1953,491 +1387,3 @@ Bell Laboratories,
 modified by the University of California,
 Berkeley California.
 November 1980.
 modified by the University of California,
 Berkeley California.
 November 1980.

-.++ A
-.+c "SENDMAIL USAGE"
-.pp
-Arguments must be presented with flags before addresses.
-The flags are:
-.nr ii 1i
-.ip "\-f addr"
-The mail is from
-.i addr .
-This flag is ignored unless the real user
-is root,
-network,
-or uucp,
-or if
-.i addr
-contains an exclamation point
-(because of certain restrictions in UUCP).
-.ip "\-r addr"
-An obsolete form of
-.b \-f .
-.ip "\-h cnt"
-Sets the
-.q "hop count"
-to
-.i cnt .
-This represents the number of times this message has been processed
-by
-.i sendmail
-(to the extent that it is supported by the underlying networks).
-.i Cnt
-is incremented during processing,
-and if it reaches
-MAXHOP
-(currently 30)
-.i sendmail
-throws away the message with an error.
-.ip "\-F\&name"
-Sets the full name of this user to
-.i name .
-.ip \-e\&p
-Print error messages (default).
-.ip \-e\&q
-Throw away error messages.
-The only response is the exit status.
-.ip \-e\&m
-Mail back errors.
-.ip \-e\&w
-.q Write
-back errors \*- or mail them if the user is not logged in.
-.ip \-e\&e
-Do special error processing for BerkNet.
-This involves mailing back the errors
-but always returning a zero exit status.
-.ip \-n
-Don't do aliasing or forwarding.
-.ip \-m
-Include me in alias expansions.
-Normally
-.i sendmail
-suppresses the sender
-if in a group being sent to.
-.ip \-i
-Don't take a dot to end a message.
-.ip \-t
-Read the header for
-.q To: ,
-.q Cc: ,
-and
-.q Bcc:
-lines, and send to everyone listed in those lists.
-The
-.q Bcc:
-line will be deleted before sending.
-Any addresses in the argument vector will be deleted
-from the send list.
-.ip \-a\&m
-Do special processing for the
-ARPANET.
-This includes taking the
-.q "From:"
-person from the header,
-printing
-ARPANET
-style messages
-(preceded by three digit reply codes for compatibility with
-the FTP protocol
-[Neigus78, FTP2, Postel77]),
-and ending lines with <CRLF>.
-.ip \-a\&f
-Same as
-.b \-a\&m ,
-except print out message numbers appropriate for the MLFL command
-[Postel77].
-.ip \-s
-Save UNIX-style
-.q From
-lines at the beginning of headers.
-Normally they are assumed redundant
-and discarded.
-.ip \-v
-Give a blow-by-blow description of function.
-This gives information of interest to the user
-rather than for the
-.i sendmail
-maintainer;
-for example,
-aliases are printed as expanded
-and mailer functions are printed as they run.
-.ip \-C\&file
-Use a different configuration file.
-.ip \-A\&file
-Use a different alias file.
-.ip \-I
-Initialize the DBM version
-of the alias file.
-If
-.b \-I
-is given,
-no delivery is attempted.
-.ip \-V
-Verify the addresses only.
-Only partial verification is done:
-syntax is checked, and local names are verified,
-but no checking normally done by the mailer is attempted.
-.ip \-d\&level
-Set debugging level.
-.ip \-D\&x\&val
-Define macro
-.i x
-to have value
-.i val .
-.nr ii 5n
-.+c "OTHER CONFIGURATION"
-.pp
-There are some configuration changes that can be made by
-recompiling
-.i sendmail .
-Some of these are changes to compilation flags:
-.nr ii 1i
-.ip V6
-If set,
-this will compile a version 6 system,
-with 8-bit user id's,
-single character tty id's,
-etc.
-If not set,
-a version 7 system is assumed.
-.ip DBM
-If set,
-the
-.q DBM
-package in UNIX is used
-(see DBM(3X) in [UNIX80]).
-If not set,
-a much less efficient algorithm for processing aliases is used.
-.ip VFORK
-Set if your system has the experimental
-.i vfork
-system call.
-See vfork(2) in [UNIX80].
-If not set,
-the regular
-.i fork
-system call is used.
-This option improves performance.
-.ip DEBUG
-If set, debugging information is compiled in.
-To actually get the debugging output,
-the
-.b \-d
-flag must be used.
-.ip LOG
-If set,
-the
-.i syslog
-routine in use at some Berkeley sites is used.
-This logs an informational log record
-for each message processed,
-and logs a higher-priority log record
-for internal system errors.
-.ip NEWFTP
-If set, the ARPANET reply codes for
-.q "Revised New FTP" are used
-[FTP2].
-If not set,
-reply codes for the old, unrevised
-.q "New FTP"
-are used
-[Neigus78].
-If you want to use reply codes for the Mail Transfer Protocol
-[Sluizer81]
-you may find it necessary to make some code modifications.
-.ip PARANOID
-There are places where
-.i sendmail
-may opt for a more secure,
-but probably less convenient environment.
-For example,
-if this flag is set
-it is not possible to specify a program as an address directly;
-this can only be done with an alias.
-.nr ii 5n
-.pp
-If you want to enable special processing of other headers,
-you will have to add them to the
-.i HdrInfo
-table in
-.i conf.c .
-This table contains the header name
-(which should be in all lower case),
-a set of header control flags (described below),
-and a set of mailer flags,
-used by some of the header flags.
-The header flags are:
-.nr ip 1.2i
-.ip H_CHECK
-Check the flags for the receiving mailer
-against the third field in the
-.i HdrInfo
-entry.
-If the mailer has any of those bits set,
-send this field;
-otherwise, do not send this field to that mailer.
-If the field was in the message originally, however,
-it will always be sent
-(i.e., this only applies to headers being added by
-.i sendmail ).
-.ip H_ACHECK
-Same as H_CHECK,
-except that it even applies to headers that were in the
-original message.
-That is,
-if this bit is set and the mailer does not have flag bits set
-that intersect with the third field in this
-.i HdrInfo
-entry,
-the header line is
-.i always
-deleted.
-.ip H_EOH
-If this header field is set,
-treat it like a blank line,
-i.e.,
-it will signal the end of the header
-and the beginning of the message text.
-.ip H_FORCE
-Add this header entry
-even if one existed in the message before.
-If a header entry does not have this bit set,
-.i sendmail
-will not add another header line if a header line
-of this name already existed.
-This would normally be used to stamp the message
-by everyone who handled it.
-.ip H_ADDR
-If set,
-this field contains recipient addresses.
-This is used by the
-.b \-t
-flag to determine who to send to
-when it is collecting recipients from the message.
-.nr ii 5n
-.lp
-Let's look at a sample
-.i HdrInfo
-specification:
-.(b
-.sz -2
-.ta 4n +\w'"original-from",  'u +\w'H_ADDR|H_ACHECK,  'u
-struct hdrinfo HdrInfo[] =
-{
-       "date", H_CHECK,        M_NEEDDATE,
-       "from", H_CHECK,        M_NEEDFROM,
-       "original-from",        H_ACHECK,       0,
-       "sender",       0,      0,
-       "full-name",    H_ACHECK,       M_FULLNAME,
-       "to",   H_ADDR, 0,
-       "cc",   H_ADDR, 0,
-       "bcc",  H_ADDR|H_ACHECK,        0,
-       "message-id",   H_CHECK,        M_MSGID,
-       "message",      H_EOH,  0,
-       "text", H_EOH,  0,
-       "received-date",        H_CHECK,        M_LOCAL,
-       "received-from",        H_CHECK,        M_LOCAL,
-       "via",  H_FORCE,        0,
-       NULL,   0,      0,
-};
-.sz
-.)b
-This specification says that the
-.q Date: ,
-.q From: ,
-.q Message-Id: ,
-.q Received-Date: ,
-and
-.q Received-From:
-must be requested by the mailer to be inserted.
-However,
-if they were in the message as received by
-.i sendmail
-they will be propagated.
-The
-.q Full-Name:
-field, on the other hand,
-will be deleted even if it was specified before,
-unless the mailer wants it.
-The
-.q Original-From:
-and
-.q Bcc:
-fields will be deleted unconditionally
-(since it is never possible for a mailers flags
-to intersect with zero).
-The
-.q Original-From:
-is in fact used internally,
-and will be reinserted by ad hoc code,
-but only if it differs from the
-.q From:
-line that would otherwise be inserted.
-.q To: ,
-.q Cc: ,
-and
-.q Bcc:
-all specify recipient addresses.
-The
-.q Message:
-and
-.q Text:
-fields will terminate the header;
-these are specified in new protocols
-[NBS80]
-or used by random dissenters around the network world.
-The
-.q Via:
-field will always be added,
-and can be used to trace messages.
-The
-.q Sender:
-field is used internally,
-although no cliched special processing occurs.
-.pp
-There are a number of important points here.
-First,
-header fields are not added automatically just because they are in the
-.i HdrInfo
-structure;
-they must be specified in the configuration file.
-Any header fields mentioned in the configuration file but not
-mentioned in the
-.i HdrInfo
-structure have default processing performed;
-that is,
-they are added unless they were in the message already.
-Second,
-the
-.i HdrInfo
-structure only specifies cliched processing;
-certain headers are processed specially by ad hoc code
-regardless of the status specified in
-.i HdrInfo .
-For example,
-the
-.q Sender:
-and
-.q From:
-fields are always scanned on ARPANET mail
-to determine the sender;
-this is used to perform the
-.q "return to sender"
-function.
-The
-.q "From:"
-and
-.q "Full-Name:"
-fields are used to determine the full name of the sender
-if possible;
-this is stored in the macro
-.b $x
-and used in a number of ways.
-Although the
-.q "Original-From:"
-field is specified to be deleted in
-.i HdrInfo ,
-it is added automatically if the
-.q From:
-field that would be generated internally
-differs from the
-.q From:
-field that was specified in the message;
-in this case,
-the original
-.q From:
-field is renamed
-.q Original-From: .
-.pp
-The file
-.i conf.c
-also contains the specification of ARPANET reply codes.
-There are six classifications these fall into:
-.(b
-.sz -2
-.ta \w'char  'u +\w'Arpa_Usrerr[] =  'u +\w'"999";  'u
-char   Arpa_Info[] =   "050";  /* arbitrary info */
-char   Arpa_Enter[] =  "350";  /* start mail input */
-char   Arpa_Mmsg[] =   "256";  /* mail successful (MAIL cmd) */
-char   Arpa_Fmsg[] =   "250";  /* mail successful (MLFL cmd) */
-char   Arpa_Syserr[] = "455";  /* some (transient) system error */
-char   Arpa_Usrerr[] = "450";  /* some (fatal) user error */
-.sz
-.)b
-The class
-.i Arpa_Info
-is for any information that is not required by the protocol,
-such as forwarding information.
-.i Arpa_Enter
-is output when
-.i sendmail
-wants to start receiving the mail.
-.i Arpa_Mmsg
-and
-.i Arpa_Fmsg
-are given if the mail is successfully delivered;
-the selection of message number depends on the command given
-(which is communicated via the
-.b \-a
-flag).
-.i Arpa_Syserr
-is printed by the
-.i syserr
-routine;
-typically, this occurs when something has gone wrong at the
-receiving site,
-with the assumption that it is a transient condition.
-Finally,
-.i Arpa_Usrerr
-is the result of a user error
-and is generated by the
-.i usrerr
-routine;
-these are generated when the user has specified something wrong,
-and hence the error is permanent,
-i.e.,
-it will not work simply by resubmitting the request.
-.pp
-If it is necessary to restrict mail through a gateway,
-the
-.i checkcompat
-routine can be modified.
-This routine is called for every recipient address.
-It can return
-.b TRUE
-to indicate that the address is acceptable
-and mail processing will continue,
-or it can return
-.b FALSE
-to reject the recipient.
-If it returns false,
-it is up to
-.i checkcompat
-to print an error message
-(using
-.i usrerr )
-saying why the message is rejected.
-For example,
-.i checkcompat
-could read:
-.(b
-.re
-.sz -2
-bool
-checkcompat(to)
-       register ADDRESS *to;
-{
-       if (MsgSize > 50000 && to->q_mailer != MN_LOCAL)
-       {
-               usrerr("Message too large for non-local delivery");
-               return (FALSE);
-       }
-       return (TRUE);
-}
-.sz
-.)b
-This would reject messages greater than 50000 bytes
-unless they were local.
-The actual use of this routine is highly dependent on the
-implementation,
-and use should be limited.