PMDF System Manager's Guide

One application of access control mappings is to prevent people from relaying SMTP mail through your PMDF system; for instance, to prevent people from using your PMDF system to relay junk mail to hundreds or thousands of Internet mail boxes.

By default PMDF does not prevent SMTP relaying activity: for starters, SMTP relaying is not necessarily a bad thing. Sites should only block such activity if it is causing them difficulty. Morever, note that local users using POP or IMAP depend upon PMDF to act as an SMTP relay. Blocking unauthorized relaying while allowing it for legitimate local users requires configuring PMDF to know how to distinguish between the two classes of users. Configuring PMDF to make this distinction is the topic of the next section.

16.1.6.1 Differentiating Between Internal and External Mail

The switchchannel keyword works by causing the PMDF SMTP server to look at the actual IP address associated with the incoming SMTP connection. PMDF uses that IP address, in conjunction with your rewrite rules, to differentiate between an SMTP connection originated within your domain and a connection from outside of your domain. This information can then be used to segregate the message traffic between internal and external traffic.³

Let's now actually change your PMDF configuration so that you can differentiate between your internal and external message traffic. This is done by editing your PMDF configuration file, pmdf.cnf , located in the PMDF table directory.

1. In your configuration file, locate your local channel; this is the l (lowercase L) channel on OpenVMS or UNIX, or the msgstore channel on NT. It is usually preceded by the first blank line to appear in the configuration file. Immediately before the local channel, add the following defaults channel:

   defaults noswitchchannel

   So that the configuration file appears something like

   ! final rewrite rules defaults noswitchchannel ! Local channel l ...

   If you already have a defaults channel at this point in your configuration file, then simply add the noswitchchannel keyword to it.

2. Next, modify your incoming TCP/IP channel to specify the switchchannel and remotehost keywords, e.g.,

   tcp_local smtp single_sys mx switchchannel remotehost TCP-DAEMON

3. Then, after your incoming TCP/IP channel definition, add a similar new channel but with a different name, e.g.: ) )

   tcp_auth smtp single_sys mx allowswitchchannel routelocal TCP-INTERNAL

   The routelocal channel keyword is used to cause short-circuited rewriting of source routed addresses through this channel, thereby blocking possible attempts to relay by means of looping through internal SMTP hosts via explicitly source routed addresses.

4. Finally, add rewrite rules to route hosts and IP addresses in your domain to the tcp_internal channel. For instance, if your domain name is example.com and your domain's IP numbers are in the [a.b.subnet] range, then add to the top of your configuration file the rewrite rules

   .example.com $U%$H$D@TCP-INTERNAL [a.b.] $U%[a.b.$L]@TCP-INTERNAL$E$R

With the above configuration changes, SMTP mail generated within your domain will come in via the tcp_internal channel. All other SMTP mail will come in via the tcp_local channel. You can therefore distinguish between internal and external mail based upon which channel it comes in on.

How does the above work? The key is the switchchannel keyword. In Step 2 above, that keyword is applied to the tcp_local channel. When a message comes in your SMTP server, that keyword causes the server to look at the source IP address associated with the incoming connection. The server attempts a reverse-pointing envelope rewrite of the literal IP address of the incoming connection, looking for an associated channel. If that rewrite matches a local host of yours, then the rewrite rules added in Step 4 cause the address to rewrite to the tcp_internal channel added in Step 3. Since the tcp_internal channel is marked with the allowswitchchannel keyword, the message is "switched" to the tcp_internal channel and comes in on that channel. If the message comes in from an external source, the IP address will not correspond to an internal source. In that case the reverse-pointing envelope rewrite will either rewrite to the tcp_local channel or to some other channel. However, it will not rewrite to the tcp_internal channel and since all other channels were marked noswitchchannel in Step 1, the message will not "switch" to another channel and will remain with the tcp_local channel.

16.1.6.2 Differentiating Authenticated Users' Mail

The saslswitchchannel keyword takes an argument specifying the channel to switch to; if an SMTP sender succeeds in authenticating, then their submitted messages are considered to come in the specified switched to channel.

We will now continue the example of the previous section, adding in distinguishing authenticated submissions.

5. In your configuration file, add a new TCP/IP channel definition with a distinct name, e.g.:

   tcp_auth smtp single_sys mx mustsaslserver noswitchchannel TCP-AUTH

   This channel should not allow regular channel switching (that is, it should have noswitchchannel on it either explicitly or implied by a prior defaults line). This channel should have mustsaslserver on it.

6. Modify your tcp_local channel by adding maysaslserver and saslswitchchannel tcp_auth to it. So your tcp_local channel definition should now appear along the lines of:

   tcp_local smtp mx single_sys maysaslserver saslswitchchannel tcp_auth \ switchchannel TCP-DAEMON

With this configuration, SMTP mail sent by users who can authenticate with a local password will now come in the tcp_auth channel. Unauthenticated SMTP mail sent from internal hosts will still come in tcp_internal. All other SMTP mail will come in tcp_local.

16.1.6.3 Preventing Mail Relaying

An ORIG_SEND_ACCESS mapping table can be used to block traffic based upon the source and destination channel. In this case, traffic from and back to the tcp_local channel is to be blocked. This is realized with the following ORIG_SEND_ACCESS mapping table:

ORIG_SEND_ACCESS tcp_local|*|tcp_local|* $NRelaying$ not$ permitted

In the above, the entry states that messages cannot come in the tcp_local channel and go right back out it. That is, this entry disallows external mail from coming in your SMTP server and being relayed right back out to the Internet.

An ORIG_SEND_ACCESS mapping table is used rather than a SEND_ACCESS mapping table, so that the blocking will not apply to addresses that originally match the l (lowercase "L") channel (but which can expand via an alias or mailing list definition back to an "external" address). With a SEND_ACCESS mapping table one would have to go to extra lengths to allow outsiders to send to mailing lists that expand back out to "external" users, or to send to users who forward their messages back out to "external" addresses.

16.1.6.4 Allowing localhost Submissions to the SMTP Port

Some sites can want to disallow submissions to the SMTP port from clients running on the system itself; for instance, if no legitimate applications are expected to attempt this, then blocking such submissions closes one avenue by which users can spoof (forge) e-mail.

Other sites, however, can have legitimate applications that perform message submission by making a TCP/IP connection to the SMTP port of their own system. For instance, some third party mailing list expansion applications (though not PMDF's own mailing list expansion) operate in this way.

Further, to simplify their configuration such applications can connect using a loopback name or address, such as LOCALHOST or [127.0.0.1], rather than using the system's domain name. Depending on the underlying TCP/IP package, this can result in the incoming connection also appearing to come "from" LOCALHOST or [127.0.0.1], rather than coming from the system's specific domain name or IP address.

Using merely the internal vs external differentiation as shown above in Section 16.1.6.1 would result in treating SMTP submissions from clients on the host system itself as coming in the tcp_local channel. Thus if tcp_local to tcp_local message traffic is prevented, as discussed in Section 16.1.6.3, then any users or applications attempting to submit messages in such a way would not be allowed to submit messages to external addressees.

If you want to treat such submissions as "internal" submissions, for instance, in order to allow third party mailing list applications to operate even if SMTP relay blocking has been implemented, then an additional configuration step should be performed.

To the very top of the PMDF configuration file, add rewrite rules for the local host name (or LOCALHOST or [127.0.0.1], depending on from where the underlying TCP/IP package "sees" the connection as having originated) of the following form:

localhostname $U%localhostname@TCP-INTERNAL$E$R [localhostipnumber] $U%localhostname@TCP-INTERNAL$E$R LOCALHOST $U%localhostname@TCP-INTERNAL$E$R [127.0.0.1] $U%localhostname@TCP-INTERNAL$E$R

where localhostname is the official host name on the L channel. The $E and $R control sequences on these rewrite rules, which limit their effect to envelope From: address rewriting, mean that normal rewriting will still apply to addresses addressed to the local system. Yet switchchannel rewriting will use these rules also, and hence will see message submissions from the system to its own SMTP port as "internal" submissions.