|
|
|
|
The <EnumFilter> element specifies the LDAP search filter used for address enumeration. The search is repeated for each <BaseDN> element. If you do not specify the <EnumFilter> element, then it is calculated from the <Filter> element as follows:
The enumeration search filter will be set to the contents of the <Filter> element, except that instances of:
are replaced by %A (in order).
The %A placeholder is initially set to *, resulting in the selection of any record for which the requested attribute exists.
The following table shows the default <EnumFilter> elements for Zimbra, GroupWise, and Active Directory:
Server Type |
Default |
Zimbra |
(&(zimbraMailStatus=enabled)(|(mail=%A)(zimbraMailAlias=%A))) |
GroupWise |
(objectclass=%A) |
Active Directory |
(|(proxyAddresses=smtp:%A)(mail=%A)) |
Some LDAP servers have a limit on the number of records returned by any search. If the server returns a special error code indicating too many search results, then the application runs the search repeatedly, each time replacing, %A in order, with the following (separated in this list by semicolons (;)):
a*; b*; c* … z*; 0*; 1* … 9*; _*; .*; -*
This substitution results in up to 39 separate searches. If any of these searches return the "too many results" error code, then that particular search is divided 39 ways again. For example if a search of (mail=s*) returns too many results, it would be retried as another 39 separate searches (mail=sa*) , (mail=sb*), and so on.
The set of splits for the %A placeholder is retained from one enumeration run to the next. The split will not be re-merged unless the application is restarted or the verifier in question is altered.
Some LDAP servers, such as GroupWise and ActiveDirectory, perform very poorly when searched for attributes that do not have indices. Instead, use a broad filter as shown in the table above.