Address reversals are not applied to envelope To: addresses. The reasons for this omission are fairly obvious --- envelope To: addresses are continuously rewritten and modified as messages proceed through the mail system. The entire goal of routing is to convert envelope To: addresses to increasingly system and mailbox-specific formats. The canonicalization functions of address reversal are entirely inappropriate for envelope To: addresses.

In any case, plenty of machinery is available in PMDF to perform substitutions on envelope To: addresses. The alias file, alias database, and general database, as well as the directory channel and its associated databases, provide precisely this functionality.

PMDF also has available the forward database and FORWARD mapping, used for special sorts of forwarding purposes, such as pattern based forwarding, source-specific forwarding, or "autoregistration" of addresses. Note that the forward database and FORWARD mapping are intended for use primarily for certain special sorts of address forwarding; most sorts of address forwarding, however, are better performed using one of PMDF's other forwarding mechanisms. See Section 3.5 for an overview of various forwarding techniques.

The various substitution mechanisms for envelope To: addresses discussed previously provide functionality equivalent to the reversal database, but none yet discussed provide functionality equivalent to the reverse mapping. And circumstances do arise where mapping functionality for envelope To: addresses is useful and desirable.

The FORWARD mapping table provides this functionality of pattern based forwarding, and also provides a mechanism for source specific forwarding. If a FORWARD mapping table exists in the mapping file, it is applied to each envelope To: address. No changes are made if this mapping does not exist or no entries in the mapping match. See Chapter 5 for details on the mapping file.

If the address matches a mapping entry, the result of the mapping is tested. The resulting string will replace the envelope To: address if the entry specifies a $Y ; a $N will discard the result of the mapping. See Table 3-5 for a list of additional flags.

The FORWARD mapping, if present, is consulted before any forward database lookup. If a FORWARD mapping matches and has the flag $G , then the result of the FORWARD mapping will be checked against the forward database, if forward database use has been enabled via the appropriate setting of USE_FORWARD_DATABASE . (Note that if channel specific forward database use has been specified, then the source address and source channel will be prefixed to the result of the FORWARD mapping before looking up in the forward database.) If a matching FORWARD mapping entry specifies $D , then the result of the FORWARD mapping (and optional forward database lookup) will be run through the PMDF address rewriting process again. If a matching FORWARD mapping entry specifies $H , then no further FORWARD mapping or database lookups will be performed during that subsequent address rewriting (that resulting from the use of $D ).

Table 3-5 FORWARD Mapping Table Flags

Flags	Description
$Y	Use output as new address
$N	Address remains unchanged
$D	Run output through the rewriting process again
$G	Run output through the forward database, if forward database use has been enabled
$H	Disable further forward database or FORWARD mapping lookups
$I	Hold the message as a .HELD file

Example 3-7 illustrates the use of a complex REVERSE and FORWARD mapping. Suppose that a system or pseudo domain named am.sample.example.com associated with the mr_local channel produces RFC 822 addresses of the general form:

"lastname, firstname"@am.sample.example.com

or

"lastname,firstname"@am.sample.example.com

Although these addresses are perfectly legal they often confuse other mailers which do not fully comply with RFC 822 syntax rules --- mailers which do not handle quoted addresses properly, for instance. Consequently, an address format which does not require quoting tends to operate with more mailers. One such format is

firstname.lastname@am.sample.example.com

Example 3-7 A Complex FORWARD and REVERSE Mapping Example

REVERSE *|mr_local|"*,$ *"@am.sample.example.com $Y"$1,$ $2"@am.sample.example.com *|mr_local|"*,*"@am.sample.example.com $Y"$1,$ $2"@am.sample.example.com *|*|"*,$ *"@am.sample.example.com $Y$3.$2@am.sample.example.com *|*|"*,*"@am.sample.example.com $Y$3.$2@am.sample.example.com *|mr_local|*.*@am.sample.example.com $Y"$2,$ $1"@am.sample.example.com *|*|*.*@am.sample.example.com $Y$2.$3@am.sample.example.com FORWARD "*,$ *"@am.sample.example.com $Y"$0,$ $1"@am.sample.example.com "*,*"@am.sample.example.com $Y"$0,$ $1"@am.sample.example.com *.*@am.sample.example.com $Y"$1,$ $0"@am.sample.example.com

So the goals of the sample mapping tables in Example 3-7 are threefold. (1) Allow any of these three address formats above to be used. (2) Present only addresses in the original format to the mr_local channel, converting formats as necessary. (3) Present only addresses in the new unquoted format to all other channels, converting formats as necessary. (The REVERSE mapping shown assumes that bit 3 in the PMDF option USE_REVERSE_DATABASE is set; see Section 7.2.)

In cases where address forwardings need to be autoregistered, or source specific, the forward database is available. Note that use of the forward database for simple forwarding of messages is generally not appropriate; the alias database is a more efficient way to perform such forwarding. By default, the forward database is not used at all; its use must be explicitly enabled via the USE_FORWARD_DATABASE option, as described in Section 7.3.1. Forward database lookups are performed after address rewriting and after alias expansion is performed, and after any FORWARD mapping is checked. If a forward database lookup succeeds, the resulting substituted address is then run through the PMDF address rewriting process all over again.

The forward database is a PMDF crdb database, created using the PMDF CRDB (OpenVMS) or pmdf crdb (UNIX or NT) utility from a source text file. The format of the source text file by default is expected to be:

user1@domain1 changedmailbox1@changeddomain1 user2@domain2 changedmailbox@changeddomain2

But if source specific use of the forward database has been enabled by setting bit 3 of the USE_FORWARD_DATABASE option, then the source text file format expected is:

source-channel|source-address|original-address changed-address

For instance, an entry such as

snads_local|Bobby@BLUE|12345678@PMDF user.with.a.long.name@else.where.com

would allow the Bobby@BLUE SNADS user to send to a SNADS address of 12345678@PMDF when they want to send to user.with.a.long.name@else.where.com .