rfc1711.txt

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

   and default routes (upstream).

3.1.  Firewalls

   A firewall 'attracts' all messages for a certain set of addresses
   (the address sub space behind the firewall) from the outside e-mail
   world to a central relaying MTA (the firewall). This is done by
   publishing routes to all other MTAs that must relay their messages
   over this firewall (the attracted community). Note that local
   knowledge should be used to route messages within the address space
   behind the firewall. An example for this is presented later on. There



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


   exist many reasons for using firewalls, e.g., security considerations
   or to concentrate the management for a given domain onto one well
   managed system.

   The Internet mail system would allow all mail hosts connected to the
   Internet to directly accept mail from any other host, but not all
   hosts use this possibility. Many domains are hidden behind one or
   more 'Mail eXchanger' (MX), which offer to relay all incoming mail
   for those domains. The RELAY-MTAs mentioned earlier can also be
   considered firewall systems.

         +-----------------------------------+
         |                                   |
         | The rest of the e-mail world      |
         |                                   |
         +-----------------------------------+
                     \  |  |   /
                      \ |  |  /
                       \|  | /
                        v  vv
                  +--------------+
                  |Firewall MTA A|
                  +--------------+
                    ^  /  ^  \  ^
                   /  /   |   \  \
                  /  /    |    \  \
  Default route--o  /     |     \  o---Default route
                /  /      |      \  \
               /  /       |       \  \
              /  v        v        v  \
           +-----+     +-----+   +-------+
           |MTA B|<----|MTA C|   |MTA D  |
           +-----+     +-----+   +-------+
            /  |         |         |   \
           /   |         |         |    \
          /    |         |         |     \
       +----+ +----+  +----+   +----+ +----+
       | UA | | UA |  | UA |   | UA | | UA |
       +----+ +----+  +----+   +----+ +----+

        Figure 2. Firewall and default route

3.2.  Default versus rule based

   Default routing is to outgoing mail what a firewall is for incoming
   mail, and is thus often used in conjunction with firewalls. It is
   about the simplest routing algorithm one can think of: route every
   message to one and the same MTA, which is trusted to take further



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


   care of routing the message towards its destination. Pure default
   routing is rather useless; it is normally used as a fall back
   mechanism accompanying a rule based algorithm.

   For example, the simplest usable default algorithm is the following:
   first check if a mail should be delivered to a local UA. If not,
   perform default routing.

   In order to avoid loops, it is not acceptable for all MTAs within a
   certain routing community (see chapter 9) to use default routing. At
   least one MTA should be able to access all routing rules for that
   community. Consider the following example: An X.400 MTA A, which
   serves the organisation organisational unit OU=orgunA within the
   organisation O=org, receives a message for the domain O=org;
   OU=orgunB;. Since MTA B in the same organisation serves all other
   OUs, A will default route the message to B. Suppose that B would use
   the same mechanism: first check if the OU is local and if not,
   default route to A. If OU=orgunC is not served by either A or B, this
   routing set-up will lead to a loop. The decision that a certain OU
   does not exist can only be made if at least one of the MTAs has
   knowledge of all existing OUs under O.

   An example of a firewall and two default routes is shown in figure 2.
   It visualises that a firewall is a downstream and a default route is
   an upstream indirection. MTA B and D use default routing; they can
   only route to one other MTA, MTA A.

   For more detailed information, please refer to [3], which lists most
   pros and cons of both approaches. Your choice will depend on many
   factors that are specific for your messaging environment.

4.    Routing at user level

   Normally a message is routed down to the deepest level domain, and
   then delivered to the recipient per default routing. I.e., every user
   in this domain is considered to have his mailbox uniquely defined
   within this domain on the same MTA, and every user on that MTA can be
   distinguished within this domain. Exceptions can occur when the users
   within a domain have their mailboxes on different MTAs (distributed
   domain), or when several domains exist on the same MTA (shared MTA).

4.1.  Distributed domains

   Routing is normally performed down to a certain domain level. Mail to
   all users that are directly registered under this domain is then
   delivered per default routing, i.e., delivered locally. Explicit user
   routing (i.e., rule-based routing on user level attributes according
   to a fixed table listing all users) may be necessary when not all



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


   users have their UAs connected to the same MTA.

   Note that the whole issue of distributed domains is nothing more than
   a special case of the problems discussed in chapter 3.2: 'Default
   versus rule-based'. The only reason for mentioning this in a separate
   chapter is that there are many software products that don't deal with
   routing based on local address parts in the same way as with routing
   based on domain related address parts.

   As an example, consider an organisation where two mail platforms are
   available. Some users prefer using platform A, others prefer platform
   B. Of course, the easiest solution would be to create a subdomain A
   and a subdomain B, and then route domain A to system A and B to B.
   Default user routing on both platforms would then do the rest.
   However, when an organisation wants to present itself to the outside
   world using only one domain, this scheme cannot be used, at least not
   without special precautions (see the paragraph about avoiding loops
   in chapter 3.2).

     +----------+      +---------------------------+
     |   MTA A  |      |        Shared MTA B       |
     +----------+      +---------------------------+
        |     |         /        |     |        |
     +-----------------/----+ +-----------+  +----------+
     |  |     |       /     | |  |     |  |  |  |       |
     | +--+ +--+ +--+/      | | +--+ +--+ |  | +--+     |
     | |UA| |UA| |UA|       | | |UA| |UA| |  | |UA|     |
     | +--+ +--+ +--+       | | +--+ +--+ |  | +--+     |
     | Distributed Domain A | | Domain B  |  | Domain C |
     +----------------------+ +-----------+  +----------+

   Figure 3. Distributed domains and shared MTAs

   Another possibility to have uniform addresses in outgoing e-mail,
   despite the fact that a domain is distributed, is to make routing
   decisions on information in the local part of the address, e.g., in
   X.400 the Surname in exactly the same manner as making routing
   decisions on any other attributes. Thus products and routing
   algorithms that are able to route on user related address parts are
   said to support distributed domains.

4.2.  Shared MTA

   The opposite of a distributed domain is a shared MTA: several domains
   are routed locally on the same MTA. These domains sharing one MTA may
   cause problems when two or more domains have a local user with the
   same name.




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


   Theoretically, this problem doesn't exist: the address is being
   routed down to the deepest domain level, and within that level, there
   will only be one user with that name (let's at least assume this for
   simplicity). Some products however use only one database of all users
   locally connected to this MTA instead of one database per domain, so
   that default user routing at the deepest level can lead to conflicts.
   It is beyond the scope of this document to describe the tricks needed
   to avoid these conflicts when using such products.

5.    Routing control

   Routing control means that routing decisions can be affected by the
   originator of a message. This normally takes the form of either
   granting or denying access for a certain user or group of users.

   Routing control is often useful in an X.400 ADMD/PRMD environment,
   where it is either used to grant access only to users who are known
   to be chargeable, or where ADMDs can refuse messages that were
   relayed to them over international PRMD connections; a policy that is
   not allowed in the CCITT version of the standards (as opposed to the
   ISO version). Of course, the PRMDs can also perform routing control
   themselves in order to circumvent such problems.

   Although there may be good reasons for using routing control, one
   must be aware that it can make the messaging environment
   unpredictable for end-users. Where using routing control is
   unavoidable, the originator whose message has been rejected is likely
   to appreciate receiving a message, clearly telling him where and why
   routing of his message was refused, whom to contact, and what options
   are available to avoid such rejections in the future.

6.    Bulk routing

   In order to reduce network traffic, intelligent mailers may prefer a
   message addressed to a group of remote users to be transferred to a
   remote domain only once, thus postponing the 'explosion' into several
   copies. This technique, called bulk routing, is especially useful
   when an MTA hosts large mailing lists.

   Several possibilities exist. In a typical hierarchical firewall mail
   system, bulk routing can be done almost automatically by intelligent
   MTAs. For instance, in an X.400 community, a large international
   distribution list can create a message with an envelope containing
   1000 recipient addresses, some of which can probably be grouped by
   the MTA depending on whether they can be routed further to the same
   remote MTA, according to the normal routing implementation at this
   MTA. The size and number of these groups will largely depend on how
   indirect this routing implementation is. In the GO-MHS community, the



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


   number of groups will almost always be less than 50, which provides a
   rather fair distribution of traffic load over the involved MTAs (that
   is, fair according to the author's taste, who is not aware of any
   existing fair mail load distribution formula).

   As an extreme example, the simplest way to automatically (i.e.,
   without using special optimisation tools) bulk route mail is to use
   one default route. Any outgoing message, regardless of the number of
   recipients, will be routed over the default route only once. The
   default remote MTA will then have to break up the message (envelope)
   into several copies and is thus responsible for the actual explosion
   and distribution. NB. This mechanism can be exploited to shift the
   cost and overhead of exploding a message towards another domain/MTA.
   If you ever get a request for a bilateral default route agreement;
   i.e., the requesting party wants to default route over your MTA, it
   may be worth to check first if the requesting party is running or
   planning to run large mailing lists.

   In more direct routing environments, such as BITNET, bulk routing
   will not function as automatically as described above. Without
   special precautions, an MTA would open a direct connection to every
   single host that occurs in the message's envelope, regardless of
   whether some of these hosts are far away from this MTA, but close to
   each other, measured by underlying network topology. This can clearly