RFC 1801 (rfc1801) - Page 3 of 73

MHS use of the X

RFC 1801        X.400-MHS Routing using X.500 Directory        June 1995


      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.





Kille                         Experimental