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 munnari.oz.au. 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 person. 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 available. 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 goals. 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 future. 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: "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 ( 1.3.6.1.4.1.299.3.1 NAME 'SUrfc822Routing' SUP top AUXILIARY 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 ( 1.3.6.1.4.1.299.1.1 NAME 'SUmailDrop' 'SUrfc822RoutingAddress' DESC 'address to where admin domain MTA forwards this entry's email' Hodges & Bense Informational Track [Page 3] INTERNET-DRAFT LDAP-based Routing of SMTP Messages Mar-1997 SUP mail SINGLE-VALUE ) 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 (iso.identifiedOrganization.dod.internet.private.enterprises.299) (1.3.6.1.4.1.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), , 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]