Draft article 'X.500 directory service usage for X.400 e-mail'

[Urs Eppenberger <[e-mail]>]

Dear colleagues,

for the next SWITCHjournal I drafted an article on 'X.500 directory 
service usage for X.400 e-mail'. The readers do use email or know somebody
who uses email ;-) . Directory services have been presented in an earlier
issue. Could you as the experts have a look at what I wrote and help me
where I messed something up. This document is not related to MHS-DS or
IETF and it should NOT be spread around wider than just to the MHS-DS
discussion list members. A better version of the document is likely to
appear end of June.

Many thanks for your help,

Urs.

-------------------------------------------------------------------------------
Urs Eppenberger, SWITCH, Zurich, June 1, 1993


            X.500 directory service usage for X.400 e-mail


1 Introduction
    
    Directory services are a mandatory requirement for global
  electronic messaging, this is accepted since years. Only now the
  first concrete ideas get into shape on how this should be done.
  Registering persons in the directory is in a quite advanced state
  already. Registering email routing and distribution list information
  is in a pilot phase. This article shows the current developments and
  the implications for end users and service managers.


2 Naming, Addressing and Routing
    
    There has always been confusion about the difference between
  information used for naming, addressing and routing. This chapter
  should shed some light on these issues based on a concrete example:
    
    The NAME of the author is 'Urs Eppenberger', full stop. Since this
  name is not unique some context is needed to know who exactly is
  meant. Different contexts exist which uniquely identify the author.
  For Swiss PTTs postal service the context is 'Urs Eppenberger, who
  lives in Zurich', for MHS managers it is 'Urs Eppenberger, who works
  with the MHS Coordination Service'.
    
    A directory service is needed to look up the ADDRESS. This
  function is generally referred to as 'white page service'. The X.500
  directory service project has defined to use the organisation and
  the country where I work as the context to uniquely identify myself.
  The SEARCH KEY for the directory service is therefore something like
  'Urs Eppenberger, SWITCH, CH'.
    
    The result is a list of information about the author, the mailbox
  address only is used to continue the discussion with:
    
    S=eppenberger; O=switch; P=switch; A=arcom; C=ch;
    
    This is an X.400 OR address uniquely identifying the author's
  mailbox. An email with this address needs somehow to be routed
  through the mail systems to the mailbox. At the moment the routing
  is based on the hierarchical address. The mail systems are manually
  configured to check for the country, the management domains or the
  personal name, depending on how far away the mail system is relative
  to the destination mailbox.
    
    A new approach to email routing suggests now to use the directory
  to find the best route for a message to its destination, thus making
  it unnecessary to pack routing information in an address.


3 Design Goals
    
    Email routing is a highly complex task, especially in a global
  environment. A solution needs to
  
  o be understandable for MHS managers
    The MHS managers get as much support as possible to handle the
    complex task of routing configuration
  
  o be robust
    Wrong or out of date information should cause minimal and local
    damage.
  
  o deal with link failures by choosing alternative routes
  
  o support protocol and format conversion
  
  o support different routing policies
  
  o support X.400 operation over multiple protocol stacks (TCP/IP,
    X.25, CLNS, CONS) and in different networks
  
  o minimise the delay of a message in transit through the mail system
  
  o support a large number of MTAs (>1 Million) and a large number of
    organisations.
  
  o routing updates should propagate automatically through the system
  
  o support X.400 and RFC822 routing and be extensible for other
    protocols


4 The MHS-DS Approach
    
    Steve E. Kille has written eight documents which define the
  information that needs to be stored in the X.500 Directory
  Information Tree (DIT) and how the MTAs can use this information. An
  IETF (Internet Engineering Task Force) working group MHS-DS has been
  created to review the work and start a pilot to investigate the
  feasibility of the approach. The titles of the documents read
  
  o Representing the O/R Address hierarchy in the Directory
    Information Tree
  
  o Representing Tables and Subtrees in the Directory
  
  o MHS use of Directory to support MHS Routing
  
  o Use of the Directory to support mapping between X.400 and RFC822
    Addresses
  
  o MHS use of the Directory to support distribution lists
  
  o Use of the Directory to support routing for RFC822 and related
    protocols
  
  o MHS use of Directory to support MHS Content Conversion
  
  o A simple profile for MHS use of Directory
    
    The first two documents define how to store the information. The
  third document is the core document defining how to use the
  information for routing. The next four documents extend the
  functionality with mapping, distribution list support, RFC822
  routing and content conversion functionality. The last document
  defines a subset which should be implemented to support the X.400
  routing functionality.
    
    The basic idea is to create a separate routing tree in the
  directory which is formed by the OR address hierarchy. At a node in
  the tree one finds the routing information for the specified domain,
  indicating the next hop, which should be as 'close' to the end
  system as possible. The mechanism is explained in more detail in the
  following chapters.
    
    The most recent Internet Drafts can be retrieved with anonymous
  FTP from the host nic.switch.ch in the directory standard/internet-
  draft, check for documents starting with draft-ietf-mhsds.
  
  
  4.1 The routing information in the DIT
      
      The OR address hierarchy defines a tree which is mapped straight
    forward into the DIT. The same entry is used for the OR address
    country code as for the Country in the White Page information.
    The ADMDs are registered below the country, including ' ' (single
    space) and '0'. The following table shows the supported OR
    attributes and their hierarchy in the DIT:
    
    O/R      Object Class               Naming Attribute
    Address
    
    C        mHSCountry                 countryName
                                        or
                                        mHSNumericCountryName
    ADMD     aDMD                       aDMDName
    PRMD     pRMD                       pRMDName
    UA-ID    mHSNumericUserIdentifier   mHSNumericUserIdentifierName
    X121     mHSX121                    mHSX121Address
    O        mHSOrganisation            mHSOrganisationName
    OU       mHSOrganisationalUnit      mHSOrganisationalUnitName
    PN       mHSPerson                  personName
    CN       mHSNamedObject             mHSCommonName
    T-ID     mHSTerminalID              mHSTerminalIDName
    DDA      mHSDomainDefinedAttribute  mHSDomainDefinedAttributeType
                                        and
                                        mHSDomainDefinedAttributeValue
      
      The numeric country code is always stored too as an alias. The
    Personal name is normalised into a string according RFC1327,
    S=eppenberger; G=urs would be stored as CN=urs.eppenberger. The
    author's OR address
      
      S=eppenberger; O=switch; P=switch; A=arcom; C=ch;
      
      is represented in the directory as the following Distinguished
    Name (DN):
      
      CN=eppenberger, MHS-O=switch, PRMD=switch, ADMD=arcom, C=ch
  
  
  4.2 The basic routing mechanism
      
      The need for having a powerful routing mechanism for various
    user communities (ADMD service providers, large multinational
    companies, the R&D community, ...) lead to a complex routing
    document. The simple profile reduces the functionality to what is
    needed to globally connect X.400 networks in an open and
    distributed managed way.
      
      The following routing tree might be stored in the DIT, carrying
    information for two ADMDs and two PRMDs. MTAinfo is used to
    indicate that a node in the DIT contains MTA connection
    information.
    
                                 MTAinfo2
                     PRMD=switch/
          ADMD=arcom/           \             MTAinfo3
     C=ch/          \            MHS-O=switch/
    /                MTAinfo1                \CN=eppenberger\
    \                                                       MTAinfo3
     C=it\          MTAinfo4
          ADMD=garr/
                   \(access restricted)
                    PRMD=infn\
                              MTAinfo5
      
      If an MTA at SURFnet, NL needs to relay a message to me, it
    takes my OR address, maps it to a Distinguished Name as explained
    in 4.1 and finds directly MTAinfo3. If the Dutch MTA is connected
    to the same network as MTA3, then a connection can be established
    an the message transferred. If the two MTAs do not share the same
    network, the least significant attribute of the DN is stripped and
    the directory might return an MTA which is connectable.
      
      Another message might be sent to
      
      S=allocchio; O=elettra-ts; P=infn; A=garr; C=it;
      
      which gives a DN of
      
      CN=allocchio, MHS-O=elettra-ts, PRMD=infn, ADMD=garr, C=it
      
      Since the access to PRMD level is restricted by X.500 access
    control to Italian MTAs only, the Dutch MTA is able to retrieve
    the connection info stored at ADMD level, MTAinfo4. This MTA is in
    Italy and can read all the entries and will then be able to do the
    final delivery. This is how firewalls can be set up with MTAs on
    both sides of the firewall using the same directory based routing
    mechanism.
      
      A very interesting but not deployed feature is the possibility
    of storing User Agent capabilities in the directory. The sending
    MTA will be able determine that the receiving UA cannot handle
    video and will therefore omit this part of the message. The MTA
    might also find that the receiving UA does support PostScript, but
    does not understand G3FAX. It will therefore check the DIT for a
    relaying MTA which can convert G3FAX to Postscript.


4 Project LONGBUD
    
    The IETF MHS-DS working group saw the necessity to gather
  operational experience with the proposed routing mechanism. A few
  organisations with operational DSAs and X.400 software supporting
  MHS-DS functionality will start to populate the routing tree and
  exchange messages based on X.500 routing information. Amongst the
  participating organisations are Nordunet(NO), CDC(US), EDF(FR),
  SURFnet(NL), Nexor(UK), and SWITCH(CH).
    
    The directory infrastructure is more or less ready to be used. The
  pilot project will show if the response times are acceptable and if
  the functionality offered by the current X.500 implementations and
  standards matches the requirements for MHS-DS, which are probably
  different to the requirements of end users searching for white page
  information..
    
    The plan is to present first results at the next IETF MHS-DS
  meeting in Amsterdam, July 12-16, 1993.
    
    Documents concerning MHS-DS and project LONGBUD can be retrieved
  with anonymous FTP from quixote.css.cdc.com, directory pub/mhs-ds.


5 EXPLODE
    
    Based on the definition on how to use X.500 to support
  distribution list a software package has been developed in the
  COSINE initiative to extend the PP X.400 software. The EXPLODE
  system provides a self subscription electronic mail distribution
  list system with archive facilities. It works in a multi-protocol
  mail environment, including support for X.400 (both 84 and 88) and
  Internet RFC 822 mail.
    
    In EXPLODE the distribution list members are stored in the X.500
  Directory. When a message is sent to the distribution list, a
  component called the list expander reads the list of members from
  the Directory entry and re-distributes the message to each of the
  members. This Directory entry can be viewed using a standard
  Directory user agent (DUA), allowing a distribution list to get
  identified and addressed easily. The expansion mechanism used by the
  list expander is based upon the process defined by X.400(88).
    
    Optionally, all messages sent to an EXPLODE distribution list can
  also be archived. Users (not necessarily members of the distribution
  list) can send mail messages to the archive requesting that they be
  sent a copy of selected messages from the archive.
    
    To manage both, the list and archive, a mail based management
  interface is provided, as well as a line based DUA supporting list
  management.
    
    Both the archive and list expander have a number of policy options
  available. These are used to control (amongst other things) who can
  submit messages to the archive, who can add members to the list, the
  type(s) of messages that can be accepted and how to deal with
  errors, giving the system a great deal of configuration flexibility,
  enabling the software to be used in a wide range of configurations.
    
    Details on requirements for the EXPLODE software can be found in
  the document EXPLODE via anonymous FTP from the host nic.switch.ch
  in the directory e-mail/docs.


6 Conclusion
    
    X.500 usage for X.400 email needs still significant research and
  development efforts. The EXPLODE software is ready to be used, the
  email interface is subject to change, however, since IETF is
  considering to standardise the interfaces of mail based servers for
  the benefit of the users. Project LONGBUD is still in its starting
  phase and it will take several month until the first results will
  provide feedback to the design. There is some effort to standardise
  X.500 usage for X.400 routing in ISO. It is highly probably that
  CCITT is not going to adopt this approach since it allows to bypass
  the ADMD infrastructure with end-to-end delivery if the MTAs share
  the same network.