Application Working Group Bruce Greenblatt Internet Draft 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]