PMDF System Manager's Guide

When attempting to forward all mail for one or more hosts to another host, you must take into account mailbox name conflicts. Two sorts of conflicts may arise. First, when forwarding mail for the host old-host-1 to the host new-host, you must ascertain whether or not there are mailbox names on old-host-1 which also exist on new-host but correspond to different users. For example, suppose you forward mail for bob@old-host-1 to bob@new-host. Have you just now sent Bob Smith's mail (bob@old-host-1) to Bilbo O. Baggin's mailbox (bob@new-host)? The second potential conflict arises when forwarding both mail for old-host-1 and old-host-2 to new-host: are there conflicts between mailbox names on old-host-1 and old-host-2?

After you determine what sort of conflicts may arise, you can go ahead and set up the appropriate form of forwarding. If there are no mailbox name conflicts and the mailbox names remain unchanged, then you can use domain rewrite rules as described in Section 3.5.2.1. That is, if you will simply be forwarding all mail for user@old-host-1, user@old-host-2, ... etc., to user@new-host with no change in the user part, then you can use rewrite rules. This is the most efficient and straightforward method. If there are conflicts or the mailbox name does not remain unchanged, then you will have to use either a FORWARD mapping, alias database, or directory channel. Use of the FORWARD mapping is preferable when you can algorithmically map the incoming address to its forwarding address, e.g., if addresses of the form First.Last@example.com map to Last@host.example.com. If, however, you cannot specify a simple algorithm, then you should use either the alias database or a directory channel. Use the alias database when the incoming addresses are local addresses (e.g., old-host-1 is the local host). Otherwise, use the directory channel---or in some cases, use of a special channel marked with aliaslocal may be appropriate. The directory channel has the least optimal performance of all the options as it entails the use of an extra channel processing step. See Section 3.5.2.2 for an example in which the FORWARD mapping is used; for information on the alias database or directory channel, see, respectively, Sections 3.1.2 or 3.2.

3.5.2.1 Using Rewrite Rules to Forward Mail

old-host-1 $U%new-host$E$F old-host-2 $U%new-host$E$F

The $E$F causes these rewrite rules to only affect envelope To: addresses. It's that easy! Well, not quite. You should also consider whether or not you want to "transparently" forward these messages. The example shown above causes the forwarding to be transparent in the sense that no occurrence of user@old-host-1 in the message header will be changed. If you want those occurrences to be changed also, then remove the $E from the rewrite rules. Moreover, if you want user@old-host-1 to always be changed to user@new-host regardless of whether or not the address in question is forward (e.g., To: or cc:) or backward pointing (e.g., From:), then omit the $F.

One disadvantage to using rewrite rules to do this is that it often requires identifying and listing each old host name. If that is not feasible and you can identify the old host names via pattern matching, then use the FORWARD mapping as described in Section 3.5.2.2.

3.5.2.2 Using the FORWARD Mapping to Forward Mail

For instance, suppose that the following forwardings need to be effected:

First.Last@example.com -> LastF@example.com (no change in destination host) First_Last@example.com -> LastF@example.com (no change in destination host) "First Last"@example.com -> LastF@example.com (no change in destination host) First.Last@MR.example.com -> "Last, First"%A1@MR.VAXA.example.com First_Last@MR.example.com -> "Last, First"%A1@MR.VAXA.example.com "First Last"@Mr.example.com -> "Last, First"%A1@MR.VAXA.example.com *-LIST@Obsolete.example.com -> *-L@Listserv.example.com *%vax*@VAXA.example.com -> *@VAX*.example.com

These forwardings may be realized with the FORWARD mapping table shown in Example 3-8. The following items of note are identified with callouts in that example.

1. The first three entries do not require a $D flag as there is no change in the host name portion of the address.
2. In the left-hand column a "$ " sequence is used to represent a literal space.
3. This and subsequent entries do involve a change in host name and thus the $D flag is specified.
4. In the left hand column a $% sequence is used to represent a literal percent sign. An unquoted percent sign would be interpreted as a wild card which matches a single character as in the first three entries.

Example 3-8 Using a FORWARD Mapping Table to Forward Messages

FORWARD %*.*@example.com $2$0@example.com$Y (1) %*_*@example.com $2$0@example.com$Y "%*$ *"@example.com $2$0@example.com$Y (2) ! *.*@MR.example.com "$1,$ $0"%A1@MR.VAXA.example.com$Y$D (3) *_*@MR.example.com "$1,$ $0"%A1@MR.VAXA.example.com$Y$D "*$ *"@MR.example.com "$1,$ $0"%A1@MR.VAXA.example.com$Y$D ! *-LIST@Obsolete.example.com $0-L@Listserv.example.com$Y$D *$%vax*@VAXA.example.com $0@VAX$1.example.com$Y$D (4)

3.5.2.3 Using the Forward Database to Forward Mail

The sort of case where use of the forward database for forwarding mail is appropriate is generally when different sorts of forwarding need to be performed depending upon the source of the message being forwarded. Forward database forwarding can be made source specific, via the USE_FORWARD_DATABASE option. For instance, autoregistered addresses are often a case where source specific forwarding is appropriate; see Section 3.7.