Address Reversal

Address reversal with direct LDAP starts with a USE_REVERSE_DATABASE value of 4, which disables the use of any reverse database. It then builds on the routing facilities previously discussed. In particular, in the previous version, it began with a reverse URL specification of the form:

REVERSE_URL=ldap:///$V?mail?sub?$Q

The $V metacharacter has already been described in the context of alias URLs However, the $Q metacharacter, while quite similar in function to the $R metacharacter used in alias URLs, is specifically intended for use in address reversal. Unlike $R, it produces a filter that searches attributes containing addresses that are candidates for address reversal. The list of attributes to search comes from the MTA option LDAP_MAIL_REVERSES. If this option is not set, the local.imta.schematag configutil parameter is examined, and depending on its value, an appropriate set of default attributes is chosen.

Table 9–10 shows the local.imta.schematag values and the default attributes chosen.

The use of $Q is no longer appropriate, however. In order for message capture and other facilities to work correctly, address reversal has been enhanced to pay attention to the attribute that matched in addition to the fact that a match occurred. This means that $R should be used to specify the filter instead of $Q. Additionally, the $N metacharacter has been added, which returns a list of the attributes of interest to address reversal. The resulting option value is:

REVERSE_URL=ldap:///$V?$N?sub?$R

As always, local.imta.schematag can be a comma-separated list. If more than one schema is supported, the combined list of attributes, with duplicates eliminated, is used.

Additionally, the filter searches not only for the address that was originally supplied, but also for an address with the same local part but the domain that was actually found in the domain tree (which was saved in step 2 of Rewrite Rule Machinery). The iterative nature of the domain tree lookup means the two addresses may be different.

For example, suppose that the domain siroe.com appears in the domain tree and the MTA looks the address:

u@host1.siroe.com

The filter that results from the expansion of $R and an ims50 schema tag will be something like:

     (|(mail=u@siroe.com) 
     (mail=u@host1.siroe.com)
     (mailAlternateAddress=u@siroe.com)
     (mailAlternateAddress=u@host1.siroe.com)
     (mailEquivalentAddress=u@siroe.com)
     (mailEquivalentAddress=u@host1.siroe.com))

Note that the reverse URL explicitly specifies the attribute containing the canonicalized address. Normally this will be the mail attribute.

After the URL is constructed an LDAP search is performed. If the search is successful the first attribute value returned replaces the original address. Unsuccessful searches or errors leave the original address unchanged.

Due to the frequency with which address reversal operations are performed, especially given the number of addresses that can appear in a message header, and the expense of the directory queries involved, both negative and positive results need to be cached. This is implemented with an in-memory, open-chained, dynamically-expanded hash table. The maximum size of the cache is set by the REVERSE_ADDRESS_CACHE_SIZE MTA option (default 100000) and the timeout for entries in the cache is set by the REVERSE_ADDRESS_CACHE_TIMEOUT MTA option (default 600 seconds). The cache actually stores addresses themselves, not the LDAP URLs and LDAP results.