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
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
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
$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
@domain.com with an address of the form
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
@domain.com and never see internal addresses. A text file
reverse.txt containing lines of the form
firstname.lastname@example.org email@example.com firstname.lastname@example.org email@example.com . .' . .' . .
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 domain.com are actually of the form user@hostX.domain.com, but, fortunately, the username space is such that firstname.lastname@example.org and email@example.com specify the same person for all hosts at domain.com. 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:
REVERSE *@*.domain.com $firstname.lastname@example.org$Y$D
This mapping maps addresses of the form
$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.
- Rewrite rules
- reverse_url MTA Option
- LDAP lookups for address reversal
- REVERSE mapping table
- use_reverse_database MTA Option
- usereversedatabase Option
- reverse_envelope MTA Option
- noreverse Option
- use_text_databases MTA Option
- reverse_database_url MTA Option
- imta_reverse_database MTA Option
- imta_reverse_data MTA Option
- crdb utility
- Address reversal