diff options
Diffstat (limited to 'usr.sbin/sendmail/doc/intro/intro.me')
| -rw-r--r-- | usr.sbin/sendmail/doc/intro/intro.me | 1478 |
1 files changed, 1478 insertions, 0 deletions
diff --git a/usr.sbin/sendmail/doc/intro/intro.me b/usr.sbin/sendmail/doc/intro/intro.me new file mode 100644 index 0000000..0406bb1 --- /dev/null +++ b/usr.sbin/sendmail/doc/intro/intro.me @@ -0,0 +1,1478 @@ +.\" Copyright (c) 1983 Eric P. Allman +.\" Copyright (c) 1988, 1993 +.\" The Regents of the University of California. All rights reserved. +.\" +.\" Redistribution and use in source and binary forms, with or without +.\" modification, are permitted provided that the following conditions +.\" are met: +.\" 1. Redistributions of source code must retain the above copyright +.\" notice, this list of conditions and the following disclaimer. +.\" 2. Redistributions in binary form must reproduce the above copyright +.\" notice, this list of conditions and the following disclaimer in the +.\" documentation and/or other materials provided with the distribution. +.\" 3. All advertising materials mentioning features or use of this software +.\" must display the following acknowledgement: +.\" This product includes software developed by the University of +.\" California, Berkeley and its contributors. +.\" 4. Neither the name of the University nor the names of its contributors +.\" may be used to endorse or promote products derived from this software +.\" without specific prior written permission. +.\" +.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND +.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE +.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE +.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL +.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS +.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) +.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY +.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +.\" SUCH DAMAGE. +.\" +.\" @(#)intro.me 8.2 (Berkeley) 11/27/93 +.\" +.\" pic -Pxx intro.me | ditroff -me -Pxx +.eh 'SMM:9-%''SENDMAIL \*- An Internetwork Mail Router' +.oh 'SENDMAIL \*- An Internetwork Mail Router''SMM:9-%' +.nr si 3n +.if n .ls 2 +.+c +.(l C +.sz 14 +SENDMAIL \*- An Internetwork Mail Router +.sz +.sp +Eric Allman* +.sp 0.5 +.i +University of California, Berkeley +Mammoth Project +.)l +.sp +.(l F +.ce +ABSTRACT +.sp \n(psu +Routing mail through a heterogenous internet presents many new +problems. Among the worst of these is that of address mapping. +Historically, this has been handled on an +.i "ad hoc" +basis. However, +this approach has become unmanageable as internets grow. +.sp \n(psu +Sendmail acts a unified "post office" to which all mail can be +submitted. Address interpretation is controlled by a production +system, which can parse both domain-based addressing and old-style +.i "ad hoc" +addresses. +The production system is powerful +enough to rewrite addresses in the message header to conform to the +standards of a number of common target networks, including old +(NCP/RFC733) Arpanet, new (TCP/RFC822) Arpanet, UUCP, and Phonenet. +Sendmail also implements an SMTP server, message +queueing, and aliasing. +.)l +.sp 2 +.(f +*A considerable part of this work +was done while under the employ +of the INGRES Project +at the University of California at Berkeley +and at Britton Lee. +.)f +.pp +.i Sendmail +implements a general internetwork mail routing facility, +featuring aliasing and forwarding, +automatic routing to network gateways, +and flexible configuration. +.pp +In a simple network, +each node has an address, +and resources can be identified +with a host-resource pair; +in particular, +the mail system can refer to users +using a host-username pair. +Host names and numbers have to be administered by a central authority, +but usernames can be assigned locally to each host. +.pp +In an internet, +multiple networks with different characterstics +and managements +must communicate. +In particular, +the syntax and semantics of resource identification change. +Certain special cases can be handled trivially +by +.i "ad hoc" +techniques, +such as +providing network names that appear local to hosts +on other networks, +as with the Ethernet at Xerox PARC. +However, the general case is extremely complex. +For example, +some networks require point-to-point routing, +which simplifies the database update problem +since only adjacent hosts must be entered +into the system tables, +while others use end-to-end addressing. +Some networks use a left-associative syntax +and others use a right-associative syntax, +causing ambiguity in mixed addresses. +.pp +Internet standards seek to eliminate these problems. +Initially, these proposed expanding the address pairs +to address triples, +consisting of +{network, host, resource} +triples. +Network numbers must be universally agreed upon, +and hosts can be assigned locally +on each network. +The user-level presentation was quickly expanded +to address domains, +comprised of a local resource identification +and a hierarchical domain specification +with a common static root. +The domain technique +separates the issue of physical versus logical addressing. +For example, +an address of the form +.q "eric@a.cc.berkeley.arpa" +describes only the logical +organization of the address space. +.pp +.i Sendmail +is intended to help bridge the gap +between the totally +.i "ad hoc" +world +of networks that know nothing of each other +and the clean, tightly-coupled world +of unique network numbers. +It can accept old arbitrary address syntaxes, +resolving ambiguities using heuristics +specified by the system administrator, +as well as domain-based addressing. +It helps guide the conversion of message formats +between disparate networks. +In short, +.i sendmail +is designed to assist a graceful transition +to consistent internetwork addressing schemes. +.sp +.pp +Section 1 discusses the design goals for +.i sendmail . +Section 2 gives an overview of the basic functions of the system. +In section 3, +details of usage are discussed. +Section 4 compares +.i sendmail +to other internet mail routers, +and an evaluation of +.i sendmail +is given in section 5, +including future plans. +.sh 1 "DESIGN GOALS" +.pp +Design goals for +.i sendmail +include: +.np +Compatibility with the existing mail programs, +including Bell version 6 mail, +Bell version 7 mail +[UNIX83], +Berkeley +.i Mail +[Shoens79], +BerkNet mail +[Schmidt79], +and hopefully UUCP mail +[Nowitz78a, Nowitz78b]. +ARPANET mail +[Crocker77a, Postel77] +was also required. +.np +Reliability, in the sense of guaranteeing +that every message is correctly delivered +or at least brought to the attention of a human +for correct disposal; +no message should ever be completely lost. +This goal was considered essential +because of the emphasis on mail in our environment. +It has turned out to be one of the hardest goals to satisfy, +especially in the face of the many anomalous message formats +produced by various ARPANET sites. +For example, +certain sites generate improperly formated addresses, +occasionally +causing error-message loops. +Some hosts use blanks in names, +causing problems with +UNIX mail programs that assume that an address +is one word. +The semantics of some fields +are interpreted slightly differently +by different sites. +In summary, +the obscure features of the ARPANET mail protocol +really +.i are +used and +are difficult to support, +but must be supported. +.np +Existing software to do actual delivery +should be used whenever possible. +This goal derives as much from political and practical considerations +as technical. +.np +Easy expansion to +fairly complex environments, +including multiple +connections to a single network type +(such as with multiple UUCP or Ether nets +[Metcalfe76]). +This goal requires consideration of the contents of an address +as well as its syntax +in order to determine which gateway to use. +For example, +the ARPANET is bringing up the +TCP protocol to replace the old NCP protocol. +No host at Berkeley runs both TCP and NCP, +so it is necessary to look at the ARPANET host name +to determine whether to route mail to an NCP gateway +or a TCP gateway. +.np +Configuration should not be compiled into the code. +A single compiled program should be able to run as is at any site +(barring such basic changes as the CPU type or the operating system). +We have found this seemingly unimportant goal +to be critical in real life. +Besides the simple problems that occur when any program gets recompiled +in a different environment, +many sites like to +.q fiddle +with anything that they will be recompiling anyway. +.np +.i Sendmail +must be able to let various groups maintain their own mailing lists, +and let individuals specify their own forwarding, +without modifying the system alias file. +.np +Each user should be able to specify which mailer to execute +to process mail being delivered for him. +This feature allows users who are using specialized mailers +that use a different format to build their environment +without changing the system, +and facilitates specialized functions +(such as returning an +.q "I am on vacation" +message). +.np +Network traffic should be minimized +by batching addresses to a single host where possible, +without assistance from the user. +.pp +These goals motivated the architecture illustrated in figure 1. +.(z +.hl +.ie t \ +\{\ +.ie !"\*(.T"" \ +\{\ +.PS +boxht = 0.5i +boxwid = 1.0i + + down +S: [ + right + S1: box "sender1" + move + box "sender2" + move + S3: box "sender3" + ] + arrow +SM: box "sendmail" wid 2i ht boxht + arrow +M: [ + right + M1: box "mailer1" + move + box "mailer2" + move + M3: box "mailer3" + ] + + arrow from S.S1.s to 1/2 between SM.nw and SM.n + arrow from S.S3.s to 1/2 between SM.n and SM.ne + + arrow from 1/2 between SM.sw and SM.s to M.M1.n + arrow from 1/2 between SM.s and SM.se to M.M3.n +.PE +.\} +.el \ +. sp 18 +.\} +.el \{\ +.(c ++---------+ +---------+ +---------+ +| sender1 | | sender2 | | sender3 | ++---------+ +---------+ +---------+ + | | | + +----------+ + +----------+ + | | | + v v v + +-------------+ + | sendmail | + +-------------+ + | | | + +----------+ + +----------+ + | | | + v v v ++---------+ +---------+ +---------+ +| mailer1 | | mailer2 | | mailer3 | ++---------+ +---------+ +---------+ +.)c +.\} + +.ce +Figure 1 \*- Sendmail System Structure. +.hl +.)z +The user interacts with a mail generating and sending program. +When the mail is created, +the generator calls +.i sendmail , +which routes the message to the correct mailer(s). +Since some of the senders may be network servers +and some of the mailers may be network clients, +.i sendmail +may be used as an internet mail gateway. +.sh 1 "OVERVIEW" +.sh 2 "System Organization" +.pp +.i Sendmail +neither interfaces with the user +nor does actual mail delivery. +Rather, +it collects a message +generated by a user interface program (UIP) +such as Berkeley +.i Mail , +MS +[Crocker77b], +or MH +[Borden79], +edits the message as required by the destination network, +and calls appropriate mailers +to do mail delivery or queueing for network transmission\**. +.(f +\**except when mailing to a file, +when +.i sendmail +does the delivery directly. +.)f +This discipline allows the insertion of new mailers +at minimum cost. +In this sense +.i sendmail +resembles the Message Processing Module (MPM) +of [Postel79b]. +.sh 2 "Interfaces to the Outside World" +.pp +There are three ways +.i sendmail +can communicate with the outside world, +both in receiving and in sending mail. +These are using the conventional UNIX +argument vector/return status, +speaking SMTP over a pair of UNIX pipes, +and speaking SMTP over an interprocess(or) channel. +.sh 3 "Argument vector/exit status" +.pp +This technique is the standard UNIX method +for communicating with the process. +A list of recipients is sent in the argument vector, +and the message body is sent on the standard input. +Anything that the mailer prints +is simply collected and sent back to the sender +if there were any problems. +The exit status from the mailer is collected +after the message is sent, +and a diagnostic is printed if appropriate. +.sh 3 "SMTP over pipes" +.pp +The SMTP protocol +[Postel82] +can be used to run an interactive lock-step interface +with the mailer. +A subprocess is still created, +but no recipient addresses are passed to the mailer +via the argument list. +Instead, they are passed one at a time +in commands sent to the processes standard input. +Anything appearing on the standard output +must be a reply code +in a special format. +.sh 3 "SMTP over an IPC connection" +.pp +This technique is similar to the previous technique, +except that it uses a 4.2bsd IPC channel +[UNIX83]. +This method is exceptionally flexible +in that the mailer need not reside +on the same machine. +It is normally used to connect to a sendmail process +on another machine. +.sh 2 "Operational Description" +.pp +When a sender wants to send a message, +it issues a request to +.i sendmail +using one of the three methods described above. +.i Sendmail +operates in two distinct phases. +In the first phase, +it collects and stores the message. +In the second phase, +message delivery occurs. +If there were errors during processing +during the second phase, +.i sendmail +creates and returns a new message describing the error +and/or returns an status code +telling what went wrong. +.sh 3 "Argument processing and address parsing" +.pp +If +.i sendmail +is called using one of the two subprocess techniques, +the arguments +are first scanned +and option specifications are processed. +Recipient addresses are then collected, +either from the command line +or from the SMTP +RCPT command, +and a list of recipients is created. +Aliases are expanded at this step, +including mailing lists. +As much validation as possible of the addresses +is done at this step: +syntax is checked, and local addresses are verified, +but detailed checking of host names and addresses +is deferred until delivery. +Forwarding is also performed +as the local addresses are verified. +.pp +.i Sendmail +appends each address +to the recipient list after parsing. +When a name is aliased or forwarded, +the old name is retained in the list, +and a flag is set that tells the delivery phase +to ignore this recipient. +This list is kept free from duplicates, +preventing alias loops +and duplicate messages deliverd to the same recipient, +as might occur if a person is in two groups. +.sh 3 "Message collection" +.pp +.i Sendmail +then collects the message. +The message should have a header at the beginning. +No formatting requirements are imposed on the message +except that they must be lines of text +(i.e., binary data is not allowed). +The header is parsed and stored in memory, +and the body of the message is saved +in a temporary file. +.pp +To simplify the program interface, +the message is collected even if no addresses were valid. +The message will be returned with an error. +.sh 3 "Message delivery" +.pp +For each unique mailer and host in the recipient list, +.i sendmail +calls the appropriate mailer. +Each mailer invocation sends to all users receiving the message on one host. +Mailers that only accept one recipient at a time +are handled properly. +.pp +The message is sent to the mailer +using one of the same three interfaces +used to submit a message to sendmail. +Each copy of the message is +prepended by a customized header. +The mailer status code is caught and checked, +and a suitable error message given as appropriate. +The exit code must conform to a system standard +or a generic message +(\c +.q "Service unavailable" ) +is given. +.sh 3 "Queueing for retransmission" +.pp +If the mailer returned an status that +indicated that it might be able to handle the mail later, +.i sendmail +will queue the mail and try again later. +.sh 3 "Return to sender" +.pp +If errors occur during processing, +.i sendmail +returns the message to the sender for retransmission. +The letter can be mailed back +or written in the file +.q dead.letter +in the sender's home directory\**. +.(f +\**Obviously, if the site giving the error is not the originating +site, the only reasonable option is to mail back to the sender. +Also, there are many more error disposition options, +but they only effect the error message \*- the +.q "return to sender" +function is always handled in one of these two ways. +.)f +.sh 2 "Message Header Editing" +.pp +Certain editing of the message header +occurs automatically. +Header lines can be inserted +under control of the configuration file. +Some lines can be merged; +for example, +a +.q From: +line and a +.q Full-name: +line can be merged under certain circumstances. +.sh 2 "Configuration File" +.pp +Almost all configuration information is read at runtime +from an ASCII file, +encoding +macro definitions +(defining the value of macros used internally), +header declarations +(telling sendmail the format of header lines that it will process specially, +i.e., lines that it will add or reformat), +mailer definitions +(giving information such as the location and characteristics +of each mailer), +and address rewriting rules +(a limited production system to rewrite addresses +which is used to parse and rewrite the addresses). +.pp +To improve performance when reading the configuration file, +a memory image can be provided. +This provides a +.q compiled +form of the configuration file. +.sh 1 "USAGE AND IMPLEMENTATION" +.sh 2 "Arguments" +.pp +Arguments may be flags and addresses. +Flags set various processing options. +Following flag arguments, +address arguments may be given, +unless we are running in SMTP mode. +Addresses follow the syntax in RFC822 +[Crocker82] +for ARPANET +address formats. +In brief, the format is: +.np +Anything in parentheses is thrown away +(as a comment). +.np +Anything in angle brackets (\c +.q "<\|>" ) +is preferred +over anything else. +This rule implements the ARPANET standard that addresses of the form +.(b +user name <machine-address> +.)b +will send to the electronic +.q machine-address +rather than the human +.q "user name." +.np +Double quotes +(\ "\ ) +quote phrases; +backslashes quote characters. +Backslashes are more powerful +in that they will cause otherwise equivalent phrases +to compare differently \*- for example, +.i user +and +.i +"user" +.r +are equivalent, +but +.i \euser +is different from either of them. +.pp +Parentheses, angle brackets, and double quotes +must be properly balanced and nested. +The rewriting rules control remaining parsing\**. +.(f +\**Disclaimer: Some special processing is done +after rewriting local names; see below. +.)f +.sh 2 "Mail to Files and Programs" +.pp +Files and programs are legitimate message recipients. +Files provide archival storage of messages, +useful for project administration and history. +Programs are useful as recipients in a variety of situations, +for example, +to maintain a public repository of systems messages +(such as the Berkeley +.i msgs +program, +or the MARS system +[Sattley78]). +.pp +Any address passing through the initial parsing algorithm +as a local address +(i.e, not appearing to be a valid address for another mailer) +is scanned for two special cases. +If prefixed by a vertical bar (\c +.q \^|\^ ) +the rest of the address is processed as a shell command. +If the user name begins with a slash mark (\c +.q /\^ ) +the name is used as a file name, +instead of a login name. +.pp +Files that have setuid or setgid bits set +but no execute bits set +have those bits honored if +.i sendmail +is running as root. +.sh 2 "Aliasing, Forwarding, Inclusion" +.pp +.i Sendmail +reroutes mail three ways. +Aliasing applies system wide. +Forwarding allows each user to reroute incoming mail +destined for that account. +Inclusion directs +.i sendmail +to read a file for a list of addresses, +and is normally used +in conjunction with aliasing. +.sh 3 "Aliasing" +.pp +Aliasing maps names to address lists using a system-wide file. +This file is indexed to speed access. +Only names that parse as local +are allowed as aliases; +this guarantees a unique key +(since there are no nicknames for the local host). +.sh 3 "Forwarding" +.pp +After aliasing, +recipients that are local and valid +are checked for the existence of a +.q .forward +file in their home directory. +If it exists, +the message is +.i not +sent to that user, +but rather to the list of users in that file. +Often +this list will contain only one address, +and the feature will be used for network mail forwarding. +.pp +Forwarding also permits a user to specify a private incoming mailer. +For example, +forwarding to: +.(b +"\^|\|/usr/local/newmail myname" +.)b +will use a different incoming mailer. +.sh 3 "Inclusion" +.pp +Inclusion is specified in RFC 733 [Crocker77a] syntax: +.(b +:Include: pathname +.)b +An address of this form reads the file specified by +.i pathname +and sends to all users listed in that file. +.pp +The intent is +.i not +to support direct use of this feature, +but rather to use this as a subset of aliasing. +For example, +an alias of the form: +.(b +project: :include:/usr/project/userlist +.)b +is a method of letting a project maintain a mailing list +without interaction with the system administration, +even if the alias file is protected. +.pp +It is not necessary to rebuild the index on the alias database +when a :include: list is changed. +.sh 2 "Message Collection" +.pp +Once all recipient addresses are parsed and verified, +the message is collected. +The message comes in two parts: +a message header and a message body, +separated by a blank line. +.pp +The header is formatted as a series of lines +of the form +.(b + field-name: field-value +.)b +Field-value can be split across lines by starting the following +lines with a space or a tab. +Some header fields have special internal meaning, +and have appropriate special processing. +Other headers are simply passed through. +Some header fields may be added automatically, +such as time stamps. +.pp +The body is a series of text lines. +It is completely uninterpreted and untouched, +except that lines beginning with a dot +have the dot doubled +when transmitted over an SMTP channel. +This extra dot is stripped by the receiver. +.sh 2 "Message Delivery" +.pp +The send queue is ordered by receiving host +before transmission +to implement message batching. +Each address is marked as it is sent +so rescanning the list is safe. +An argument list is built as the scan proceeds. +Mail to files is detected during the scan of the send list. +The interface to the mailer +is performed using one of the techniques +described in section 2.2. +.pp +After a connection is established, +.i sendmail +makes the per-mailer changes to the header +and sends the result to the mailer. +If any mail is rejected by the mailer, +a flag is set to invoke the return-to-sender function +after all delivery completes. +.sh 2 "Queued Messages" +.pp +If the mailer returns a +.q "temporary failure" +exit status, +the message is queued. +A control file is used to describe the recipients to be sent to +and various other parameters. +This control file is formatted as a series of lines, +each describing a sender, +a recipient, +the time of submission, +or some other salient parameter of the message. +The header of the message is stored +in the control file, +so that the associated data file in the queue +is just the temporary file that was originally collected. +.sh 2 "Configuration" +.pp +Configuration is controlled primarily by a configuration file +read at startup. +.i Sendmail +should not need to be recomplied except +.np +To change operating systems +(V6, V7/32V, 4BSD). +.np +To remove or insert the DBM +(UNIX database) +library. +.np +To change ARPANET reply codes. +.np +To add headers fields requiring special processing. +.lp +Adding mailers or changing parsing +(i.e., rewriting) +or routing information +does not require recompilation. +.pp +If the mail is being sent by a local user, +and the file +.q .mailcf +exists in the sender's home directory, +that file is read as a configuration file +after the system configuration file. +The primary use of this feature is to add header lines. +.pp +The configuration file encodes macro definitions, +header definitions, +mailer definitions, +rewriting rules, +and options. +.sh 3 Macros +.pp +Macros can be used in three ways. +Certain macros transmit +unstructured textual information +into the mail system, +such as the name +.i sendmail +will use to identify itself in error messages. +Other macros transmit information from +.i sendmail +to the configuration file +for use in creating other fields +(such as argument vectors to mailers); +e.g., the name of the sender, +and the host and user +of the recipient. +Other macros are unused internally, +and can be used as shorthand in the configuration file. +.sh 3 "Header declarations" +.pp +Header declarations inform +.i sendmail +of the format of known header lines. +Knowledge of a few header lines +is built into +.i sendmail , +such as the +.q From: +and +.q Date: +lines. +.pp +Most configured headers +will be automatically inserted +in the outgoing message +if they don't exist in the incoming message. +Certain headers are suppressed by some mailers. +.sh 3 "Mailer declarations" +.pp +Mailer declarations tell +.i sendmail +of the various mailers available to it. +The definition specifies the internal name of the mailer, +the pathname of the program to call, +some flags associated with the mailer, +and an argument vector to be used on the call; +this vector is macro-expanded before use. +.sh 3 "Address rewriting rules" +.pp +The heart of address parsing in +.i sendmail +is a set of rewriting rules. +These are an ordered list of pattern-replacement rules, +(somewhat like a production system, +except that order is critical), +which are applied to each address. +The address is rewritten textually until it is either rewritten +into a special canonical form +(i.e., +a (mailer, host, user) +3-tuple, +such as {arpanet, usc-isif, postel} +representing the address +.q "postel@usc-isif" ), +or it falls off the end. +When a pattern matches, +the rule is reapplied until it fails. +.pp +The configuration file also supports the editing of addresses +into different formats. +For example, +an address of the form: +.(b +ucsfcgl!tef +.)b +might be mapped into: +.(b +tef@ucsfcgl.UUCP +.)b +to conform to the domain syntax. +Translations can also be done in the other direction. +.sh 3 "Option setting" +.pp +There are several options that can be set +from the configuration file. +These include the pathnames of various support files, +timeouts, +default modes, +etc. +.sh 1 "COMPARISON WITH OTHER MAILERS" +.sh 2 "Delivermail" +.pp +.i Sendmail +is an outgrowth of +.i delivermail . +The primary differences are: +.np +Configuration information is not compiled in. +This change simplifies many of the problems +of moving to other machines. +It also allows easy debugging of new mailers. +.np +Address parsing is more flexible. +For example, +.i delivermail +only supported one gateway to any network, +whereas +.i sendmail +can be sensitive to host names +and reroute to different gateways. +.np +Forwarding and +:include: +features eliminate the requirement that the system alias file +be writable by any user +(or that an update program be written, +or that the system administration make all changes). +.np +.i Sendmail +supports message batching across networks +when a message is being sent to multiple recipients. +.np +A mail queue is provided in +.i sendmail. +Mail that cannot be delivered immediately +but can potentially be delivered later +is stored in this queue for a later retry. +The queue also provides a buffer against system crashes; +after the message has been collected +it may be reliably redelivered +even if the system crashes during the initial delivery. +.np +.i Sendmail +uses the networking support provided by 4.2BSD +to provide a direct interface networks such as the ARPANET +and/or Ethernet +using SMTP (the Simple Mail Transfer Protocol) +over a TCP/IP connection. +.sh 2 "MMDF" +.pp +MMDF +[Crocker79] +spans a wider problem set than +.i sendmail . +For example, +the domain of +MMDF includes a +.q "phone network" +mailer, whereas +.i sendmail +calls on preexisting mailers in most cases. +.pp +MMDF and +.i sendmail +both support aliasing, +customized mailers, +message batching, +automatic forwarding to gateways, +queueing, +and retransmission. +MMDF supports two-stage timeout, +which +.i sendmail +does not support. +.pp +The configuration for MMDF +is compiled into the code\**. +.(f +\**Dynamic configuration tables are currently being considered +for MMDF; +allowing the installer to select either compiled +or dynamic tables. +.)f +.pp +Since MMDF does not consider backwards compatibility +as a design goal, +the address parsing is simpler but much less flexible. +.pp +It is somewhat harder to integrate a new channel\** +.(f +\**The MMDF equivalent of a +.i sendmail +.q mailer. +.)f +into MMDF. +In particular, +MMDF must know the location and format +of host tables for all channels, +and the channel must speak a special protocol. +This allows MMDF to do additional verification +(such as verifying host names) +at submission time. +.pp +MMDF strictly separates the submission and delivery phases. +Although +.i sendmail +has the concept of each of these stages, +they are integrated into one program, +whereas in MMDF they are split into two programs. +.sh 2 "Message Processing Module" +.pp +The Message Processing Module (MPM) +discussed by Postel [Postel79b] +matches +.i sendmail +closely in terms of its basic architecture. +However, +like MMDF, +the MPM includes the network interface software +as part of its domain. +.pp +MPM also postulates a duplex channel to the receiver, +as does MMDF, +thus allowing simpler handling of errors +by the mailer +than is possible in +.i sendmail . +When a message queued by +.i sendmail +is sent, +any errors must be returned to the sender +by the mailer itself. +Both MPM and MMDF mailers +can return an immediate error response, +and a single error processor can create an appropriate response. +.pp +MPM prefers passing the message as a structured object, +with type-length-value tuples\**. +.(f +\**This is similar to the NBS standard. +.)f +Such a convention requires a much higher degree of cooperation +between mailers than is required by +.i sendmail . +MPM also assumes a universally agreed upon internet name space +(with each address in the form of a net-host-user tuple), +which +.i sendmail +does not. +.sh 1 "EVALUATIONS AND FUTURE PLANS" +.pp +.i Sendmail +is designed to work in a nonhomogeneous environment. +Every attempt is made to avoid imposing unnecessary constraints +on the underlying mailers. +This goal has driven much of the design. +One of the major problems +has been the lack of a uniform address space, +as postulated in [Postel79a] +and [Postel79b]. +.pp +A nonuniform address space implies that a path will be specified +in all addresses, +either explicitly (as part of the address) +or implicitly +(as with implied forwarding to gateways). +This restriction has the unpleasant effect of making replying to messages +exceedingly difficult, +since there is no one +.q address +for any person, +but only a way to get there from wherever you are. +.pp +Interfacing to mail programs +that were not initially intended to be applied +in an internet environment +has been amazingly successful, +and has reduced the job to a manageable task. +.pp +.i Sendmail +has knowledge of a few difficult environments +built in. +It generates ARPANET FTP/SMTP compatible error messages +(prepended with three-digit numbers +[Neigus73, Postel74, Postel82]) +as necessary, +optionally generates UNIX-style +.q From +lines on the front of messages for some mailers, +and knows how to parse the same lines on input. +Also, +error handling has an option customized for BerkNet. +.pp +The decision to avoid doing any type of delivery where possible +(even, or perhaps especially, local delivery) +has turned out to be a good idea. +Even with local delivery, +there are issues of the location of the mailbox, +the format of the mailbox, +the locking protocol used, +etc., +that are best decided by other programs. +One surprisingly major annoyance in many internet mailers +is that the location and format of local mail is built in. +The feeling seems to be that local mail is so common +that it should be efficient. +This feeling is not born out by +our experience; +on the contrary, +the location and format of mailboxes seems to vary widely +from system to system. +.pp +The ability to automatically generate a response to incoming mail +(by forwarding mail to a program) +seems useful +(\c +.q "I am on vacation until late August...." ) +but can create problems +such as forwarding loops +(two people on vacation whose programs send notes back and forth, +for instance) +if these programs are not well written. +A program could be written to do standard tasks correctly, +but this would solve the general case. +.pp +It might be desirable to implement some form of load limiting. +I am unaware of any mail system that addresses this problem, +nor am I aware of any reasonable solution at this time. +.pp +The configuration file is currently practically inscrutable; +considerable convenience could be realized +with a higher-level format. +.pp +It seems clear that common protocols will be changing soon +to accommodate changing requirements and environments. +These changes will include modifications to the message header +(e.g., [NBS80]) +or to the body of the message itself +(such as for multimedia messages +[Postel80]). +Experience indicates that +these changes should be relatively trivial to integrate +into the existing system. +.pp +In tightly coupled environments, +it would be nice to have a name server +such as Grapvine +[Birrell82] +integrated into the mail system. +This would allow a site such as +.q Berkeley +to appear as a single host, +rather than as a collection of hosts, +and would allow people to move transparently among machines +without having to change their addresses. +Such a facility +would require an automatically updated database +and some method of resolving conflicts. +Ideally this would be effective even without +all hosts being under +a single management. +However, +it is not clear whether this feature +should be integrated into the +aliasing facility +or should be considered a +.q "value added" +feature outside +.i sendmail +itself. +.pp +As a more interesting case, +the CSNET name server +[Solomon81] +provides an facility that goes beyond a single +tightly-coupled environment. +Such a facility would normally exist outside of +.i sendmail +however. +.sh 0 "ACKNOWLEDGEMENTS" +.pp +Thanks are due to Kurt Shoens for his continual cheerful +assistance and good advice, +Bill Joy for pointing me in the correct direction +(over and over), +and Mark Horton for more advice, +prodding, +and many of the good ideas. +Kurt and Eric Schmidt are to be credited +for using +.i delivermail +as a server for their programs +(\c +.i Mail +and BerkNet respectively) +before any sane person should have, +and making the necessary modifications +promptly and happily. +Eric gave me considerable advice about the perils +of network software which saved me an unknown +amount of work and grief. +Mark did the original implementation of the DBM version +of aliasing, installed the VFORK code, +wrote the current version of +.i rmail , +and was the person who really convinced me +to put the work into +.i delivermail +to turn it into +.i sendmail . +Kurt deserves accolades for using +.i sendmail +when I was myself afraid to take the risk; +how a person can continue to be so enthusiastic +in the face of so much bitter reality is beyond me. +.pp +Kurt, +Mark, +Kirk McKusick, +Marvin Solomon, +and many others have reviewed this paper, +giving considerable useful advice. +.pp +Special thanks are reserved for Mike Stonebraker at Berkeley +and Bob Epstein at Britton-Lee, +who both knowingly allowed me to put so much work into this +project +when there were so many other things I really should +have been working on. +.+c +.ce +REFERENCES +.nr ii 1.5i +.ip [Birrell82] +Birrell, A. D., +Levin, R., +Needham, R. M., +and +Schroeder, M. D., +.q "Grapevine: An Exercise in Distributed Computing." +In +.ul +Comm. A.C.M. 25, +4, +April 82. +.ip [Borden79] +Borden, S., +Gaines, R. S., +and +Shapiro, N. Z., +.ul +The MH Message Handling System: Users' Manual. +R-2367-PAF. +Rand Corporation. +October 1979. +.ip [Crocker77a] +Crocker, D. H., +Vittal, J. J., +Pogran, K. T., +and +Henderson, D. A. Jr., +.ul +Standard for the Format of ARPA Network Text Messages. +RFC 733, +NIC 41952. +In [Feinler78]. +November 1977. +.ip [Crocker77b] +Crocker, D. H., +.ul +Framework and Functions of the MS Personal Message System. +R-2134-ARPA, +Rand Corporation, +Santa Monica, California. +1977. +.ip [Crocker79] +Crocker, D. H., +Szurkowski, E. S., +and +Farber, D. J., +.ul +An Internetwork Memo Distribution Facility \*- MMDF. +6th Data Communication Symposium, +Asilomar. +November 1979. +.ip [Crocker82] +Crocker, D. H., +.ul +Standard for the Format of Arpa Internet Text Messages. +RFC 822. +Network Information Center, +SRI International, +Menlo Park, California. +August 1982. +.ip [Metcalfe76] +Metcalfe, R., +and +Boggs, D., +.q "Ethernet: Distributed Packet Switching for Local Computer Networks" , +.ul +Communications of the ACM 19, +7. +July 1976. +.ip [Feinler78] +Feinler, E., +and +Postel, J. +(eds.), +.ul +ARPANET Protocol Handbook. +NIC 7104, +Network Information Center, +SRI International, +Menlo Park, California. +1978. +.ip [NBS80] +National Bureau of Standards, +.ul +Specification of a Draft Message Format Standard. +Report No. ICST/CBOS 80-2. +October 1980. +.ip [Neigus73] +Neigus, N., +.ul +File Transfer Protocol for the ARPA Network. +RFC 542, NIC 17759. +In [Feinler78]. +August, 1973. +.ip [Nowitz78a] +Nowitz, D. A., +and +Lesk, M. E., +.ul +A Dial-Up Network of UNIX Systems. +Bell Laboratories. +In +UNIX Programmer's Manual, Seventh Edition, +Volume 2. +August, 1978. +.ip [Nowitz78b] +Nowitz, D. A., +.ul +Uucp Implementation Description. +Bell Laboratories. +In +UNIX Programmer's Manual, Seventh Edition, +Volume 2. +October, 1978. +.ip [Postel74] +Postel, J., +and +Neigus, N., +Revised FTP Reply Codes. +RFC 640, NIC 30843. +In [Feinler78]. +June, 1974. +.ip [Postel77] +Postel, J., +.ul +Mail Protocol. +NIC 29588. +In [Feinler78]. +November 1977. +.ip [Postel79a] +Postel, J., +.ul +Internet Message Protocol. +RFC 753, +IEN 85. +Network Information Center, +SRI International, +Menlo Park, California. +March 1979. +.ip [Postel79b] +Postel, J. B., +.ul +An Internetwork Message Structure. +In +.ul +Proceedings of the Sixth Data Communications Symposium, +IEEE. +New York. +November 1979. +.ip [Postel80] +Postel, J. B., +.ul +A Structured Format for Transmission of Multi-Media Documents. +RFC 767. +Network Information Center, +SRI International, +Menlo Park, California. +August 1980. +.ip [Postel82] +Postel, J. B., +.ul +Simple Mail Transfer Protocol. +RFC821 +(obsoleting RFC788). +Network Information Center, +SRI International, +Menlo Park, California. +August 1982. +.ip [Schmidt79] +Schmidt, E., +.ul +An Introduction to the Berkeley Network. +University of California, Berkeley California. +1979. +.ip [Shoens79] +Shoens, K., +.ul +Mail Reference Manual. +University of California, Berkeley. +In UNIX Programmer's Manual, +Seventh Edition, +Volume 2C. +December 1979. +.ip [Sluizer81] +Sluizer, S., +and +Postel, J. B., +.ul +Mail Transfer Protocol. +RFC 780. +Network Information Center, +SRI International, +Menlo Park, California. +May 1981. +.ip [Solomon81] +Solomon, M., Landweber, L., and Neuhengen, D., +.q "The Design of the CSNET Name Server." +CS-DN-2, +University of Wisconsin, Madison. +November 1981. +.ip [Su82] +Su, Zaw-Sing, +and +Postel, Jon, +.ul +The Domain Naming Convention for Internet User Applications. +RFC819. +Network Information Center, +SRI International, +Menlo Park, California. +August 1982. +.ip [UNIX83] +.ul +The UNIX Programmer's Manual, Seventh Edition, +Virtual VAX-11 Version, +Volume 1. +Bell Laboratories, +modified by the University of California, +Berkeley, California. +March, 1983. |
