General PMDF configurations are usually set up to allow very flexible address rewriting, fixing up as many sorts of addresses as possible no matter what source the address comes in from. In a firewall configuration, however, you may wish to control which sorts of rewriting happen for which sorts of messages. Therefore source and destination specific, and direction specific rewrite rules may be of particular interest. (This is akin/related to the point below regarding centralized naming, that a technique such as a directory channel (with a directory database), which isolates the address transformation to a particular channel, allowing for greater control at the cost of some additional overhead, may be more appropriate than the (more efficient but more "inline") alias database, general database, or mapping table sorts of approaches.)
For instance, consider a common setup where externally originating messages to internal users are expected to be addressed using a centralized format without internal node names, and where a directory channel (with a directory database) is then used to transform the addresses to the true internal address format. In a firewall configuration you may want to ensure not only that the centralized addresses work, but that only the centralized addresses work. So for instance, you might have a rewrite rule for the centralized domain routing it to the directory channel, and then make the rewrite rules for the true internal domains (routing such addresses to channels for sending internal) be source channel specific rewrite rules that only apply for messages coming from the directory channel.
29.4.4.1 Sample configuration controlling internal domain rewriting
For instance, consider a site that wishes to accept messages addressed
in the form First.Last@acme.com, route such
messages to the directory channel where a directory database will
transform the address to internal addresses such as
FLast@hosta.acme.com, or
Last@hostb.acme.com, or "First
Last"@ccmail.acme.com, but, for whatever reason, does not
wish to accept messages that come in from the external world already
addressed to any of the domains hosta.acme.com, hostb.acme.com, or
ccmail.acme.com.
Note that unless the site has MX records for hosta.acme.com, hostb.acme.com, or ccmail.acme.com pointing to the e-mail firewall system, then messages addressed using such explicit internal domain names would not normally ever reach the e-mail firewall system in the first place --- unless the sender used explicit routing in the address, e.g.,
Last%hostb.acme.com@emailfirewalldomain
To achieve the goal of routing messages addressed to acme.com to the directory channel for expansion to internal addresses, but rejecting messages that come in from the external world already addressed to such an internal address, appropriate rewrite rules and channels might be along the lines of:
acme.com $U%acme.com@DIRECTORY-DAEMON hosta.acme.com $U@bogus$?Explicit domain addressing not allowed$Ntcp_local hosta.acme.com $U%hosta.acme.com@GTCP-DAEMON$Mdirectory hosta.acme.com $U%hosta.acme.com@GTCP-DAEMON$Mdefragment hosta.acme.com $U%hosta.acme.com@GTCP-DAEMON$Mconversion hostb.acme.com $U@bogus$?Explicit domain addressing not allowed$Ntcp_local hostb.acme.com $U%hosta.acme.com@GTCP-DAEMON$Mdirectory hostb.acme.com $U%hosta.acme.com@GTCP-DAEMON$Mdefragment hostb.acme.com $U%hosta.acme.com@GTCP-DAEMON$Mconversion ccmail.acme.com $U@bogus$?Explicit domain addressing not allowed$Ntcp_local ccmail.acme.com $U%hosta.acme.com@GTCP-DAEMON$Mdirectory ccmail.acme.com $U%hosta.acme.com@GTCP-DAEMON$Mdefragment ccmail.acme.com $U%hosta.acme.com@GTCP-DAEMON$Mconversion ... .AD $U%$H$D@TCP-DAEMON ... .ZW $U%$H$D@TCP-DAEMON ... tcp_local ... TCP-DAEMON tcp_internal ... GTCP-DAEMON directory ... DIRECTORY-DAEMON