Application Working Group Bruce Greenblatt
Internet Draft
<draft-greenblatt-defema-02>
Expires in six months
Directory Entries From Email Address
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
andits 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 made obsolete
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 (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
Distribution of this document is unlimited.
Abstract
This draft describes various means for finding a user's direc-
tory entry in a LDAP directory presuming that the user's electronic
mail address is known. This draft does not presume any specific DIT
structure or schema modifications.
1. Mechanism
It is crucial to the success of finding services in the Internet
that SRV records as defined in [1] be deployed. This draft shows how
these records can be used in a straightforward manner to assist in
the location of user records. First, assume that a users email
address is of the form: name@domain, and domain is of the form: dcn.
... .dc0.tld, where: tld is a top level domain, dc0 is an IETF
registered domain name, and dcn through dc1 are locally administer
subdomains of dc1, and n is greater than or equal to 0. Examples of
Greenblatt [Page 1]
Internet Draft July 1997
valid name forms are:
- bgg@novell.com
- user@scvwd.ca.us
- foo@bar2.bar1.bar0.za
In order to find the directory entry that corresponds to these
email addresses, find the most specific domain name, i.e. dcn. ...
.dco.tld, and use this string in a DNS lookup for an LDAP [3] service
according to the mechanisms defined in [1]. If such a service is not
found, then continue stripping off domain components until the
dc0.tld component of the address is extracted and used in a DNS
lookup for an LDAP service according to the mechanisms defined in
[1]. So, in the last example above, the DNS lookups would start
with bar2.bar1.bar0.za, and if that one yields no LDAP service, the
next lookup would be for bar1.bar0.za, and if that lookup were again
not successful the third try would be for the full hostname of
bar0.za. An example SRV record that might appear in the bar0.za zone
file is:
ldap.tcp SRV 0 0 389 ldap.bar0.za
If such a service is found in one of the DNS lookups, then an
LDAP subtree search for a person object with a "mail" attribute EQUAL
to the known email address is then used. The search base for the
search should be set to the empty string, since it is not obvious
from examining the email address, what the appropriate search base
should be. It is presumed that most directory services will be
optimized for fast lookups based on email addresses. If the email
address is valid, and the LDAP server for the registered domain
either has an entry for the person, or can generate a referal to
another directory server (possibly non-LDAP, e.g. X.500, Whois++,
etc.), then we're done, and we have (or will shortly have) the direc-
tory entry in question. Just as email administrators need to put MX
records for each publicized domain in the email address, the direc-
tory administrator needs to put SRV records for the various services
for each publicized domain name.
On the other hand, if the search fails, there are several ave-
nues available to help find this user.
- the timeLimit parameter of the session control can be raised to
a higher limit.
- do a SUBSTRING search against the "mail" attribute with just the
Greenblatt [Page 2]
Internet Draft July 1997
name component
- an LDAP service for a more fully qualified domain (e.g.
dc1.dc0.tld)
can be looked up, again according to the definitions in [1]
- a well known indexing [2] Internet directory service can be
queried for the email address
Note that it is possible that there is no directory entry for
the user, in which case all possible lookups will fail. If the user's
email address and directory entry are controlled by different domains
with no links between the two domains, it will not be possible to
find the user's directory entry from the email address initially, but
if an Indexed Internet directory that has retrieved the user's direc-
tory entry from the second domain, then it is likely that the Indexed
Internet directory will be able to generate a referal to the
appropriate domain, even though we initially started out with no
direct information about that domain. For example, a directory ser-
vice for a small Internet Service Provider (smallisp.com) might be
maintained by a wider area Directory Service (bigldap.org) on a con-
tract basis. Thus, the search for an LDAP service for smallisp.com
might fail, but the ldap lookup to the Indexing Internet Directory
would result in a referal to bigldap.com. What is more likely to be
the case is that smallisp.com will create an SRV record for its LDAP
service that points to bigldap.com.
Note that this mechanism works regardless of the DIT structure.
The DIT hierarchy can be built by making use of the traditional "O="
or "OU=" containers, or it can be built making use of alternative
proposals along the lines of RFC 1279 [4]. This is due to the fact
that the proposal assumes a particular DNS infrastructure rather than
a particular X.500/LDAP infrastructure.
2. References
[1] A. Gulbrandsen, P. Vixie, "A DNS RR for specifying the location
of services (DNS SRV)," RFC 2052, October 1996.
[2] J. Allen, "The Common Indexing Protocol (CIP)," Internet Draft
(work in progress) 19 November 1996.
[3] W. Yeong, T. Howes, S. Kille, "Lightweight Directory Access Pro-
tocol", RFC 1777, March 1995.
[4] S. Kille, "X.500 and Domains", RFC 1279, November 1991.
Greenblatt [Page 3]
Internet Draft July 1997
3. Author's Address
Bruce Greenblatt
Novell
2180 Fortune Drive
San Jose, CA 95131
USA
Phone: +1-408-577-7688
Fax: +1-408-577-7605
Email: bgg@novell.com
Greenblatt [Page 4]