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