![[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.