One of the fundamental issues for a firewall configuration tends to be separation between internal and external messages: separating message traffic allows for tracking and appropriately controlling the different sorts of messages. So the first recommendation for a firewall system is to set up separate channels to handle messages originating from external sites versus messages originating from internal systems.
For background on rewrite rules, see Section 2.2 ; for background on channels, see Section 2.3 .
29.4.1.1 Separating SMTP over TCP/IP message traffic
The most common case is where messages originating from external sites
come in to the PMDF system as SMTP messages over a TCP/IP channel. To
separate the externally originating SMTP messages from internally
originating SMTP message, use a separate TCP/IP channel in addition to
the default TCP/IP channel; e.g., use a tcp_internal channel
in addition to the default tcp_local channel. Put the
switchchannel channel keyword on your current tcp_local
channel, the allowswitchchannel channel keyword (the
default) on the tcp_internal channel and any other channels you wish to
allow switching to, and put noswitchchannel on all other
channels, e.g., the local channel, and use rewrite rules to
associate internal TCP/IP system names and IP addresses with the
tcp_internal channel and all other domains, e.g., Internet
domains, with the tcp_local channel.
When deciding whether and to what channel to "switch" an
incoming connection, PMDF uses the literal IP address of the incoming
connection to perform a reverse-pointing envelope rewrite looking for
an associated channel. If that rewrite fails, or if that rewrite
matches the default incoming TCP/IP channel, then PMDF will try
rewriting the host name as found by a DNS reverse lookup on the
incoming IP address; (depending on the use of any ident*
keywords, such DNS reverse lookups may be disabled).
So in order to allow internal systems to be recognized as such, you
should use IP literal rewrite rules to associate internal IP literals
(at least during backwards envelope rewriting) with your internal
TCP/IP channel. (Note that even if you do not normally use any IP
literal rewrite rules so that PMDF tries to fall through to using host
names, you should have such rewrite rules for your internal systems in
case of DNS problems causing DNS reverse lookup failures.) If you wish
to limit the rewriting of internal IP numbers to actual system names in
the forward direction, say if you do not wish to allow external users
to "probe" for internal IP number/internal system name
correspondences, then you may want these IP literal rewrite rules to be
backwards envelope specific, i.e., $E$R rewrite
rules.
Note that the default incoming TCP/IP channel is tcp_local and only system names or IP numbers recognized as internal system names are "switched" to the tcp_internal channel. This provides "failsafe" behavior; systems not specifically recognized (even internal systems, if the PMDF configuration has not been set up to recognize them) are handled by the external, "unsafe" channel.
By default, PMDF allows any channel to be "switched to";
i.e, the default is allowswitchchannel. On a
firewall system in particular, it is likely appropriate to make
noswitchchannel the default --- for instance, you probably
do not want to allow "switching" to the local channel---and
mark only the specific channels for which you wish to allow switching
with the allowswitchchannel channel keyword.
29.4.1.1.1 Sample configuration with separate TCP/IP channels
For instance, a site whose internal systems' IP numbers are all in the
[a.b.subnet] range, might want channels
defaults noswitchchannel routelocal l defragment ... official-local-host-name ... tcp_local single_sys smtp mx remotehost switchchannel inner TCP-DAEMON tcp_internal single_sys smtp mx noremotehost allowswitchchannel routelocal TCP-INTERNALand rewrite rules
! Rewrite rules for private TCP/IP systems/domains ! internaldomain1 $U%internaldomain1@TCP-INTERNAL internaldomain2 $U%internaldomain2@TCP-INTERNAL ... ! Rewrite rules for private TCP/IP system/domain literals ! [a.b.] $U%[a.b.$L]@TCP-INTERNAL$E$R ... ! Rewrite rules for the Internet ! Principality of Andorra .AD $U%$H$D@TCP-DAEMON ... ! Zimbabwe .ZW $U%$H$D@TCP-DAEMON
Note also how the remotehost and noremotehost
channel keywords are used on these channels. The
remotehost and noremotehost channel keywords
affect PMDF's handling of bare usernames ("addresses" that
are illegally formatted in that they have no domain name). PMDF always
inserts a domain name on such addresses, to make the addresses
syntactically legal. For envelope To: addresses that are missing a
domain name, PMDF always inserts the local host name. However for other
sorts of addresses, such as From: addresses, another factor comes into
play. The remotehost channel keyword on the tcp_local
channel (handling incoming messages from external sites) tells PMDF to
use the remote sending system's name (as determined by a reverse DNS
lookup); the default noremotehost channel keyword on the
tcp_internal channel (handling incoming messages from internal sites)
tells PMDF to use its own local host name, which may be particularly
appropriate in the case of poorly configured POP clients.
The routelocal keyword causes PMDF to attempt "short
circuited" rewriting of any explicit routing in the address, such
as ! routing, %-hack routing, or @ source routing. If a site expects no
legitimate uses of explicit source routing, then blocking such usage
blocks a potential way for external senders to relay messages by
explicitly routing them past the firewall system through internal
systems. Of course, sites that have legitimate uses of explicit routing
will not be able to afford to block such usage and hence should not use
routelocal on all channels.
The inner keyword causes PMDF address rewriting to be
applied to addresses in embedded message parts (MESSAGE/RFC822 parts)
within the message; if you are applying address reversal on outgoing
messages, this is liable to be desirable.
29.4.1.2 The case of an internal mailhub
In the case where the e-mail firewall relays all messages for internal
systems to an internal mailhub system, and receives internal messages
only from the internal mailhub, message traffic separation is
straightforward: the connection to and from the mailhub system is the
only internal connection, and all other connections are external.
Indeed, this may be thought of as a two system e-mail firewall setup, where the system we have been referring to as the e-mail firewall is the external portion of the e-mail firewall, and the mailhub system is the internal portion of the e-mail firewall. (In such a setup, particularly if the internal mailhub is a capable system such as another PMDF system, you may even wish to have the e-mail firewall system be ignorant of internal addressing details which are handled by the internal mailhub system.)
For such a setup you will want an internal channel for communicating with the internal mailhub, and an external channel (generally a TCP/IP channel, but UUCP, Phonenet, etc. channels are also possible) or channels for communicating with the rest of the world, and corresponding rewrite rules.
29.4.1.2.1 Sample configuration with an internal mailhub system
For instance, for a site using SMTP over TCP/IP to communicate between
the e-mail firewall and the mailhub, and with an SMTP over TCP/IP
connection to the Internet, a configuration where all internal mail
passes through the internal mailhub is simply a special (and
potentially simpler) case of having separate TCP/IP channels, as in
Section 29.4.1 above, with the major difference being that the
tcp_internal channel should be a daemon router channel
connecting to the mailhub system, e.g.,
defaults noswitchchannel routelocal l defragment ... official-local-host-name tcp_local single_sys smtp mx remotehost switchchannel inner TCP-DAEMON tcp_internal smtp mx remotehost allowswitchchannel daemon router mailhubdomain TCP-INTERNALand rewrite rules
! Rewrite rules for private TCP/IP systems/domains ! internaldomain1 $U%internaldomain1@TCP-INTERNAL internaldomain2 $U%internaldomain2@TCP-INTERNAL ... ! Rewrite rules for private TCP/IP system/domain literals ! [mailhubIPaddress] $U%[mailhubIPaddress]@GTCP-INTERNAL$E$R ... ! Rewrite rules for the Internet ! Principality of Andorra .AD $U%$H$D@TCP-DAEMON ... ! Zimbabwe .ZW $U%$H$D@TCP-DAEMON
Compare this with the sample configuration excerpt shown in Section 29.4.1.1.1 .
In this case, since messages from the internal side are coming from a
PMDF system, the remotehost keyword is likely appropriate
on both channels.