home *** CD-ROM | disk | FTP | other *** search
/ Handbook of Infosec Terms 2.0 / Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso / text / rfcs / rfc1711.txt < prev    next >
Text File  |  1996-09-11  |  49KB  |  1,068 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                        J. Houttuin
  8. Request for Comments: 1711                                          RARE
  9. Category: Informational                                     October 1994
  10.  
  11.  
  12.                    Classifications in E-mail Routing
  13.  
  14. Status of this Memo
  15.  
  16.    This memo provides information for the Internet community.  This memo
  17.    does not specify an Internet standard of any kind.  Distribution of
  18.    this memo is unlimited.
  19.  
  20. Abstract
  21.  
  22.    This paper presents a classification for e-mail routing issues. It
  23.    clearly defines commonly used terminology such as static routing,
  24.    store-and-forward routing, source routing and others. Real life
  25.    examples show which routing options are used in existing projects.
  26.  
  27.    The goal is to define all terminology in one reference paper. This
  28.    will also help relatively new mail system managers to understand the
  29.    issues and make the right choices. The reader is expected to already
  30.    have a solid understanding of general networking terminology.
  31.  
  32.    In this paper, the word Message Transfer Agent (MTA) is used to
  33.    describe a routing entity, which can be an X.400 MTA, a UNIX mailer,
  34.    or any other piece of software performing mail routing functions. An
  35.    MTA processes the so called envelope information of a message. The
  36.    term User Agent (UA) is used to describe a piece of software
  37.    performing user related mail functions. It processes the contents of
  38.    a message's envelope, i.e., the header fields and body parts.
  39.  
  40. Table of Contents
  41.  
  42.    1.   Naming, addressing and routing                               2
  43.    2.   Static versus dynamic                                        4
  44.    3.   Direct versus indirect                                       5
  45.    3.1.       Firewalls                                              5
  46.    3.2.       Default versus rule based                              6
  47.    4.   Routing at user level                                        7
  48.    4.1.       Distributed domains                                    7
  49.    4.2.       Shared MTA                                             8
  50.    5.   Routing control                                              9
  51.    6.   Bulk routing                                                 9
  52.    7.   Source routing                                              11
  53.    8.   Poor man's routing                                          12
  54.    9.   Routing communities                                         12
  55.  
  56.  
  57.  
  58. Houttuin                                                        [Page 1]
  59.  
  60. RFC 1711           Classifications in E-mail Routing        October 1994
  61.  
  62.  
  63.    10.  Realisations                                                14
  64.    10.1.      Internet mail                                         14
  65.    10.2.      UUCP                                                  15
  66.    10.3.      EARN                                                  15
  67.    10.4.      GO-MHS                                                15
  68.    10.5.      ADMD infrastructure                                   15
  69.    10.6.      Long Bud                                              16
  70.    10.7.      X42D                                                  16
  71.    11.  Conclusion                                                  16
  72.    12.  Abbreviations                                               17
  73.    13.  References                                                  17
  74.    14.  Security Considerations                                     19
  75.    15.  Author's Address                                            19
  76.  
  77. 1.    Naming, addressing and routing
  78.  
  79.    A name uniquely identifies a network object (without loss of
  80.    generality, we will assume the 'object' is a person).
  81.  
  82.    Once a person's name is known, it can be used as a key to determine
  83.    his address.
  84.  
  85.    An address uniquely defines where the person is located. It can
  86.    normally be divided into a domain related part (e.g., the RFC 822
  87.    domainpart or in X.400 an ADMD or OU attribute) and a local or user
  88.    related part (e.g., the RFC 822 localpart or in X.400 a DDA or
  89.    Surname attribute). The domain related part of an address typically
  90.    consists of several components, which normally have a certain
  91.    hierarchical order. These domain levels can be used for routing
  92.    purposes, as we will see later.
  93.  
  94.    Once a person's address is known, it can be used as a key to
  95.    determine a route to that person's location.
  96.  
  97.    We will use the following definition of an e-mail route:
  98.  
  99.        e-mail route           a path between two leaves in a
  100.                               directed Message Transfer System
  101.                               (MTS) graph that a message travels
  102.                               for one originator/recipient pair.
  103.                               (see Figure 1)
  104.  
  105.    Note that, in this definition, the User Agents (UAs) are not part of
  106.    the route themselves. Thus if a message is redirected at the UA
  107.    level, a new route is established from the redirecting UA to the UA
  108.    the message is redirected to.
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Houttuin                                                        [Page 2]
  115.  
  116. RFC 1711           Classifications in E-mail Routing        October 1994
  117.  
  118.  
  119.    The first and last leaves in a mail route are not always UAs. A route
  120.    may start from a UA, but stop at a certain point because one of the
  121.    MTAs is unable to take any further routing decisions. If this
  122.    happens, a warning is generated by the MTA (not by a UA), and sent
  123.    back to the originator of the undeliverable message. It may even
  124.    happen that none of the leaves is a UA, for instance if a warning
  125.    message as discussed above turns out to be undeliverable itself. The
  126.    cautious reader may have noticed that this is a dangerous situation.
  127.    Special precautions are needed to avoid loops in such cases (see
  128.    [1]).
  129.  
  130.            user                        user
  131.             |                           ^
  132.             v                           |
  133.      +-----------------------------------------+
  134.      |      |                           ^      |
  135.      |      v                           |      |
  136.      |   +-----+                     +-----+   |
  137.      |   | UA  |                     | UA  |   |
  138.      |   +-----+                     +-----+   |
  139.      |      |                           ^      |
  140.      |      v                           |      |
  141.      | +-------------------------------------+ |
  142.      | |    v                           ^    | |
  143.      | |    v                           ^    | |
  144.      | |    v                           ^    | |
  145.      | | +-----+                     +-----+ | |
  146.      | | | MTA |.....................| MTA | | |
  147.      | | +-----+                     +-----+ | |
  148.      | |    v   \                       ^    | |
  149.      | |    v    \................      ^    | |
  150.      | |    v                     \     ^    | | NB The actual route
  151.      | | +-----+                   \ +-----+ | |    is drawn as
  152.      | | | MTA |>>>>>>>>>>>>>>>>>>>>>| MTA | | |    v            ^
  153.      | | +-----+                     +-----+ | |    v            ^
  154.      | | Message Transfer System             | |    v  >>>>>>>>  ^
  155.      | +-------------------------------------+ |
  156.      | Message Handling System                 |
  157.      +-----------------------------------------+
  158.  
  159.                 Figure 1. A mail route
  160.  
  161.    It is important that the graph is directed, because routes are not
  162.    necessarily symmetric. A reply to a message may be sent over a
  163.    completely different mail route for reasons such as cost, non-
  164.    symmetric network connectivity, network load, etc.
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Houttuin                                                        [Page 3]
  171.  
  172. RFC 1711           Classifications in E-mail Routing        October 1994
  173.  
  174.  
  175.    According to the definition, if a message has two different
  176.    recipients, there will also be two mail routes. Since the delivery to
  177.    a UA (not the UA itself) is a part of the route, this definition is
  178.    still valid if two UAs are connected to the same MTA.
  179.  
  180.    The words '.. for one originator-recipient pair.' in the definition
  181.    do not imply that this pair provides the MTA with all necessary
  182.    information to choose one specific route. One originator-recipient
  183.    pair may give an MTA the possibility to choose from a number of
  184.    possible routes, the so-called routing indicators (see chapter 2).
  185.  
  186.    Other information (e.g., line load, cost, availability) can then be
  187.    used to choose one route from the routing indicators.
  188.  
  189.    Routing is defined as the process of establishing routes. Note that
  190.    this is a distributed process; every intermediate MTA takes its own
  191.    routing decisions, thus contributing to the establishment of the
  192.    complete route.
  193.  
  194.    Taking a routing decision is not a purely algorithmic process,
  195.    otherwise there would hardly be any difference between an address and
  196.    a route. The address is used as a key to find a route, typically in
  197.    some sort of rule-based routing database. The possible options for
  198.    realising this database and algorithms for using it are the subject
  199.    of the rest of this paper.
  200.  
  201. 2.    Static versus dynamic
  202.  
  203.    Dynamic (mail) routing allows a routing decision to be influenced by
  204.    external factors, such as system availability, network load, etc. In
  205.    contrast, static (mail) routing is not able to adapt to environmental
  206.    constraints. Static routing can be viewed as an extremely simple form
  207.    of dynamic routing, namely where there is only one choice for every
  208.    routing decision.
  209.  
  210.    Dynamic routing algorithms normally use some kind of distributed
  211.    databases to store and retrieve routing information, whereas static
  212.    routing is typically implemented in routing tables.
  213.  
  214.    Note that dynamic routing can occur at different layers: at the mail
  215.    level, dynamic routing might allow a message to be relayed to a
  216.    choice of MTAs (the routing indicators). As an example, consider the
  217.    Internet mechanism of using multiple Mail eXchanger (MX) records,
  218.    describing MTAs that can serve a domain. If the primary choice MTA is
  219.    not available, a second choice MTA can be tried. If this second
  220.    choice MTA is busy, a third one will be tried, etc. On lower layers,
  221.    there may be more than one presentation address for one MTA, each of
  222.    which can again have an associated priority and other attributes.
  223.  
  224.  
  225.  
  226. Houttuin                                                        [Page 4]
  227.  
  228. RFC 1711           Classifications in E-mail Routing        October 1994
  229.  
  230.  
  231.    These choices may represent that an MTA prefers to be connected to
  232.    using one certain stack, e.g., RFC1006/TCP/IP, but is also able to
  233.    accept incoming calls over another stack, such as TP0/CONS/X.25. We
  234.    will call this dynamic stack routing. Theoretically, dynamic stack
  235.    routing should be transparent to the mail routing application, and is
  236.    thus not a part of dynamic mail routing. It is mentioned here because
  237.    in existing products, dynamic stack routing is often very well
  238.    visible at the mail configuration level, so MTA managers should at
  239.    least be aware of it.
  240.  
  241.    Although static routing is often table based, not all table based
  242.    routing algorithms are necessarily static in nature. As a counter
  243.    example, X.400 routing according to RFC 1465 [2] is clearly table
  244.    based, but at the same time allows a fairly dynamic kind of mail
  245.    routing (as well as dynamic stack routing, which in this approach is
  246.    cleanly separated from the dynamic mail routing part). A mail domain
  247.    can specify a choice of so-called RELAY-MTAs (formerly called WEPs)
  248.    that will serve it, each with a priority and maximum number of
  249.    retries.
  250.  
  251.    For reasons of flexibility and reliability, dynamic routing is almost
  252.    always the preferred method.
  253.  
  254. 3.    Direct versus indirect
  255.  
  256.    Direct routing allows the originator's MTA to contact the recipient's
  257.    MTA directly, whereas indirect routing (also known as store-and-
  258.    forward routing) uses intermediate MTAs to relay the message towards
  259.    the recipient. It is difficult to clearly distinguish between direct
  260.    and indirect routing: direct routing assumes the existence of a fully
  261.    meshed routing topology, whereas indirect routing assumes the
  262.    existence of a more tree-like hierarchical topology. Mail routing in
  263.    most existing networks is upto some degree indirect. Networks can be
  264.    classified as being more or less direct according for the following
  265.    rule of thumb: larger fan out of the routing tree means more direct
  266.    routing, greater depth of the tree means less direct routing. Two
  267.    kinds of indirect routing are presented here: firewalls (downstream)
  268.    and default routes (upstream).
  269.  
  270. 3.1.  Firewalls
  271.  
  272.    A firewall 'attracts' all messages for a certain set of addresses
  273.    (the address sub space behind the firewall) from the outside e-mail
  274.    world to a central relaying MTA (the firewall). This is done by
  275.    publishing routes to all other MTAs that must relay their messages
  276.    over this firewall (the attracted community). Note that local
  277.    knowledge should be used to route messages within the address space
  278.    behind the firewall. An example for this is presented later on. There
  279.  
  280.  
  281.  
  282. Houttuin                                                        [Page 5]
  283.  
  284. RFC 1711           Classifications in E-mail Routing        October 1994
  285.  
  286.  
  287.    exist many reasons for using firewalls, e.g., security considerations
  288.    or to concentrate the management for a given domain onto one well
  289.    managed system.
  290.  
  291.    The Internet mail system would allow all mail hosts connected to the
  292.    Internet to directly accept mail from any other host, but not all
  293.    hosts use this possibility. Many domains are hidden behind one or
  294.    more 'Mail eXchanger' (MX), which offer to relay all incoming mail
  295.    for those domains. The RELAY-MTAs mentioned earlier can also be
  296.    considered firewall systems.
  297.  
  298.          +-----------------------------------+
  299.          |                                   |
  300.          | The rest of the e-mail world      |
  301.          |                                   |
  302.          +-----------------------------------+
  303.                      \  |  |   /
  304.                       \ |  |  /
  305.                        \|  | /
  306.                         v  vv
  307.                   +--------------+
  308.                   |Firewall MTA A|
  309.                   +--------------+
  310.                     ^  /  ^  \  ^
  311.                    /  /   |   \  \
  312.                   /  /    |    \  \
  313.   Default route--o  /     |     \  o---Default route
  314.                 /  /      |      \  \
  315.                /  /       |       \  \
  316.               /  v        v        v  \
  317.            +-----+     +-----+   +-------+
  318.            |MTA B|<----|MTA C|   |MTA D  |
  319.            +-----+     +-----+   +-------+
  320.             /  |         |         |   \
  321.            /   |         |         |    \
  322.           /    |         |         |     \
  323.        +----+ +----+  +----+   +----+ +----+
  324.        | UA | | UA |  | UA |   | UA | | UA |
  325.        +----+ +----+  +----+   +----+ +----+
  326.  
  327.         Figure 2. Firewall and default route
  328.  
  329. 3.2.  Default versus rule based
  330.  
  331.    Default routing is to outgoing mail what a firewall is for incoming
  332.    mail, and is thus often used in conjunction with firewalls. It is
  333.    about the simplest routing algorithm one can think of: route every
  334.    message to one and the same MTA, which is trusted to take further
  335.  
  336.  
  337.  
  338. Houttuin                                                        [Page 6]
  339.  
  340. RFC 1711           Classifications in E-mail Routing        October 1994
  341.  
  342.  
  343.    care of routing the message towards its destination. Pure default
  344.    routing is rather useless; it is normally used as a fall back
  345.    mechanism accompanying a rule based algorithm.
  346.  
  347.    For example, the simplest usable default algorithm is the following:
  348.    first check if a mail should be delivered to a local UA. If not,
  349.    perform default routing.
  350.  
  351.    In order to avoid loops, it is not acceptable for all MTAs within a
  352.    certain routing community (see chapter 9) to use default routing. At
  353.    least one MTA should be able to access all routing rules for that
  354.    community. Consider the following example: An X.400 MTA A, which
  355.    serves the organisation organisational unit OU=orgunA within the
  356.    organisation O=org, receives a message for the domain O=org;
  357.    OU=orgunB;. Since MTA B in the same organisation serves all other
  358.    OUs, A will default route the message to B. Suppose that B would use
  359.    the same mechanism: first check if the OU is local and if not,
  360.    default route to A. If OU=orgunC is not served by either A or B, this
  361.    routing set-up will lead to a loop. The decision that a certain OU
  362.    does not exist can only be made if at least one of the MTAs has
  363.    knowledge of all existing OUs under O.
  364.  
  365.    An example of a firewall and two default routes is shown in figure 2.
  366.    It visualises that a firewall is a downstream and a default route is
  367.    an upstream indirection. MTA B and D use default routing; they can
  368.    only route to one other MTA, MTA A.
  369.  
  370.    For more detailed information, please refer to [3], which lists most
  371.    pros and cons of both approaches. Your choice will depend on many
  372.    factors that are specific for your messaging environment.
  373.  
  374. 4.    Routing at user level
  375.  
  376.    Normally a message is routed down to the deepest level domain, and
  377.    then delivered to the recipient per default routing. I.e., every user
  378.    in this domain is considered to have his mailbox uniquely defined
  379.    within this domain on the same MTA, and every user on that MTA can be
  380.    distinguished within this domain. Exceptions can occur when the users
  381.    within a domain have their mailboxes on different MTAs (distributed
  382.    domain), or when several domains exist on the same MTA (shared MTA).
  383.  
  384. 4.1.  Distributed domains
  385.  
  386.    Routing is normally performed down to a certain domain level. Mail to
  387.    all users that are directly registered under this domain is then
  388.    delivered per default routing, i.e., delivered locally. Explicit user
  389.    routing (i.e., rule-based routing on user level attributes according
  390.    to a fixed table listing all users) may be necessary when not all
  391.  
  392.  
  393.  
  394. Houttuin                                                        [Page 7]
  395.  
  396. RFC 1711           Classifications in E-mail Routing        October 1994
  397.  
  398.  
  399.    users have their UAs connected to the same MTA.
  400.  
  401.    Note that the whole issue of distributed domains is nothing more than
  402.    a special case of the problems discussed in chapter 3.2: 'Default
  403.    versus rule-based'. The only reason for mentioning this in a separate
  404.    chapter is that there are many software products that don't deal with
  405.    routing based on local address parts in the same way as with routing
  406.    based on domain related address parts.
  407.  
  408.    As an example, consider an organisation where two mail platforms are
  409.    available. Some users prefer using platform A, others prefer platform
  410.    B. Of course, the easiest solution would be to create a subdomain A
  411.    and a subdomain B, and then route domain A to system A and B to B.
  412.    Default user routing on both platforms would then do the rest.
  413.    However, when an organisation wants to present itself to the outside
  414.    world using only one domain, this scheme cannot be used, at least not
  415.    without special precautions (see the paragraph about avoiding loops
  416.    in chapter 3.2).
  417.  
  418.      +----------+      +---------------------------+
  419.      |   MTA A  |      |        Shared MTA B       |
  420.      +----------+      +---------------------------+
  421.         |     |         /        |     |        |
  422.      +-----------------/----+ +-----------+  +----------+
  423.      |  |     |       /     | |  |     |  |  |  |       |
  424.      | +--+ +--+ +--+/      | | +--+ +--+ |  | +--+     |
  425.      | |UA| |UA| |UA|       | | |UA| |UA| |  | |UA|     |
  426.      | +--+ +--+ +--+       | | +--+ +--+ |  | +--+     |
  427.      | Distributed Domain A | | Domain B  |  | Domain C |
  428.      +----------------------+ +-----------+  +----------+
  429.  
  430.    Figure 3. Distributed domains and shared MTAs
  431.  
  432.    Another possibility to have uniform addresses in outgoing e-mail,
  433.    despite the fact that a domain is distributed, is to make routing
  434.    decisions on information in the local part of the address, e.g., in
  435.    X.400 the Surname in exactly the same manner as making routing
  436.    decisions on any other attributes. Thus products and routing
  437.    algorithms that are able to route on user related address parts are
  438.    said to support distributed domains.
  439.  
  440. 4.2.  Shared MTA
  441.  
  442.    The opposite of a distributed domain is a shared MTA: several domains
  443.    are routed locally on the same MTA. These domains sharing one MTA may
  444.    cause problems when two or more domains have a local user with the
  445.    same name.
  446.  
  447.  
  448.  
  449.  
  450. Houttuin                                                        [Page 8]
  451.  
  452. RFC 1711           Classifications in E-mail Routing        October 1994
  453.  
  454.  
  455.    Theoretically, this problem doesn't exist: the address is being
  456.    routed down to the deepest domain level, and within that level, there
  457.    will only be one user with that name (let's at least assume this for
  458.    simplicity). Some products however use only one database of all users
  459.    locally connected to this MTA instead of one database per domain, so
  460.    that default user routing at the deepest level can lead to conflicts.
  461.    It is beyond the scope of this document to describe the tricks needed
  462.    to avoid these conflicts when using such products.
  463.  
  464. 5.    Routing control
  465.  
  466.    Routing control means that routing decisions can be affected by the
  467.    originator of a message. This normally takes the form of either
  468.    granting or denying access for a certain user or group of users.
  469.  
  470.    Routing control is often useful in an X.400 ADMD/PRMD environment,
  471.    where it is either used to grant access only to users who are known
  472.    to be chargeable, or where ADMDs can refuse messages that were
  473.    relayed to them over international PRMD connections; a policy that is
  474.    not allowed in the CCITT version of the standards (as opposed to the
  475.    ISO version). Of course, the PRMDs can also perform routing control
  476.    themselves in order to circumvent such problems.
  477.  
  478.    Although there may be good reasons for using routing control, one
  479.    must be aware that it can make the messaging environment
  480.    unpredictable for end-users. Where using routing control is
  481.    unavoidable, the originator whose message has been rejected is likely
  482.    to appreciate receiving a message, clearly telling him where and why
  483.    routing of his message was refused, whom to contact, and what options
  484.    are available to avoid such rejections in the future.
  485.  
  486. 6.    Bulk routing
  487.  
  488.    In order to reduce network traffic, intelligent mailers may prefer a
  489.    message addressed to a group of remote users to be transferred to a
  490.    remote domain only once, thus postponing the 'explosion' into several
  491.    copies. This technique, called bulk routing, is especially useful
  492.    when an MTA hosts large mailing lists.
  493.  
  494.    Several possibilities exist. In a typical hierarchical firewall mail
  495.    system, bulk routing can be done almost automatically by intelligent
  496.    MTAs. For instance, in an X.400 community, a large international
  497.    distribution list can create a message with an envelope containing
  498.    1000 recipient addresses, some of which can probably be grouped by
  499.    the MTA depending on whether they can be routed further to the same
  500.    remote MTA, according to the normal routing implementation at this
  501.    MTA. The size and number of these groups will largely depend on how
  502.    indirect this routing implementation is. In the GO-MHS community, the
  503.  
  504.  
  505.  
  506. Houttuin                                                        [Page 9]
  507.  
  508. RFC 1711           Classifications in E-mail Routing        October 1994
  509.  
  510.  
  511.    number of groups will almost always be less than 50, which provides a
  512.    rather fair distribution of traffic load over the involved MTAs (that
  513.    is, fair according to the author's taste, who is not aware of any
  514.    existing fair mail load distribution formula).
  515.  
  516.    As an extreme example, the simplest way to automatically (i.e.,
  517.    without using special optimisation tools) bulk route mail is to use
  518.    one default route. Any outgoing message, regardless of the number of
  519.    recipients, will be routed over the default route only once. The
  520.    default remote MTA will then have to break up the message (envelope)
  521.    into several copies and is thus responsible for the actual explosion
  522.    and distribution. NB. This mechanism can be exploited to shift the
  523.    cost and overhead of exploding a message towards another domain/MTA.
  524.    If you ever get a request for a bilateral default route agreement;
  525.    i.e., the requesting party wants to default route over your MTA, it
  526.    may be worth to check first if the requesting party is running or
  527.    planning to run large mailing lists.
  528.  
  529.    In more direct routing environments, such as BITNET, bulk routing
  530.    will not function as automatically as described above. Without
  531.    special precautions, an MTA would open a direct connection to every
  532.    single host that occurs in the message's envelope, regardless of
  533.    whether some of these hosts are far away from this MTA, but close to
  534.    each other, measured by underlying network topology. This can clearly
  535.    lead to a waste of expensive bandwidth. In order to be able to detect
  536.    such cases, and to act upon it by sending one single copy over an
  537.    expensive link and have it distributed at some remote hosts, an MTA
  538.    must have additional knowledge of the relation between mail domains
  539.    and the underlying network topology.
  540.  
  541.    BITNET uses the distribute protocol [4] for this purpose. A selected
  542.    set of hosts is published to have the required topology knowledge and
  543.    to be able to efficiently distribute the mail on behalf of other
  544.    MTAs, who can explicitly route all bulk mail to one of those hosts.
  545.    The complete message, including the envelope, is encoded in a message
  546.    body, which starts with a distribution request to the distribute
  547.    server. This server will break up the rest of the body into the
  548.    original envelope and contents and then use it's topology knowledge
  549.    to efficiently distribute the original message. Note that this
  550.    protocol violates the conceptual model of the layering of MTA and UA
  551.    functionality, but it is about the only trick that will work in a
  552.    very direct routing environment. It is only needed to overrule a non-
  553.    efficient (for large mailing lists) routing topology.
  554.  
  555.    Bulk routing is an area where mail routing issues start to overlap
  556.    with the area of distributing netnews (bulletin board services).
  557.    Several organisations, such as ISO, RARE and the IETF have started
  558.    initiatives in the direction of harmonising the two worlds. The first
  559.  
  560.  
  561.  
  562. Houttuin                                                       [Page 10]
  563.  
  564. RFC 1711           Classifications in E-mail Routing        October 1994
  565.  
  566.  
  567.    results, be it standards or products, are not expected before 1995
  568.    though.
  569.  
  570. 7.    Source routing
  571.  
  572.    Source routing was originally intended to allow a user to force a
  573.    message to take a certain route. The mechanism works as follows: the
  574.    MTA that the user wants the message to be routed through is
  575.    integrated into the address. Once the message has arrived at the
  576.    specified MTA, that MTA strips itself from the source-routed address
  577.    and routes the remaining address in the usual way. This mechanism is
  578.    called explicit source routing and can be useful if a user wants to
  579.    test a routing path or force a message to be routed over a faster,
  580.    cheaper, more reliable, or otherwise preferred path.
  581.  
  582.    For instance, if the Internet user user@uni-a.edu wants to test the
  583.    mail connections to and from a remote domain uni-b.edu, he might
  584.    source route a message to himself over the MTA at uni-b.edu by
  585.    addressing the mail to:  @uni-b.edu:user@uni-a.edu
  586.  
  587.    Source routing need not always be explicit. Source routes can also be
  588.    generated automatically by a gateway, in which case we speak of
  589.    address rooting (to that gateway). The gateway will root itself to
  590.    the message by putting its own domain in the source route mapped
  591.    address, thus ensuring that any replies to the gatewayed message will
  592.    be routed back through the same gateway.
  593.  
  594.    Example 1: RFC 1327 left hand side encoding (see [5]) performed by
  595.    the gateway 'gw.ch':
  596.  
  597.         C=zz;A=a;P=p;O=oo;S=plork ->
  598.         "/C=zz/A=a/P=p/O=oo/S=plork/"@gw.ch
  599.  
  600.    Example 2: RFC 1327 DDA mapping (see [5]) performed by the gateway
  601.    C=zz;A=a;
  602.  
  603.         bush@dole.us ->
  604.         DD.RFC-822=bush(a)dole.us;C=zz;A=a;
  605.  
  606.    Example 3: the so-called %-hack:
  607.  
  608.         user%final.domain@1st.relay
  609.  
  610.    When the relaying host '1st.relay' receives the message, it strips
  611.    its own domain part and interprets the localpart 'user%final.domain':
  612.    it changes the % to an @ sign and relays the message to the address
  613.  
  614.         user@final.domain
  615.  
  616.  
  617.  
  618. Houttuin                                                       [Page 11]
  619.  
  620. RFC 1711           Classifications in E-mail Routing        October 1994
  621.  
  622.  
  623.  
  624.    Example 4: Another example of the already mentioned explicit source
  625.    routing, this time through two relays:
  626.  
  627.         @1st.relay,@2nd.relay:user@final.domain
  628.  
  629.    In the Internet, use of explicit source routing is strongly
  630.    discouraged (see [6]), one reason being that not all mail relays will
  631.    handle such addresses in a consistent manner. Apart from that, the
  632.    need to use explicit source routing has disappeared over the last
  633.    decennia. In earlier days, when the RFC 822 world consisted of many
  634.    sparsely connected 'mail islands', source routing was sometimes
  635.    needed to make sure that a message was routed through a gateway that
  636.    was known to be connected to a remote island. Nowadays, the RFC 822
  637.    world is almost fully interconnected through the Internet, so the
  638.    need for end-users to have knowledge of the mail network's topology
  639.    has become superfluous.
  640.  
  641. 8.    Poor man's routing
  642.  
  643.    If we combine static, indirect and source routing, we get what is
  644.    commonly known as "poor man's routing". The user thus specifies the
  645.    complete route in the address. A classic example is the old UUCP bang
  646.    style addressing:
  647.  
  648.         host1!host2!host3!host4!user
  649.  
  650.    Poor man's routing is presented here for historical reasons only.
  651.    Since, for reasons discussed earlier, most present networks
  652.    discourage source routing and prefer dynamic over static routing,
  653.    poor man's routing is not widely deployed anymore.
  654.  
  655. 9.    Routing communities
  656.  
  657.    A routing community can be defined as follows:
  658.  
  659.        Routing community:     a set of MTAs X, with the property
  660.                               that for any address a, every MTA
  661.                               in X except a subset Ya will have
  662.                               the option, according to an agreed
  663.                               upon set of routing rules, to
  664.                               directly route that address to at
  665.                               least one MTA in Ya.
  666.  
  667.    Which is a rather formal way of describing that a routing community
  668.    consists of a set of MTAs (and human operators) that agreed on a
  669.    common set of rules on how to route messages among each other.
  670.  
  671.  
  672.  
  673.  
  674. Houttuin                                                       [Page 12]
  675.  
  676. RFC 1711           Classifications in E-mail Routing        October 1994
  677.  
  678.  
  679.    An example of a routing community is the large Internet routing
  680.    community, in which the agreed rules are implemented in the Domain
  681.    Name System (DNS). For details, refer to [7]. The subset Ya is in
  682.    this case the set of MTAs that have an MX record in the DNS for a.
  683.    MTAs that hide behind fire walls or behind default routes are thus
  684.    not considered direct members of this community, but normally form
  685.    their own smaller routing community, with one host (the mail
  686.    exchanger/default route) belonging to both communities.
  687.  
  688.    Another example is the GO-MHS community, consisting of a set of
  689.    documented RELAY-MTAs (formerly called WEPs, Well-known Entry
  690.    Points). Routing communities can be further classified depending on
  691.    the openness and topology of their routing rules. [3] defines four
  692.    classes of routing communities:
  693.  
  694.        Local community:       The scope of a single MTA. Contains
  695.                               the MTAs view of the set of
  696.                               bilateral routing agreements, and
  697.                               routing information local to the
  698.                               MTA. Example: any local MTA.
  699.  
  700.        Closed community:      This is like a local community, but
  701.                               involves more than one MTA. The
  702.                               idea is to route messages only
  703.                               within this closed community. A
  704.                               small subset of the involved MTAs
  705.                               can be in another community as
  706.                               well, in order to get the
  707.                               connectivity to the outside world,
  708.                               as described earlier. Example: A
  709.                               set of Private Management Domains
  710.                               (PRMDs) representing the same
  711.                               organisation in multiple countries.
  712.  
  713.        Open community:        All routing information is public
  714.                               and any MTA is invited to use it.
  715.                               Example: the Internet.
  716.  
  717.        Hierarchical community:A subtree of the O/R address tree.
  718.                               Note that the subtree will in
  719.                               practice often be pruned; sub-sub-
  720.                               trees may form their own routing
  721.                               community. Example: GO-MHS.
  722.  
  723.    This classification cannot always be followed too strictly. For
  724.    example, completely closed communities are relatively rare. In order
  725.    for e-mail to be an effective communication tool, an organisation
  726.    will typically designate at least one of its MTAs as a gateway to
  727.  
  728.  
  729.  
  730. Houttuin                                                       [Page 13]
  731.  
  732. RFC 1711           Classifications in E-mail Routing        October 1994
  733.  
  734.  
  735.    another routing community, for instance to the Internet. The
  736.    organisation will register an Internet domain, say 'org.net', which
  737.    points to this gateway, and thus acts as a firewall from the Internet
  738.    to the domain 'org.net', and as a default route from the closed
  739.    community to the rest of the Internet. At this stage, the gateway MTA
  740.    can be regarded as being a member of any of the four types of routing
  741.    communities. The reader is invited to check this himself.
  742.  
  743.    Especially the distinction between open and closed communities is not
  744.    always easy. To some extent, most routing communities are open, at
  745.    least among their own participants. It is just that some routing
  746.    communities are more open than others. Also, even the most open
  747.    routing community is not just open to anyone. It is not enough for a
  748.    community participant to use the community's routing rules and
  749.    connect to any other MTA in the community. The participant will
  750.    typically also have to fulfil an agreed upon set of operational
  751.    requirements, for example the Internet host requirements [6] or the
  752.    GO-MHS domain requirements [8].
  753.  
  754.    The most open routing community known today is certainly the Internet
  755.    mail community. As for X.400 routing communities, some problems occur
  756.    when trying to open a community, the main one being that most X.400
  757.    software does not support the so called 'anonymous' connection mode,
  758.    which allows any remote MTA to connect to it. Most software was
  759.    designed or configured to use passwords for setting up MTA
  760.    connections. This, together with the fact that X.400 routing was
  761.    originally designed to be hierarchical, is one of the main reasons
  762.    why most X.400 communities today are either closed or hierarchical.
  763.  
  764. 10.   Realisations
  765.  
  766.    In this chapter some of the routing classifications described above
  767.    are assigned to existing mail services and projects.
  768.  
  769. 10.1. Internet mail
  770.  
  771.    RFC 822 mail. An operational service. Co-ordination: distributed.
  772.    Mostly dynamic routing, although static routing is also possible. DNS
  773.    based routing rules(*). Mostly direct routing, although indirect is
  774.    also possible. No dynamic stack routing. Distributed domains
  775.    possible. Shared MTAs possible, but rare. Routing control not
  776.    normally used. Bulk routing via SMTP envelope grouping; also
  777.    possible, but not widely deployed, using the 'distribute protocol'
  778.    [4]. Source routing supported, but strongly discouraged. No poor
  779.    man's routing. Open (and hierarchical) routing community.
  780.  
  781.    (*) Sub-communities don't use DNS based routing: The MX records in
  782.    the DNS are used to "attract" messages from the Internet to the
  783.  
  784.  
  785.  
  786. Houttuin                                                       [Page 14]
  787.  
  788. RFC 1711           Classifications in E-mail Routing        October 1994
  789.  
  790.  
  791.    "border" between the Internet and the sub-community. Thus from the
  792.    Internet we have dynamic, directory based routing but once the
  793.    "border" is reached, it is no longer possible to use MX records for
  794.    mail routing, and thus some form of static routing is generally
  795.    needed.
  796.  
  797. 10.2. UUCP
  798.  
  799.    RFC 822 style mail. An operational service. Co-ordination:
  800.    distributed. Mostly static routing, although dynamic routing is also
  801.    possible. Table based routing rules. Mostly indirect routing. No
  802.    dynamic stack routing. No distributed domains. Shared MTAs possible,
  803.    but rare. Routing control not normally used. No bulk routing
  804.    possible. Source routing (poor man's routing) still widely used by
  805.    means of 'bang' addressing, but strongly discouraged. Open (and
  806.    hierarchical) routing community.
  807.  
  808. 10.3. EARN
  809.  
  810.    BITNET mail. An operational service. Co-ordination: The EARN Office,
  811.    France. Static routing. Table based routing rules, although an X.500
  812.    based experiment is running. Mostly direct routing, although indirect
  813.    is also possible. No dynamic stack routing. No distributed domains.
  814.    No shared MTAs. Routing control not normally used. Bulk routing
  815.    possible using the 'distribute protocol' [4]. Source routing not
  816.    supported. No poor man's routing. Open routing community.
  817.  
  818. 10.4. GO-MHS
  819.  
  820.    X.400 mail. An operational service. Co-ordination: GO-MHS Project
  821.    Team, Switzerland. Mostly static routing, although dynamic routing is
  822.    getting more and more deployed since the introduction of RFC 1465
  823.    [2]. Table based community-wide routing rules. Indirect routing.
  824.  
  825.    Dynamic stack routing. Distributed domains possible. Shared MTAs.
  826.    Routing control not normally used, only to avoid routing control
  827.    problems when routing international traffic to ADMDs. Bulk routing
  828.    using X.400 'responsibility' envelope flags. Source routing supported
  829.    for gatewaying to the Internet. No poor man's routing. Hierarchical,
  830.    but open, routing community.
  831.  
  832. 10.5. ADMD infrastructure
  833.  
  834.    X.400 mail. An operational service. Co-ordination: The joint
  835.    Administrative Management Domains (ADMDs), typically operated by
  836.    PTTs. Mostly static routing. Indirect routing. Table based bilateral
  837.    routing rules. No dynamic stack routing. Distributed domains not
  838.    supported. Shared MTAs. Routing control used to prohibit routing of
  839.  
  840.  
  841.  
  842. Houttuin                                                       [Page 15]
  843.  
  844. RFC 1711           Classifications in E-mail Routing        October 1994
  845.  
  846.  
  847.    international traffic through PRMDs and to limit access to certain
  848.    gateways. Bulk routing using X.400 'responsibility' envelope flags.
  849.    Source routing possible for gatewaying to the Internet. No poor man's
  850.    routing. Closed hierarchical routing community.
  851.  
  852. 10.6. Long Bud
  853.  
  854.    X.400 mail. A pilot project. Co-ordination: The IETF MHS-DS working
  855.    group. Dynamic routing. X.500 based routing rules. Mostly indirect
  856.    routing, although direct is also possible. Dynamic stack routing.
  857.    Distributed domains. Shared MTAs. No routing control. Bulk routing
  858.    using X.400 'responsibility' envelope flags. Source routing supported
  859.    for gatewaying to the Internet. No poor man's routing. Open
  860.    hierarchical routing community.
  861.  
  862. 10.7. X42D
  863.  
  864.    X.400 mail. An experiment. Co-ordination: INFN, Italy. Dynamic
  865.    routing. DNS based routing rules as defined in [9]. Mostly indirect
  866.    routing, although direct is also possible. Dynamic stack routing. No
  867.    distributed domains. Shared MTAs. No routing control. Bulk routing
  868.    using X.400 'responsibility' envelope flags. Source routing supported
  869.    for gatewaying to the Internet. No poor man's routing. Open
  870.    hierarchical routing community.
  871.  
  872. 11.   Conclusion
  873.  
  874.    We have seen several dimensions in which mail routing can be
  875.    classified. There are many more issues that were not discussed here,
  876.    such as how exactly the routing databases are implemented, which
  877.    algorithms to use for making the actual choices in dynamic routing,
  878.    etc. A follow-up paper is planned to discuss such aspects in more
  879.    detail.
  880.  
  881.    So far, the author has tried to keep this paper free of opinion, but
  882.    he would like to conclude by listing his own favourite routing
  883.    options (without any further explanation or justification; please
  884.    feel free to disagree):
  885.  
  886.        Static/dynamic:        Dynamic
  887.        Direct/indirect:       Every routing community has its own
  888.                               optimum level of indirection
  889.        User routing:          Support
  890.        Routing control:       Avoid
  891.        Bulk routing:          Efficient distribution should be
  892.                               transparent at mail level, but we
  893.                               may need better e-mail models
  894.                               before this becomes possible
  895.  
  896.  
  897.  
  898. Houttuin                                                       [Page 16]
  899.  
  900. RFC 1711           Classifications in E-mail Routing        October 1994
  901.  
  902.  
  903.        Source routing:        Avoid where possible
  904.        Poor man's routing:    Avoid
  905.  
  906. 12.   Abbreviations
  907.  
  908.     ADMD              Administration Management Domain
  909.     CCITT             Comite Consultatif International de
  910.                        Telegraphique et Telephonique
  911.     CONS              Connection Oriented Network Service
  912.     DDA               Domain Defined Attribute
  913.     DNS               Domain Name System
  914.     GO-MHS            Global Open MHS
  915.     IP                Internet Protocol
  916.     ISO               International Organisation for Standardisation
  917.     Long Bud          Not an abbreviation
  918.     MHS               Message Handling System
  919.     MHS-DS            MHS and Directory Services
  920.     MTA               Message Transfer Agent
  921.     MTS               Message Transfer System
  922.     MX                Mail eXchanger
  923.     O/R address       Originator/Recipient address
  924.     PP                Not an abbreviation
  925.     PRMD              Private Management Domain
  926.     RARE              Reseaux Associes pour la Recherche Europeenne
  927.     RFC               Internet Request for Comments
  928.     RTR               RARE Technical Report
  929.     SMTP              Simple Mail Transfer Protocol
  930.     STD               Internet Standard RFC
  931.     TCP               Transfer Control Protocol
  932.     TP0               Transport Protocol Class 0
  933.     UA                User Agent
  934.     UUCP              UNIX to UNIX CoPy
  935.     WEP               Well-known Entry Point
  936.  
  937. 13.   References
  938.  
  939.       [1]         Houttuin, J., "C-BoMBS : A Classification of Breeds
  940.                   Of Mail Based Servers", RARE WG-MSG Work in Progress,
  941.                   April 1994.
  942.  
  943.       [2]         Eppenberger, E., "Routing Coordination for X.400 MHS
  944.                   Services Within a Multi Protocol / Multi Network
  945.                   Environment Table Format V3 for Static Routing",
  946.                   RFC 1465, SWITCH, May 1993.
  947.  
  948.       [3]         Kille, S., "MHS use of the Directory to support MHS
  949.                   routing", Work in Progress, July 1993.
  950.  
  951.  
  952.  
  953.  
  954. Houttuin                                                       [Page 17]
  955.  
  956. RFC 1711           Classifications in E-mail Routing        October 1994
  957.  
  958.  
  959.       [4]         Thomas, E., "Listserv Distribute Protocol",
  960.                   RFC 1429, Swedish University Network, February 1993.
  961.  
  962.       [5]         Kille, S., "Mapping between X.400(1988) / ISO 10021
  963.                   and RFC 822", RFC 1327, RARE RTR 2, University
  964.                   College London, May 1992.
  965.  
  966.       [6]         Braden, R., Editor, "Requirements for Internet Hosts
  967.                   - Application and Support", STD 3, RFC 1123, USC/
  968.                   Information Sciences Institute,  October 1989.
  969.  
  970.       [7]         Partridge, C., "Mail Routing and the Domain System",
  971.                   STD 14, RFC 974, BBN, January 1986.
  972.  
  973.       [8]         Hansen, A. and R. Hagens, "Operational Requirements
  974.                   for X.400 Management Domains in the GO-MHS
  975.                   Community", Work in Progress, March 1993.
  976.  
  977.       [9]         Allocchio, C., Bonito, A., Cole, B., Giordano, S.,
  978.                   and R. Hagens "Using the Internet DNS to Distribute
  979.                   RFC1327 Mail Address Mapping Tables", RFC 1664,
  980.                   GARR-Italy, Cisco Systems Inc, Centro Svizzero
  981.                   Calcolo Scientific, Advanced Network & Services,
  982.                   February 1993.
  983.  
  984.       [10]        Houttuin, J., "A Tutorial on Gatewaying between X.400
  985.                   and Internet Mail", RFC 1506, RTR 6, RARE Secretariat,
  986.                   August 1993.
  987.  
  988.       [11]        Postel, J., "Simple Mail Transfer Protocol", STD 10,
  989.                   RFC 821, USC/Information Sciences Institute, August
  990.                   1982.
  991.  
  992.       [12]        Crocker, D., "Standard for the Format of ARPA
  993.                   Internet Text Messages", STD 11, RFC 822, UDEL,
  994.                   August 1982.
  995.  
  996.       [13]        Alvestrand, H.T., et al, "Introducing Project Long
  997.                   Bud Internet Pilot Project for the Deployment of
  998.                   X.500 Directory Information in Support of X.400
  999.                   Routing", Work in Progress, June 1993.
  1000.  
  1001.       [14]        Kille, S., "A Simple Profile for MHS use of
  1002.                   Directory", Work in Progress, July 1993.
  1003.  
  1004.       [15]        Kille, S., "MHS use of the Directory to Support
  1005.                   Distribution Lists", Work in Progress, November 1992.
  1006.  
  1007.  
  1008.  
  1009.  
  1010. Houttuin                                                       [Page 18]
  1011.  
  1012. RFC 1711           Classifications in E-mail Routing        October 1994
  1013.  
  1014.  
  1015.       [16]        Eppenberger, U., "X.500 directory service usage for
  1016.                   X.400 e-mail", Computer Networks for Research in
  1017.                   Europe No.1: Computer Networks and ISDN Systems 25,
  1018.                   Suppl.1 (1993) S3-8, September 1993.
  1019.  
  1020.       [17]        CCITT Recommendations X.400 - X.430. Data
  1021.                   Communication Networks: Message Handling Systems.
  1022.                   CCITT Red Book, Vol. VIII - Fasc. VIII.7, Malaga-
  1023.                   Torremolinos 1984.
  1024.  
  1025.       [18]        CCITT Recommendations X.400 - X.420. Data
  1026.                   Communication Networks: Message Handling Systems.
  1027.                   CCITT Blue Book, Vol. VIII - Fasc. VIII.7, Melbourne
  1028.                   1988.
  1029.  
  1030. 14.   Security Considerations
  1031.  
  1032.    Security issues are discussed in section 3.1.
  1033.  
  1034. 15.   Author's Address
  1035.  
  1036.    Jeroen Houttuin
  1037.    RARE Secretariat
  1038.    Singel 466-468
  1039.    NL-1017 AW Amsterdam
  1040.    The Netherlands
  1041.  
  1042.    Phone: +31 20 639 11 31
  1043.    Fax:  +31 20 639 32 89
  1044.    EMail: houttuin@rare.nl
  1045.  
  1046.  
  1047.  
  1048.  
  1049.  
  1050.  
  1051.  
  1052.  
  1053.  
  1054.  
  1055.  
  1056.  
  1057.  
  1058.  
  1059.  
  1060.  
  1061.  
  1062.  
  1063.  
  1064.  
  1065.  
  1066. Houttuin                                                       [Page 19]
  1067.  
  1068.