rfc1801.txt

中、英文RFC文档大全打包下载完全版 .

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

   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.



Kille                         Experimental                      [Page 6]

RFC 1801        X.400-MHS Routing using X.500 Directory        June 1995


 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



Kille                         Experimental                      [Page 7]

RFC 1801        X.400-MHS Routing using X.500 Directory        June 1995


    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.



Kille                         Experimental                      [Page 8]

RFC 1801        X.400-MHS Routing using X.500 Directory        June 1995


 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
    protocol.
    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
    entry.

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



Kille                         Experimental                      [Page 9]

RFC 1801        X.400-MHS Routing using X.500 Directory        June 1995


    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
    desirable.)

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.



Kille                         Experimental                     [Page 10]

RFC 1801        X.400-MHS Routing using X.500 Directory        June 1995


   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
   trees.





Kille                         Experimental                     [Page 11]

RFC 1801        X.400-MHS Routing using X.500 Directory        June 1995


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