PMDF System Manager's Guide

The ability of rewrite rules to map an address to a system that does not appear in the channel table can be used to advantage in some cases. Suppose PMDF has to contend with a strict subset of a large local DECnet network. The simplest way to handle a large local DECnet network is to place all the systems in a domain (e.g., .firm.com) and use a general rewrite rule of the form:

.firm.com $U%$H@decnet-mail

However, this does not limit access to a subset of the local DECnet; any address that ends in .firm.com will work. The alternative is to list all the accessible systems explicitly, giving each system its own entry in the rewrite rule table, and omit the more general rule. But suppose that another rewrite exists to map all non-local systems in the .com domain to a gateway system:

.com $U%$H.com@gateway-system

Then an illegal address of the form user@bad-system.firm.com will be routed to the gateway, which is incorrect and may even result in a mail loop if the gateway returns the message improperly.

One solution is to list all the local systems in the channel table instead of using rewrite rules. This solves the problem at the expense of making the channel table very large. Channel table entries, unlike rewrite rules, cannot be placed in an auxiliary database. Ultimately, large numbers of channel table entries may have an adverse impact on the performance of PMDF.

A better solution is to keep the individual rewrite rules for all the local systems and insert a rule that deliberately rewrites an unknown address in the local domain to an illegal system (which might as well be the unknown system itself):

.firm.com $U@$H$D

When an illegal local system name is used this rule will be activated before the more general .com rule is used and the address will immediately be found to be illegal.