Sun Java System Messaging Server 6.3 Administration Guide

9.2 Address Reversal

Address reversal with direct LDAP starts with a USE_REVERSE_DATABASE value of 4, which disables the use of any reverse database. You should also set USE_TEXT_DATABASES to read the IMTA_TABLE:reverse.txt file, as the sleepycat databases are being deprecated. 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:


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.

Note –

Changing REVERSE_URL for any reason is discouraged.

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

Table 9–10 local.imta.schematag Values and Attributes

Schema Tag Value 








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 value of $N cannot exactly be controlled: the MTA constructs it from its own, hard-coded (and subject to change) list of the relevant attributes for address reversal purposes. If you use the various LDAP_* global MTA options to change what the MTA thinks are the names of attributes of interest, you will, in fact, fetch different attributes from LDAP. But it is always whatever attributes that correspond semantically to the MTA's idea of relevant attributes. These are: LDAP_CAPTURE (no default), LDAP_RECIPIENTLIMIT (no default), LDAP_RECIPIENTCUTOFF (no default), LDAP_SOURCEBLOCKLIMIT (no default), LDAP_SOURCE_CHANNEL (no default), LDAP_PERSONAL_NAME (no default), LDAP_SOURCE_CONVERSION_TAG (no default), LDAP_PRIMARY_ADDRESS (mail), LDAP_ALIAS_ADDRESSES (mailAlternateAddress), LDAP_EQUIVALENCE_ADDRESSES (mailEquivalentAddress), plus the LDAP_SPARE_* attributes.

The resulting option value is:


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 appears in the domain tree and the MTA looks the address:

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


Reverse lookup returns several attributes, and the MTA knows to use the mail attribute (more precisely, the attribute named by LDAP_PRIMARY_ADDRESS) as the one for address reversal. Note that the mailEquivalentAddress (more precisely, the attribute named by LDAP_EQUIVALENCE_ADDRESSES) is also permitted.

After the URL is constructed an LDAP search is performed. If the search is successful, LDAP returns multiple attributes in essentially arbitrary order. 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.