Reverse database

From Messaging Server Technical Reference Wiki
Jump to: navigation, search

During the address reversal stage of address processing (which note occurs after rewriting via the MTA's rewrite rules), first any reverse_url LDAP-based address reversal is performed, as discussed in LDAP lookups for address reversal. After any such LDAP-based address reversal, then header From: addresses and other backwards-pointing addresses and forwards-pointing header addresses may receive yet another address reversal processing step which makes use of the address reversal database and REVERSE mapping.9

The relevance of the address reversal database is quite limited nowadays, as nowadays the sorts of changes it used to be used to make are instead performed via LDAP lookups for address reversal. However, the process of its use will be described below.

When use of the address reversal database has been configured, the MTA uses each address specification, with any routing address but less any personal name fields, as an index key to the special database called the reverse database.10

Note that the format of probes to the reverse database (and to the REVERSE mapping table) can be affected by the use_reverse_database MTA option.

If the address is found in the reverse database, the corresponding right hand side from the database is substituted for the address.

If the address is not found, then an attempt is made to locate a mapping table named REVERSE. No substitution is made and rewriting terminates normally if the table does not exist or no entries from the table match. But if the address does match a REVERSE mapping entry, then the result of the mapping is tested. The resulting string will replace the address if the entry specifies a $Y; a $N will discard the result of the mapping. If the mapping entry specifies $D in addition to $Y, the resulting string will be run through the reversal database once more, and if a match occurs the template from the database will replace the mapping result (and hence the address).

Note that you do not need to have an address reversal database in order to use a REVERSE mapping. That is, you can use a REVERSE mapping without having an address reversal database. And, of course, the reverse is true: you do not need to have a REVERSE mapping to use an address reversal database. Prior to the implementation of LDAP lookups for address reversal, this back-and-forth consultation of reverse database, REVERSE mapping, optionally reverse database again, was intended to allow convenient use and combination of the strengths of each facility: the reverse database's ability to make changes exactly targeted to a single address, and the REVERSE mapping's ability to make generic, pattern-based changes to addresses. Nowadays, typically changes targeted to a single address are made via the LDAP entry for the user with that address, superceding former uses of the address reversal database, and even the REVERSE mapping table tends to get used only for special circumstances.

Entries in the address reversal database consist of two e-mail addresses: the address to match against and the address with which to replace a match. The database is usually created by preparing a text file and processing it with the imsimta crdb utility.

For example, suppose a site wishes to replace all reverse pointing addresses of the form with an address of the form where first.last is formed from the first (given) and last (family) names of the owner of the account user. This will then cause the outside world to only see addresses of the form and never see internal addresses. A text file reverse.txt containing lines of the form 
     .                      .'     .                      .'     .                      .

could then be set up and converted to an address reversal database with the UNIX commands,

# imsimta crdb reverse.txt IMTA_DATAROOT:db/reversedb-tmp
# imsimta renamedb IMTA_DATAROOT:db/reversedb-tmp IMTA_DATAROOT:db/reversedb

An intermediate, temporary database is used so as to minimize any window of time during which the database file is in an undefined state as it is being generated or regenerated.

As another example, suppose that the internal addresses at are actually of the form, but, fortunately, the username space is such that and specify the same person for all hosts at Then, rather than have to enter all possible user and host combinations in the address reversal database, the following, very simple REVERSE mapping may be used in conjunction with the address reversal database:

  *@*           $$Y$D 

This mapping maps addresses of the form to The $D flag causes the address reversal database to then be consulted. The address reversal database should contain entries of the form shown in the previous example.

Although there is no address reversal database or REVERSE mapping table by default, their use for address reversal is activated automatically once such an address reversal database (depending upon the use_reverse_database MTA option value) or REVERSE mapping exists.

9Address reversal processing can be restricted to only backwards pointing addresses if the third bit, bit 2, in the MTA option use_reverse_database is cleared. Application of this processing to envelope From address can be disabled using the reverse_envelope MTA option. The noreverse channel option can disable address reversal from being performed during enqueues to particular destination channels. However, note that at typical Messaging Server sites such options should not be used -- address reversal should not be disabled -- as a wide range of functionality, including functionality that might not at first glance seem to be address reversal related, depends critically upon normal address reversal processing.

10 Depending upon the setting of the MTA option use_text_databases, the reverse "database" is either stored and accessed as an on-disk database (the default), or as an in-memory structure constructed (during configuration compilation or MTA initialization) from an on-disk flat text file. Or new in MS 8.0, the reverse "database" can be stored in memcache; see the reverse_database_url MTA option. The on-disk database, if that is what is being used, used to be located via the (now deleted) imta_reverse_database MTA Tailor option; nowadays its location is simply IMTA_DATAROOT:db/reversedb. This database file is built with the imsimta crdb utility from some site-supplied source text file, and the database itself must be world-readable for proper operation. If an in-memory database structure is instead being used, then when the MTA configuration is compiled (or at MTA process initialization time, if a compiled configuration is not in use) the MTA reads the file IMTA_TABLE:reverse.txt (formerly relocatable via the imta_reverse_data MTA Tailor option) and compiles it into an in-memory structure. This file should be world-readable for proper operation. Use of an in-memory "database" is normally recommended (for reasons of performance and reliability); however, do note that use of this in-memory "database" does require recompiling and reloading the configuration to get changes to the "database" (changes to the source text file) incorporated into the active configuration.

See also: