PMDF System Manager's Guide

3.3.2 The Address Reversal Database and REVERSE Mapping

Header From: addresses and other backwards-pointing addresses and forwards-pointing header addresses receive one additional processing step.⁹ PMDF uses each address specification with any routing address but less any personal name fields as an index key to a special database called the address reversal database.

The address reversal database must be world readable and is generally located in the PMDF table directory. ^a This database file is built with the PMDF CRDB (OpenVMS) or pmdf crdb (UNIX and NT) utility.

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.

Note 1

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.

Note 2

If you have a compiled configuration, then you must recompile and reinstall your configuration in order for changes to the REVERSE mapping table, (or indeed for any changes to the PMDF mappings file), to take effect.

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). See Table 3-4 for a description of additional flags available for the REVERSE mapping, and Table 5-2 for a list of general mapping table substitution sequences and metacharacters.

Table 3-4 REVERSE Mapping Table Flags
Flags Description

$Y Use output as new address

$N Address remains unchanged

$D Run output through the reversal database

$A Add pattern as reverse database entry

$F Add pattern as forward database entry

Flag comparisons Description

$:B Match only header (body) addresses

$:E Match only envelope addresses

$:F Match only forward pointing addresses

$:R Match only backwards pointing addresses

$:I Match only message-ids

**Table 3-4 REVERSE Mapping Table Flags**
Flags	Description
`$Y`	Use output as new address
`$N`	Address remains unchanged
`$D`	Run output through the reversal database
`$A`	Add pattern as reverse database entry
`$F`	Add pattern as forward database entry
Flag comparisons	Description
`$:B`	Match only header (body) addresses
`$:E`	Match only envelope addresses
`$:F`	Match only forward pointing addresses
`$:R`	Match only backwards pointing addresses
`$:I`	Match only message-ids

The reverse and noreverse channel keywords, and the PMDF options USE_REVERSE_DATABASE and REVERSE_ENVELOPE may be 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.

The primary use of address reversal is to substitute a generic address (perhaps an address on a central machine) for addresses on remote, and possibly transitory, systems. Address reversal is a particularly powerful tool when used in conjunction with aliases or the directory channel.

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 PMDF CRDB (OpenVMS) or pmdf crdb (UNIX or NT) utility.

For example, suppose a site wants to replace all reverse pointing addresses of the form user@example.com with an address of the form first.last@example.com 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 first.last@example.com and never see internal addresses. A text file reverse.txt containing lines of the form

Note

The exact format needed for reverse database entries is determined by the value of the option USE_REVERSE_DATABASE in the OPTION.DAT file.

user1@example.com first1.last1@example.com user2@example.com first2.last2@example.com . . . . . .

should then be set up and converted to an address reversal database with the OpenVMS commands,

$ PMDF CRDB reverse.txt PMDF_TABLE:reverse.tmp $ RENAME PMDF_TABLE:reverse.tmp PMDF_REVERSE_DATABASE

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. or the UNIX commands,

# pmdf crdb reverse.txt /pmdf/table/reversedb

As another example, suppose that the internal addresses at example.com are actually of the form user@host.example.com, but, fortunately, the username space is such that user@hosta.example.com and user@hostb.example.com specify the same person for all hosts at example.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 *@*.example.com $0@example.com$Y$D

This mapping maps addresses of the form user@host.example.com to user@example.com. 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.

Additional examples are given in Sections 3.4 and 3.6.

Normally a REVERSE mapping or reverse database must be constructed manually. The design and maintenance of such a database is likely to be a very site-specific task. The database, for the most part, may end up being the inverse of the translations imposed by aliases on the local system. This is not a requirement, however, and it may be useful to have the database perform other, nonbijective (i.e., non-invertible), address transformations.

Although there is no address reversal database or mapping table by default, address reversal is activated automatically once such an address reversal database or REVERSE mapping exists. (Note that if you have a compiled PMDF configuration, then you must recompile---and on OpenVMS reinstall---your PMDF configuration in order for changes to the REVERSE mapping to take effect.)

Note

⁹ This processing can be restricted to only backwards pointing addresses if the third bit, bit 2, in the PMDF option `USE_REVERSE_DATABASE` is cleared; see Section 7.2.

^a On OpenVMS systems the database is the file pointed at by the `PMDF_REVERSE_DATABASE` logical, which by default points to the file `PMDF_TABLE:reverse.dat`. On UNIX systems, the database is the file pointed to by the PMDF Tailor file option `PMDF_REVERSE_DATABASE`, by default `/pmdf/table/reversedb.`. On NT systems, the database is the file pointed at by the `PMDF_REVERSE_DATABASE` Registry entry, generally `C:\pmdf\table\reversedb.`.

Contents

Index

PMDF System Manager's Guide

3.3.2 The Address Reversal Database and REVERSE Mapping

9 This processing can be restricted to only backwards pointing addresses if the third bit, bit 2, in the PMDF option USE_REVERSE_DATABASE is cleared; see Section 7.2.

⁹ This processing can be restricted to only backwards pointing addresses if the third bit, bit 2, in the PMDF option `USE_REVERSE_DATABASE` is cleared; see Section 7.2.