Header From: addresses and other backward-pointing headers receive one additional processing step. This processing can be extended to all header addresses if the third bit (bit 2) in the IMTA option USE_REVERSE_DATABASE is set. While uid@mailhost.alpha.com is the fully qualified form of the address, mail recipients, especially those outside the company, should not see the address in that form. The reverse database allows you to specify a per-user return address, which is the preferredRfc822Originator address in the directory.
The reverse database is created each time you run the imta dirsync command.
The address-reversal database is generally located in the IMTA database directory. The database is the files whose names are specified with the IMTA_REVERSE_DATABASE option in the /etc/opt/SUNWmail/imta/imta_tailor file, which by default are the files /var/opt/SUNWmail/imta/db/reversedb.*.
Note - Do not edit this database directly. Any required changes must be done in the directory.
If the address is found in the database, the corresponding right-hand side from the database is substituted for the address. If the address is not found, an attempt is made to locate a mapping table named REVERSE in the mapping file. No substitution is made and rewriting terminates normally if the table does not exist or no entries from the table match.
Reverse mapping can also be performed on a per-channel basis. src_channel| destination and channel| internal addresses need to be mapped to *|tcp_local|*@*.acme.com and $|@acme.com$Y.
If the address matches a mapping entry, 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).
As an example, suppose that the internal addresses at acme.com are actually of the form user@host.acme.com, but, unfortunately, the user name space is such that user@hosta.acme.com and user@hostb.acme.com specify the same person for all hosts at acme.com. Then the following, very simple REVERSE mapping may be used in conjunction with the address-reversal database:
REVERSE
*@*.acme.com $0@host.acme.com$Y$D
This mapping maps addresses of the form user@host.acme.com to user@host.acme.com. The $D metacharacter causes the address-reversal database to be consulted. The address-reversal database should contain entries of the form:
user@host.acme.com first.last@acme.com
The reverse and noreverse channel keywords, and the IMTA options USE_REVERSE_DATABASE and REVERSE_ENVELOPE may used to control the specifics of when and how address reversal is applied. In particular, address reversal will not be applied to addresses in messages when the destination channel is marked with the noreverse keyword. If USE_REVERSE_DATABASE is set to 0, address reversal will not be used with any channel. The REVERSE_ENVELOPE option controls whether or not address reversal is applied to envelope From: addresses as well as message header addresses. See the descriptions of these options and keywords for additional information on their effects. By default, the address reversal database is used if the routability scope is set to the mail server domains.