[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00                                                            
Network Working Group                                  Jeffrey D. Hodges
INTERNET-DRAFT                                              Booker Bense
Track: Informational                                 Stanford University
                                                           26 March 1996

  LDAP-based Routing of SMTP Messages: Approach at Stanford University

Status of this Memo

   This document is an Internet Draft.  Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas,
   and its Working Groups.  Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months.  Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a
   ``working draft'' or ``work in progress''.

   To learn the current status of any Internet-Draft, please check the
   1id-abstracts.txt listing contained in the Internet-Drafts Shadow
   Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or

   A revised version of this draft document will be submitted to the RFC
   editor for consideration as an Informational RFC for the Internet
   Community.  Discussion and suggestions for improvement are requested.
   This document will expire in September 1997. Distribution of this
   draft is unlimited.

1.  Abstract

   The "Internet X.500 Schema" defines an RFC-822 email address
   attribute of a person's entry, rfc822Mailbox (aka "Mail"), but it
   does not address the issues involved in routing RFC-822-based email
   within an administrative domain served by an X.500/LDAP-based
   directory service. Significantly, it doesn't delineate between a
   person's publicaly "advertised" or "promoted" email address and the
   actual "internal to the administrative domain" address for the

   This memo illustrates an object class and an attendant attribute we
   use at Stanford University to solve this issue. This scheme provides
   us with flexible, simple to implement, distributed routing of RFC-

Hodges & Bense           Informational Track                    [Page 1]

INTERNET-DRAFT    LDAP-based Routing of SMTP Messages           Mar-1997

   822-based email to people represented by entries within our directory
   service. The LDAP-enabled version of sendmail we use is freely

   Additionally, we anticipate that the Internet community will devise
   conventions and perhaps support a process for facilitating multi-
   vendor directory utilization. We present an anticipated tenet and

2.  Motivation and Background

   Directory enabled email routing has long been a goal of the overall
   directory service effort in the Internet [1]. Although one can claim
   it has been long implemented in a sort of "once removed" fashion via
   the marriage local user account names and DNS host names via RFC-822
   format addresses [2], there are, as yet, no Internet standards or
   informational documents defining general purpose, directory-enabled,
   X.500/LDAP-based routing of RFC-822-based email messages.

   The "Internet X.500 Schema" [3, 4] defines an RFC-822 email address
   attribute of a person's entry, rfc822Mailbox (aka "Mail"), plus, RFCs
   exist covering the topics of directory enabled mapping between RFC-
   822- and X.400-based email message formats, and of directory enabled
   routing of  X.400-based email messages [5, 6]. But, they do not cover
   delivery of RFC-822-based email messages to users, nor do they
   address the issues of providing a level of indirection for
   administrative domain oriented email routing.

   One of the most common and significant issues of providing email
   service to a body of users is providing a stable, relatively simple
   email address for users to advertise to the Internet at large that
   provides for user account mobility within the administrative domain.
   Many approaches exist for solving this issue, but using a general-
   purpose, standards-based directory service to do so brings along many
   obvious benefits.

   This memo defines an attribute and its semantics that enable the
   routing, via an LDAP/X.500-based directory, of email messages
   addressed as "entity@domain", where entity's actual mail server may
   be any machine within or without the domain. Note that this scheme
   presupposes that the administrative domain has implemented some sort
   of unique entry naming scheme -- i.e. there is an entry naming scheme
   that ensures that a person's "advertised" email address maps uniquely
   back to that person's directory entry. This "entry naming" topic thus
   is related, but orthogonal, to the topic covered here. It will be
   discussed in a companion Internet-Draft, to be issued in the near

Hodges & Bense           Informational Track                    [Page 2]

INTERNET-DRAFT    LDAP-based Routing of SMTP Messages           Mar-1997

3.  Anticipated Tenet and Goals for Multi-vendor Directory Utilization

   The approach to email routing described in this memo is only one way
   to address that issue. We expect that various vendors and
   institutions will devise other approaches.  We feel the key,
   underlying tenet of multi-vendor directory utilization will be that
   various vendor- and system-specific object classes and attributes
   peacefully coexist, rather than necessarily interoperate or interfere
   with each other. Further, we feel that promoting and supporting reuse
   of object classes and attributes will yield various benefits to
   people designing and/or deploying directory-based systems. We
   anticipate that these goals will be reached through some form of
   generally-accepted, Internet-wide schema documentation and
   registration process.

   In anticipation of this, we've prefixed the names of the object class
   and attribute in this memo with the string "SU". Such "uniqifying" of
   object class and attribute names is necessary in the LDAP world
   because the names themselves, not object identifiers (OIDs), are
   carried in protocol. Plus it allows for other vendors or institutions
   to define similar attributes that differ in details such as precise
   semantics and syntax, and allow for them to have similar names. For
   example, a vendor may define their own version of a "rfc822Routing"
   object class, and can differentiate it by naming it like:
   "<vendor>rfc822Routing". However, if an attribute and object class is
   officially standardized upon by the IETF, we anticipate that
   uniqifying information, such as a prefix, would be dropped.

4.  Definition of the SUrfc822Routing Object Class

       NAME 'SUrfc822Routing'
       SUP top
       MUST SUmailDrop

   This object class provides an attribute that enables site-specific
   routing of RFC-822-based email messages to an entity represented by
   the directory entry to which this attribute is attached. The format
   above, and of those below, is as defined in [4].

5.  Definition of the SUmailDrop Attribute

       NAME 'SUmailDrop' 'SUrfc822RoutingAddress'
       DESC 'address to where admin domain MTA forwards this entry's

Hodges & Bense           Informational Track                    [Page 3]

INTERNET-DRAFT    LDAP-based Routing of SMTP Messages           Mar-1997

       SUP mail

   The SUmailDrop attribute indicates to where a site-specific email
   routing system should forward rfc822-based email intendend for the
   person represented by the entry it is a part of. It is based on the
   "mail" attribute, whose AttributeTypeDescription, from [4], is given
   below. The syntax of this attribute is that it must contain a RFC-822
   address [2].

      ( 0.9.2342.19200300.100.1.3 NAME 'mail'
        EQUALITY caseIgnoreIA5Match
        SUBSTRINGS caseIgnoreIA5SubstringsMatch
        SYNTAX 'IA5String{256}' )

6.  A Simple Tutorial Example

   Here is an outline of the steps that administrative domain
   administrators need to go through to route RFC 822-based email via
   the SUrfc822Routing object class and SUmailDrop attribute.

   This example assumes that the administrative domain has some system
   of assigning at least one guaranteed-unique identifier value to each
   involved individual. We'll call this "guaranteed-unique identifier
   value" an "EntityID" in this example, but discussion of generating
   and assigning EntityIDs is outside the scope of this memo.

   Let's suppose there's a user named "Im A. User", whose administrative
   domain is isp-r-us.com. Im A. User has an account on a machine called
   "ImasMachine", which is registered in the isp-r-us.com domain and is
   where she reads her email. Her account is "imasacnt", and
   "imasacnt@ImasMachine.isp-r-us.com" is her actual email address.

   Let's further suppose that isp-r-us.com has an LDAP/X.500-based
   directory service and has assigned Im A. User an EntityID of
   "Im.A.User". They've chosen to map their users' EntityIDs to one
   value of their user's "cn" attribute.

   isp-r-us.com also runs a Mail Transfer Agent (aka "MTA", an example
   of which is the "sendmail" daemon on UNIX-based systems) on isp-r-
   us.com, which accepts mail addressed to "name@isp-r-us.com", performs
   a lookup in the isp-r-us.com directory service with a filter of
   "(cn=name)", and sends the email message to the address specified in
   the returned entry's "SUmailDrop" attribute. Note that the message
   will not be immediately routable if the "name" is not an existing
   EntityID in the directory.

Hodges & Bense           Informational Track                    [Page 4]

INTERNET-DRAFT    LDAP-based Routing of SMTP Messages           Mar-1997

   So, Im A. User's directory entry ends up looking something like this:

      objectClass: top
      objectClass: person
      objectClass: SUrfc822Routing
      cn: Im A. User
      cn: I. A. User
      cn: Im.A.User
      mail: Im.A.User@isp-r-us.com
      SUmailDrop: imasacnt@ImasMachine.isp-r-us.com

   Thus, Im A. User may widely promote the email address
   "Im.A.User@isp-r-us.com" and email sent to that address will be
   routed to imasacnt@ImasMachine.isp-r-us.com, where she can read it.

   Things to note:

        isp-r-us.com chose to map EntityIDs to a value of the "cn"
        attribute. They could have chosen to map it to some other
        attribute if they wished. The critical link is having the MTA
        filter on whatever attribute they decide on using.

        Im A. User's Distinguished Name isn't shown above. This is
        because it is irrelevant in this example. This scheme doesn't
        depend on having any particular directory naming hierarchy in
        place. We're assuming that the administrative domain has
        configured the MTA to be able to do entry lookups given only the
        EntityID of an entry. This implies, for an LDAP-based directory,
        configuring the MTA with the "base distinguished name" to use
        with the "cn=EntityID" filter for such lookups. However, there
        are many alternative ways the administrative domain can define
        its EntityIDs and the specific manner in which their MTA
        performs directory queries.

7.  Implementation and Deployment Experience to Date

   Close precursors of the object class and attribute defined in this
   memo have been in production use at Stanford University since May
   1996. This system, known to users as the Stanford Email Alias Service
   (SEAS), is based on our unique entity naming system, called Stanford

Hodges & Bense           Informational Track                    [Page 5]

INTERNET-DRAFT    LDAP-based Routing of SMTP Messages           Mar-1997

   University Network Identifier (SUNetID) [7]. SEAS allows users to
   promote email addresses of the form "my.name@stanford.edu" to the
   Internet at large, and actually receive their email on their system
   of choice within or without the Stanford.edu domain.

   SUNetID is an implementation of the EntityID concept, and our SEAS
   MTA is an embodiment of an LDAP-enabled MTA -- a modified version of
   sendmail [8]. The SEAS MTA receives email addressed to
   "@stanford.edu", looks up the local-part of the address in the
   directory, and then forwards the email message based on the
   SUmailDrop attribute found in the entry returned in the lookup.

   This particular directory service instance is not yet being promoted
   as a general pupose directory. Once it is, though, users will be free
   to use their rfc822Mailbox (aka "mail") attribute to advertise their
   preferred form of their email address. Additionally, access controls
   can be applied to the various attributes of users' entries so that
   the values of "internal" attributes, such as SUmailDrop can be hidden
   from arbitrary queries.

   At the time of this writing, approximately 25,500 people presently
   have directory entries. Of that, approximately 13,500 have
   "@stanford.edu" email routing enabled. Email traffic to and from
   these people generates approximately 10,000 to 11,000 email messages
   per day. This number is small compared to the total daily email
   volume on the campus network, but that is due largely because this
   service is new and voluntary. We expect the volume of
   "@stanford.edu"-addressed email to steadily grow.

   Directory performance has proven more than adequate. Directory
   queries are at the rate of only once every four seconds or so, far
   less than the maximum sustained "server query response" rate obtained
   in testing, which was on the order of 12..16 queries per second.

8.  Security considerations

   Security considerations are not directly discussed in this memo.

9.  Acknowledgements

   The SUNetID team, led by Lynn McRae, designed and implemented both
   the SUNetID namespace service (SUNetID) and the Stanford Email Alias
   System (SEAS), as a part of which the SUrfc822Routing object class
   and attendant attributes were designed. RL "Bob" Morgan, in
   particular, contributed greatly to the work expressed in this
   document. Yvonne Lee contributed cogent editing to this memo.

10.  Appendix A

Hodges & Bense           Informational Track                    [Page 6]

INTERNET-DRAFT    LDAP-based Routing of SMTP Messages           Mar-1997

   Source and definitions of OIDs used in this document:
        stanford:                  enterprises.299


        # STANFORD OIDs  ("su" == Stanford University)

        suAttributeType:           stanford.1
        suAttributeSyntax:         stanford.2
        suObjectClass:             stanford.3

11.  References

   [1] S. Hardcastle-Kille, E. Huizer, V. Cerf, R. Hobby & S. Kent,
       "A Strategic Plan for Deploying an Internet X.500 Directory
       Service", RFC 1430, February 1993.

   [2] D. Crocker, "Standard for the format of ARPA Internet text
       messages", RFC 822, August 1982.

   [3] P. Barker, S. Kille, "The COSINE and Internet X.500 Schema", RFC
       1274, November 1991.

   [4] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory
       Access Protocol: Standard and Pilot Attribute Definitions",
       INTERNET-DRAFT (work-in-progress),
       <draft-ietf-asid-ldapv3-attributes-03.txt>, October 1996.

   [5] S. Hardcastle-Kille, "Mapping between X.400(1988) / ISO 10021
       and RFC 822", RFC 1327, May 1992.

   [6] S. Kille, "Use of the X.500 Directory to support mapping
       between X.400 and RFC 822 Addresses", RFC 1838, August 1995.

   [7] Stanford University, "SUNetID: Stanford University Network
       Identifier", v1.0, November 1996.

   [8] B. Bense, "Using LDAP with sendmail.8.8.x", October 1996.

12.  Authors' Addresses

Hodges & Bense           Informational Track                    [Page 7]

INTERNET-DRAFT    LDAP-based Routing of SMTP Messages           Mar-1997

      Jeffrey D. Hodges
      Computing and Communication Systems
      115 Pine Hall
      Stanford University
      Stanford, CA  94305-4122

      Email:  Jeff.Hodges@Stanford.EDU

      Booker Bense
      Computing and Communication Systems
      115 Pine Hall
      Stanford University
      Stanford, CA  94305-4122

      Email:  bbense@Networking.Stanford.EDU

Hodges & Bense           Informational Track                    [Page 8]