Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 1801

MHS use of the X.500 Directory to support MHS Routing

Pages: 73
Part 1 of 3 – Pages 1 to 17
None   None   Next

Top   ToC   RFC1801 - Page 1
Network Working Group                                           S. Kille
Request for Comments: 1801                              ISODE Consortium
Category: Experimental                                         June 1995

   X.400-MHS use of the X.500 Directory to support X.400-MHS Routing

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  This memo does not specify an Internet standard of any
   kind.  Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Table of Contents

  1   Introduction                                                     3
  2   Goals                                                            3
  3   Approach                                                         5
  4   Direct vs Indirect Connection                                    6
  5   X.400 and RFC 822                                                8
  6   Objects                                                          9
  7   Communities                                                     10
  8   Routing Trees                                                   11
      8.1    Routing Tree Definition   .   .   .   .   .   .   .      12
      8.2    The Open Community Routing Tree   .   .   .   .   .      12
      8.3    Routing Tree Location     .   .   .   .   .   .   .      13
      8.4    Example Routing Trees     .   .   .   .   .   .   .      13
      8.5    Use of Routing Trees to look up Information   .   .      13
  9   Routing Tree Selection                                          14
      9.1    Routing Tree Order    .   .   .   .   .   .   .   .      14
      9.2    Example use of Routing Trees  .   .   .   .   .   .      15
          9.2.1    Fully Open Organisation     .   .   .   .   .      15
          9.2.2    Open Organisation with Fallback     .   .   .      15
          9.2.3    Minimal-routing MTA     .   .   .   .   .   .      16
          9.2.4    Organisation with Firewall  .   .   .   .   .      16
          9.2.5    Well Known Entry Points     .   .   .   .   .      16
          9.2.6    ADMD using the Open Community for Advertising      16
          9.2.7    ADMD/PRMD gateway   .   .   .   .   .   .   .      17
  10  Routing Information                                             17
      10.1   Multiple routing trees    .   .   .   .   .   .   .      20
      10.2   MTA Choice    .   .   .   .   .   .   .   .   .   .      22
      10.3   Routing Filters   .   .   .   .   .   .   .   .   .      25
      10.4   Indirect Connectivity     .   .   .   .   .   .   .      26
  11  Local Addresses (UAs)                                           27
      11.1   Searching for Local Users     .   .   .   .   .   .      30
  12  Direct Lookup                                                   30
  13  Alternate Routes                                                30
Top   ToC   RFC1801 - Page 2
      13.1   Finding Alternate Routes  .   .   .   .   .   .   .      30
      13.2   Sharing routing information   .   .   .   .   .   .      31
  14  Looking up Information in the Directory                         31
  15  Naming MTAs                                                     33
      15.1   Naming 1984 MTAs  .   .   .   .   .   .   .   .   .      35
  16  Attributes Associated with the MTA                              35
  17  Bilateral Agreements                                            36
  18  MTA Selection                                                   38
      18.1   Dealing with protocol mismatches  .   .   .   .   .      38
      18.2   Supported Protocols   .   .   .   .   .   .   .   .      39
      18.3   MTA Capability Restrictions   .   .   .   .   .   .      39
      18.4   Subtree Capability Restrictions   .   .   .   .   .      40
  19  MTA Pulling Messages                                            41
  20  Security and Policy                                             42
      20.1   Finding the Name of the Calling MTA   .   .   .   .      42
      20.2   Authentication    .   .   .   .   .   .   .   .   .      42
      20.3   Authentication Information    .   .   .   .   .   .      44
  21  Policy and Authorisation                                        46
      21.1   Simple MTA Policy     .   .   .   .   .   .   .   .      46
      21.2   Complex MTA Policy    .   .   .   .   .   .   .   .      47
  22  Delivery                                                        49
      22.1   Redirects     .   .   .   .   .   .   .   .   .   .      49
      22.2   Underspecified O/R Addresses  .   .   .   .   .   .      50
      22.3   Non Delivery  .   .   .   .   .   .   .   .   .   .      51
      22.4   Bad Addresses     .   .   .   .   .   .   .   .   .      51
  23  Submission                                                      53
      23.1   Normal Derivation     .   .   .   .   .   .   .   .      53
      23.2   Roles and Groups  .   .   .   .   .   .   .   .   .      53
  24  Access Units                                                    54
  25  The Overall Routing Algorithm                                   54
  26  Performance                                                     55
  27  Acknowledgements                                                55
  28  References                                                      56
  29  Security Considerations                                         57
  30  Author's Address                                                58
  A.  Object Identifier Assignment                                    59
  B.  Community Identifier Assignments                                60
  C.  Protocol Identifier Assignments                                 60
  D.  ASN.1 Summary                                                   61
  E.  Regular Expression Syntax                                       71

List of Figures

      1      Location of Routing Trees     .   .   .   .   .   .      12
      2      Routing Tree Use Definition   .   .   .   .   .   .      14
      3      Routing Information at a Node     .   .   .   .   .      17
      4      Indirect Access   .   .   .   .   .   .   .   .   .      25
      5      UA Attributes     .   .   .   .   .   .   .   .   .      27
      6      MTA Definitions   .   .   .   .   .   .   .   .   .      33
      7      MTA Bilateral Table Entry     .   .   .   .   .   .      36
Top   ToC   RFC1801 - Page 3
      8      Bilateral Table Attribute     .   .   .   .   .   .      37
      9      Supported MTS Extensions  .   .   .   .   .   .   .      39
      10     Subtree Capability Restriction    .   .   .   .   .      40
      11     Pulling Messages  .   .   .   .   .   .   .   .   .      41
      12     Authentication Requirements   .   .   .   .   .   .      43
      13     MTA Authentication Parameters     .   .   .   .   .      45
      14     Simple MTA Policy Specification   .   .   .   .   .      46
      15     Redirect Definition   .   .   .   .   .   .   .   .      48
      16     Non Delivery Information  .   .   .   .   .   .   .      50
      17     Bad Address Pointers  .   .   .   .   .   .   .   .      52
      18     Access Unit Attributes    .   .   .   .   .   .   .      53
      19     Object Identifier Assignment  .   .   .   .   .   .      59
      20     Transport Community Object Identifier Assignments        60
      21     Protocol Object Identifier Assignments    .   .   .      61
      22     ASN.1 Summary     .   .   .   .   .   .   .   .   .      61

1.  Introduction

   MHS Routing is the problem of controlling the path of a message as it
   traverses one or more MTAs to reach its destination recipients.
   Routing starts with a recipient O/R Address, and parameters
   associated with the message to be routed.  It is assumed that this is
   known a priori, or is derived at submission time as described in
   Section 23.

   The key problem in routing is to map from an O/R Address onto an MTA
   (next hop).  This shall be an MTA which in some sense is "nearer" to
   the destination UA. This is done repeatedly until the message can be
   directly delivered to the recipient UA. There are a number of things
   which need to be considered to determine this.  These are discussed
   in the subsequent sections.  A description of the overall routing
   process is given in Section 25.

2.  Goals

   Application level routing for MHS is a complex procedure, with many
   requirements.  The following goals for the solution are set:

 o  Straightforward to manage.  Non-trivial configuration of routing
    for current message handling systems is a black art, often
    involving gathering and processing many tables, and editing
    complex configuration files.  Many problems are solved in a very
    ad hoc manner.  Managing routing for MHS is the most serious
    headache for most mail system managers.

 o  Economic, both in terms of network and computational resources.
Top   ToC   RFC1801 - Page 4
 o  Robust.  Errors and out of date information shall cause minimal
    and localised damage.

 o  Deal with link failures.  There needs to be some ability to choose
    alternative routes.  In general, it is desirable that the routing
    approach be redundant.

 o  Load sharing.  Information on routes shall allow "equal" routes
    to be specified, and thus facilitate load sharing.

 o  Support format and protocol conversion

 o  Dynamic and automatic.  There shall be no need for manual
    propagation of tables or administrator intervention.

 o  Policy robust.  It shall not allow specification of policies which
    cause undesirable routing effects.

 o  Reasonably straightforward to implement.

 o  Deal with X.400, RFC 822, and their interaction.

 o  Extensible to other mail architectures

 o  Recognise existing RFC 822 routing, and coexist smoothly.

 o  Improve RFC 822 routing capabilities.  This is particularly
    important for RFC 822 sites not in the SMTP Internet.

 o  Deal correctly with different X.400 protocols (P1, P3, P7), and
    with 1984, 1988 and 1992 versions.

 o  Support X.400 operation over multiple protocol stacks (TCP/IP,
    CONS, CLNS) and in different communities.

 o  Messages shall be routed consistently.  Alternate routing
    strategies, which might introduce unexpected delay, shall be used
    with care (e.g., routing through a protocol converter due to
    unavailability of an MTA).

 o  Delay between message submission and delivery shall be minimised.
    This has indirect impact on the routing approaches used.

 o  Interact sensibly with ADMD services.

 o  Be global in scope
Top   ToC   RFC1801 - Page 5
 o  Routing strategy shall deal with a scale of order of magnitude
    1,000,000 -- 100,000,000 MTAs.

 o  Routing strategy shall deal with of order 1,000,000 -- 100,000,000

 o  Information about alterations in topology shall propagate rapidly
    to sites affected by the change.

 o  Removal, examination, or destruction of messages by third parties
    shall be difficult.  This is hard to quantify, but "difficult"
    shall be comparable to the effort needed to break system security
    on a typical MTA system.

 o  As with current Research Networks, it is recognised that
    prevention of forged mail will not always be possible.  However,
    this shall be as hard as can be afforded.

 o  Sufficient tracing and logging shall be available to track down
    security violations and faults.

 o  Optimisation of routing messages with multiple recipients, in
    cases where this involves selection of preferred single recipient

The following are not initial goals:

 o  Advanced optimisation of routing messages with multiple
    recipients, noting dependencies between the recipients to find
    routes which would not have been chosen for any of the single

 o  Dynamic load balancing.  The approach does not give a means to
    determine load.  However, information on alternate routes is
    provided, which is the static information needed for load

3.  Approach

   A broad problem statement, and a survey of earlier approaches to the
   problem is given in the COSINE Study on MHS Topology and Routing [8].
   The interim (table-based) approach suggested in this study, whilst
   not being followed in detail, broadly reflects what the research
   X.400 (GO-MHS) community is doing.  The evolving specification of the
   RARE table format is defined in [5].  This document specifies the
   envisaged longer term approach.
Top   ToC   RFC1801 - Page 6
   Some documents have made useful contributions to this work:

 o  A paper by the editor on MHS use of directory, which laid out the
    broad approach of mapping the O/R Address space on to the DIT [7].

 o  Initial ISO Standardisation work on MHS use of Directory for
    routing [19].  Subsequent ISO work in this area has drawn from
    earlier drafts of this specification.

 o  The work of the VERDI Project [3].

 o  Work by Kevin Jordan of CDC [6].

 o  The routing approach of ACSNet [4, 17] paper.  This gives useful
    ideas on incremental routing, and replicating routing data.

 o  A lot of work on network routing is becoming increasingly
    relevant.  As the MHS routing problem increases in size, and
    network routing increases in sophistication (e.g., policy based
    routing), the two areas have increasing amounts in common.  For
    example, see [2].

4.  Direct vs Indirect Connection

   Two extreme approaches to routing connectivity are:

   1.  High connectivity between MTAs.  An example of this is the way
       the Domain Name Server system is used on the DARPA/NSF Internet.
       Essentially, all MTAs are fully interconnected.

   2.  Low connectivity between MTAs.  An example of this is the UUCP

   In general an intermediate approach is desirable.  Too sparse a
   connectivity is inefficient, and leads to undue delays.  However,
   full connectivity is not desirable, for the reasons discussed below.
   A number of general issues related to relaying are now considered.
   The reasons for avoiding relaying are clear.  These include.

 o  Efficiency.  If there is an open network, it is desirable that it
    be used.

 o  Extra hops introduce delay, and increase the (very small)
    possibility of message loss.  As a basic principle, hop count
    shall be minimised.

 o  Busy relays or Well Known Entry points can introduce high delay
    and lead to single point of failure.
Top   ToC   RFC1801 - Page 7
 o  If there is only one hop, it is straightforward for the user to
    monitor progress of messages submitted.  If a message is delayed,
    the user can take appropriate action.

 o  Many users like the security of direct transmission.  It is an
    argument often given very strongly for use of SMTP.

   Despite these very powerful arguments, there are a number of reasons
   why some level of relaying is desirable:

 o  Charge optimisation.  If there is an expensive network/link to be
    traversed, it may make sense to restrict its usage to a small
    number of MTAs.  This would allow for optimisation with respect to
    the charging policy of this link.

 o  Copy optimisation.  If a message is being sent to two remote MTAs
    which are close together, it is usually optimal to send the
    message to one of the MTAs (for both recipients), and let it pass
    a copy to the other MTA.

 o  To access an intermediate MTA for some value added service.  In
    particular for:

    --  Message Format Conversion

    --  Distribution List expansion

 o  Dealing with different protocols.  The store and forward approach
    allows for straightforward conversion.  Relevant cases include:

    --  Provision of X.400 over different OSI Stacks (e.g.,
        Connectionless Network Service).

    --  Use of a different version of X.400.

    --  Interaction with non-X.400 mail services

 o  To compensate for inadequate directory services:  If tables are
    maintained in an ad hoc manner, the manual effort to gain full
    connectivity is too high.

 o  To hide complexity of structure.  If an organisation has many
    MTAs, it may still be advantageous to advertise a single entry
    point to the outside world.  It will be more efficient to have an
    extra hop, than to (widely) distribute the information required to
    connect directly.  This will also encourage stability, as
    organisations need to change internal structure much more
    frequently than their external entry points.  For many
Top   ToC   RFC1801 - Page 8
    organisations, establishing such firewalls is high priority.

 o  To handle authorisation, charging and security issues.  In
    general, it is desirable to deal with user oriented authorisation
    at the application level.  This is essential when MHS specific
    parameters shall be taken into consideration.  It may well be
    beneficial for organisations to have a single MTA providing access
    to the external world, which can apply a uniform access policy
    (e.g., as to which people are allowed access).  This would be
    particularly true in a multi-vendor environment, where different
    systems would otherwise have to enforce the same policy --- using
    different vendor-specific mechanisms.

   In summary there are strong reasons for an intermediate approach.
   This will be achieved by providing mechanisms for both direct and
   indirect connectivity.  The manager of a configuration will then be
   able to make appropriate choices for the environment.

   Two models of managing large scale routing have evolved:

   1.  Use of a global directory/database.  This is the approach
       proposed here.

   2.  Use of a routing table in each MTA, which is managed either by a
       management protocol or by directory.  This is coupled with means
       to exchange routing information between MTAs.  This approach is
       more analogous to how network level routing is commonly performed.
       It has good characteristics in terms of managing links and
       dealing with link related policy.  However, it assumes limited
       connectivity and does not adapt well to a network environment
       with high connectivity available.

5.  X.400 and RFC 822

   This document defines mechanisms for X.400 message routing.  It is
   important that this can be integrated with RFC 822 based routing, as
   many MTAs will work in both communities.  This routing document is
   written with this problem in mind, and some work to verify this has
   been done.  support for RFC 822 routing using the same basic
   infrastructure is defined in a companion document [13].  In addition
   support for X.400/RFC 822 gatewaying is needed, to support
   interaction.  Directory based mechanisms for this are defined in
   [16].  The advantages of the approach defined by this set of
   specifications are:

 o  Uniform management for sites which wish to support both protocols.

 o  Simpler management for gateways.
Top   ToC   RFC1801 - Page 9
 o  Improved routing services for RFC 822 only sites.

   For sites which are only X.400 or only RFC 822, the mechanisms
   associated with gatewaying or with the other form of addressing are
   not needed.

6.  Objects

   It is useful to start with a manager's perspective.  Here is the set
   of object classes used in this specification.  It is important that
   all information entered relates to something which is being managed.
   If this is achieved, configuration decisions are much more likely to
   be correct.  In the examples, distinguished names are written using
   the String Syntax for Distinguished Names [11].  The list of objects
   used in this specification is:

User An entry representing a single human user.  This will typically
    be named in an organisational context.  For example:

     CN=Edgar Smythe,
     O=Zydeco Services, C=GB

    This entry would have associated information, such as telephone
    number, postal address, and mailbox.

MTA A Message Transfer Agent.  In general, the binding between
    machines and MTAs will be complex.  Often a small number of MTAs
    will be used to support many machines, by use of local approaches
    such as shared filestores.  MTAs may support multiple protocols,
    and will identify separate addressing information for each
    To achieve support for multiple protocols, an MTA is modelled as
    an Application Process, which is named in the directory.  Each MTA
    will have one or more associated Application Entities.  Each
    Application Entity is named as a child of the Application Process,
    using a common name which conveniently identifies the Application
    Entity relative to the Application Process.  Each Application
    Entity supports a single protocol, although different Application
    Entities may support the same protocol.  Where an MTA only
    supports one protocol or where the addressing information for all
    of the protocols supported have different attributes to represent
    addressing information (e.g., P1(88) and SMTP) the Application
    Entity(ies) may be represented by the single Application Process

User Agent (Mailbox) This defines the User Agent (UA) to which mail
    may be delivered.  This will define the account with which the UA
    is associated, and may also point to the user(s) associated with
Top   ToC   RFC1801 - Page 10
    the UA. It will identify which MTAs are able to access the UA.
    (In the formal X.400 model, there will be a single MTA delivering
    to a UA. In many practical configurations, multiple MTAs can
    deliver to a single UA. This will increase robustness, and is

Role Some organisational function.  For example:

     CN=System Manager, OU=Sales,
     O=Zydeco Services, C=GB

    The associated entry would indicate the occupant of the role.

Distribution Lists There would be an entry representing the
    distribution list, with information about the list, the manger,
    and members of the list.

7.  Communities

There are two basic types of agreement in which an MTA may participate
in order to facilitate routing:

Bilateral Agreements An agreement between a pair of MTAs to route
    certain types of traffic.  This MTA pair agreement usually
    reflects some form of special agreement and in general bilateral
    information shall be held for the link at both ends.  In some
    cases, this information shall be private.

Open Agreements An agreement between a collection of MTAs to behave
    in a cooperative fashion to route traffic.  This may be viewed as
    a general bilateral agreement.

   It is important to ensure that there are sufficient agreements in
   place for all messages to be routed.  This will usually be done by
   having agreements which correspond to the addressing hierarchy.  For
   X.400, this is the model where a PRMD connects to an ADMD, and the
   ADMD provides the inter PRMD connectivity, by the ability to route to
   all other ADMDs.  Other agreements may be added to this hierarchy, in
   order to improve the efficiency of routing.  In general, there may be
   valid addresses, which cannot be routed to, either for connectivity
   or policy reasons.

   We model these two types of agreements as communities.  A community
   is a scope in which an MTA advertises its services and learns about
   other services.  Each MTA will:

   1.  Register its services in one or more communities.
Top   ToC   RFC1801 - Page 11
   2.  Look up services in one or more communities.

   In most cases an MTA will deal with a very small number of
   communities --- very often one only.  There are a number of different
   types of community.

The open community This is a public/global scope.  It reflects
    routing information which is made available to any MTA which
    wishes to use it.

The local community This is the scope of a single MTA. It reflects
    routing information private to the MTA. It will contain an MTA's
    view of the set of bilateral agreements in which it participates,
    and routing information private and local to the MTA.

Hierarchical communities A hierarchical community is a subtree of the
    O/R Address tree.  For example, it might be a management domain,
    an organisation, or an organisational unit.  This sort of
    community will allow for firewalls to be established.  A community
    can have complex internal structure, and register a small subset
    of that in the open community.

Closed communities A closed community is a set of MTAs which agrees
    to route amongst themselves.  Examples of this might be ADMDs
    within a country, or a set of PRMDs representing the same
    organisation in multiple countries.

   Formally, a community indicates the scope over which a service is
   advertised.  In practice, it will tend to reflect the scope of
   services offered.  It does not make sense to offer a public service,
   and only advertise it locally.  Public advertising of a private
   service makes more sense, and this is shown below.  In general,
   having a community offer services corresponding to the scope in which
   they are advertised will lead to routing efficiency.  Examples of how
   communities can be used to implement a range of routing policies are
   given in Section 9.2.

8.  Routing Trees

   Communities are a useful abstract definition of the routing approach
   taken by this specification.  Each community is represented in the
   directory as a routing tree.  There will be many routing trees
   instantiated in the directory.  Typically, an MTA will only be
   registered in and make use of a small number of routing trees.  In
   most cases, it will register in and use the same set of routing
Top   ToC   RFC1801 - Page 12
8.1  Routing Tree Definition

   Each community has a model of the O/R address space.  Within a
   community, there is a general model of what to do with a given O/R
   Address.  This is structured hierarchically, according to the O/R
   address hierarchy.  A community can register different possible
   actions, depending on the depth of match.  This might include
   identifying the MTA associated with a UA which is matched fully, and
   providing a default route for an O/R address where there is no match
   in the community --- and all intermediate forms.  The name structure
   of a routing tree follows the O/R address hierarchy, which is
   specified in a separate document [15].  Where there is any routing
   action associated with a node in a routing tree, the node is of
   object class routingInformation, as defined in Section 10.

8.2  The Open Community Routing Tree

   The routing tree of the open community starts at the root of the DIT.
   This routing tree also serves the special function of instantiating
   the global O/R Address space in the Directory.  Thus, if a UA wishes
   to publish information to the world, this hierarchy allows it to do

   The O/R Address hierarchy is a registered tree, which may be
   instantiated in the directory.  Names at all points in the tree are
   valid, and there is no requirement that the namespace is instantiated
   by the owner of the name.  For example, a PRMD may make an entry in
   the DIT, even if the ADMD above it does not.  In this case, there
   will be a "skeletal" entry for the ADMD, which is used to hang the
   PRMD entry in place.  The skeletal entry contains the minimum number
   of entries which are needed for it to exist in the DIT (Object Class
   and Attribute information needed for the relative distinguished
   name).  This entry may be placed there solely to support the
   subordinate entry, as its existence is inferred by the subordinate
   entry.  Only the owner of the entry may place information into it.
   An analogous situation in current operational practice is to make DIT
   entries for Countries and US States.


routingTreeRoot OBJECT-CLASS ::= {
    SUBCLASS OF {routingInformation|subtree}
    ID oc-routing-tree-root}

                  Figure 1: Location of Routing Trees

Top   ToC   RFC1801 - Page 13
8.3  Routing Tree Location

   All routing trees follow the same O/R address hierarchy.  Routing
   trees other than the open community routing tree are rooted at
   arbitrary parts of the DIT. These routing trees are instantiated
   using the subtree mechanism defined in the companion document
   "Representing Tables and Subtrees in the Directory" [15].  A routing
   tree is identified by the point at which it is rooted.  An MTA will
   use a list of routing trees, as determined by the mechanism described
   in Section 9.  Routing trees may be located in either the
   organisational or O/R address structured part of the DIT. All routing
   trees, other than the open community routing tree, are rooted by an
   entry of object class routingTreeRoot, as defined in Figure 1.

8.4  Example Routing Trees

   Consider routing trees with entries for O/R Address:

    P=ABC; A=XYZMail; C=GB;

   In the open community routing tree, this would have a distinguished
   name of:


   Consider a routing tree which is private to:

    O=Zydeco Services, C=GB

   They might choose to label a routing tree root "Zydeco Routing Tree",
   which would lead to a routing tree root of:

    CN=Zydeco Routing Tree, O=Zydeco Services, C=GB

   The O/R address in question would be stored in this routing tree as:

    C=GB, CN=Zydeco Routing Tree,
    O=Zydeco Services, C=GB

8.5  Use of Routing Trees to look up Information

   Lookup of an O/R address in a routing tree is done as follows:

   1.  Map the O/R address onto the O/R address hierarchy described in
       [15] in order to generate a Distinguished Name.
Top   ToC   RFC1801 - Page 14
   2.  Append this to the Distinguished Name of the routing tree, and
       then look up the whole name.

   3.  Handling of errors will depend on the application of the lookup,
       and is discussed later.

   Note that it is valid to look up a null O/R Address, as the routing
   tree root may contain default routing information for the routing
   tree.  This is held in the root entry of the routing tree, which is a
   subclass of routingInformation.  The open community routing tree does
   not have a default.

   Routing trees may have aliases into other routing trees.  This will
   typically be done to optimise lookups from the first routing tree
   which a given MTA uses.  Lookup needs to take account of this.

9.  Routing Tree Selection

   The list of routing trees which a given MTA uses will be represented
   in the directory.  This uses the attribute defined in Figure 2.


   routingTreeList ATTRIBUTE ::= {
           WITH SYNTAX RoutingTreeList
           SINGLE VALUE
           ID at-routing-tree-list}

   RoutingTreeList ::= SEQUENCE OF RoutingTreeName

   RoutingTreeName ::= DistinguishedName

                   Figure 2: Routing Tree Use Definition


   This attribute defines the routing trees used by an MTA, and the
   order in which they are used.  Holding these in the directory eases
   configuration management.  It also enables an MTA to calculate the
   routing choice of any other MTA which follows this specification,
   provided that none of its routing trees have access restrictions.
   This will facilitate debugging routing problems.

9.1  Routing Tree Order

   The order in which routing trees are used will be critical to the
   operation of this algorithm.  A common approach will be:
Top   ToC   RFC1801 - Page 15
   1.  Access one or more shared private routing trees to access private
       routing information.

   2.  Utilise the open routing tree.

   3.  Fall back to a default route from one of the private routing

   Initially, the open routing tree will be very sparse, and there will
   be little routing information in ADMD level nodes.  Access to many
   services will only be via ADMD services, which in turn will only be
   accessible via private links.  For most MTAs, the fallback routing
   will be important, in order to gain access to an MTA which has the
   right private connections configured.

   In general, for a site, UAs will be registered in one routing tree
   only, in order to avoid duplication.  They may be placed into other
   routing trees by use of aliases, in order to gain performance.  For
   some sites, Users and UAs with a 1:1 mapping will be mapped onto
   single entries by use of aliases.

9.2  Example use of Routing Trees

   Some examples of how this structure might be used are now given.
   Many other combinations are possible to suit organisational

9.2.1  Fully Open Organisation

   The simplest usage is to place all routing information in the open
   community routing tree.  An organisation will simply establish O/R
   addresses for all of its UAs in the open community tree, each
   registering its supporting MTA. This will give access to all systems
   accessible from this open community.

9.2.2  Open Organisation with Fallback

   In practice, some MTAs and MDs will not be directly reachable from
   the open community (e.g., ADMDs with a strong model of bilateral
   agreements).  These services will only be available to
   users/communities with appropriate agreements in place.  Therefore it
   will be useful to have a second (local) routing tree, containing only
   the name of the fallback MTA at its root.  In many cases, this
   fallback would be to an ADMD connection.

   Thus, open routing will be tried first, and if this fails the message
   will be routed to a single selected MTA.
Top   ToC   RFC1801 - Page 16
9.2.3  Minimal-routing MTA

   The simplest approach to routing for an MTA is to deliver messages to
   associated users, and send everything else to another MTA (possibly
   with backup).

   An organisation using MTAs with this approach will register its users
   as for the fully open organisation.  A single routing tree will be
   established, with the name of the organisation being aliased into the
   open community routing tree.  Thus the MTA will correctly identify
   local users, but use a fallback mechanism for all other addresses.

9.2.4  Organisation with Firewall

   An organisation can establish an organisation community to build a
   firewall, with the overall organisation being registered in the open
   community.  This is an important structure, which it is important to
   support cleanly.

    o  Some MTAs are registered in the open community routing tree to
       give access into the organisation.  This will include the O/R tree
       down to the organisational level.  Full O/R Address verification
       will not take place externally.

    o  All users are registered in a private (organisational) routing

    o  All MTAs in the organisation are registered in the organisation's
       private routing tree, and access information in the organisation's
       community.  This gives full internal connectivity.

    o  Some MTAs in the organisation access the open community routing
       tree.  These MTAs take traffic from the organisation to the
       outside world.  These will often be the same MTAs that are
       externally advertised.

9.2.5  Well Known Entry Points

   Well known entry points will be used to provide access to countries
   and MDs which are oriented to private links.  A private routing tree
   will be established, which indicates these links.  This tree would be
   shared by the well known entry points.

9.2.6  ADMD using the Open Community for Advertising

   An ADMD uses the open community for advertising.  It advertises its
   existence and also restrictive policy.  This will be useful for:
Top   ToC   RFC1801 - Page 17
    o  Address validation

    o  Advertising the mechanism for a bilateral link to be established

9.2.7  ADMD/PRMD gateway

   An MTA provides a gateway from a PRMD to an ADMD. It is important to
   note that many X.400 MDs will not use the directory.  This is quite
   legitimate.  This technique can be used to register access into such
   communities from those that use the directory.

    o  The MTA registers the ADMD in its local community (private link)

    o  The MTA registers itself in the PRMD's community to give access to
       the ADMD.

(page 17 continued on part 2)

Next Section