home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_a_c / draft-ietf-asid-email-routing-su-00.txt < prev    next >
Text File  |  1997-03-27  |  17KB  |  450 lines
  1.  
  2. Network Working Group                                  Jeffrey D. Hodges
  3. INTERNET-DRAFT                                              Booker Bense
  4. Track: Informational                                 Stanford University
  5.                                                            26 March 1996
  6.  
  7.  
  8.   LDAP-based Routing of SMTP Messages: Approach at Stanford University
  9.                <draft-ietf-asid-email-routing-su-00.txt>
  10.  
  11.  
  12. Status of this Memo
  13.  
  14.    This document is an Internet Draft.  Internet Drafts are working
  15.    documents of the Internet Engineering Task Force (IETF), its Areas,
  16.    and its Working Groups.  Note that other groups may also distribute
  17.    working documents as Internet Drafts.
  18.  
  19.    Internet Drafts are draft documents valid for a maximum of six
  20.    months.  Internet Drafts may be updated, replaced, or obsoleted by
  21.    other documents at any time.  It is not appropriate to use Internet
  22.    Drafts as reference material or to cite them other than as a
  23.    ``working draft'' or ``work in progress''.
  24.  
  25.    To learn the current status of any Internet-Draft, please check the
  26.    1id-abstracts.txt listing contained in the Internet-Drafts Shadow
  27.    Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or
  28.    munnari.oz.au.
  29.  
  30.    A revised version of this draft document will be submitted to the RFC
  31.    editor for consideration as an Informational RFC for the Internet
  32.    Community.  Discussion and suggestions for improvement are requested.
  33.    This document will expire in September 1997. Distribution of this
  34.    draft is unlimited.
  35.  
  36. 1.  Abstract
  37.  
  38.    The "Internet X.500 Schema" defines an RFC-822 email address
  39.    attribute of a person's entry, rfc822Mailbox (aka "Mail"), but it
  40.    does not address the issues involved in routing RFC-822-based email
  41.    within an administrative domain served by an X.500/LDAP-based
  42.    directory service. Significantly, it doesn't delineate between a
  43.    person's publicaly "advertised" or "promoted" email address and the
  44.    actual "internal to the administrative domain" address for the
  45.    person.
  46.  
  47.    This memo illustrates an object class and an attendant attribute we
  48.    use at Stanford University to solve this issue. This scheme provides
  49.    us with flexible, simple to implement, distributed routing of RFC-
  50.  
  51.  
  52.  
  53. Hodges & Bense           Informational Track                    [Page 1]
  54.  
  55. INTERNET-DRAFT    LDAP-based Routing of SMTP Messages           Mar-1997
  56.  
  57.  
  58.    822-based email to people represented by entries within our directory
  59.    service. The LDAP-enabled version of sendmail we use is freely
  60.    available.
  61.  
  62.    Additionally, we anticipate that the Internet community will devise
  63.    conventions and perhaps support a process for facilitating multi-
  64.    vendor directory utilization. We present an anticipated tenet and
  65.    goals.
  66.  
  67. 2.  Motivation and Background
  68.  
  69.    Directory enabled email routing has long been a goal of the overall
  70.    directory service effort in the Internet [1]. Although one can claim
  71.    it has been long implemented in a sort of "once removed" fashion via
  72.    the marriage local user account names and DNS host names via RFC-822
  73.    format addresses [2], there are, as yet, no Internet standards or
  74.    informational documents defining general purpose, directory-enabled,
  75.    X.500/LDAP-based routing of RFC-822-based email messages.
  76.  
  77.    The "Internet X.500 Schema" [3, 4] defines an RFC-822 email address
  78.    attribute of a person's entry, rfc822Mailbox (aka "Mail"), plus, RFCs
  79.    exist covering the topics of directory enabled mapping between RFC-
  80.    822- and X.400-based email message formats, and of directory enabled
  81.    routing of  X.400-based email messages [5, 6]. But, they do not cover
  82.    delivery of RFC-822-based email messages to users, nor do they
  83.    address the issues of providing a level of indirection for
  84.    administrative domain oriented email routing.
  85.  
  86.    One of the most common and significant issues of providing email
  87.    service to a body of users is providing a stable, relatively simple
  88.    email address for users to advertise to the Internet at large that
  89.    provides for user account mobility within the administrative domain.
  90.    Many approaches exist for solving this issue, but using a general-
  91.    purpose, standards-based directory service to do so brings along many
  92.    obvious benefits.
  93.  
  94.    This memo defines an attribute and its semantics that enable the
  95.    routing, via an LDAP/X.500-based directory, of email messages
  96.    addressed as "entity@domain", where entity's actual mail server may
  97.    be any machine within or without the domain. Note that this scheme
  98.    presupposes that the administrative domain has implemented some sort
  99.    of unique entry naming scheme -- i.e. there is an entry naming scheme
  100.    that ensures that a person's "advertised" email address maps uniquely
  101.    back to that person's directory entry. This "entry naming" topic thus
  102.    is related, but orthogonal, to the topic covered here. It will be
  103.    discussed in a companion Internet-Draft, to be issued in the near
  104.    future.
  105.  
  106.  
  107.  
  108.  
  109. Hodges & Bense           Informational Track                    [Page 2]
  110.  
  111. INTERNET-DRAFT    LDAP-based Routing of SMTP Messages           Mar-1997
  112.  
  113.  
  114. 3.  Anticipated Tenet and Goals for Multi-vendor Directory Utilization
  115.  
  116.    The approach to email routing described in this memo is only one way
  117.    to address that issue. We expect that various vendors and
  118.    institutions will devise other approaches.  We feel the key,
  119.    underlying tenet of multi-vendor directory utilization will be that
  120.    various vendor- and system-specific object classes and attributes
  121.    peacefully coexist, rather than necessarily interoperate or interfere
  122.    with each other. Further, we feel that promoting and supporting reuse
  123.    of object classes and attributes will yield various benefits to
  124.    people designing and/or deploying directory-based systems. We
  125.    anticipate that these goals will be reached through some form of
  126.    generally-accepted, Internet-wide schema documentation and
  127.    registration process.
  128.  
  129.    In anticipation of this, we've prefixed the names of the object class
  130.    and attribute in this memo with the string "SU". Such "uniqifying" of
  131.    object class and attribute names is necessary in the LDAP world
  132.    because the names themselves, not object identifiers (OIDs), are
  133.    carried in protocol. Plus it allows for other vendors or institutions
  134.    to define similar attributes that differ in details such as precise
  135.    semantics and syntax, and allow for them to have similar names. For
  136.    example, a vendor may define their own version of a "rfc822Routing"
  137.    object class, and can differentiate it by naming it like:
  138.    "<vendor>rfc822Routing". However, if an attribute and object class is
  139.    officially standardized upon by the IETF, we anticipate that
  140.    uniqifying information, such as a prefix, would be dropped.
  141.  
  142. 4.  Definition of the SUrfc822Routing Object Class
  143.  
  144.    ( 1.3.6.1.4.1.299.3.1
  145.        NAME 'SUrfc822Routing'
  146.        SUP top
  147.        AUXILIARY
  148.        MUST SUmailDrop
  149.    )
  150.  
  151.    This object class provides an attribute that enables site-specific
  152.    routing of RFC-822-based email messages to an entity represented by
  153.    the directory entry to which this attribute is attached. The format
  154.    above, and of those below, is as defined in [4].
  155.  
  156. 5.  Definition of the SUmailDrop Attribute
  157.  
  158.    ( 1.3.6.1.4.1.299.1.1
  159.        NAME 'SUmailDrop' 'SUrfc822RoutingAddress'
  160.        DESC 'address to where admin domain MTA forwards this entry's
  161.              email'
  162.  
  163.  
  164.  
  165. Hodges & Bense           Informational Track                    [Page 3]
  166.  
  167. INTERNET-DRAFT    LDAP-based Routing of SMTP Messages           Mar-1997
  168.  
  169.  
  170.        SUP mail
  171.        SINGLE-VALUE
  172.     )
  173.  
  174.    The SUmailDrop attribute indicates to where a site-specific email
  175.    routing system should forward rfc822-based email intendend for the
  176.    person represented by the entry it is a part of. It is based on the
  177.    "mail" attribute, whose AttributeTypeDescription, from [4], is given
  178.    below. The syntax of this attribute is that it must contain a RFC-822
  179.    address [2].
  180.  
  181.       ( 0.9.2342.19200300.100.1.3 NAME 'mail'
  182.         EQUALITY caseIgnoreIA5Match
  183.         SUBSTRINGS caseIgnoreIA5SubstringsMatch
  184.         SYNTAX 'IA5String{256}' )
  185.  
  186.  
  187. 6.  A Simple Tutorial Example
  188.  
  189.    Here is an outline of the steps that administrative domain
  190.    administrators need to go through to route RFC 822-based email via
  191.    the SUrfc822Routing object class and SUmailDrop attribute.
  192.  
  193.    This example assumes that the administrative domain has some system
  194.    of assigning at least one guaranteed-unique identifier value to each
  195.    involved individual. We'll call this "guaranteed-unique identifier
  196.    value" an "EntityID" in this example, but discussion of generating
  197.    and assigning EntityIDs is outside the scope of this memo.
  198.  
  199.    Let's suppose there's a user named "Im A. User", whose administrative
  200.    domain is isp-r-us.com. Im A. User has an account on a machine called
  201.    "ImasMachine", which is registered in the isp-r-us.com domain and is
  202.    where she reads her email. Her account is "imasacnt", and
  203.    "imasacnt@ImasMachine.isp-r-us.com" is her actual email address.
  204.  
  205.    Let's further suppose that isp-r-us.com has an LDAP/X.500-based
  206.    directory service and has assigned Im A. User an EntityID of
  207.    "Im.A.User". They've chosen to map their users' EntityIDs to one
  208.    value of their user's "cn" attribute.
  209.  
  210.    isp-r-us.com also runs a Mail Transfer Agent (aka "MTA", an example
  211.    of which is the "sendmail" daemon on UNIX-based systems) on isp-r-
  212.    us.com, which accepts mail addressed to "name@isp-r-us.com", performs
  213.    a lookup in the isp-r-us.com directory service with a filter of
  214.    "(cn=name)", and sends the email message to the address specified in
  215.    the returned entry's "SUmailDrop" attribute. Note that the message
  216.    will not be immediately routable if the "name" is not an existing
  217.    EntityID in the directory.
  218.  
  219.  
  220.  
  221. Hodges & Bense           Informational Track                    [Page 4]
  222.  
  223. INTERNET-DRAFT    LDAP-based Routing of SMTP Messages           Mar-1997
  224.  
  225.  
  226.    So, Im A. User's directory entry ends up looking something like this:
  227.  
  228.       objectClass: top
  229.       objectClass: person
  230.       objectClass: SUrfc822Routing
  231.            .
  232.            .
  233.       cn: Im A. User
  234.       cn: I. A. User
  235.       cn: Im.A.User
  236.            .
  237.            .
  238.       mail: Im.A.User@isp-r-us.com
  239.            .
  240.            .
  241.       SUmailDrop: imasacnt@ImasMachine.isp-r-us.com
  242.            .
  243.            .
  244.  
  245.    Thus, Im A. User may widely promote the email address
  246.    "Im.A.User@isp-r-us.com" and email sent to that address will be
  247.    routed to imasacnt@ImasMachine.isp-r-us.com, where she can read it.
  248.  
  249.    Things to note:
  250.  
  251.         isp-r-us.com chose to map EntityIDs to a value of the "cn"
  252.         attribute. They could have chosen to map it to some other
  253.         attribute if they wished. The critical link is having the MTA
  254.         filter on whatever attribute they decide on using.
  255.  
  256.         Im A. User's Distinguished Name isn't shown above. This is
  257.         because it is irrelevant in this example. This scheme doesn't
  258.         depend on having any particular directory naming hierarchy in
  259.         place. We're assuming that the administrative domain has
  260.         configured the MTA to be able to do entry lookups given only the
  261.         EntityID of an entry. This implies, for an LDAP-based directory,
  262.         configuring the MTA with the "base distinguished name" to use
  263.         with the "cn=EntityID" filter for such lookups. However, there
  264.         are many alternative ways the administrative domain can define
  265.         its EntityIDs and the specific manner in which their MTA
  266.         performs directory queries.
  267.  
  268. 7.  Implementation and Deployment Experience to Date
  269.  
  270.    Close precursors of the object class and attribute defined in this
  271.    memo have been in production use at Stanford University since May
  272.    1996. This system, known to users as the Stanford Email Alias Service
  273.    (SEAS), is based on our unique entity naming system, called Stanford
  274.  
  275.  
  276.  
  277. Hodges & Bense           Informational Track                    [Page 5]
  278.  
  279. INTERNET-DRAFT    LDAP-based Routing of SMTP Messages           Mar-1997
  280.  
  281.  
  282.    University Network Identifier (SUNetID) [7]. SEAS allows users to
  283.    promote email addresses of the form "my.name@stanford.edu" to the
  284.    Internet at large, and actually receive their email on their system
  285.    of choice within or without the Stanford.edu domain.
  286.  
  287.    SUNetID is an implementation of the EntityID concept, and our SEAS
  288.    MTA is an embodiment of an LDAP-enabled MTA -- a modified version of
  289.    sendmail [8]. The SEAS MTA receives email addressed to
  290.    "@stanford.edu", looks up the local-part of the address in the
  291.    directory, and then forwards the email message based on the
  292.    SUmailDrop attribute found in the entry returned in the lookup.
  293.  
  294.    This particular directory service instance is not yet being promoted
  295.    as a general pupose directory. Once it is, though, users will be free
  296.    to use their rfc822Mailbox (aka "mail") attribute to advertise their
  297.    preferred form of their email address. Additionally, access controls
  298.    can be applied to the various attributes of users' entries so that
  299.    the values of "internal" attributes, such as SUmailDrop can be hidden
  300.    from arbitrary queries.
  301.  
  302.    At the time of this writing, approximately 25,500 people presently
  303.    have directory entries. Of that, approximately 13,500 have
  304.    "@stanford.edu" email routing enabled. Email traffic to and from
  305.    these people generates approximately 10,000 to 11,000 email messages
  306.    per day. This number is small compared to the total daily email
  307.    volume on the campus network, but that is due largely because this
  308.    service is new and voluntary. We expect the volume of
  309.    "@stanford.edu"-addressed email to steadily grow.
  310.  
  311.    Directory performance has proven more than adequate. Directory
  312.    queries are at the rate of only once every four seconds or so, far
  313.    less than the maximum sustained "server query response" rate obtained
  314.    in testing, which was on the order of 12..16 queries per second.
  315.  
  316. 8.  Security considerations
  317.  
  318.    Security considerations are not directly discussed in this memo.
  319.  
  320. 9.  Acknowledgements
  321.  
  322.    The SUNetID team, led by Lynn McRae, designed and implemented both
  323.    the SUNetID namespace service (SUNetID) and the Stanford Email Alias
  324.    System (SEAS), as a part of which the SUrfc822Routing object class
  325.    and attendant attributes were designed. RL "Bob" Morgan, in
  326.    particular, contributed greatly to the work expressed in this
  327.    document. Yvonne Lee contributed cogent editing to this memo.
  328.  
  329. 10.  Appendix A
  330.  
  331.  
  332.  
  333. Hodges & Bense           Informational Track                    [Page 6]
  334.  
  335. INTERNET-DRAFT    LDAP-based Routing of SMTP Messages           Mar-1997
  336.  
  337.  
  338.    Source and definitions of OIDs used in this document:
  339.         stanford:                  enterprises.299
  340.  
  341.        (iso.identifiedOrganization.dod.internet.private.enterprises.299)
  342.        (1.3.6.1.4.1.299)
  343.  
  344.         # STANFORD OIDs  ("su" == Stanford University)
  345.  
  346.         suAttributeType:           stanford.1
  347.         suAttributeSyntax:         stanford.2
  348.         suObjectClass:             stanford.3
  349.  
  350.  
  351. 11.  References
  352.  
  353.    [1] S. Hardcastle-Kille, E. Huizer, V. Cerf, R. Hobby & S. Kent,
  354.        "A Strategic Plan for Deploying an Internet X.500 Directory
  355.        Service", RFC 1430, February 1993.
  356.  
  357.    [2] D. Crocker, "Standard for the format of ARPA Internet text
  358.        messages", RFC 822, August 1982.
  359.  
  360.    [3] P. Barker, S. Kille, "The COSINE and Internet X.500 Schema", RFC
  361.        1274, November 1991.
  362.  
  363.    [4] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory
  364.        Access Protocol: Standard and Pilot Attribute Definitions",
  365.        INTERNET-DRAFT (work-in-progress),
  366.        <draft-ietf-asid-ldapv3-attributes-03.txt>, October 1996.
  367.  
  368.    [5] S. Hardcastle-Kille, "Mapping between X.400(1988) / ISO 10021
  369.        and RFC 822", RFC 1327, May 1992.
  370.  
  371.    [6] S. Kille, "Use of the X.500 Directory to support mapping
  372.        between X.400 and RFC 822 Addresses", RFC 1838, August 1995.
  373.  
  374.    [7] Stanford University, "SUNetID: Stanford University Network
  375.        Identifier", v1.0, November 1996.
  376.        <URL:http://www-leland.stanford.edu/group/itss/services
  377.                   /sunetid/>
  378.  
  379.    [8] B. Bense, "Using LDAP with sendmail.8.8.x", October 1996.
  380.        <URL:http://www-leland.stanford.edu/~bbense/Inst.html>
  381.  
  382.  
  383.  
  384. 12.  Authors' Addresses
  385.  
  386.  
  387.  
  388.  
  389. Hodges & Bense           Informational Track                    [Page 7]
  390.  
  391. INTERNET-DRAFT    LDAP-based Routing of SMTP Messages           Mar-1997
  392.  
  393.  
  394.       Jeffrey D. Hodges
  395.       Computing and Communication Systems
  396.       115 Pine Hall
  397.       Stanford University
  398.       Stanford, CA  94305-4122
  399.  
  400.       Email:  Jeff.Hodges@Stanford.EDU
  401.  
  402.  
  403.       Booker Bense
  404.       Computing and Communication Systems
  405.       115 Pine Hall
  406.       Stanford University
  407.       Stanford, CA  94305-4122
  408.  
  409.       Email:  bbense@Networking.Stanford.EDU
  410.  
  411.  
  412.  
  413.  
  414.  
  415.  
  416.  
  417.  
  418.  
  419.  
  420.  
  421.  
  422.  
  423.  
  424.  
  425.  
  426.  
  427.  
  428.  
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445. Hodges & Bense           Informational Track                    [Page 8]
  446.  
  447.  
  448.  
  449.  
  450.