rfc1711.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                        J. Houttuin
Request for Comments: 1711                                          RARE
Category: Informational                                     October 1994


                   Classifications in E-mail Routing

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Abstract

   This paper presents a classification for e-mail routing issues. It
   clearly defines commonly used terminology such as static routing,
   store-and-forward routing, source routing and others. Real life
   examples show which routing options are used in existing projects.

   The goal is to define all terminology in one reference paper. This
   will also help relatively new mail system managers to understand the
   issues and make the right choices. The reader is expected to already
   have a solid understanding of general networking terminology.

   In this paper, the word Message Transfer Agent (MTA) is used to
   describe a routing entity, which can be an X.400 MTA, a UNIX mailer,
   or any other piece of software performing mail routing functions. An
   MTA processes the so called envelope information of a message. The
   term User Agent (UA) is used to describe a piece of software
   performing user related mail functions. It processes the contents of
   a message's envelope, i.e., the header fields and body parts.

Table of Contents

   1.   Naming, addressing and routing                               2
   2.   Static versus dynamic                                        4
   3.   Direct versus indirect                                       5
   3.1.       Firewalls                                              5
   3.2.       Default versus rule based                              6
   4.   Routing at user level                                        7
   4.1.       Distributed domains                                    7
   4.2.       Shared MTA                                             8
   5.   Routing control                                              9
   6.   Bulk routing                                                 9
   7.   Source routing                                              11
   8.   Poor man's routing                                          12
   9.   Routing communities                                         12



Houttuin                                                        [Page 1]

RFC 1711           Classifications in E-mail Routing        October 1994


   10.  Realisations                                                14
   10.1.      Internet mail                                         14
   10.2.      UUCP                                                  15
   10.3.      EARN                                                  15
   10.4.      GO-MHS                                                15
   10.5.      ADMD infrastructure                                   15
   10.6.      Long Bud                                              16
   10.7.      X42D                                                  16
   11.  Conclusion                                                  16
   12.  Abbreviations                                               17
   13.  References                                                  17
   14.  Security Considerations                                     19
   15.  Author's Address                                            19

1.    Naming, addressing and routing

   A name uniquely identifies a network object (without loss of
   generality, we will assume the 'object' is a person).

   Once a person's name is known, it can be used as a key to determine
   his address.

   An address uniquely defines where the person is located. It can
   normally be divided into a domain related part (e.g., the RFC 822
   domainpart or in X.400 an ADMD or OU attribute) and a local or user
   related part (e.g., the RFC 822 localpart or in X.400 a DDA or
   Surname attribute). The domain related part of an address typically
   consists of several components, which normally have a certain
   hierarchical order. These domain levels can be used for routing
   purposes, as we will see later.

   Once a person's address is known, it can be used as a key to
   determine a route to that person's location.

   We will use the following definition of an e-mail route:

       e-mail route           a path between two leaves in a
                              directed Message Transfer System
                              (MTS) graph that a message travels
                              for one originator/recipient pair.
                              (see Figure 1)

   Note that, in this definition, the User Agents (UAs) are not part of
   the route themselves. Thus if a message is redirected at the UA
   level, a new route is established from the redirecting UA to the UA
   the message is redirected to.





Houttuin                                                        [Page 2]

RFC 1711           Classifications in E-mail Routing        October 1994


   The first and last leaves in a mail route are not always UAs. A route
   may start from a UA, but stop at a certain point because one of the
   MTAs is unable to take any further routing decisions. If this
   happens, a warning is generated by the MTA (not by a UA), and sent
   back to the originator of the undeliverable message. It may even
   happen that none of the leaves is a UA, for instance if a warning
   message as discussed above turns out to be undeliverable itself. The
   cautious reader may have noticed that this is a dangerous situation.
   Special precautions are needed to avoid loops in such cases (see
   [1]).

           user                        user
            |                           ^
            v                           |
     +-----------------------------------------+
     |      |                           ^      |
     |      v                           |      |
     |   +-----+                     +-----+   |
     |   | UA  |                     | UA  |   |
     |   +-----+                     +-----+   |
     |      |                           ^      |
     |      v                           |      |
     | +-------------------------------------+ |
     | |    v                           ^    | |
     | |    v                           ^    | |
     | |    v                           ^    | |
     | | +-----+                     +-----+ | |
     | | | MTA |.....................| MTA | | |
     | | +-----+                     +-----+ | |
     | |    v   \                       ^    | |
     | |    v    \................      ^    | |
     | |    v                     \     ^    | | NB The actual route
     | | +-----+                   \ +-----+ | |    is drawn as
     | | | MTA |>>>>>>>>>>>>>>>>>>>>>| MTA | | |    v            ^
     | | +-----+                     +-----+ | |    v            ^
     | | Message Transfer System             | |    v  >>>>>>>>  ^
     | +-------------------------------------+ |
     | Message Handling System                 |
     +-----------------------------------------+

                Figure 1. A mail route

   It is important that the graph is directed, because routes are not
   necessarily symmetric. A reply to a message may be sent over a
   completely different mail route for reasons such as cost, non-
   symmetric network connectivity, network load, etc.





Houttuin                                                        [Page 3]

RFC 1711           Classifications in E-mail Routing        October 1994


   According to the definition, if a message has two different
   recipients, there will also be two mail routes. Since the delivery to
   a UA (not the UA itself) is a part of the route, this definition is
   still valid if two UAs are connected to the same MTA.

   The words '.. for one originator-recipient pair.' in the definition
   do not imply that this pair provides the MTA with all necessary
   information to choose one specific route. One originator-recipient
   pair may give an MTA the possibility to choose from a number of
   possible routes, the so-called routing indicators (see chapter 2).

   Other information (e.g., line load, cost, availability) can then be
   used to choose one route from the routing indicators.

   Routing is defined as the process of establishing routes. Note that
   this is a distributed process; every intermediate MTA takes its own
   routing decisions, thus contributing to the establishment of the
   complete route.

   Taking a routing decision is not a purely algorithmic process,
   otherwise there would hardly be any difference between an address and
   a route. The address is used as a key to find a route, typically in
   some sort of rule-based routing database. The possible options for
   realising this database and algorithms for using it are the subject
   of the rest of this paper.

2.    Static versus dynamic

   Dynamic (mail) routing allows a routing decision to be influenced by
   external factors, such as system availability, network load, etc. In
   contrast, static (mail) routing is not able to adapt to environmental
   constraints. Static routing can be viewed as an extremely simple form
   of dynamic routing, namely where there is only one choice for every
   routing decision.

   Dynamic routing algorithms normally use some kind of distributed
   databases to store and retrieve routing information, whereas static
   routing is typically implemented in routing tables.

   Note that dynamic routing can occur at different layers: at the mail
   level, dynamic routing might allow a message to be relayed to a
   choice of MTAs (the routing indicators). As an example, consider the
   Internet mechanism of using multiple Mail eXchanger (MX) records,
   describing MTAs that can serve a domain. If the primary choice MTA is
   not available, a second choice MTA can be tried. If this second
   choice MTA is busy, a third one will be tried, etc. On lower layers,
   there may be more than one presentation address for one MTA, each of
   which can again have an associated priority and other attributes.



Houttuin                                                        [Page 4]

RFC 1711           Classifications in E-mail Routing        October 1994


   These choices may represent that an MTA prefers to be connected to
   using one certain stack, e.g., RFC1006/TCP/IP, but is also able to
   accept incoming calls over another stack, such as TP0/CONS/X.25. We
   will call this dynamic stack routing. Theoretically, dynamic stack
   routing should be transparent to the mail routing application, and is
   thus not a part of dynamic mail routing. It is mentioned here because
   in existing products, dynamic stack routing is often very well
   visible at the mail configuration level, so MTA managers should at
   least be aware of it.

   Although static routing is often table based, not all table based
   routing algorithms are necessarily static in nature. As a counter
   example, X.400 routing according to RFC 1465 [2] is clearly table
   based, but at the same time allows a fairly dynamic kind of mail
   routing (as well as dynamic stack routing, which in this approach is
   cleanly separated from the dynamic mail routing part). A mail domain
   can specify a choice of so-called RELAY-MTAs (formerly called WEPs)
   that will serve it, each with a priority and maximum number of
   retries.

   For reasons of flexibility and reliability, dynamic routing is almost
   always the preferred method.

3.    Direct versus indirect

   Direct routing allows the originator's MTA to contact the recipient's
   MTA directly, whereas indirect routing (also known as store-and-
   forward routing) uses intermediate MTAs to relay the message towards
   the recipient. It is difficult to clearly distinguish between direct
   and indirect routing: direct routing assumes the existence of a fully
   meshed routing topology, whereas indirect routing assumes the
   existence of a more tree-like hierarchical topology. Mail routing in
   most existing networks is upto some degree indirect. Networks can be
   classified as being more or less direct according for the following
   rule of thumb: larger fan out of the routing tree means more direct
   routing, greater depth of the tree means less direct routing. Two
   kinds of indirect routing are presented here: firewalls (downstream)