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