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