Creating a well defined LDAP directory query interface for email clients

As part of my job running Stanford's Directory service, I've had to look at many email clients LDAP directory interface for gathering addressbook related information. What I've found is that there is no unified concept on how to do this, and the method used is often so poorly done as to be unusable in any real sense. This document is to present a guideline on writing a well written LDAP directory interface for an email client, in the hopes that various email client developers will read it and make use of it.

1. Filter string
   The first part of an LDAP query is the search filter used to define what attributes are checked against. Few email clients actually allow you to define this filter string, which greatly limits the capabilities of the client. Even worse, most email clients assume particular attributes will be used for the search filters, when that may not be the case. The fact that search filters should be customizable is ignored by nearly all email clients.
2. Attributes
   Many organizations have created, or will create, their own attributes to hold various pieces of information, as many default schemas simply do not have the requesite attributes necessary for their purposes. Few email clients allow you to specify how custom attributes will map into the addressbook. Even worse, most email clients enforce their own concepts of how the directory information is stored on the user, which is often unworkable. Email clients also tend to limit what data is returned from the server, cutting out information of potential use to the user.
3. Authentication mechanisms
   Starting with LDAP Protocol v3, there are a variety of authentication mechanisms available to use to query directory services. However, as far as I have found, there is not a single email client that implements these alternative mechanisms. Most rely on the LDAP Protocol version 2 simple bind using username/password either in the clear or over SSL. None of them appear to implement the required LDAP Protocol version 3 mechanism, SASL/External. There also is no support for other SASL mechanisms, like DIGEST-MD5 or GSSAPI. It is critical that the email clients be RFC compliant, and implement multiple methods for authenticating to the LDAP Directory service.

Eudora is the only email client software I've found that understands the first two concepts required to write a well written client interface to an LDAP server.

• Search filter: Eudora allows you to fully define how the search filter works with its "Word-Wise Search Filter" configuration option. It uses the special string ^0 to represent the text being searched for, and then allows you to define the filter going to the directory. An example Eudora search filter:
  (|(cn=*^0*)(sn=*^0*)(mail=^0@*)(susearchid=^0)(telephonenumber=*^0*)(suuniqueidentifier=^0))
  
  In this case, the user is able to define their own custom search filter to be used to find results from the directory, including the use of custom attributes.
  
  
• Attributes: Eudora allows you to map the attributes from the directory into the address book. The user simply goes to the "Attributes Tab:" for the directory server setup, and defines what attribute from the server should be mapped to various addressbook values. For example:
  
  • displayName presented as Name
  • title presented as Title
  • ou presented as Division
  • street presented as Street(w)
  • suMailAddress presented as Street(h)
  
  This ability to map attributes to the address book again allows the user to use custom attributes for gathering data. In addition, a common fallacy of email clients is the assumption that the "cn" attribute is what should be used for name information. It is entirely possible that the "cn" attribute does not contain the best representation of a persons name, and being able to specify another attribute for that information is the correct way to handle things. Another excellent feature of Eudora is the capability to see all attributes returned for a given entry if that is desired, which can help the user map attributes to their addressbook, and then they can disable the feature for that LDAP server going forward.