rsalz@uunet.uu.net (Rich Salz) (11/14/88)
Submitted-by: Lennart Lovstrand <lovstran@arisia.xerox.com>
Posting-number: Volume 16, Issue 78
Archive-name: ida2/part06
#! /bin/sh
# This is a shell archive. Remove anything before this line, then unpack
# it by saving it into a file and typing "sh file". To overwrite existing
# files, type "sh file -c". You can also feed this as standard input via
# unshar, or by typing "sh <file", e.g.. If this archive is complete, you
# will see the following message at the end:
# "End of archive 6 (of 8)."
# Contents: ida/doc/part1.ms
PATH=/bin:/usr/bin:/usr/ucb ; export PATH
if test -f ida/doc/part1.ms -a "${1}" != "-c" ; then
echo shar: Will not over-write existing file \"ida/doc/part1.ms\"
else
echo shar: Extracting \"ida/doc/part1.ms\" \(40946 characters\)
sed "s/^X//" >ida/doc/part1.ms <<'END_OF_ida/doc/part1.ms'
X.\" refer -e -l,2 -s paper.ms | tbl | pstroff -ms -*- nroff -*-
X.AM
X.RP
X.ds < \v'0.2m'\s-3
X.ds > \s0\v'-0.2m'
X.de DQ \" Double quoted string
X\\&\\$3\\*Q\\$1\\*U\\$2
X..
X.de SQ \" Single quoted string
X\\&\\$3`\\$1'\\$2
X..
X.de UC \" Uppercase string (in a smaller font)
X\\&\\$3\\s-1\\$1\\s+1\&\\$2
X..
X.de UQ \" Uppercase quoted string (in a smaller font)
X\\&\\$3\\*Q\\s-1\\$1\\s+1\\*U\\$2
X..
X.de QQ \" Quoted paragraph (possibly in a sized font)
X.QP
X.if !'\\$1'' .ps \\$1
X..
X.de II \" Indented, auto numbered paragraph
X.if !'\\$1'' .nr II \\$1-1 1
X.IP [\\n+(II]
X..
X.de JB \" Indented paragraph, bold label, extended width
X.IP "\fB\\$1\fR" 15
X..
X.de JS \" Indented paragraph, small label
X.IP "\s-1\\$1\s+1"
X..
X.de AP \" Appendix
X.if \\n(1T .bp
X.RT
X.if \\n(1T .sp
X.if !\\n(1T .BG
X.RT
X.ft 3
X.if n .ul 100
XAPPENDIX \\$1:
X..
X.de DO \" Domain table entry, see Appendix D
X.br
X.UC \\$1
X\t\\$2
X..
X.de X1 \" Generate 1st level index entry
X.br
X.ie '\\$3'' .ta \\n(LLu-\\w"\\$1"u \\n(LLuR
X.el .ta \\n(LLu-\\w'\\$3'u-1u \\n(LLu-\\w'\\$3'u
X\\$2\a\t\\$1
X..
X.de X2 \" Generate 2nd level index entry
X.in 3n
X.nr LL \\n(LL-3n
X.X1 "\\$1" "\\$2"
X.nr LL \\n(LL+3n
X.in 0
X..
X.\" ***** HERE BEGINS THE ACTUAL CODE (ie TEXT)
X.ND May 27, 1987
X.ie n .ds LH Electronic Mail Addressing
X.el .ds LH Electronic Mail Addressing with The IDA Sendmail Enhancement Kit
X.ds CH
X.ds RH Lennart Lo\\*:vstrand \\(co 1987
X.ds LF
X.ds CF \*- % \*-
X.ds RF
X.TL
XElectronic Mail Addressing in Theory and Practice
X.SM
X.br
Xwith The IDA Sendmail Enhancement Kit
X.if t \{\
X.SM
X.br
X(or The Postmaster's Last Will and Testament)
X.\}
X.AU
XLennart Lo\*:vstrand*
X.FS
X* New address from July 1987: Xerox EuroPARC, 61 Regent Street,
XCambridge CB2 1AB, U.K.
X.FE
X<lel@ida.liu.se>
X.AI
XDepartment of Computer and Information Science
XUniversity of Linko\*:ping
XS-581 83 Linko\*:ping
XSWEDEN
X.AB
XThis paper discusses theoretical and practical aspects of handling
Xelectronic mail addresses in a heterogeneous environment. It argues for
Xmore intelligent Mail Transport Agents that are able to fully format
Xaddresses according to different formats and that does not unnecessarily
Xcomplicate header addresses. Also described is a set of enhancements to
Xthe
X.UX
X.I sendmail
Xprogram and accompanying rewriting rules used to fulfill our two main
Xgoals: (1) To provide a canonical format for handling all electronic
Xmail addresses in which
X.DQ replying
Xregularly will work and where local users do not have to depend on the
Xrecipient's explicit route or addressing syntax when submitting a
Xmessage. (2) To design and implement a method for managing mail to and
Xfrom local users in a machine independent way, allowing them to change
Xtheir preferred actual mailboxes while maintaining the same visible
Xsurface addresses at all times.
X.FS
X.ps +1
X.sp
XReport no. LiTH-IDA-Ex-8715
X.FE
X.AE
X.NH
XINTRODUCTION
X.QQ
X.I
XWhile some computer-based mail addressing systems are actually easier to
Xdeal with than the paper-based model, they are the exception\*-and not
Xthe rule.
X.br
X.ti +\n(QIu
XWhy, you might ask, has electronic mail service become so very complex?
XMost of the problems are simply inherent in reaching beyond a local
Xsystem to connect with another.
X.br
X.R
X.ad r
X\&
X.[[
X%A David Crocker
X%T Networking Considered Harmful
X%J Unix Review
X%V 5
X%N 3
X%D 1987
X.]]
X.br
X.ad b
X.LP
XSending electronic mail is not always as easy as it ought to be. Too
Xmany incompatible mail addressing formats exist, forcing the presumptive
Xuser sending a message to know a great deal more than can be thought
Xreasonable about the recipient mail system's idiosyncrasies. This is a
Xwidely recognized problem, which can be seen as a consequence of the
Xever increasing interconnectivity between different computer systems,
Xeach subscribing to a different addressing standard. There are gateways
Xthat do address transformation on messages passing from one network to
Xanother, but it is normally done in a too insufficient manner to get rid
Xof the unintelligible hybrid addresses that often infest us. Even worse
Xare the many systems that assault these mixed format addresses by
Xrewriting them to malformed or incomplete ones. A hybrid address
Xpassing several network boundaries is often transformed in such a way
Xthat it no longer is possible to use it as a
X.DQ reply
Xor error return address; not even for a human being, much less for a
Xmachine.
X.PP
XThese problems are especially frequent in the
X.UX
Xworld. Networks like the
X.UC ARPANET
Xand
X.UC CSNET
Xhave the advantage of being more internally coherent; both
Xfollow the Internet mail syntax specifications, described in
X.UC RFC 822
X\&
X.[[
X%A David Crocker
X%T Standard for the Format of \s-1ARPA\s+1 Internet Text Messages
X%S \s-1RFC\s+1\&822
X%D 1982
X.]].
XThe
X.UX
Xworld used to practice the
X.SQ ! -path
Xaddressing syntax in which all addresses are relative routes, but has
Xrecently been moving over to the domain address standard of the
XInternet. The present problems concern nodes that has not yet done the
Xtransition and those that
X.I cannot
Xchange, because their standard mailer software is unable to handle these
Xnew format addresses. A typical example of the latter are the System V
Xsystems. Berkeley systems have the freedom of
X.I sendmail (8),
Xwhich unfortunately not always turns out as a blessing. In a way, it is
Xtoo easy to rewrite addresses using
X.I sendmail ,
Xbut too hard to control the transformations. This often leads to strange and
Xincompatible formats that don't belong in either standard.
X.PP
XThis paper discusses the most common formats and functions electronic
Xmail addresses have. It argues for more intelligent Mail Transport
XAgents that are able to fully format addresses according to different
Xformats and that does not unnecessarily complicate header addresses. In
Xthe end, it moves over to describe the
X.I
XIDA Sendmail Enhancement Kit
X.R
Xand the work and rationale that lies behind it. The Kit is made up of
Xtwo parts: First, the configuration file setup and the rewriting rules
Xcontained in it. These implement a rewriting strategy based on always
X.I completely
Xresolving addresses instead of being content by looking at the immediate
Xhost. The addresses are then fully transformed again according to the
Xrespective mailer's and expected ultimate recipient's format. Second,
Xwe describe a set of modifications to the
X.I sendmail
Xsource, giving it an extended functionality that in the opinion of this
Xauthor should have been implemented long ago. Typical additions are:
XDirect Access to Dbm(3) Files, Separate Envelope/Header Rewritings, and
XMulti-Token Class Matches. The configuration file is heavily dependent
Xof these modifications and will not function without them.
X.PP
XWe have also developed a way of handling mail to or from local users in
Xa machine independent way by hiding their actual sender and recipient
Xaddresses behind generic organization oriented addresses. This way, one
Xmay have a fixed visible address which is dynamically associated with
Xone or more physical mailboxes. Mails sent from any of a person's
X.DQ "well known"
Xaccounts will appear to come from his generic address. Similarly, mail
Xto any of his generic address will be forwarded to his preferred
Xmailbox(es). Note that the generic addresses as a group have no
Xconnection to any particular machine. Instead, they are merely database
Xentries on one or more nodes.
X.NH
XNAMES, ADDRESSES, AND ROUTES
X.LP
XLarry Kluger and John Shoch has in an excellent article
X.[ [
X%A Larry Kluger
X%A John Shoch
X%T Names, Addresses, and Routes
X%J Unix Review
X%V 4
X%N 1
X%D 1986
X.]]
Xdescribed the distinction between
X.I names ,
X.I addresses ,
Xand
X.I routes ,
Xin short:
X.QQ
X.I
XThe name of a resource refers to what we seek, an address indicates
Xwhere the resource is, and a route tells us how to get there.
X.LP
XWhen dealing with electronic mail,
X.I names
Xare typically used in identifying three kinds of entities: (1) The
Xmailbox associated with the sender (originator) and recipient of a
Xmessage, (2) The name space (domain) in which the sender/recipient is
Xknown, and (3) The computer system that houses a Mail Transfer Agent
X(MTA) able of delivering or forwarding messages. Often, the two latter
Xcoincide by associating the domain of a set of mailboxes with the actual
Xmachine that implements them. Furthermore, an
X.I address
Xwould be the data structure used in directly connecting to another MTA
Xover a computer network, such as a four-byte Internet number + TCP port
Xnumber, or an ordinary telephone number. It may well happen that many
Xnames map to the same address, or that the same name have more than one
Xaddress. Lastly, a
X.I route
Xconsists of an ordered sequence of two or more MTA names or addresses,
Xforming an explicit path that the message should take to reach its
Xrecipient. Routes can be further divided into
X.I "system routes,"
Xwhere the MTA itself is the responsible of constructing a useful path
Xand
X.I "source routes,"
Xwhere that responsibility lies on the person sending the message.
X.PP
XThe mapping from
X.I names
Xto
X.I addresses
Xis essentially beyond the scope of this paper, and will only briefly be
Xmentioned in the following sections.
XThus, we have taken the liberty of using the general meaning of the word
X.I address
Xto it denote both mailbox/domain name pairs as well as complete routes.
XAlso, we are using the words
X.I system ,
X.I host ,
Xand
X.I node
Xto all denote MTAs somewhere in a network. It is our hope that the
Xreader should not be confused because of this.
X.NH
XMAIL ADDRESS FORMATS
X.LP
XThe absolute majority of today's mailing systems use addresses,\**
X.FS
XThat is, routes or mailbox/domain name pairs.
X.FE
Xrepresented by a simple string of characters. Some of these characters
Ximplement operators that are used to divide the address into
Xmailbox/domain/route parts when parsed by an MTA. Different
Xoperators have different directions of associativity, making it
Xincreasingly difficult to unambiguously parse addresses produced by
Xcombining incompatible operators of different mail address syntaxes. It
Xis hoped that at least some of these problems will be solved with the
Xemergence of the structured attribute list addresses of
X.UC X .400.
XIn the mean time, we have a variety of different formats in use, each
Xsubscribing to a different set of delimiting operators. It is not uncommon to
Xsee addresses like:
X.QQ
Xmcvax!enea!liuida!obelix!p_e%seismo.css.gov@relay.cs.net
X.LP
Xor even
X.QQ
Xenea!seismo.\s-1CSS.GOV\s+1!!\s-1OZ.AI.MIT.EDU\s+1,!\s-1MC.LCS.MIT.EDU\s+1:ebg!\s-1REAGAN.AI.MIT.EDU\s+1
X.LP
Xturn up in message envelopes and headers. The last example comes from
Xthe envelope sender address found on a message in which the
X.UC RFC 822
Xroute was incompletely translated into
X.UUCP
X.SQ ! -path
Xsyntax. Now, before delving into a discussion about how these may be
Xresolved or preferably avoided, let's take a look at what kind of
Xaddressing formats currently exist.
X.NH 2
XRelative Addresses
X.LP
XThese types of addresses are by necessity all implemented as
X.I routes .
XIn purely relative addresses, all node names are relative to each other,
Xmaking path optimization or system routing difficult, if not impossible.
XFor the sender of a message, this means that addresses will look
Xdifferent depending on his location in the network, forcing him to
Xrecompute all addresses each time he changes his location. Even worse,
Xin a rapidly growing network, it might even happen that an address
Xbecomes invalid overnight because some link far away has been
Xdisconnected or replaced by another. All this makes it difficult for a
Xpresumptive user to continuously keep his addresses correct and up to
Xdate.
X.PP
XRelative addresses have since long been in use within the
X.UX
Xcommunity, but a great deal of work has been done by an organization
Xcalled
X.I "The \s-1UUCP\s+1 Mapping Project"
Xin eliminating duplicate host names, thus making it possible to use
Xabsolute addresses\**
X.FS
XSee the following section.
X.FE
Xin a flat name space. It is presently moving towards utilizing full
Xdomain names but is delayed by the fact that some systems, notably
X.I "System V"
Xsystems, cannot handle anything but
X.UC UUCP
Xsource routes with standard mailer software. The addressing syntax for
X.UX
X.UC UUCP
X.SQ ! -paths
Xis as follows:
X.QQ
Xnode!\|.\|.\|.\|!node!user
X.LP
XThe route sequence is read from the left to the right, with the ultimate
Xrecipient on the rightmost end. Other systems that have similar
Xaddressing formats are the Berknet and
X.UC VAX/VMS
Xmail systems, which use:
X.QQ
Xnode:\|.\|.\|.\|:node:user
X.LP
Xand
X.QQ
Xnode::\|.\|.\|.\|::node::user
X.LP
Xrespectively.
X.UC RFC 822
Xalso specifies a way of constructing explicit paths using the somewhat
Xcomplicated syntax:
X.QQ
X<@node,@node,\|.\|.\|.\|:user@node>
X.LP
XHere, the message should be passed through each successive node from
Xleft to right, ending up in the last user@node's mailbox. Note that the
Xless than and greater than brackets are included in the syntax. Another
Xwidely used but undocumented format is
X.I
XYe Olde
X.UC ARPANET
X.SQ % -Kludge:
X.R
X.QQ
Xuser%node%\|.\|.\|.\|%node@node
X.LP
Xwhich is interpreted from the right to the left by delivering the
Xmessage to the node after the atsign and then instantiating the
Xrightmost percent sign into a new atsign, etc.
X.NH 2
XAbsolute Addresses
X.QQ
X.nf
X.I
XThe Tao that can be told of is not the Absolute Tao;
XThe Names that can be given are not Absolute Names.\k:
X
XThe Nameless is the origin of Heaven and Earth;
XThe Named is it the Mother of all Things.
X.br
X.R
X\h'|\n:u-\w'[LaotseBC]'u'
X.[[
X%A Laotse
X%T Tao Te Ching
X%S Book 1, Verse 1
X%D ca 500 BC
X.]]
X.br
X.ad b
X.LP
XAbsolute addresses have the advantage of being universally unique and
Xthus applicable by any MTA\**
X.FS
XAt least in theory\*-not all MTAs necessarily know about how to deliver
Xto all addresses.
X.FE
Xindependently of where it is located. Since the names should be
Xuniquely identified, some way of distributing them within their name
Xspace needs to be accomplished. The simplest way of doing this is by
Xregistering plain node names with some central name directory on a
Xfirst-come-you-get-it service. The
X.I "\s-1UUCP\s+1 Project"
Xtried this to avoid duplicate
X.UC UUCP
Xnode names. However, maintaining such a directory and propagating its
Xchanges easily becomes too heavy a burden to handle. Another strategy
Xwas first adopted by the
X.UC ARPA
XInternet community, the hierarchical domain naming system described by
X.UC RFC 882
X\&
X.[[
X%A Paul Mockapetris
X%T Domain Names\*-Concepts and Facilities
X%S \s-1RFC\s+1\&882
X%D 1983
X.]],
X.UC RFC 920
X\&
X.[[
X%A Jon Postel
X%A Joyce Reynolds
X%T Domain Requirements
X%S \s-1RFC\s+1\&920
X%D 1984
X.]]
Xand others.
X.PP
XIn this system, a labelled tree is built with each node in the tree
Xdenoting a specific domain. Some nodes correspond to actual hosts,
Xtypically the leaves in the tree, while others simply map to some
Xorganizational entity, like a group, department, or institution. The
Xpurpose of the domain naming system is to distribute the naming
Xauthority throughout the tree. Letting each domain have the
Xresponsibility of naming the domains immediately beneath it guarantees
Xthe uniqueness of all simple domain names relative to their parents.
XThe full, qualified domain names are constructed by concatenating each
Xlevel's simple domain name with a dot in between. For example, there
Xmight exist a certain mail computer named
X.UQ MC
Xwithin the Laboratory of Computer Science of the Massachusetts Institute
Xof Technology, an Educational organization. A possible domain name for
Xthis computer would be:
X.QQ -1
XMC.LCS.MIT.EDU
X.LP
XThere might be many hosts named
X.UQ MC,
Xbut only one within the
X.UQ LCS.MIT.EDU
Xdomain. The same goes for the
X.UQ LCS
Xdomain within the
X.UQ MIT.EDU
Xdomain. The global uniqueness of each fully qualified domain is thus
Xguaranteed by its parentage.
X.PP
XThe domain system is currently in use within the
X.UC ARPA
XInternet,
X.UC CSNET,
Xand is in progress within the
X.UC UUCP
Xworld. Under its anonymous root domain, it presently has six
Xthree-letter organizational domains registered and a continuously
Xincreasing number of national two-letter domains. The organizational
Xdomains are mainly used within the U.S., and the national domains in
XEurope and Asia. There are also a set of
X.I "de facto"
Xnetwork based domains in use, although not officially registered. These
Xare really mock domains used to incorporate hosts on physical networks
Xthat cannot or do not want to handle domain addresses. Examples of
Xthese are
X.UC BITNET
Xand still most of the
X.UC UUCP
Xworld. Appendix D lists all domains currently registered with the SRI
XNetwork Information Center together with a set of otherwise frequently
Xrecognized network based domains.
X.NH 2
XAttribute Addresses
X.LP
XWith the
X.UC CCITT \**
X.FS
X.I
XComite\*' Consultatif International Te\*'le\*'phonique et
XTe\*'le\*'graphique,
X.R
Xi.e. the International Telegraph and Telephone Consultive Committee
X.FE
X.UC X .400
X\&
X.[[
X%A Malaga-Torremolinos
X%T Message Handling Systems: System Model\\*-Service Elements
X%S \s-1X\s+1.400
X%D 1984
X.]]
Xseries standard for electronic mail in emergence, a new kind of
Xaddressing system is being proposed. In this format, recipients are
Xuniquely identified using a list of attribute-value pairs. Some of
Xthese, like the Organization and Country attributes, are obligatory
Xwhile others may be supplied only if known by the sender. The idea is
Xthat the base attributes should be able to guide the message to a
Xrelevant directory server, while the others then are used to select the
Xactual recipient. Attribute sets that select no or more than one
Xrecipient will probably be considered erroneous, but could be used in
Xselecting multiple recipients.
X.PP
XIt will yet take several years before the attribute addressing scheme
Xhas come to widespread use. It will, however, surely come\*-if nothing
Xelse, then because it has the force of the united PTTs behind it.
XAlready, there exists guidelines for mapping between
X.UC RFC 822
Xbased addresses and
X.UC X .400,
Xsuch as
X.UC RFC 987
X\&
X.[[
X%A Steven Kille
X%S \s-1RFC\s+1\&987
X%T Mapping Between \s-1X\s+1.400 and \s-1RFC\s+1\&822
X%D 1986
X.]].
X.NH 2
XHybrid Addresses
X.LP
XWith all this in mind, let's take a look at how different formats
Xsometimes are combined and how we can resolve them. The three major
Xaddressing formats for routing messages are:
X.TS
Xl lw(2i) l.
X[1] T{
XThe
X.UC UUCP
X.SQ ! -path
XT} <\fInode\*<1\*>\fP!\fInode\*<2\*>\fP!\fInode\*<3\*>\fP!\fIuser\fP>
X[2] T{
XYe Olde
X.UC ARPANET
X.SQ % -Kludge
XT} <\fIuser\fP%\fInode\*<3\*>\fP%\fInode\*<2\*>\fP@\fInode\*<1\*>\fP>
X[3] T{
XThe
X.UC RFC 822
Xroute syntax
XT} <@\fInode\*<1\*>\fP,@\fInode\*<2\*>\fP:\fIuser\fP@\fInode\*<3\*>\fP>
X.TE
X.LP
Xwhere the latter mostly is used for envelope senders.
X.PP
XCombinations of the above usually appear in messages crossing one or
Xmore network boundaries with different addressing formats. Since each
Xof these formats were independently developed, it may not be obvious how
Xthey should be interpreted when combined. Still, by reasoning a little,
Xmuch can be inferred from how they incrementally are constructed.
X.PP
XStarting with the Domainist's approach to the matter, we have to give
X.SQ @
Xprecedence over
X.SQ !
Xsince this is implied by
X.UC RFC 822.
XThis means that addresses like:
X.QQ
Xnode\*<2\*>!node\*<1\*>!user@domain
X.LP
Xwill be interpreted as:
X.QQ
Xdomain \(-> node\*<2\*> \(-> node\*<1\*> \(-> user
X.LP
XNow, since
X.SQ %
Xis often the
X.I "de facto"
Xstandard routing operator on top of
X.SQ @ ,
Xan address like:
X.QQ
Xhost!user@domain
X.LP
Xthat is autorouted through
X.I relay
Xwill probably end up looking as:
X.QQ
Xhost!user%domain@relay
X.LP
Xmeaning:
X.QQ
Xrelay \(-> domain \(-> host \(-> user
X.LP
XThis forces us to give
X.SQ %
Xpriority over
X.SQ ! .
XHowever, a
X.SQ ! -path
Xaddress ending with a
X.DQ user%node,
Xcannot be a domain address (no
X.SQ @ )
Xand should therefore be interpreted using
X.UC UUCP
Xsemantics by prioritizing
X.SQ !
Xover
X.SQ % .
XThus,
X.QQ
Xnode\*<1\*>!node\*<2\*>!user%domain
X.LP
Xshould be read as:
X.QQ
Xnode\*<1\*> \(-> node\*<2\*> \(-> domain \(-> user
X.LP
XMixtures with
X.UC RFC 822
Xroutes may look hard to read, but are actually easy to parse. A fairly complicated address like:
X.QQ
Xnode\*<1\*>!node\*<2\*>!@domain\*<1\*>,@domain\*<2\*>:host!user%relay@domain\*<3\*>
X.LP
Xhas to be interpreted as:
X.QQ
Xnode\*<1\*> \(-> node\*<2\*> \(-> domain\*<1\*> \(-> domain\*<2\*> \(-> domain\*<3\*> \(-> relay \(-> host \(-> user
X.LP
Xsince
X.UC RFC 822
Xlike
X.SQ ! -paths
Xassociate left-to-right, and since the last
X.DQ localpart@domain
Xcan be unambiguously found after the colon.
X.PP
XNow, not all of us are Domainists. Many nodes can and will only be able
Xto interpret
X.UC UUCP
X.SQ ! -paths,
Xwhich leads to complications with mixed
X.SQ ! -
Xand
X.SQ @ -style
Xaddresses. The only workable solution to this is to try and avoid such
Xmixtures altogether. The easiest way of doing this is to write them as
X.SQ ! -
Xand
X.SQ % -style
Xcombinations, but even better would be to wrap them wholly around to the
X.SQ ! -path
Xformat. They should then turned back into
X.SQ %
Xand
X.SQ @
Xcombinations when breaking the Domain Land boundary.
X.NH
XA SHORT ANATOMY OF THE ELECTRONIC MESSAGE
X.LP
XIn analogy to the written letter, there are two major parts of a
Xmessage: The envelope and the contents. The envelope is there
Xspecifically for the MTAs to handle and contains the sender address
Xtogether with the message's actual recipients. The contents are usually
Xfurther subdivided into the header lines and the actual body, where only
Xthe latter is under the sender's full control. The headers are used by
Xthe MTAs and MUAs\**
X.FS
XMail User Agent, the program that the user directly interacts with when
Xreading or composing messages.
X.FE
Xto store various information of interest to the recipient, such as
Xsender, all official recipients, posting date, etc. Although the body
Xusually is left uninterpreted, some mail systems put constraints by
Xlimiting the length of each line or the whole message, or by only
Xallowing printable
X.UC ASCII
Xcharacters.
X.NH 2
XThe Envelope
X.LP
XThe envelope contains the physical message's actual recipients, which
Xvery well may be different from those in the headers. Typically, a
Xmessage sent to more than one recipient will be split into
X.I n
Xcopies, one for each network. These messages will have the original's
Xall recipients listed in their header lines, but each copy's envelope
Xshould only have those being delivered over the network in question.
XThere is usually also the option of
X.I "Blank Carbon Copy"
Xrecipients, which per definition never shall show up in the headers.
X.PP
XThe envelope will also contain the explicit path back to the sender for
Xerror messages and tracing purposes. This path should formed by having
Xeach node that forwards the message incrementally add its name to the
Xroute, thus avoiding routing problems that otherwise may appear. The
Xresult of each rewriting should be a full route in a suitable format
Xleading from the current node back to the originator.
X.PP
XIf the envelope recipient(s) are routes, they are handled in an
Xanalogous manner to the senders by removing the local node's name from
Xeach address before propagating it further. Optionally, the address can
Xbe made fully relative to the immediate receiving node by removing its
Xname from the route as well. This should be determined on a mailer
Xdependent basis. The MTA has the full freedom of at any point turning a
Xsimple envelope recipient address into a route if it sees reason to do
Xso. This could be done on the grounds that the immediate recipient node
Xcannot perform automatic routing. It should, however, be avoided if
Xpossible since it is hard to keep routing tables fully updated with
Xtopological changes in distant parts of the network. Turning envelope
Xroutes into simple addresses should also be avoided since there usually
Xexists a good reason for a route to be there.
X.NH 2
XThe Headers
X.LP
XHeader addresses are not normally used by the MTA. Exceptions may be
Xwhen headers such as
X.DQ "Return-Receipt-To:"
Xexists and the MTA is doing the final delivery or when the delivery of a
Xmessage fails and there exists a
X.DQ Errors-To:
Xheader.\**
X.FS
XThese are
X.I sendmail
Xspecific; other MTAs may have other exceptions.
X.FE
XThe MTA is also allowed to rewrite, or
X.DQ munge,
Xheader addresses when a message is forwarded from one network to
Xanother. This is done by first removing the addressing idiosyncrasies
Xof the transmitting network to obtain some internal canonical format and
Xthen applying the receiving network's idiosyncrasies to produce a
Xconforming address
X.[ [
X%A Marshall Rose
X%T Proposed Standard for Message Header Munging
X%S \s-1RFC\s+1\&886
X%D 1983
X.]].
XOf course, this should be done to both envelope and header addresses.
X.PP
XEven within one world, like the
X.UC UUCP
Xpseudo-network, it may be necessary to
X.DQ munge
Xaddresses for them to be understandable by the recipient system. For
Xinstance, many mail systems does not recognize all domains or perhaps
Xcannot even handle anything but pure and fully routed
X.UC UUCP
X.SQ ! -paths.
XIf the transmitting MTA does not take this into consideration, the user
Xsending the message has to submit full source routes with each receiving
Xnetwork's addressing syntax embedded. Except in the most simple cases,
Xthis task requires great knowledge\**
X.FS
XThat is, a case for a
X.I guru !
X.FE
Xabout how networks are interconnected, much more than can be considered
Xreasonable by any casual or even experienced user.
X.PP
X.I
XIn our opinion, this is currently the greatest obstacle in making
Xelectronic mail usable.
X.R
XOn from bad to worse, these user supplied source routes that are fully
Xcontained in the headers often get rewritten into further complicated
Xroutes. When such a message is received by its recipient, its header
Xaddresses may very well be too unintelligible to be understandable by a
Xhuman being, much less by a machine. In the best case, they will just
Xhave routes with incorrect points of reference, forcing
X.DQ reply
Xmessages to the other recipients to first be (automatically) routed to
Xthe first node of the path before it can start on the actual route.
XThen often in the opposite direction, leading half way back again.
X.NH
XADDRESS REWRITING STRATEGIES
X.LP
XNow, given the freedom and flexibility of
X.I sendmail ,
Xour project's task has been to construct a configuration file that, with
Xthe necessary enhancements to the
X.I sendmail
Xsource, will completely resolve and canonicalize all envelope and header
Xaddresses to an internal format. All unqualified addresses are then
Xofficialized using the
X.UC TCP/IP
Xname server function and a local
X.I dbm (3)
Xbased domain name table, and a route is found using a direct interface
Xto a
X.I pathalias (1)
Xrouting file.
XFinally, using a static
X.I dbm (3)
Xmailer table together again with the
X.UC TCP/IP
Xname server function, the message is dispatched to the appripriate
Xmailer which fully rewrites the addresses according to its own
Xidiosyncrasies.
X.NH 2
XSneak-In Preview
X.LP
XTo give a taste of how the complete system performs with a realistic
Xcase, consider at the following only partly imaginary example:
X.QQ
X.nf
X.ne 2.1
X.B Envelope:
X Sender: enea!seismo!relay.cs.net!cate%busch%pany.com
X Recipient: obelix!p_e
X.ne 2.1
X.B Headers:
X From: enea!relay.cs.net!cate%busch%pany.com
X To: mcvax!enea!liuida!obelix!p_e%seismo.css.gov@relay.cs.net
X cc: ree.pete%fidelio.uu.se%seismo.css.gov@relay.cs.net
X.fi
X.LP
XA user
X.I cate
Xon the Company Inc's local host
X.I busch
Xhas sent a message to two Swedish recipients:
X.I p_e
Xon the
X.UC UUCP
Xhost
X.I obelix
Xin Linko\*:ping and to
X.I ree.pete
Xon the Uppsala node
X.I fidelio.uu.se.
XIf the headers would be left untouched, a reply from
X.I p_e
Xto both
X.I cate
Xand
X.I ree.pete
Xwould force
X.I ree.pete 's
Xcopy to go all the way back to
X.I relay.cs.net
Xbefore it could return to Sweden and Uppsala. Clearly, this is a waste of
Xboth resources and time when there might (and does) exist a much shorter
Xpath within the country. With The Kit's rewriting heuristics, the same
Xheader lines will look like the following when leaving the local node:
X.QQ
X.nf
X.ne 2.1
X.B Envelope:
X Sender: @majestix.liu.se,@enea.se,@seismo:cate%busch%pany.com@relay.cs.net
X Recipient: p_e%obelix.liu.se@asterix.liu.se
X.ne 2.1
X.B Headers:
X From: cate%busch@pany.com
X To: p_e@obelix.\s-1UUCP\s+1
X cc: ree.pete@fidelio.uu.se
X.fi
X.LP
XHere, our local node's name has been added to the envelope sender path,
Xwhich also has been transformed into a
X.UC RFC 822
Xroute\**.
X.FS
XSave for the
X.SQ <
Xand
X.SQ >
Xbrackets.
X.FE
XOther options would be to have it as a
X.SQ ! -path
Xor
X.SQ % -path.
XThe envelope recipient has been routed via
X.I asterix.liu.se,
Xand changed into a
X.SQ % -path,
Xon the basis that the message is forwarded over a
X.UC TCP/IP
Xconnection and this is the preferred route format for most such systems.
X.PP
XAlso, the route has been removed from the header
X.DQ From:
Xline, leaving the first universally qualified node there together with a
X.SQ % -path
Xfrom that point to the recipient. The
X.DQ To:
Xline has undergone even more drastic changes. First, the route to
X.I seismo.css.gov
Xwas removed since this is the first universally qualified node. Then
Xa table of well-known
X.UC UUCP
Xrelays was consulted to further compress the path.
X.I Mcvax ,
X.I enea ,
Xand
X.I liuida
Xwere all members of that list. This gave
X.DQ obelix!p_e
Xas a result, which then was turned into the domain form
X.DQ p_e@obelix.\s-1UUCP\s+1.
XIn the last line,
X.DQ ree.pete@fidelio.uu.se
Xsimply had its path removed since
X.UC \fISE\fP
Xis a registered top domain.
X.NH 2
XThe Configuration File
X.LP
XThe IDA Sendmail Master Configuration File should be sent through the
X.I m4 (1)
Xmacro processor to produce an actual configuration file.
XSeveral
X.I m4
Xidentifiers are used to customize the file; each of them is described in
X.I "Appendix C: Customization Parameters" .
XUnlike the Berkeley version, it was not designed as a set of
X.I m4
Xfragments that
X.DQ sources
Xeach other to form a full configuration, but rather as a single master
Xconfiguration file which holds a
X.I bank
Xof all possible mailers and corresponding rewriting rulesets. The
Xinstance's actually available mailers are enabled by giving values to
Xtheir corresponding
X.I m4
Xidentifiers. The current version include mailer definitions for a
X.UC TCP/IP
Xmailer, three kinds of
X.UC UUCP
Xmailers depending on the remote node's address handling capabilities, a
Xmock
X.UC DEC net
Xmailer, as well as the
X.UC LOCAL
Xand
X.UC PROG
Xmailers. Their design has been kept as clean as possible to make the
Xconstruction of e.g.
X.UC BITNET
Xor
X.UC CSNET
Xmailers using these as templates straight-forward.
X.PP
XThe rewriting rules of the Kit's configuration file are
Xexplicitly oriented towards the domain naming syntax. They will resolve
Xall input addresses to an internal domain based format and then rewrite
Xthem according to the selected mailer's preferences. Internally,
Xall addresses have the same
X.QQ
Xuser@.domain
X.LP
Xformat. Note the dot after the atsign; it is there to make it easier
Xto rewrite the address. Also note
Xthat this differs substantially from the Berkeley
X.DQ "whatever<@host>whatever"
Xformat. For historical reasons, both the
X.UC RFC 822
Xroute syntax and
X.I
XYe Olde
X.UC ARPANET
X.SQ % -Kludge
X.R
Xare used internally to represent routes when only one of them should be
Xsufficient.
X.NH 2
XCanonicalizing the Address
X.LP
XRuleset 3 canonicalizes all addresses, making them conform to our
Xinternal format. After the canonicalization, the
X.DQ user
Xpart may end up containing a route in either standard
X.UC RFC 822
Xformat or using the
X.SQ % -path
Xformat.
X.SQ ! -,
X.SQ : -,
Xand
X.SQ :: -style
Xpaths are rewritten into
X.UC RFC 822
Xroutes. Reasonable mixtures of route formats are resolved
Xusing the strategies described in the section about
X.I "Hybrid Addresses" .
XAs an option, the (untested)
X.UC UUCPPRECEDENCE
Xswitch may be turned on in the configuration master file. This will
Xenable some simple heuristics that will decide between domain style and
X.UC UUCP
X.SQ ! -path
Xprioritized unpacking depending on whether the
X.I domain
Xis qualified or not. In any case, ruleset 3 will make sure that the
X.I domain
Xpart of all
X.DQ user@.domain
Xaddresses are mapped to their full, official domain names whenever
Xpossible using both the
X.UC TCP/IP
Xname server and a dbm domaintable. It also goes through some effort to
Xrepair malformed addresses, but much of this is probably too site
Xspecific to be generally useful.
X.PP
XSince
X.SQ ! -paths
Xare internally represented as
X.UC RFC 822
Xroutes, you should not be surprised when you see an address like:
X.QQ
Xfoo!bar!baz!user
X.LP
Xfirst be transformed into:
X.QQ
X@foo.\s-1UUCP\s+1,@bar:user@baz
X.LP
Xand then to:
X.QQ
Xbar:user@baz@.foo.\s-1UUCP\s+1
X.LP
XThe
X.UC UUCP
Xdomain of
X.I foo
Xhas been inferred from the
X.SQ ! -style
Xsyntax. If
X.I foo
Xhad been known by the domaintable to have specific domain name, that had
Xbeen used instead. Nothing can be inferred about the nodes
X.I bar
Xand
X.I baz ,
Xsince we they may be local to
X.I foo .
XNow, since the pure
X.UC RFC 822
Xroute doesn't conform to our internal format, i.e. it does not have a
X.DQ user
Xpart followed by an atsign-dot and a
X.DQ domain,
Xwe had to rearrange it a little. The closest node of the route was thus
Xextracted and added the right side of the rest of the route together
Xwith the atsign-dot. It may not be very pretty to look at, but it is
Xeasier to handle this way.
X.PP
XNote that there is a risk of confusing
X.UC UUCP
Xnode names with local hosts using the domaintable lookup. For example,
Xif you had a local node
X.I linus
Xwith a full domain name of
X.I linus.liu.se
Xand received an address like
X.DQ linus!user,
Xthis would be interpreted as the local
X.I linus
Xand rewritten into
X.DQ user@linus.liu.se.
XThis is probably right for envelope recipients, but not so surely in
Xheader lines. You can define
X.UC BANGIMPLIESUUCP
Xif you want to disable the domaintable qualification.
X.NH 2
XFinding Route and Mailer
X.QQ
X.I
X.in +\n(QIu
X.ti -\n(QIu
X\*QWould you tell me, please, which way I ought to go from here?\*U
X.br
X.ti -\n(QIu
X\*QThat depends a good deal on where you want to get to,\*U said the Cat.
X.br
X.in -\n(QIu
X.R
X.ad r
X\&
X.[[
X%A Lewis Carrol
X%T Alice in Wonderland
X%D 1896
X.]]
X.br
X.ad b
X.LP
XBefore ruleset 0 tries to find an applicable mailer, it digests all
Xroutes through the local host by stripping off its own name and sending
Xthe address through ruleset 3 again. It then has four strategies of
Xfinding a suitable mailer for the address:
X.II 1
XTry to find a mailer that will connect to the immediate host in the
Xaddress.
X.II
XTry to find a route to the address' domain using a
X.I dbm (3)
Xrouting table and a mailer that will connect to the route's closest
Xnode.
X.II
XUse the firm-wired
X.UC RELAY_MAILER
Xand
X.UC RELAY_HOST
Xpairs to automatically forward the message.
X.II
XGive up; send the address to the
X.UC ERROR
Xmailer.
X.LP
XThe code that determines if a mailer directly can deliver to a certain
Xdomain is found in ruleset 26.\**
X.FS
XYes, I too wish that named rulesets would be available in
X.I sendmail .
XPerhaps somebody should convert this configuration file into
X.I ease .
X.FE
XIt does this on a per mailer bases with the following order of priority:
X.IP \s-1LOCAL\s+1 10
XIf the supplied domain is any of local host's names (member of the
X.B $w
Xclass), or if the complete address is found in the
X.I aliases (5)
Xfile, the message is delivered locally. The latter type of local
Xdelivery will cause the address to be expanded to the RHS of the alias
Xentry and the complete process to recurse.
X.IP \\\\k:\\fISpecial\\fP\\\\h'|\\\\n:u'\\\\v'+1'\\fIMailers\\fP\\\\v'-1'
XIn order to override the standard mailer selection, a
Xspecial dbm
X.I mailertable
Xmay be used to force addresses to be delivered using specific mailers.
XIf the address' domain is found in the
X.I mailertable ,
Xthe associated mailer will be used. The mailer table should map
Xofficial domain names to
X.DQ mailer:host
Xpairs, with a colon between the mailer and the host.
X.IP \s-1TCP/IP\s+1
XWith the new
X.I default
Xargument of the
X.UC TCP/IP
Xnameserver lookup function, it is possible to determine if an address
Xcan be delivered using this protocol family without relying on static
Xhost tables. If the address' domain is known to the
X.UC TCP/IP
Xnameserver, it is returned together with its canonicalized host name.
X.IP \s-1DEC\s+1net
XThe
X.UC DEC net
Xmailer does not share the network based nameserver facilities of the
X.UC TCP/IP
Xmailer, and thus has to rely on a host table. This is done with a
Xtwo-phase operation\*-first the domain is mapped to a
X.UC DEC net
Xname, if known, then
Xthe the
X.UC DEC net
Xhost name is checked in the list of connectable
X.UC DEC net
Xhosts before it is returned. This is because some
X.UC DEC net
Xnodes cannot talk across area boundaries, forcing recipient addresses to
Xbe explicitly routed over an intermediary host.
X.I Note:
XThe supplied
X.UC DEC net
Xmailer uses a
X.UC TCP/IP
Xconnection to a
X.UC DEC system-20
Xacting as gateway. A real implementation should remove the immediate
Xnode from routes before returning them, but we cannot do this.
X.IP \s-1UUCP\s+1
XThe
X.UC UUCP
Xmailer is also determined with a two-phase operation\*-first the domains
Xis mapped through the
X.UC UUCP
Xtranslation table, returning the
X.UC UUCP
Xnode name, if known. The
X.UC UUCP
Xmailer will then be selected only if the
X.UC UUCP
Xname is known to be directly connectable by us (normally determined
Xusing the /usr/lib/uucp/L.sys file). All nodes found this way will be
Xsent to through the
X.DQ dumb
X.UC UUCP
Xmailer. Delivery using either the
X.UC UUCP-A
Xor the
X.UC UUCP-B
Xmailer has to be determined using the special mailertable previously
Xmentioned.
X.LP
XIf an address needs to be routed, i.e. if the first pass through ruleset
X26 fails, it is given to ruleset 22 where its domain is looked up in a
X.I pathalias (1)
Xtype routing table. Routes to explicit domain/host names are preferred
Xover general (parent) domain routes. Before the new address is
Xreturned, it is sent through the canonicalization routines of ruleset 3.
XThis makes specific
X.I pathalias
Xroute syntax effectively ineffective. The normal way would be not to
Xspecify any special routing syntax at all to
X.I pathalias ,
Xbut to invariably let it produce
X.SQ ! -paths.
X.NH 2
XExternalizing the Address
X.LP
XAfter a mailer has been chosen, addresses are rewritten using rulesets 1
Xand 2 for envelope senders/recipients and rulesets 5 and 6 for header
Xsenders/recipients. Envelope senders are left untouched by this
Xprocess, but envelope recipients will have
X.UC RFC 822
Xroutes turned into
X.SQ % -paths.
XHeader
X.UC RFC 822
Xroutes will also be turned into
X.SQ % -paths
Xand then gently compressed by having paths to fully qualified domains
Xand
X.UC UUCP
Xrelay-to-relay paths removed.
XHeader senders will furthermore have their host names hidden by
X.UC HIDDENNAME,
Xif defined, and their addresses filtered through the
X.UC GENERICFROM
Xtable, if available.
X.PP
XWhen this is done, the mailer specific rewriting phase starts. The
X.UC LOCAL
Xand
X.UC PROG
Xmailers does not do any further rewriting as supplied, but could be
Xconvinced to produce
X.SQ ! -paths
Xfor
X.UC UUCP
Xroutes if preferred [using ruleset 15 or a variant thereof].
X.PP
XThe
X.UC TCP/IP
Xand
X.UC DEC net
Xmailers will add a call to ruleset 24 for all envelope recipients. This
Xwill turn domains corresponding to
X.UC DEC net
Xnodes into flatspaced
X.UC DEC net
Xhost names, since domains are not supported there. This should really
Xnot be done in the
X.UC TCP/IP
Xmailer, but all our
X.UC DEC net
Xtraffic is presently routed over a
X.UC TCP/IP
Xlink. Since no special rewriting is done for envelope senders, this
Xmeans that they normally will appear in
X.UC RFC 822
Xroute format using these as well as any of the previous mailers.
X.PP
XThere are three variants of the
X.UC UUCP
Xmailer depending on the remote node's address handling capabilities.
XThe
X.DQ dumb
Xversion, simply called
X.UC UUCP ,
Xcorresponds closely to the class 1 mailer of
X.UC RFC 976
X\&
X.[[
X%A Mark Horton
X%T \s-1UUCP\s+1 Mail Interchange Format Standard
X%S \s-1RFC\s+1\&976
X%D 1986
X.]].
XIt will rewrite all addresses into
X.SQ ! -format,
Xand makes all header addresses
X.SQ ! -relative
Xthe recipient node, routed through the transmitting node if
Xnecessary.\**
X.FS
XSee the new
X.UC M_RELATIVIZE
Xmailer flag in the following section.
X.FE
XThe
X.UC UUCP-A
Xis closer to the
X.UC RFC 976
Xclasses 2 and 3 mailers in that it will let all header addresses stay in
X.SQ @ -format,
Xbut change envelope addresses to
X.SQ ! -paths
Xwhenever applicable. The
X.UC UUCP-B
Xmailer, finally, functions as the
X.UC UUCP-A
Xmailer but will in addition supply envelope senders in
X.UC RFC 822
Xroute format and transmit the message to a
X.I bsmtp
Xprogram on the remote node.
X.PP
XRuleset 4 will as usual make the address truly external. In our case,
Xthis means by removing the dot after the atsign and by moving the
Ximmediate domain to the head of
X.UC RFC 822
Xroutes.
END_OF_ida/doc/part1.ms
if test 40946 -ne `wc -c <ida/doc/part1.ms`; then
echo shar: \"ida/doc/part1.ms\" unpacked with wrong size!
fi
# end of overwriting check
fi
echo shar: End of archive 6 \(of 8\).
cp /dev/null ark6isdone
MISSING=""
for I in 1 2 3 4 5 6 7 8 ; do
if test ! -f ark${I}isdone ; then
MISSING="${MISSING} ${I}"
fi
done
if test "${MISSING}" = "" ; then
echo You have unpacked all 8 archives.
echo "See ida/README and ida/INSTALL for further directions."
rm -f ark[1-9]isdone
else
echo You still need to unpack the following archives:
echo " " ${MISSING}
fi
## End of shell archive.
exit 0
--
Please send comp.sources.unix-related mail to rsalz@uunet.uu.net.