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
<draft-ietf-asid-email-routing-su-00.txt>
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:
"<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
( 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),
<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.
<URL:http://www-leland.stanford.edu/group/itss/services
/sunetid/>
[8] B. Bense, "Using LDAP with sendmail.8.8.x", October 1996.
<URL:http://www-leland.stanford.edu/~bbense/Inst.html>
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]
