PMDF System Manager's Guide

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 can want to control which sorts of rewriting happen for which sorts of messages. Therefore source and destination specific, and direction specific rewrite rules can 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, can 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 can 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.

28.4.4.1 Sample Configuration Controlling Internal Domain Rewriting

Note that unless the site has MX records for hosta.example.com, hostb.example.com, or ccmail.example.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.example.com@emailfirewalldomain

To achieve the goal of routing messages addressed to example.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:

example.com $U%example.com@DIRECTORY-DAEMON hosta.example.com $U@bogus$?Explicit domain addressing not allowed$Ntcp_local hosta.example.com $U%hosta.example.com@GTCP-DAEMON$Mdirectory hosta.example.com $U%hosta.example.com@GTCP-DAEMON$Mdefragment hosta.example.com $U%hosta.example.com@GTCP-DAEMON$Mconversion hostb.example.com $U@bogus$?Explicit domain addressing not allowed$Ntcp_local hostb.example.com $U%hosta.example.com@GTCP-DAEMON$Mdirectory hostb.example.com $U%hosta.example.com@GTCP-DAEMON$Mdefragment hostb.example.com $U%hosta.example.com@GTCP-DAEMON$Mconversion ccmail.example.com $U@bogus$?Explicit domain addressing not allowed$Ntcp_local ccmail.example.com $U%hosta.example.com@GTCP-DAEMON$Mdirectory ccmail.example.com $U%hosta.example.com@GTCP-DAEMON$Mdefragment ccmail.example.com $U%hosta.example.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