rfc1711.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,068 行 · 第 1/4 页

   lead to a waste of expensive bandwidth. In order to be able to detect
   such cases, and to act upon it by sending one single copy over an
   expensive link and have it distributed at some remote hosts, an MTA
   must have additional knowledge of the relation between mail domains
   and the underlying network topology.

   BITNET uses the distribute protocol [4] for this purpose. A selected
   set of hosts is published to have the required topology knowledge and
   to be able to efficiently distribute the mail on behalf of other
   MTAs, who can explicitly route all bulk mail to one of those hosts.
   The complete message, including the envelope, is encoded in a message
   body, which starts with a distribution request to the distribute
   server. This server will break up the rest of the body into the
   original envelope and contents and then use it's topology knowledge
   to efficiently distribute the original message. Note that this
   protocol violates the conceptual model of the layering of MTA and UA
   functionality, but it is about the only trick that will work in a
   very direct routing environment. It is only needed to overrule a non-
   efficient (for large mailing lists) routing topology.

   Bulk routing is an area where mail routing issues start to overlap
   with the area of distributing netnews (bulletin board services).
   Several organisations, such as ISO, RARE and the IETF have started
   initiatives in the direction of harmonising the two worlds. The first



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


   results, be it standards or products, are not expected before 1995
   though.

7.    Source routing

   Source routing was originally intended to allow a user to force a
   message to take a certain route. The mechanism works as follows: the
   MTA that the user wants the message to be routed through is
   integrated into the address. Once the message has arrived at the
   specified MTA, that MTA strips itself from the source-routed address
   and routes the remaining address in the usual way. This mechanism is
   called explicit source routing and can be useful if a user wants to
   test a routing path or force a message to be routed over a faster,
   cheaper, more reliable, or otherwise preferred path.

   For instance, if the Internet user [e-mail] wants to test the
   mail connections to and from a remote domain uni-b.edu, he might
   source route a message to himself over the MTA at uni-b.edu by
   addressing the mail to:  @uni-b.edu:[e-mail]

   Source routing need not always be explicit. Source routes can also be
   generated automatically by a gateway, in which case we speak of
   address rooting (to that gateway). The gateway will root itself to
   the message by putting its own domain in the source route mapped
   address, thus ensuring that any replies to the gatewayed message will
   be routed back through the same gateway.

   Example 1: RFC 1327 left hand side encoding (see [5]) performed by
   the gateway 'gw.ch':

        C=zz;A=a;P=p;O=oo;S=plork ->
        "/C=zz/A=a/P=p/O=oo/S=plork/"@gw.ch

   Example 2: RFC 1327 DDA mapping (see [5]) performed by the gateway
   C=zz;A=a;

        [e-mail] ->
        DD.RFC-822=bush(a)dole.us;C=zz;A=a;

   Example 3: the so-called %-hack:

        [e-mail]

   When the relaying host '1st.relay' receives the message, it strips
   its own domain part and interprets the localpart 'user%final.domain':
   it changes the % to an @ sign and relays the message to the address

        [e-mail]



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



   Example 4: Another example of the already mentioned explicit source
   routing, this time through two relays:

        @1st.relay,@2nd.relay:[e-mail]

   In the Internet, use of explicit source routing is strongly
   discouraged (see [6]), one reason being that not all mail relays will
   handle such addresses in a consistent manner. Apart from that, the
   need to use explicit source routing has disappeared over the last
   decennia. In earlier days, when the RFC 822 world consisted of many
   sparsely connected 'mail islands', source routing was sometimes
   needed to make sure that a message was routed through a gateway that
   was known to be connected to a remote island. Nowadays, the RFC 822
   world is almost fully interconnected through the Internet, so the
   need for end-users to have knowledge of the mail network's topology
   has become superfluous.

8.    Poor man's routing

   If we combine static, indirect and source routing, we get what is
   commonly known as "poor man's routing". The user thus specifies the
   complete route in the address. A classic example is the old UUCP bang
   style addressing:

        host1!host2!host3!host4!user

   Poor man's routing is presented here for historical reasons only.
   Since, for reasons discussed earlier, most present networks
   discourage source routing and prefer dynamic over static routing,
   poor man's routing is not widely deployed anymore.

9.    Routing communities

   A routing community can be defined as follows:

       Routing community:     a set of MTAs X, with the property
                              that for any address a, every MTA
                              in X except a subset Ya will have
                              the option, according to an agreed
                              upon set of routing rules, to
                              directly route that address to at
                              least one MTA in Ya.

   Which is a rather formal way of describing that a routing community
   consists of a set of MTAs (and human operators) that agreed on a
   common set of rules on how to route messages among each other.




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


   An example of a routing community is the large Internet routing
   community, in which the agreed rules are implemented in the Domain
   Name System (DNS). For details, refer to [7]. The subset Ya is in
   this case the set of MTAs that have an MX record in the DNS for a.
   MTAs that hide behind fire walls or behind default routes are thus
   not considered direct members of this community, but normally form
   their own smaller routing community, with one host (the mail
   exchanger/default route) belonging to both communities.

   Another example is the GO-MHS community, consisting of a set of
   documented RELAY-MTAs (formerly called WEPs, Well-known Entry
   Points). Routing communities can be further classified depending on
   the openness and topology of their routing rules. [3] defines four
   classes of routing communities:

       Local community:       The scope of a single MTA. Contains
                              the MTAs view of the set of
                              bilateral routing agreements, and
                              routing information local to the
                              MTA. Example: any local MTA.

       Closed community:      This is like a local community, but
                              involves more than one MTA. The
                              idea is to route messages only
                              within this closed community. A
                              small subset of the involved MTAs
                              can be in another community as
                              well, in order to get the
                              connectivity to the outside world,
                              as described earlier. Example: A
                              set of Private Management Domains
                              (PRMDs) representing the same
                              organisation in multiple countries.

       Open community:        All routing information is public
                              and any MTA is invited to use it.
                              Example: the Internet.

       Hierarchical community:A subtree of the O/R address tree.
                              Note that the subtree will in
                              practice often be pruned; sub-sub-
                              trees may form their own routing
                              community. Example: GO-MHS.

   This classification cannot always be followed too strictly. For
   example, completely closed communities are relatively rare. In order
   for e-mail to be an effective communication tool, an organisation
   will typically designate at least one of its MTAs as a gateway to



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


   another routing community, for instance to the Internet. The
   organisation will register an Internet domain, say 'org.net', which
   points to this gateway, and thus acts as a firewall from the Internet
   to the domain 'org.net', and as a default route from the closed
   community to the rest of the Internet. At this stage, the gateway MTA
   can be regarded as being a member of any of the four types of routing
   communities. The reader is invited to check this himself.

   Especially the distinction between open and closed communities is not
   always easy. To some extent, most routing communities are open, at
   least among their own participants. It is just that some routing
   communities are more open than others. Also, even the most open
   routing community is not just open to anyone. It is not enough for a
   community participant to use the community's routing rules and
   connect to any other MTA in the community. The participant will
   typically also have to fulfil an agreed upon set of operational
   requirements, for example the Internet host requirements [6] or the
   GO-MHS domain requirements [8].

   The most open routing community known today is certainly the Internet
   mail community. As for X.400 routing communities, some problems occur
   when trying to open a community, the main one being that most X.400
   software does not support the so called 'anonymous' connection mode,
   which allows any remote MTA to connect to it. Most software was
   designed or configured to use passwords for setting up MTA
   connections. This, together with the fact that X.400 routing was
   originally designed to be hierarchical, is one of the main reasons
   why most X.400 communities today are either closed or hierarchical.

10.   Realisations

   In this chapter some of the routing classifications described above
   are assigned to existing mail services and projects.

10.1. Internet mail

   RFC 822 mail. An operational service. Co-ordination: distributed.
   Mostly dynamic routing, although static routing is also possible. DNS
   based routing rules(*). Mostly direct routing, although indirect is
   also possible. No dynamic stack routing. Distributed domains
   possible. Shared MTAs possible, but rare. Routing control not
   normally used. Bulk routing via SMTP envelope grouping; also
   possible, but not widely deployed, using the 'distribute protocol'
   [4]. Source routing supported, but strongly discouraged. No poor
   man's routing. Open (and hierarchical) routing community.

   (*) Sub-communities don't use DNS based routing: The MX records in
   the DNS are used to "attract" messages from the Internet to the



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


   "border" between the Internet and the sub-community. Thus from the
   Internet we have dynamic, directory based routing but once the
   "border" is reached, it is no longer possible to use MX records for
   mail routing, and thus some form of static routing is generally
   needed.

10.2. UUCP

   RFC 822 style mail. An operational service. Co-ordination:
   distributed. Mostly static routing, although dynamic routing is also
   possible. Table based routing rules. Mostly indirect routing. No