Return to usenix.me CVS log

Up to [CSRG BSD Unix] / 43BSDReno / usr.sbin / sendmail / doc

Annotation of 43BSDReno/usr.sbin/sendmail/doc/usenix.me, revision 1.1

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.