![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to usenix.me CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSD / usr.lib / sendmail / doc|
Return to usenix.me CVS log | Up to [CSRG BSD Unix] / 43BSD / usr.lib / sendmail / doc |
1.1 root 1: .nr si 3n
2: .he 'Mail Systems and Addressing in 4.2bsd''%'
3: .fo 'Version 4.1'USENIX \- Jan 83'Last Mod 7/25/83'
4: .if n .ls 2
5: .+c
6: .(l C
7: .sz 14
8: Mail Systems and Addressing
9: in 4.2bsd
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: .sp 0.5
19: .r
20: [email protected]
21: ucbvax!eric
22: .)l
23: .sp
24: .(l F
25: .ce
26: ABSTRACT
27: .sp \n(psu
28: Routing mail through a heterogeneous internet presents many new
29: problems.
30: Among the worst of these is that of address mapping.
31: Historically, this has been handled on an ad hoc basis.
32: However,
33: this approach has become unmanageable as internets grow.
34: .sp \n(psu
35: Sendmail acts a unified
36: .q "post office"
37: to which all mail can be
38: submitted.
39: Address interpretation is controlled by a production
40: system,
41: which can parse both old and new format addresses.
42: The
43: new format is
44: .q "domain-based,"
45: a flexible technique that can
46: handle many common situations.
47: Sendmail is not intended to perform
48: user interface functions.
49: .sp \n(psu
50: Sendmail will replace delivermail in the Berkeley 4.2 distribution.
51: Several major hosts are now or will soon be running sendmail.
52: This change will affect any users that route mail through a sendmail
53: gateway.
54: The changes that will be user visible are emphasized.
55: .)l
56: .sp 2
57: .(f
58: \(dgA considerable part of this work
59: was done while under the employ
60: of the INGRES Project
61: at the University of California at Berkeley.
62: .)f
63: .pp
64: The mail system to appear in 4.2bsd
65: will contain a number of changes.
66: Most of these changes are based on the replacement of
67: .i delivermail
68: with a new module called
69: .i sendmail.
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: Of key interest to the mail system user
76: will be the changes in the network addressing structure.
77: .pp
78: In a simple network,
79: each node has an address,
80: and resources can be identified
81: with a host-resource pair;
82: in particular,
83: the mail system can refer to users
84: using a host-username pair.
85: Host names and numbers have to be administered by a central authority,
86: but usernames can be assigned locally to each host.
87: .pp
88: In an internet,
89: multiple networks with different characteristics
90: and managements
91: must communicate.
92: In particular,
93: the syntax and semantics of resource identification change.
94: Certain special cases can be handled trivially
95: by
96: .i "ad hoc"
97: techniques,
98: such as
99: providing network names that appear local to hosts
100: on other networks,
101: as with the Ethernet at Xerox PARC.
102: However, the general case is extremely complex.
103: For example,
104: some networks require that the route the message takes
105: be explicitly specified by the sender,
106: simplifying the database update problem
107: since only adjacent hosts must be entered
108: into the system tables,
109: while others use logical addressing,
110: where the sender specifies the location of the recipient
111: but not how to get there.
112: Some networks use a left-associative syntax
113: and others use a right-associative syntax,
114: causing ambiguity in mixed addresses.
115: .pp
116: Internet standards seek to eliminate these problems.
117: Initially, these proposed expanding the address pairs
118: to address triples,
119: consisting of
120: {network, host, username}
121: triples.
122: Network numbers must be universally agreed upon,
123: and hosts can be assigned locally
124: on each network.
125: The user-level presentation was changed
126: to address domains,
127: comprised of a local resource identification
128: and a hierarchical domain specification
129: with a common static root.
130: The domain technique
131: separates the issue of physical versus logical addressing.
132: For example,
133: an address of the form
134: .q "[email protected]"
135: describes the logical
136: organization of the address space
137: (user
138: .q eric
139: on host
140: .q a
141: in the Computer Center
142: at Berkeley)
143: but not the physical networks used
144: (for example, this could go over different networks
145: depending on whether
146: .q a
147: were on an ethernet
148: or a store-and-forward network).
149: .pp
150: .i Sendmail
151: is intended to help bridge the gap
152: between the totally
153: .i "ad hoc"
154: world
155: of networks that know nothing of each other
156: and the clean, tightly-coupled world
157: of unique network numbers.
158: It can accept old arbitrary address syntaxes,
159: resolving ambiguities using heuristics
160: specified by the system administrator,
161: as well as domain-based addressing.
162: It helps guide the conversion of message formats
163: between disparate networks.
164: In short,
165: .i sendmail
166: is designed to assist a graceful transition
167: to consistent internetwork addressing schemes.
168: .sp
169: .pp
170: Section 1 defines some of the terms
171: frequently left fuzzy
172: when working in mail systems.
173: Section 2 discusses the design goals for
174: .i sendmail .
175: In section 3,
176: the new address formats
177: and basic features of
178: .i sendmail
179: are described.
180: Section 4 discusses some of the special problems
181: of the UUCP network.
182: The differences between
183: .i sendmail
184: and
185: .i delivermail
186: are presented in section 5.
187: .sp
188: .(l F
189: .b DISCLAIMER:
190: A number of examples
191: in this paper
192: use names of actual people
193: and organizations.
194: This is not intended
195: to imply a commitment
196: or even an intellectual agreement
197: on the part of these people or organizations.
198: In particular,
199: Bell Telephone Laboratories (BTL),
200: Digital Equipment Corporation (DEC),
201: Lawrence Berkeley Laboratories (LBL),
202: Britton-Lee Incorporated (BLI),
203: and the University of California at Berkeley
204: are not committed to any of these proposals at this time.
205: Much of this paper
206: represents no more than
207: the personal opinions of the author.
208: .)l
209: .sh 1 "DEFINITIONS"
210: .pp
211: There are four basic concepts
212: that must be clearly distinguished
213: when dealing with mail systems:
214: the user (or the user's agent),
215: the user's identification,
216: the user's address,
217: and the route.
218: These are distinguished primarily by their position independence.
219: .sh 2 "User and Identification"
220: .pp
221: The user is the being
222: (a person or program)
223: that is creating or receiving a message.
224: An
225: .i agent
226: is an entity operating on behalf of the user \*-
227: such as a secretary who handles my mail.
228: or a program that automatically returns a
229: message such as
230: .q "I am at the UNICOM conference."
231: .pp
232: The identification is the tag
233: that goes along with the particular user.
234: This tag is completely independent of location.
235: For example,
236: my identification is the string
237: .q "Eric Allman,"
238: and this identification does not change
239: whether I am located at U.C. Berkeley,
240: at Britton-Lee,
241: or at a scientific institute in Austria.
242: .pp
243: Since the identification is frequently ambiguous
244: (e.g., there are two
245: .q "Robert Henry" s
246: at Berkeley)
247: it is common to add other disambiguating information
248: that is not strictly part of the identification
249: (e.g.,
250: Robert
251: .q "Code Generator"
252: Henry
253: versus
254: Robert
255: .q "System Administrator"
256: Henry).
257: .sh 2 "Address"
258: .pp
259: The address specifies a location.
260: As I move around,
261: my address changes.
262: For example,
263: my address might change from
264: .q [email protected]
265: to
266: .q [email protected]
267: or
268: .q [email protected]
269: depending on my current affiliation.
270: .pp
271: However,
272: an address is independent of the location of anyone else.
273: That is,
274: my address remains the same to everyone who might be sending me mail.
275: For example,
276: a person at MIT and a person at USC
277: could both send to
278: .q [email protected]
279: and have it arrive to the same mailbox.
280: .pp
281: Ideally a
282: .q "white pages"
283: service would be provided to map user identifications
284: into addresses
285: (for example, see
286: [Solomon81]).
287: Currently this is handled by passing around
288: scraps of paper
289: or by calling people on the telephone
290: to find out their address.
291: .sh 2 "Route"
292: .pp
293: While an address specifies
294: .i where
295: to find a mailbox,
296: a route specifies
297: .i how
298: to find the mailbox.
299: Specifically,
300: it specifies a path
301: from sender to receiver.
302: As such, the route is potentially different
303: for every pair of people in the electronic universe.
304: .pp
305: Normally the route is hidden from the user
306: by the software.
307: However,
308: some networks put the burden of determining the route
309: onto the sender.
310: Although this simplifies the software,
311: it also greatly impairs the usability
312: for most users.
313: The UUCP network is an example of such a network.
314: .sh 1 "DESIGN GOALS"
315: .pp
316: Design goals for
317: .i sendmail \**
318: .(f
319: \**This section makes no distinction between
320: .i delivermail
321: and
322: .i sendmail.
323: .)f
324: include:
325: .np
326: Compatibility with the existing mail programs,
327: including Bell version 6 mail,
328: Bell version 7 mail,
329: Berkeley
330: .i Mail
331: [Shoens79],
332: BerkNet mail
333: [Schmidt79],
334: and hopefully UUCP mail
335: [Nowitz78].
336: ARPANET mail
337: [Crocker82]
338: was also required.
339: .np
340: Reliability, in the sense of guaranteeing
341: that every message is correctly delivered
342: or at least brought to the attention of a human
343: for correct disposal;
344: no message should ever be completely lost.
345: This goal was considered essential
346: because of the emphasis on mail in our environment.
347: It has turned out to be one of the hardest goals to satisfy,
348: especially in the face of the many anomalous message formats
349: produced by various ARPANET sites.
350: For example,
351: certain sites generate improperly formated addresses,
352: occasionally
353: causing error-message loops.
354: Some hosts use blanks in names,
355: causing problems with
356: mail programs that assume that an address
357: is one word.
358: The semantics of some fields
359: are interpreted slightly differently
360: by different sites.
361: In summary,
362: the obscure features of the ARPANET mail protocol
363: really
364: .i are
365: used and
366: are difficult to support,
367: but must be supported.
368: .np
369: Existing software to do actual delivery
370: should be used whenever possible.
371: This goal derives as much from political and practical considerations
372: as technical.
373: .np
374: Easy expansion to
375: fairly complex environments,
376: including multiple
377: connections to a single network type
378: (such as with multiple UUCP or Ethernets).
379: This goal requires consideration of the contents of an address
380: as well as its syntax
381: in order to determine which gateway to use.
382: .np
383: Configuration information should not be compiled into the code.
384: A single compiled program should be able to run as is at any site
385: (barring such basic changes as the CPU type or the operating system).
386: We have found this seemingly unimportant goal
387: to be critical in real life.
388: Besides the simple problems that occur when any program gets recompiled
389: in a different environment,
390: many sites like to
391: .q fiddle
392: with anything that they will be recompiling anyway.
393: .np
394: .i Sendmail
395: must be able to let various groups maintain their own mailing lists,
396: and let individuals specify their own forwarding,
397: without modifying the system alias file.
398: .np
399: Each user should be able to specify which mailer to execute
400: to process mail being delivered for him.
401: This feature allows users who are using specialized mailers
402: that use a different format to build their environment
403: without changing the system,
404: and facilitates specialized functions
405: (such as returning an
406: .q "I am on vacation"
407: message).
408: .np
409: Network traffic should be minimized
410: by batching addresses to a single host where possible,
411: without assistance from the user.
412: .pp
413: These goals motivated the architecture illustrated in figure 1.
414: .(z
415: .hl
416: .ie t \
417: . sp 18
418: .el \{\
419: .(c
420: +---------+ +---------+ +---------+
421: | sender1 | | sender2 | | sender3 |
422: +---------+ +---------+ +---------+
423: | | |
424: +----------+ + +----------+
425: | | |
426: v v v
427: +-------------+
428: | sendmail |
429: +-------------+
430: | | |
431: +----------+ + +----------+
432: | | |
433: v v v
434: +---------+ +---------+ +---------+
435: | mailer1 | | mailer2 | | mailer3 |
436: +---------+ +---------+ +---------+
437: .)c
438: .\}
439:
440: .ce
441: Figure 1 \*- Sendmail System Structure.
442: .hl
443: .)z
444: The user interacts with a mail generating and sending program.
445: When the mail is created,
446: the generator calls
447: .i sendmail ,
448: which routes the message to the correct mailer(s).
449: Since some of the senders may be network servers
450: and some of the mailers may be network clients,
451: .i sendmail
452: may be used as an internet mail gateway.
453: .sh 1 "USAGE"
454: .sh 2 "Address Formats"
455: .pp
456: Arguments may be flags or addresses.
457: Flags set various processing options.
458: Following flag arguments,
459: address arguments may be given.
460: Addresses follow the syntax in RFC822
461: [Crocker82]
462: for ARPANET
463: address formats.
464: In brief, the format is:
465: .np
466: Anything in parentheses is thrown away
467: (as a comment).
468: .np
469: Anything in angle brackets (\c
470: .q "<\|>" )
471: is preferred
472: over anything else.
473: This rule implements the ARPANET standard that addresses of the form
474: .(b
475: user name <machine-address>
476: .)b
477: will send to the electronic
478: .q machine-address
479: rather than the human
480: .q "user name."
481: .np
482: Double quotes
483: (\ "\ )
484: quote phrases;
485: backslashes quote characters.
486: Backslashes are more powerful
487: in that they will cause otherwise equivalent phrases
488: to compare differently \*- for example,
489: .i user
490: and
491: .i
492: "user"
493: .r
494: are equivalent,
495: but
496: .i \euser
497: is different from either of them.
498: This might be used
499: to avoid normal aliasing
500: or duplicate suppression algorithms.
501: .pp
502: Parentheses, angle brackets, and double quotes
503: must be properly balanced and nested.
504: The rewriting rules control remaining parsing\**.
505: .(f
506: \**Disclaimer: Some special processing is done
507: after rewriting local names; see below.
508: .)f
509: .pp
510: Although old style addresses are still accepted
511: in most cases,
512: the preferred address format
513: is based on ARPANET-style domain-based addresses
514: [Su82a].
515: These addresses are based on a hierarchical, logical decomposition
516: of the address space.
517: The addresses are hierarchical in a sense
518: similar to the U.S. postal addresses:
519: the messages may first be routed to the correct state,
520: with no initial consideration of the city
521: or other addressing details.
522: The addresses are logical
523: in that each step in the hierarchy
524: corresponds to a set of
525: .q "naming authorities"
526: rather than a physical network.
527: .pp
528: For example,
529: the address:
530: .(l
531: [email protected]
532: .)l
533: would first look up the domain
534: BigSite
535: in the namespace administrated by
536: ARPA.
537: A query could then be sent to
538: BigSite
539: for interpretation of
540: HostA.
541: Eventually the mail would arrive at
542: HostA,
543: which would then do final delivery
544: to user
545: .q eric.
546: .sh 2 "Mail to Files and Programs"
547: .pp
548: Files and programs are legitimate message recipients.
549: Files provide archival storage of messages,
550: useful for project administration and history.
551: Programs are useful as recipients in a variety of situations,
552: for example,
553: to maintain a public repository of systems messages
554: (such as the Berkeley
555: .i msgs
556: program).
557: .pp
558: Any address passing through the initial parsing algorithm
559: as a local address
560: (i.e, not appearing to be a valid address for another mailer)
561: is scanned for two special cases.
562: If prefixed by a vertical bar (\c
563: .q \^|\^ )
564: the rest of the address is processed as a shell command.
565: If the user name begins with a slash mark (\c
566: .q /\^ )
567: the name is used as a file name,
568: instead of a login name.
569: .sh 2 "Aliasing, Forwarding, Inclusion"
570: .pp
571: .i Sendmail
572: reroutes mail three ways.
573: Aliasing applies system wide.
574: Forwarding allows each user to reroute incoming mail
575: destined for that account.
576: Inclusion directs
577: .i sendmail
578: to read a file for a list of addresses,
579: and is normally used
580: in conjunction with aliasing.
581: .sh 3 "Aliasing"
582: .pp
583: Aliasing maps local addresses to address lists using a system-wide file.
584: This file is hashed to speed access.
585: Only addresses that parse as local
586: are allowed as aliases;
587: this guarantees a unique key
588: (since there are no nicknames for the local host).
589: .sh 3 "Forwarding"
590: .pp
591: After aliasing,
592: if an recipient address specifies a local user
593: .i sendmail
594: searches for a
595: .q .forward
596: file in the recipient's home directory.
597: If it exists,
598: the message is
599: .i not
600: sent to that user,
601: but rather to the list of addresses in that file.
602: Often
603: this list will contain only one address,
604: and the feature will be used for network mail forwarding.
605: .pp
606: Forwarding also permits a user to specify a private incoming mailer.
607: For example,
608: forwarding to:
609: .(b
610: "\^|\|/usr/local/newmail myname"
611: .)b
612: will use a different incoming mailer.
613: .sh 3 "Inclusion"
614: .pp
615: Inclusion is specified in RFC 733 [Crocker77] syntax:
616: .(b
617: :Include: pathname
618: .)b
619: An address of this form reads the file specified by
620: .i pathname
621: and sends to all users listed in that file.
622: .pp
623: The intent is
624: .i not
625: to support direct use of this feature,
626: but rather to use this as a subset of aliasing.
627: For example,
628: an alias of the form:
629: .(b
630: project: :include:/usr/project/userlist
631: .)b
632: is a method of letting a project maintain a mailing list
633: without interaction with the system administration,
634: even if the alias file is protected.
635: .pp
636: It is not necessary to rebuild the index on the alias database
637: when a :include: list is changed.
638: .sh 2 "Message Collection"
639: .pp
640: Once all recipient addresses are parsed and verified,
641: the message is collected.
642: The message comes in two parts:
643: a message header and a message body,
644: separated by a blank line.
645: The body is an uninterpreted
646: sequence of text lines.
647: .pp
648: The header is formated as a series of lines
649: of the form
650: .(b
651: field-name: field-value
652: .)b
653: Field-value can be split across lines by starting the following
654: lines with a space or a tab.
655: Some header fields have special internal meaning,
656: and have appropriate special processing.
657: Other headers are simply passed through.
658: Some header fields may be added automatically,
659: such as time stamps.
660: .sh 1 "THE UUCP PROBLEM"
661: .pp
662: Of particular interest
663: is the UUCP network.
664: The explicit routing
665: used in the UUCP environment
666: causes a number of serious problems.
667: First,
668: giving out an address
669: is impossible
670: without knowing the address of your potential correspondent.
671: This is typically handled
672: by specifying the address
673: relative to some
674: .q "well-known"
675: host
676: (e.g.,
677: ucbvax or decvax).
678: Second,
679: it is often difficult to compute
680: the set of addresses
681: to reply to
682: without some knowledge
683: of the topology of the network.
684: Although it may be easy for a human being
685: to do this
686: under many circumstances,
687: a program does not have equally sophisticated heuristics
688: built in.
689: Third,
690: certain addresses will become painfully and unnecessarily long,
691: as when a message is routed through many hosts in the USENET.
692: And finally,
693: certain
694: .q "mixed domain"
695: addresses
696: are impossible to parse unambiguously \*-
697: e.g.,
698: .(l
699: decvax!ucbvax!lbl-h!user@LBL-CSAM
700: .)l
701: might have many possible resolutions,
702: depending on whether the message was first routed
703: to decvax
704: or to LBL-CSAM.
705: .pp
706: To solve this problem,
707: the UUCP syntax
708: would have to be changed to use addresses
709: rather than routes.
710: For example,
711: the address
712: .q decvax!ucbvax!eric
713: might be expressed as
714: .q [email protected]
715: (with the hop through decvax implied).
716: This address would itself be a domain-based address;
717: for example,
718: an address might be of the form:
719: .(l
720: [email protected]
721: .)l
722: Hosts outside of Bell Telephone Laboratories
723: would then only need to know
724: how to get to a designated BTL relay,
725: and the BTL topology
726: would only be maintained inside Bell.
727: .pp
728: There are three major problems
729: associated with turning UUCP addresses
730: into something reasonable:
731: defining the namespace,
732: creating and propagating the necessary software,
733: and building and maintaining the database.
734: .sh 2 "Defining the Namespace"
735: .pp
736: Putting all UUCP hosts into a flat namespace
737: (e.g.,
738: .q \&[email protected] )
739: is not practical for a number of reasons.
740: First,
741: with over 1600 sites already,
742: and (with the increasing availability of inexpensive microcomputers
743: and autodialers)
744: several thousand more coming within a few years,
745: the database update problem
746: is simply intractable
747: if the namespace is flat.
748: Second,
749: there are almost certainly name conflicts today.
750: Third,
751: as the number of sites grow
752: the names become ever less mnemonic.
753: .pp
754: It seems inevitable
755: that there be some sort of naming authority
756: for the set of top level names
757: in the UUCP domain,
758: as unpleasant a possibility
759: as that may seem.
760: It will simply not be possible
761: to have one host resolving all names.
762: It may however be possible
763: to handle this
764: in a fashion similar to that of assigning names of newsgroups
765: in USENET.
766: However,
767: it will be essential to encourage everyone
768: to become subdomains of an existing domain
769: whenever possible \*-
770: even though this will certainly bruise some egos.
771: For example,
772: if a new host named
773: .q blid
774: were to be added to the UUCP network,
775: it would probably actually be addressed as
776: .q d.bli.UUCP
777: (i.e.,
778: as host
779: .q d
780: in the pseudo-domain
781: .q bli
782: rather than as host
783: .q blid
784: in the UUCP domain).
785: .sh 2 "Creating and Propagating the Software"
786: .pp
787: The software required to implement a consistent namespace
788: is relatively trivial.
789: Two modules are needed,
790: one to handle incoming mail
791: and one to handle outgoing mail.
792: .pp
793: The incoming module
794: must be prepared to handle either old or new style addresses.
795: New-style addresses
796: can be passed through unchanged.
797: Old style addresses
798: must be turned into new style addresses
799: where possible.
800: .pp
801: The outgoing module
802: is slightly trickier.
803: It must do a database lookup on the recipient addresses
804: (passed on the command line)
805: to determine what hosts to send the message to.
806: If those hosts do not accept new-style addresses,
807: it must transform all addresses in the header of the message
808: into old style using the database lookup.
809: .pp
810: Both of these modules
811: are straightforward
812: except for the issue of modifying the header.
813: It seems prudent to choose one format
814: for the message headers.
815: For a number of reasons,
816: Berkeley has elected to use the ARPANET protocols
817: for message formats.
818: However,
819: this protocol is somewhat difficult to parse.
820: .pp
821: Propagation is somewhat more difficult.
822: There are a large number of hosts
823: connected to UUCP
824: that will want to run completely standard systems
825: (for very good reasons).
826: The strategy is not to convert the entire network \*-
827: only enough of it it alleviate the problem.
828: .sh 2 "Building and Maintaining the Database"
829: .pp
830: This is by far the most difficult problem.
831: A prototype for this database
832: already exists,
833: but it is maintained by hand
834: and does not pretend to be complete.
835: .pp
836: This problem will be reduced considerably
837: if people choose to group their hosts
838: into subdomains.
839: This would require a global update
840: only when a new top level domain
841: joined the network.
842: A message to a host in a subdomain
843: could simply be routed to a known domain gateway
844: for further processing.
845: For example,
846: the address
847: .q [email protected]
848: might be routed to the
849: .q bli
850: gateway
851: for redistribution;
852: new hosts could be added
853: within BLI
854: without notifying the rest of the world.
855: Of course,
856: other hosts
857: .i could
858: be notified as an efficiency measure.
859: .pp
860: There may be more than one domain gateway.
861: A domain such as BTL,
862: for instance,
863: might have a dozen gateways to the outside world;
864: a non-BTL site
865: could choose the closest gateway.
866: The only restriction
867: would be that all gateways
868: maintain a consistent view of the domain
869: they represent.
870: .sh 2 "Logical Structure"
871: .pp
872: Logically,
873: domains are organized into a tree.
874: There need not be a host actually associated
875: with each level in the tree \*-
876: for example,
877: there will be no host associated with the name
878: .q UUCP.
879: Similarly,
880: an organization might group names together for administrative reasons;
881: for example,
882: the name
883: .(l
884: CAD.research.BigCorp.UUCP
885: .)l
886: might not actually have a host representing
887: .q research.
888: .pp
889: However,
890: it may frequently be convenient to have a host
891: or hosts
892: that
893: .q represent
894: a domain.
895: For example,
896: if a single host exists that
897: represents
898: Berkeley,
899: then mail from outside Berkeley
900: can forward mail to that host
901: for further resolution
902: without knowing Berkeley's
903: (rather volatile)
904: topology.
905: This is not unlike the operation
906: of the telephone network.
907: .pp
908: This may also be useful
909: inside certain large domains.
910: For example,
911: at Berkeley it may be presumed
912: that most hosts know about other hosts
913: inside the Berkeley domain.
914: But if they process an address
915: that is unknown,
916: they can pass it
917: .q upstairs
918: for further examination.
919: Thus as new hosts are added
920: only one host
921: (the domain master)
922: .i must
923: be updated immediately;
924: other hosts can be updated as convenient.
925: .pp
926: Ideally this name resolution process
927: would be performed by a name server
928: (e.g., [Su82b])
929: to avoid unnecessary copying
930: of the message.
931: However,
932: in a batch network
933: such as UUCP
934: this could result in unnecessary delays.
935: .sh 1 "COMPARISON WITH DELIVERMAIL"
936: .pp
937: .i Sendmail
938: is an outgrowth of
939: .i delivermail .
940: The primary differences are:
941: .np
942: Configuration information is not compiled in.
943: This change simplifies many of the problems
944: of moving to other machines.
945: It also allows easy debugging of new mailers.
946: .np
947: Address parsing is more flexible.
948: For example,
949: .i delivermail
950: only supported one gateway to any network,
951: whereas
952: .i sendmail
953: can be sensitive to host names
954: and reroute to different gateways.
955: .np
956: Forwarding and
957: :include:
958: features eliminate the requirement that the system alias file
959: be writable by any user
960: (or that an update program be written,
961: or that the system administration make all changes).
962: .np
963: .i Sendmail
964: supports message batching across networks
965: when a message is being sent to multiple recipients.
966: .np
967: A mail queue is provided in
968: .i sendmail.
969: Mail that cannot be delivered immediately
970: but can potentially be delivered later
971: is stored in this queue for a later retry.
972: The queue also provides a buffer against system crashes;
973: after the message has been collected
974: it may be reliably redelivered
975: even if the system crashes during the initial delivery.
976: .np
977: .i Sendmail
978: uses the networking support provided by 4.2BSD
979: to provide a direct interface networks such as the ARPANET
980: and/or Ethernet
981: using SMTP (the Simple Mail Transfer Protocol)
982: over a TCP/IP connection.
983: .+c
984: .ce
985: REFERENCES
986: .nr ii 1.5i
987: .ip [Crocker77]
988: Crocker, D. H.,
989: Vittal, J. J.,
990: Pogran, K. T.,
991: and
992: Henderson, D. A. Jr.,
993: .ul
994: Standard for the Format of ARPA Network Text Messages.
995: RFC 733,
996: NIC 41952.
997: In [Feinler78].
998: November 1977.
999: .ip [Crocker82]
1000: Crocker, D. H.,
1001: .ul
1002: Standard for the Format of Arpa Internet Text Messages.
1003: RFC 822.
1004: Network Information Center,
1005: SRI International,
1006: Menlo Park, California.
1007: August 1982.
1008: .ip [Feinler78]
1009: Feinler, E.,
1010: and
1011: Postel, J.
1012: (eds.),
1013: .ul
1014: ARPANET Protocol Handbook.
1015: NIC 7104,
1016: Network Information Center,
1017: SRI International,
1018: Menlo Park, California.
1019: 1978.
1020: .ip [Nowitz78]
1021: Nowitz, D. A.,
1022: and
1023: Lesk, M. E.,
1024: .ul
1025: A Dial-Up Network of UNIX Systems.
1026: Bell Laboratories.
1027: In
1028: UNIX Programmer's Manual, Seventh Edition,
1029: Volume 2.
1030: August, 1978.
1031: .ip [Schmidt79]
1032: Schmidt, E.,
1033: .ul
1034: An Introduction to the Berkeley Network.
1035: University of California, Berkeley California.
1036: 1979.
1037: .ip [Shoens79]
1038: Shoens, K.,
1039: .ul
1040: Mail Reference Manual.
1041: University of California, Berkeley.
1042: In UNIX Programmer's Manual,
1043: Seventh Edition,
1044: Volume 2C.
1045: December 1979.
1046: .ip [Solomon81]
1047: Solomon, M.,
1048: Landweber, L.,
1049: and
1050: Neuhengen, D.,
1051: .ul
1052: The Design of the CSNET Name Server.
1053: CS-DN-2.
1054: University of Wisconsin,
1055: Madison.
1056: October 1981.
1057: .ip [Su82a]
1058: Su, Zaw-Sing,
1059: and
1060: Postel, Jon,
1061: .ul
1062: The Domain Naming Convention for Internet User Applications.
1063: RFC819.
1064: Network Information Center,
1065: SRI International,
1066: Menlo Park, California.
1067: August 1982.
1068: .ip [Su82b]
1069: Su, Zaw-Sing,
1070: .ul
1071: A Distributed System for Internet Name Service.
1072: RFC830.
1073: Network Information Center,
1074: SRI International,
1075: Menlo Park, California.
1076: October 1982.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.