1.nr DR 1 \" this is a draft copy 2.nr si 3n 3.he 'SENDMAIL''%' 4.fo 'Version 3.22'DRAFT'Last Mod 11/03/82' 5.ls 2 6.+c 7.(l C 8.sz 14 9SENDMAIL \*- An Internetwork Mail Router 10.sz 11.sp 12Eric Allman\(dg 13.sp 0.5 14.i 15Britton-Lee, Inc. 161919 Addison Street, Suite 105. 17Berkeley, California 94704. 18.)l 19.sp 20.(l F 21.ce 22ABSTRACT 23.sp \n(psu 24Routing mail through a heterogenous internet presents many new 25problems. Among the worst of these is that of address mapping. 26Historically, this has been handled on an ad hoc basis. However, 27this approach has become unmanageable as internets grow. 28.sp \n(psu 29Sendmail acts a unified "post office" to which all mail can be 30submitted. Address interpretation is controlled by a production 31system, which can parse both domain-based addressing and old-style 32ad hoc addresses. 33The production system is powerful 34enough to rewrite addresses in the message header to conform to the 35standards of a number of common target networks, including old 36(NCP/RFC733) Arpanet, new (TCP/RFC822) Arpanet, UUCP, and Phonenet. 37Sendmail also implements an SMTP server, message 38queueing, and aliasing. 39.)l 40.sp 2 41.(f 42\(dgA considerable part of this work 43was done while under the employ 44of the INGRES Project 45at the University of California at Berkeley. 46.)f 47.pp 48.i Sendmail 49implements a general internetwork mail routing facility, 50featuring aliasing and forwarding, 51automatic routing to network gateways, 52and flexible configuration. 53.pp 54In a simple network, 55each node has an address, 56and resources can be identified 57with a host-resource pair; 58in particular, 59the mail system can refer to users 60using a host-username pair. 61Host names and numbers have to be administered by a central authority, 62but usernames can be assigned locally to each host. 63.pp 64In an internet, 65multiple networks with different characterstics 66and managements 67must communicate. 68In particular, 69the syntax and semantics of resource identification change. 70Certain special cases can be handled trivially 71by ad hoc techniques, 72such as 73providing network names that appear local to hosts 74on other networks, 75as with the Ethernet at Xerox PARC [ref?]. 76However, the general case is extremely complex. 77For example, 78some networks require point-to-point routing, 79which simplifies the database update problem 80since only adjacent hosts must be entered 81into the system tables, 82while others use end-to-end addressing. 83Some networks use a left-associative syntax 84and others use a right-associative syntax, 85causing ambiguity in mixed addresses. 86.pp 87Internet standards seek to eliminate these problems. 88Initially, these proposed expanding the address pairs 89to address triples, 90consisting of 91{network, host, resource} 92triples. 93Network numbers must be universally agreed upon, 94and hosts can be assigned locally 95on each network. 96The user level presentation was quickly expanded 97to address domains, 98comprised of a local resource identification 99and a hierarchical domain specification 100with a common static root. 101The domain technique 102separates the issue of physical versus logical addressing. 103For example, 104an address of the form 105.q "eric@a.cc.berkeley.arpa" 106describes only the logical 107organization of the address space. 108.pp 109.i Sendmail 110is intended to help bridge the gap 111between the totally ad hoc world 112of networks that know nothing of each other 113and the clean, tightly-coupled world 114of unique network numbers. 115It can accept old arbitrary address syntaxes, 116resolving ambiguities using heuristics 117specified by the system administrator, 118as well as domain-based addressing. 119It helps guide the conversion of message formats 120between disparate networks. 121In short, 122.i sendmail 123is designed to assist a graceful transition 124to consistent internetwork addressing schemes. 125.sp 126.pp 127Section 1 discusses the design goals for 128.i sendmail . 129Section 2 gives an overview of the basic functions of the system. 130In section 3, 131details of usage are discussed. 132Section 4 compares 133.i sendmail 134to other internet mail routers, 135and an evaluation of 136.i sendmail 137is given in section 5, 138including future plans. 139.sh 1 "DESIGN GOALS" 140.pp 141Design goals for 142.i sendmail 143include: 144.np 145Compatibility with the existing mail system, 146including Bell version 6 mail, 147Bell version 7 mail 148[UNIX80], 149Berkeley 150.i Mail 151[Shoens79], 152BerkNet mail 153[Schmidt79], 154and hopefully UUCP mail 155[Nowitz78a, Nowitz78b]. 156ARPANET mail 157[Crocker77a, Postel77] 158was also required. 159.np 160Reliability, in the sense of guaranteeing 161that every message is correctly delivered 162or at least brought to the attention of a human 163for correct disposal; 164no message should ever be completely lost. 165This was considered essential 166because of the emphasis on mail in our environment. 167This turned out to be one of the hardest goals to satisfy, 168especially in the face of the many anomalous message formats 169produced by various ARPANET sites. 170For example, 171certain sites generate incorrect from addresses 172which caused error message loops. 173Some hosts use blanks in names, 174which created problems with 175UNIX mail programs that assume that an address 176is one word. 177The semantics of some fields 178are interpreted slightly differently 179by different sites. 180In summary, 181the obscure aspects of the ARPANET mail protocol 182really 183.i are 184used and 185are difficult to support, 186but must be supported. 187But even obeying the standard is insufficient. 188For example, 189Wharton changed our host name from 190.q BERKELEY 191to 192.q BERKEL- , 193which confused error processing. 194Cases such as this 195must be handled gracefully. 196.np 197Existing software to do actual delivery 198should be used whenever possible. 199This resulted as much from political and practical considerations 200as technical. 201.np 202Easy expansion to 203fairly complex environments, 204including multiple 205connections to a single network type 206(such as with multiple UUCP or Ether nets 207[Metcalfe76]). 208This requires consideration of the contents of an address 209as well as the syntax 210in order to determine the gateway to use. 211For example, 212the ARPANET is bringing up the 213TCP protocol to replace the old NCP protocol. 214No host at Berkeley runs both TCP and NCP, 215so it is necessary to look at the ARPANET host name 216to determine whether to route mail to an NCP gateway 217or a TCP gateway. 218.np 219Configuration should not be compiled into the code. 220A single binary should be able to run as is at any site 221(modulo such basic changes as the CPU type or the operating system). 222We have found this seemingly unimportant goal 223to be critical in real life. 224Besides the simple problems that occur when any program gets recompiled 225in a different environment, 226many sites like to 227.q fiddle 228with anything that they will be recompiling anyway. 229.np 230.i Sendmail 231must be able to let various groups maintain their own mailing lists, 232and let individuals specify their own forwarding, 233without writing the system alias file. 234.np 235Each user should be able to specify the mailer to execute 236to process mail being delivered for them. 237This allows users who are using specialized mailers 238that want to use a different format to build their environment 239without changing the system, 240and allows specialized functions 241(such as returning an 242.q "I am on vacation" 243message). 244.np 245Network traffic should be minimized 246by batching addresses to a single host where possible, 247without assistance by the user. 248.pp 249This resulted in an architecture illustrated in figure 1. 250.(z 251.hl 252.ie t \ 253. sp 18 254.el \{\ 255.(c 256+---------+ +---------+ +---------+ 257| sender1 | | sender2 | | sender3 | 258+---------+ +---------+ +---------+ 259 | | | 260 +----------+ + +----------+ 261 | | | 262 v v v 263 +-------------+ 264 | sendmail | 265 +-------------+ 266 | | | 267 +----------+ + +----------+ 268 | | | 269 v v v 270+---------+ +---------+ +---------+ 271| mailer1 | | mailer2 | | mailer3 | 272+---------+ +---------+ +---------+ 273.)c 274.\} 275 276.ce 277Figure 1 \*- Sendmail System Structure. 278.hl 279.)z 280The user interacts with a mail generating and sending program. 281When the mail is created, 282the generator calls 283.i sendmail , 284which routes the message to the correct mailer(s). 285Since some of the senders may be network servers 286and some of the mailers may be network clients, 287.i sendmail 288may be used as an internet mail gateway. 289.sh 1 "OVERVIEW" 290.sh 2 "System Organization" 291.pp 292.i Sendmail 293neither interfaces with the user 294nor does actual mail delivery. 295Rather, 296it collects a message 297generated by a user interface program (UIP) 298such as Berkeley 299.i Mail , 300MS 301[Crocker77b], 302or MH 303[Borden79], 304edits the message as required by the destination network, 305and calls appropriate mailers 306to do mail delivery or queueing for network transmission\**. 307.(f 308\**except when mailing to a file, 309when 310.i sendmail 311does the delivery directly. 312.)f 313This discipline allows the insertion of new mailers 314at minimum cost. 315In this sense 316.i sendmail 317resembles the Message Processing Module (MPM) 318of [Postel79b]. 319.sh 2 "Interfaces to the Outside World" 320.pp 321There are three ways 322.i sendmail 323can communicate with the outside world, 324both in receiving and in sending mail. 325These are using the conventional UNIX 326argument vector/return status, 327speaking SMTP over a pair of UNIX pipes, 328and speaking SMTP over an interprocess(or) channel. 329.sh 3 "Argument vector/exit status" 330.pp 331This technique is the standard UNIX method 332for communicating with the process. 333All recipients are sent in the argument vector, 334and the message is sent on the standard input. 335Anything that the mailer prints 336is simply collected and sent back to the user 337if there were any problems. 338The exit status from the mailer is collected 339after the message is sent, 340and a diagnostic is printed if appropriate. 341.sh 3 "SMTP over pipes" 342.pp 343The SMTP protocol 344[Postel82] 345can be used to run an interactive lock-step interface 346with the mailer. 347A subprocess is still created, 348but no recipients are passed to the mailer 349via the argument list. 350Instead, they are passed one at a time 351in commands sent to the processes standard input. 352Anything appearing on the standard output 353must be a reply code 354in a special format. 355.sh 3 "SMTP over an IPC connection" 356.pp 357This technique is almost like the previous technique, 358except that it uses a 4.2bsd IPC channel 359[ref?]. 360This method is exceptionally flexible 361in that the mailer need not reside 362on the same machine. 363This is normally used to connect to a sendmail process 364on another machine. 365.sh 2 "Operational Description" 366.pp 367When a client wants to send a message, 368it issues a request to 369.i sendmail 370using one of the three methods described above. 371.i Sendmail 372operates in two distinct phases. 373In the first phase, 374it collects and stores the message. 375In the second phase, 376message delivery occurs. 377If there were errors during processing, 378.i sendmail 379creates and returns a new message describing the error 380and/or returns an status code 381telling what went wrong. 382.sh 3 "Argument processing and address parsing" 383.pp 384If 385.i sendmail 386is called using one of the two subprocess techniques, 387the arguments 388are first scanned 389and flag arguments processed. 390Recipient addresses are then collected, 391either from the command line 392or from the SMTP 393RCPT command, 394and a list of recipients is created. 395Aliases are expanded at this step. 396As much validation as possible of the addresses 397is done at this step: 398syntax is checked, and local addresses are verified, 399but detailed checking of host names and addresses 400is deferred until delivery. 401Forwarding is also performed 402as the local addresses are verified. 403.pp 404.i Sendmail 405appends each address 406to the recipient list after parsing. 407When a name is aliased or forwarded, 408the old name is retained in the list, 409and a flag is set that tells the delivery phase 410to ignore this recipient. 411This list is kept without duplicates, 412preventing alias loops 413and eliminating people receiving two copies of a message, 414as might occur if a person were in two groups. 415.sh 3 "Message collection" 416.pp 417.i Sendmail 418then collects the message. 419The message should have a header at the beginning. 420No formatting requirements are imposed on the message 421except that they must be lines of text 422(i.e., binary data is not allowed). 423The header is parsed and stored in memory, 424and the body of the message is saved 425in a temporary file. 426.pp 427The message is still collected even if no addresses were valid 428to simplify program interface. 429The message will be returned with an error. 430.sh 3 "Message delivery" 431.pp 432For each unique mailer and host in the send list, 433.i sendmail 434calls the appropriate mailer. 435Each mailer invocation sends to all users receiving the message on one host. 436Mailers that only accept one user at a time 437are handled properly. 438.pp 439The message is sent to the mailer 440using one of the same three interfaces 441used to submit a message to sendmail. 442Each instantiation of the message is 443prepended by a customized header. 444The mailer status code is caught and checked, 445and a suitable error message given as appropriate. 446The exit code must conform to a system standard 447or a meaningless message 448(\c 449.q "Service unavailable" ) 450is given. 451.sh 3 "Queueing for retransmission" 452.pp 453If the mailer returned an status that 454indicated that it might be able to handle the mail later, 455.i sendmail 456will queue the mail and try again later. 457.sh 3 "Return to sender" 458.pp 459If errors occurred during processing, 460.i sendmail 461returns the message to the sender for retransmission. 462The letter can be mailed back 463or written in the file 464.q dead.letter 465in the sender's home directory\**. 466.(f 467\**Obviously, if the site giving the error is not the originating 468site, the only reasonable option is to mail back to the sender. 469Also, there are many more error disposition options, 470but they only effect the error message \*- the 471.q "return to sender" 472function is always handled in one of these two ways. 473.)f 474.sh 2 "Message Header Editing" 475.pp 476Certain editing of the message header 477occurs automatically. 478Header lines can be inserted 479under control of the configuration file. 480Some lines can be merged; 481for example, 482a 483.q From: 484line and a 485.q Full-name: 486line can be merged under certain circumstances. 487.sh 2 "Configuration File" 488.pp 489Almost all configuration information is read at runtime 490from an ASCII file, 491encoding 492macro definitions 493(defining the value of macros used internally), 494header declarations 495(telling sendmail the format of header lines that it will process specially, 496i.e., lines that it will add or reformat), 497mailer definitions 498(giving information such as the location and characteristics 499of each mailer), 500and address rewriting rules 501(a limited production system to rewrite addresses 502which is used to parse and rewrite the addresses). 503.sh 1 "USAGE AND IMPLEMENTATION" 504.sh 2 "Arguments" 505.pp 506Arguments may be flags and addresses. 507Flags set various processing options. 508Following flag arguments, 509address arguments may be given, 510unless we are running in SMTP mode. 511These follow the syntax in RFC822 512[Crocker82] 513for ARPANET 514address formats. 515In brief, the format is: 516.np 517Anything in parentheses is thrown away 518(as a comment). 519.np 520Anything in angle brackets (\c 521.q "<>" ) 522is preferred 523over anything else. 524This implements the ARPANET standard that addresses of the form 525.(b 526user name <machine-address> 527.)b 528will send to the electronic 529.q machine-address 530rather than the human 531.q "user name." 532.np 533Double quotes 534(\ "\ ) 535quote phrases; 536backslashes quote characters. 537Backslashes are more powerful 538in that they will cause otherwise equivalent phrases 539to compare differently \*- for example, 540.i user 541and 542.i 543"user" 544.r 545are equivalent, 546but 547.i \euser 548is different from either of them. 549.pp 550Parentheses, angle brackets, and double quotes 551must be properly balanced and nested. 552The rewriting rules control remaining parsing\**. 553.(f 554\**Disclaimer: some special processing is done 555after rewriting local names; see below. 556.)f 557.sh 2 "Mail to Files and Programs" 558.pp 559Files and programs are legitimate message recipients. 560Files provide archival storage of messages, 561useful for project administration and history. 562Programs are useful as recipients in a variety of situations, 563for example, 564as a public repository of systems messages 565(such as the Berkeley 566.i msgs 567program, 568or the MARS system 569[Sattley78]). 570.pp 571Any address passing through the initial parsing algorithm 572as a local address 573(i.e, not appearing to be a valid address for another mailer) 574is scanned for two special cases. 575If prefixed by a vertical bar (\c 576.q \^|\^ ) 577the rest of the address is processed as a shell command. 578If the user name begins with a slash mark (\c 579.q /\^ ) 580the name is used as a file name, 581instead of a login name. 582.pp 583Files that have setuid or setgid bits set 584but no execute bits set 585have those bits honored if 586.i sendmail 587is running as root. 588.sh 2 "Aliasing, Forwarding, Inclusion" 589.pp 590.i Sendmail 591reroutes mail three ways. 592Aliasing applies system wide. 593Forwarding allows each user to reroute incoming mail 594destined for that account. 595Inclusion directs 596.i sendmail 597to read a file for a list of addresses, 598and is normally used 599in conjunction with aliasing. 600.sh 3 "Aliasing" 601.pp 602Aliasing maps names to address lists using a system-wide file. 603This file is inverted to speed access. 604Only names that parse as local 605are allowed as aliases; 606this guarantees a unique key. 607.sh 3 "Forwarding" 608.pp 609After aliasing, 610users that are local and valid 611are checked for the existence of a 612.q .forward 613file in their home directory. 614If it exists, 615the message is 616.i not 617sent to that user, 618but rather to the list of users in that file. 619The expectation is that this will normally 620be one user only, 621and the use will be for network mail forwarding. 622.pp 623Forwarding also permits a user to specify a private incoming mailer. 624For example, 625forwarding to: 626.(b 627"\^|\|/usr/local/newmail myname" 628.)b 629will use a different incoming mailer. 630.sh 3 "Inclusion" 631.pp 632Inclusion is specified in RFC 733 [Crocker77a] syntax: 633.(b 634:Include: pathname 635.)b 636An address of this form reads the file specified by 637.i pathname 638and sends to all users listed in that file. 639.pp 640The intent is 641.i not 642to support direct use of this feature, 643but rather to use this as a subset of aliasing. 644For example, 645an alias of the form: 646.(b 647project: :include:/usr/project/userlist 648.)b 649is a method of letting a project maintain a mailing list 650without interaction with the system administration, 651even if the alias file is protected. 652.pp 653It is not necessary to rebuild the alias database 654when a :include: list is changed. 655.sh 2 "Message Collection" 656.pp 657Once all recipients are collected and verified, 658the message is collected. 659The message comes in two parts: 660a message header and a message body, 661separated by a blank line. 662.pp 663The header is formatted as a series of lines 664of the form 665.(b 666field-name: field-value 667.)b 668Field-value can be split across lines by starting the following 669lines with a space or a tab. 670A number of header fields have special internal meaning, 671and have appropriate special processing. 672Other headers are simply passed through. 673Some header fields may be added automatically, 674such as time stamps. 675.pp 676The body is a series of text lines. 677It is completely uninterpreted and untouched, 678except that lines beginning with a dot 679have the dot doubled 680when transmitted over an SMTP channel. 681This extra dot is stripped by the receiver. 682.sh 2 "Message Delivery" 683.pp 684The send queue is ordered by receiving host 685before transmission 686to implement message batching. 687Each address is marked as it is sent, 688so rescanning the list is safe; 689this makes sending to mailers that can only accept one user easy. 690An argument list is built as the scan proceeds. 691Mail to files is detected during the scan of the send list. 692The interface to the mailer 693is performed using one of the techniques 694described in section 2.2. 695.pp 696After the interface is created, 697.i sendmail 698makes the per-mailer changes to the header 699and sends the result to the mailer. 700If any mail is rejected by the mailer, 701a flag is set to invoke the return-to-sender function 702after all delivery completes. 703.sh 2 "Queued Messages" 704.pp 705If the mailer gave a 706.q "temporary failure" 707exit status, 708the message is queued. 709A control file is used to describe the recipients to be sent to 710and various other parameters. 711This control file is formatted as a series of lines, 712each describing a sender, 713a recipient, 714the time of submission, 715or some other salient parameter of the message. 716The header of the message is stored 717in the control file, 718so that the associated data file in the queue 719is just the temporary file that was originally collected. 720.sh 2 "Examples of Interactions With Other Mailers" 721.pp 722Two examples of how network-specific work is passed to other programs 723are the incoming UUCP mailer 724(\c 725.i rmail ) 726and the outgoing ARPANET mailer. 727.sh 3 "Incoming UUCP mail" 728.pp 729Mail coming in from the UUCP network 730is not guaranteed to have a normal header line, 731nor will an argument be passed telling who it is from\**. 732.(f 733\**As a result of this, 734it is impossible to verify UUCP sender addresses. 735.)f 736Fortuitously, 737UUCP mail calls the program 738.i rmail 739rather than 740.i mail 741or 742.i sendmail . 743The 744.i rmail 745program has been modified here to do the special-purpose parsing 746necessary to decode UUCP headers 747and turn them into a normal UUCP address; 748this address is then passed to 749.i sendmail . 750.sh 3 "Outgoing ARPANET mail" 751.pp 752The ARPANET imposes many standards that 753.i sendmail 754does not care to enforce. 755For example, 756an arpanet sitename must be on 757.i every 758address, 759not just the 760.q "From:" 761address. 762Certain UNIX sites like to use 763.q % 764as an alternative to 765.q @ , 766which must be translated. 767The outgoing ARPANET mailer makes these transformations 768before passing the message to the network. 769.sh 2 "Configuration" 770.pp 771Configuration is controlled primarily by a configuration file 772read at startup. 773.i Sendmail 774should not need to be recomplied except 775.np 776To change operating systems 777(V6, V7/32V, 4BSD). 778.np 779To remove or insert the DBM 780(UNIX database) 781library. 782.np 783To change ARPANET reply codes. 784.np 785To add headers requiring special processing. 786.lp 787Adding mailers or changing parsing 788(i.e., rewriting) 789or routing information 790does not require recompilation. 791.pp 792If the mail is being sent by a local user, 793and the file 794.q .mailcf 795exists in the sender's home directory, 796that file is read as a configuration file 797after the system configuration file. 798The primary use of this is to add header lines. 799.pp 800The configuration file encodes macro definitions, 801header definitions, 802mailer definitions, 803rewriting rules, 804and options. 805.sh 3 Macros 806.pp 807Macros can be used in three ways. 808Certain macros transmit 809unstructured textual information 810into the mail system, 811such as the name 812.i sendmail 813will use to identify itself in error messages. 814Other macros transmit information from 815.i sendmail 816to the configuration file 817for use in creating other fields 818(such as argument vectors to mailers); 819e.g., the name of the sender, 820and the host and user 821of the recipient. 822Other macros are unused internally, 823and can be used as shorthand in the configuration file. 824.sh 3 "Header declarations" 825.pp 826Header declarations inform 827.i sendmail 828of the format of known header lines. 829Knowledge of a few header lines 830is built into 831.i sendmail , 832such as the 833.q From: 834and 835.q Date: 836lines. 837.pp 838Most configured headers 839will be automatically inserted 840in the outgoing message 841if they don't exist in the incoming message. 842Certain headers are suppressed by some mailers. 843.sh 3 "Mailer declarations" 844.pp 845Mailer declarations tell 846.i sendmail 847of the various mailers available to it. 848The definition specifies the internal name of the mailer, 849the pathname of the program to call, 850some flags associated with the mailer, 851and an argument vector to be used on the call; 852this vector is macro expanded before use. 853.sh 3 "Address rewriting rules" 854.pp 855The heart of address parsing in 856.i sendmail 857is a set of rewriting rules. 858These are an ordered list of pattern-replacement rules, 859(somewhat like a production system, 860except that order is critical), 861which are applied to each address. 862The address is rewritten textually until it is either rewritten 863into a special canonical form 864(i.e., 865a (mailer, host, user) 8663-tuple, 867such as {arpanet, usc-isif, postel} 868representing the address 869.q "postel@usc-isif" ), 870or it falls off the end. 871When a pattern matches, 872the rule is reapplied until it fails. 873.pp 874The configuration file also supports the editing of addresses 875into different formats. 876For example, 877an address of the form: 878.(b 879ucsfcgl!tef 880.)b 881might be mapped into: 882.(b 883tef@ucsfcgl.UUCP 884.)b 885to conform to the domain syntax. 886Translations can also be done in the other direction. 887.sh 3 "Option setting" 888.pp 889There are a number of options that can be set 890from the configuration file. 891These include the pathnames of various support files, 892timeouts, 893default modes, 894etc. 895.sh 1 "COMPARISON WITH OTHER MAILERS" 896.sh 2 "Delivermail" 897.pp 898.i Sendmail 899is an outgrowth of 900.i delivermail . 901The primary differences are: 902.np 903Configuration information is not compiled in. 904This simplifies many of the problems 905of moving to other machines. 906It also allows easy debugging of new mailers. 907.np 908Address parsing is more flexible. 909For example, 910.i delivermail 911only supported one gateway to any network, 912whereas 913.i sendmail 914can be sensitive to host names 915and reroute to different gateways. 916.np 917Forwarding and 918:include: 919features eliminate the requirement that the system alias file 920be writable by any user 921(or that an update program be written, 922or that the system administration make all changes). 923.np 924.i Sendmail 925supports message batching across networks 926when a message is being sent to multiple recipients. 927.sh 2 "MMDF" 928.pp 929MMDF 930[Crocker79] 931spans a wider problem set than 932.i sendmail . 933For example, 934the domain of 935MMDF includes a 936.q "phone network" 937mailer, whereas 938.i sendmail 939calls on preexisting mailers in most cases. 940.pp 941MMDF and 942.i sendmail 943both support aliasing, 944customized mailers, 945message batching, 946automatic forwarding to gateways, 947queueing, 948and retransmission. 949MMDF supports two-stage timeout, 950which 951.i sendmail 952does not currently support. 953.pp 954The configuration for MMDF 955is completely compiled into the code\**. 956.(f 957\**Dynamic configuration tables are currently being considered 958for MMDF; 959this would allow the installer to select either compiled 960or dynamic tables. 961.)f 962.pp 963Since MMDF does not consider backwards compatibility 964as a design goal, 965the address parsing is much less flexible. 966.pp 967It is slightly harder to integrate a new channel\** 968.(f 969\**The MMDF equivalent of a 970.i sendmail 971.q mailer. 972.)f 973into MMDF. 974In particular, 975MMDF must know the location and format 976of host tables for all channels, 977and the channel must speak a special protocol. 978.pp 979MMDF strictly separates the submission and delivery phases. 980Although 981.i sendmail 982has the concept of each of these stages, 983they are integrated into one program, 984whereas in MMDF they are split into two programs. 985.sh 2 "Message Processing Module" 986.pp 987The Message Processing Module (MPM) 988discussed by Postel [Postel79b] 989matches 990.i sendmail 991closely in terms of its basic architecture. 992However, 993like MMDF, 994the MPM includes the network interface software 995as part of its domain. 996.pp 997MPM also postulates a duplex channel to the receiver, 998as does MMDF. 999This allows simpler handling of errors 1000by the mailer 1001than possible in 1002.i sendmail ; 1003when a message queued by 1004.i sendmail 1005is sent, 1006any errors must be returned to the sender 1007by the mailer itself. 1008Both MPM and MMDF mailers 1009can return an immediate error response, 1010and a single error processor can create an appropriate response. 1011.pp 1012MPM prefers passing the message as a structured message, 1013with type-length-value tuples. 1014This implies a much higher degree of cooperation 1015between mailers than required by 1016.i sendmail . 1017MPM also assumes a universally agreed upon internet name space 1018(with each address a net-host-user tuple), 1019which 1020.i sendmail 1021does not. 1022.sh 1 "EVALUATIONS AND FUTURE PLANS" 1023.pp 1024.i Sendmail 1025is designed to work in a nonhomogeneous environment. 1026Every attempt is made to avoid imposing any constraints 1027on the underlying mailers. 1028This goal has driven much of the design. 1029One of the major problems 1030has been the lack of a uniform address space, 1031as postulated in [Postel79a] 1032and [Postel79b]. 1033.pp 1034A nonuniform address space implies that path will be specified 1035in all addresses, 1036either explicitly (as part of the address) 1037or implicitly 1038(as with implied forwarding to gateways). 1039This has the unpleasant effect of making replying to messages 1040exceedingly difficult, 1041since there is no one 1042.q address 1043for any person, 1044but only a way to get there from wherever you are. 1045.pp 1046Interfacing to mail programs 1047that were not initially intended to be applied 1048in an internet environment 1049has been amazingly successful, 1050and has reduced the job to a manageable task. 1051.pp 1052.i Sendmail 1053has knowledge of a few difficult environments 1054built in. 1055It generates ARPANET FTP/SMTP compatible error messages 1056(prepended with three-digit numbers 1057[Neigus73, Postel74, Postel82]) 1058as necessary, 1059optionally generates UNIX-style 1060.q From 1061lines on the front of messages for some mailers, 1062and knows how to parse the same lines on input. 1063This can be inconvenient to sites which have abandoned UNIX mail, 1064although 1065.i sendmail 1066still adds and understands ARPANET-style 1067.q From: 1068lines. 1069Also, 1070error handling has an option customized for BerkNet. 1071.pp 1072The decision to avoid doing any type of delivery where possible 1073(even, or perhaps especially, local delivery) 1074has turned out to be a good idea. 1075Even with local delivery, 1076there are issues of the location of the mailbox, 1077the format of the mailbox, 1078the locking protocol used, 1079etc., 1080that are best decided by other programs. 1081One surprisingly major annoyance in many internet mailers 1082is that the location and format of local mail is built in. 1083The feeling seems to be that local mail is so common 1084that it should be efficient. 1085This does not match our experience; 1086on the contrary, 1087the location and format of mailboxes seems to vary widely 1088from system to system. 1089.pp 1090The ability to automatically generate a response to incoming mail 1091(by forwarding mail to a program) 1092seems useful 1093(\c 1094.q "I am on vacation until late August...." ) 1095but can create problems 1096such as forwarding loops 1097(two people on vacation whose programs send notes back and forth, 1098for instance) 1099if these programs are not well written. 1100A program should be written to do standard tasks correctly, 1101but this does not solve the general case. 1102It might be desirable to implement some form of load limiting. 1103I am unaware of any mail system that addresses this problem, 1104nor am I aware of any reasonable solution at this time. 1105.pp 1106The configuration file is currently practically inscrutable; 1107considerable convenience could be realized 1108with a higher-level format. 1109.pp 1110It seems clear that common protocols will be changing soon 1111to accommodate changing requirements and environments. 1112These changes will include modifications to the message header 1113(e.g., [NBS80]) 1114or to the body of the message itself 1115(such as for multimedia messages 1116[Postel80]). 1117Experience indicates that 1118these changes should be relatively trivial to integrate 1119into the existing system. 1120.pp 1121In tightly coupled environments, 1122it would be nice to have a name server integrated into the mail system. 1123This would allow a site such as 1124.q Berkeley 1125to appear as a single host, 1126rather than as a collection of hosts, 1127and would allow people to move transparently among machines 1128without having to change their addresses. 1129This would require an automatically updated database 1130and some method of resolving conflicts. 1131Ideally this would be effective even with multiple managements. 1132However, 1133it is not clear whether this should be integrated into the 1134aliasing feature 1135or should be considered a 1136.q "value added" 1137feature outside 1138.i sendmail 1139itself. 1140.sh 0 "ACKNOWLEDGEMENTS" 1141.pp 1142Thanks are due to Kurt Shoens for his continual cheerful 1143assistance and good advice, 1144Bill Joy for pointing me in the correct direction 1145(over and over), 1146and Mark Horton for more advice, 1147prodding, 1148and many of the good ideas. 1149Kurt and Eric Schmidt are to be credited 1150for using 1151.i delivermail 1152as a server for their programs 1153(\c 1154.i Mail 1155and BerkNet respectively) 1156before any sane person should have, 1157and making the necessary modifications 1158promptly and happily. 1159Eric gave me considerable advice about the perils 1160of network software which saved me an unknown 1161amount of work and grief. 1162Mark did the original implementation of the DBM version 1163of aliasing, installed the VFORK code, 1164wrote the current version of 1165.i rmail , 1166and was the person who really convinced me 1167to put the work into 1168.i delivermail 1169to turn it into 1170.i sendmail . 1171Kurt deserves accolades for using 1172.i sendmail 1173when I was myself afraid to take the risk; 1174how a person can continue to be so enthusiastic 1175in the face of so much bitter reality is beyond me. 1176.pp 1177Kurt and Kirk McKusick 1178read early copies of this paper, 1179giving considerable useful advice. 1180.pp 1181Special thanks are reserved for Mike Stonebraker at Berkeley 1182and Bob Epstein at Britton-Lee, 1183who both knowingly allowed me to put so much work into this 1184when there were so many other things I really should 1185have been working on. 1186.+c 1187.ce 1188REFERENCES 1189.nr ii 1.5i 1190.ip [Borden79] 1191Borden, S., 1192Gaines, R. S., 1193and 1194Shapiro, N. Z., 1195.ul 1196The MH Message Handling System: Users' Manual. 1197R-2367-PAF. 1198Rand Corporation. 1199October 1979. 1200.ip [Crocker77a] 1201Crocker, D. H., 1202Vittal, J. J., 1203Pogran, K. T., 1204and 1205Henderson, D. A. Jr., 1206.ul 1207Standard for the Format of ARPA Network Text Messages. 1208RFC 733, 1209NIC 41952. 1210In [Feinler78]. 1211November 1977. 1212.ip [Crocker77b] 1213Crocker, D. H., 1214.ul 1215Framework and Functions of the MS Personal Message System. 1216R-2134-ARPA, 1217Rand Corporation, 1218Santa Monica, California. 12191977. 1220.ip [Crocker79] 1221Crocker, D. H., 1222Szurkowski, E. S., 1223and 1224Farber, D. J., 1225.ul 1226An Internetwork Memo Distribution Facility \*- MMDF. 12276th Data Communication Symposium, 1228Asilomar. 1229November 1979. 1230.ip [Crocker82] 1231Crocker, D. H., 1232.ul 1233Standard for the Format of Arpa Internet Text Messages. 1234RFC 822. 1235Network Information Center, 1236SRI International, 1237Menlo Park, California. 1238August 1982. 1239.ip [Metcalfe76] 1240Metcalfe, R., 1241and 1242Boggs, D., 1243.q "Ethernet: Distributed Packet Switching for Local Computer Networks" , 1244.ul 1245Communications of the ACM 19, 12467. 1247July 1976. 1248.ip [Feinler78] 1249Feinler, E., 1250and 1251Postel, J. 1252(eds.), 1253.ul 1254ARPANET Protocol Handbook. 1255NIC 7104, 1256Network Information Center, 1257SRI International, 1258Menlo Park, California. 12591978. 1260.ip [NBS80] 1261National Bureau of Standards, 1262.ul 1263Specification of a Draft Message Format Standard. 1264Report No. ICST/CBOS 80-2. 1265October 1980. 1266.ip [Neigus73] 1267Neigus, N., 1268.ul 1269File Transfer Protocol for the ARPA Network. 1270RFC 542, NIC 17759. 1271In [Feinler78]. 1272August, 1973. 1273.ip [Nowitz78a] 1274Nowitz, D. A., 1275and 1276Lesk, M. E., 1277.ul 1278A Dial-Up Network of UNIX Systems. 1279Bell Laboratories. 1280In 1281UNIX Programmer's Manual, Seventh Edition, 1282Volume 2. 1283August, 1978. 1284.ip [Nowitz78b] 1285Nowitz, D. A., 1286.ul 1287Uucp Implementation Description. 1288Bell Laboratories. 1289In 1290UNIX Programmer's Manual, Seventh Edition, 1291Volume 2. 1292October, 1978. 1293.ip [Postel74] 1294Postel, J., 1295and 1296Neigus, N., 1297Revised FTP Reply Codes. 1298RFC 640, NIC 30843. 1299In [Feinler78]. 1300June, 1974. 1301.ip [Postel77] 1302Postel, J., 1303.ul 1304Mail Protocol. 1305NIC 29588. 1306In [Feinler78]. 1307November 1977. 1308.ip [Postel79a] 1309Postel, J., 1310.ul 1311Internet Message Protocol. 1312RFC 753, 1313IEN 85. 1314Network Information Center, 1315SRI International, 1316Menlo Park, California. 1317March 1979. 1318.ip [Postel79b] 1319Postel, J. B., 1320.ul 1321An Internetwork Message Structure. 1322In 1323.ul 1324Proceedings of the Sixth Data Communications Symposium, 1325IEEE. 1326New York. 1327November 1979. 1328.ip [Postel80] 1329Postel, J. B., 1330.ul 1331A Structured Format for Transmission of Multi-Media Documents. 1332RFC 767. 1333Network Information Center, 1334SRI International, 1335Menlo Park, California. 1336August 1980. 1337.ip [Postel82] 1338Postel, J. B., 1339.ul 1340Simple Mail Transfer Protocol. 1341RFC821 1342(obsoleting RFC788). 1343Network Information Center, 1344SRI International, 1345Menlo Park, California. 1346August 1982. 1347.ip [Schmidt79] 1348Schmidt, E., 1349.ul 1350An Introduction to the Berkeley Network. 1351University of California, Berkeley California. 13521979. 1353.ip [Shoens79] 1354Shoens, K., 1355.ul 1356Mail Reference Manual. 1357University of California, Berkeley. 1358In UNIX Programmer's Manual, 1359Seventh Edition, 1360Volume 2C. 1361December 1979. 1362.ip [Sluizer81] 1363Sluizer, S., 1364and 1365Postel, J. B., 1366.ul 1367Mail Transfer Protocol. 1368RFC 780. 1369Network Information Center, 1370SRI International, 1371Menlo Park, California. 1372May 1981. 1373.ip [Su82] 1374Su, Zaw-Sing, 1375and 1376Postel, Jon, 1377.ul 1378The Domain Naming Convention for Internet User Applications. 1379RFC819. 1380Network Information Center, 1381SRI International, 1382Menlo Park, California. 1383August 1982. 1384.ip [UNIX80] 1385.ul 1386The UNIX Programmer's Manual, Seventh Edition, 1387Virtual VAX-11 Version, 1388Volume 1. 1389Bell Laboratories, 1390modified by the University of California, 1391Berkeley California. 1392November 1980. 1393