Reverse database

During the address reversal stage of address processing (which note occurs after rewriting via the MTA&#x27;s rewrite rules), first any     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    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   mapping table)  can be affected by the    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. 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   mapping entry,  then the result of the  mapping is tested. The resulting string will replace the address if the entry specifies a  ; a   will discard the  result of the mapping. If the mapping entry specifies   in addition to , 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    mapping. That is, you can use a  mapping without having  an address reversal database. And, of course, the reverse is true: you do not need to have a   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,    mapping,  optionally reverse database again, was intended to allow convenient use  and combination of the strengths of each facility: the reverse  database&#x27;s ability to make changes exactly targeted to a single  address, and the   mapping&#x27;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  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    utility.

For example, suppose a site wishes to replace all reverse pointing addresses of the form     with an address of the form     where    is formed from the first (given) and  last (family) names of the owner of the account. This will then cause the outside world to only see addresses of the form     and never see internal  addresses. A text file  containing lines of the  form user1@domain.com first1.last1@domain.com user2@domain.com first2.last2@domain.com     .                      .'     .                      .'     .                      . could then be set up and converted to an address reversal database with  the UNIX commands, 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.
 * 1) imsimta crdb reverse.txt IMTA_DATAROOT:db/reversedb-tmp
 * 2) imsimta renamedb IMTA_DATAROOT:db/reversedb-tmp IMTA_DATAROOT:db/reversedb

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 user@hosta.domain.com and user@hostb.domain.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    mapping may be used in  conjunction with the address reversal database: REVERSE &#x2a;@&#x2a;.domain.com          $0@domain.com$Y$D This mapping maps addresses of the form       to  . The  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  mapping table by  default, their use for address reversal is activated automatically once such an  address reversal database (depending upon the    MTA  option value) or   mapping exists.

9Address reversal processing can be restricted to only backwards pointing addresses if the third bit, bit 2, in the MTA  option   is cleared. Application of this processing to envelope From address can be disabled using the    MTA option. The  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 ,  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   MTA option. The on-disk database, if that is what is being used, used to be located via the (now deleted)   MTA Tailor option; nowadays its location is simply. This database file is built with the    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   (formerly relocatable via the   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:
 * 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