1.0 Introduction

This document describes the steps you can take to prevent people from relaying SMTP mail through your PMDF system. For instance, configuring PMDF to disallow people from using your PMDF system as a means of relaying junk mail to hundreds or thousands of Internet mail boxes. Much of the information presented in this document may be found in Chapter 29 of the PMDF System Managers' Guide.

Note that by default PMDF prevents most SMTP relaying activity. Why not all? For starters, SMTP relaying is not necessarily a bad thing. However, some local users using POP or IMAP may 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.

Note: This document assumes that you are running PMDF V6.1 or later. Some of the functionality described in this document is not available in earlier versions of PMDF.

1.1 Differentiation between internal & external mail

In order to block mail relaying activities, you must first be able to differentiate between internal mail originated at your site and external mail originated out on the Internet and passing through your system back out to the Internet. The former class of mail you want to permit; the latter class you want to block. This differentiation is achieved using the switchchannel keyword on your inbound SMTP channel, the tcp_local channel.

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 a 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.

Note: Since the source IP address is used, it is important that your network router connecting your local network to the Internet be configured to prevent "IP spoofing". Contact your router vendor for assistance if you are unsure of how to configure your router.

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/table/pmdf.cnf on UNIX platforms, PMDF_TABLE:pmdf.cnf on OpenVMS platforms, and C:\pmdf\table\pmdf.cnf on Windows NT/2000. In the following directions and throughout this document, the text

<blank line>

is used to indicate a blank line in the configuration file.

• In your configuration file, locate your local, l, channel. It is usually preceeded in by the first blank line to appear in the configuration file. Immediately before the local channel, add the following defaults channel:

·                <blank line>

·                defaults noswitchchannel 

·                <blank line>

So that the configuration file appears something like

... last rewrite rule ...

<first blank line>

defaults noswitchchannel 

<blank line>

l ... 

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

• Next, modify your tcp_local channel to specify the switchchannel and remotehost keywords:

·                <blank line>

·                tcp_local smtp single_sys mx switchchannel remotehost 

·                TCP-DAEMON 

• Then, after your tcp_local channel, add a new channel named tcp_internal:

·                <blank line>

·                tcp_internal smtp single_sys mx allowswitchchannel 

·                TCP-INTERNAL 

• 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 domain.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

·                .domain.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 does a reverse DNS lookup on that IP address to produce a host name. If the reverse lookup succeeds in returning host name, the server uses that name (and otherwise uses the literal IP address of the incoming connection) to do a reverse-pointing envelope rewrite looking for an associated channel. If the host name (or IP address) corresponds to a local host of yours, 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 host name (or IP address) determined from the DNS lookup will not correspond to an internal source. In that case the reverse-pointing envelope rewrite will either rewrite to the tcp_local channel or 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.

Note: Any mapping table or conversion file entries which use the string "tcp_local" may need to be changed to either "tcp_*" or "tcp_internal" depending upon the usage.

1.2 Preventing mail relaying

Now to the point of this document: preventing unauthorized people from relaying SMTP mail through your system. First, keep in mind that you want to allow local users to relay SMTP mail. For instance, POP and IMAP users rely upon using PMDF to send their mail. It's random people out on the Internet who you want to prevent from using you as a relay. With the configuration from Section 1.1, you can differentiate between these two classes of users and block the correct class. Specifically, you want to block mail from coming in your tcp_local channel and going back out that same channel. To that end, an ORIG_SEND_ACCESS mapping table is used.

An ORIG_SEND_ACCESS mapping table may 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|*|*|*$%*.domain.com@*      tcp_local|$0|$1|$2@$4$R 

  tcp_local|*|*|*$%domain.com@*        tcp_local|$0|$1|$2@$3$R 

  tcp_local|*|*|*$%*.domain.com$%*@*   tcp_local|$0|$1|$2@$5$R 

  tcp_local|*|*|*$%domain.com$%*@*     tcp_local|$0|$1|$2@$4$R 

  tcp_local|*|*|*$%*.*@*               $NRelaying$ not$ permitted 

  tcp_local|*|*|*.*!*@*                $NRelaying$ not$ permitted

  tcp_local|*|*|"*@*"@domain.com       $NRelaying$ not$ permitted 

  tcp_local|*|*|"*@*"@*.domain.com     $NRelaying$ not$ permitted 

  tcp_local|*|*|@*:"*@*"@domain.com    $NRelaying$ not$ permitted 

  tcp_local|*|*|@*:"*@*"@*.domain.com  $NRelaying$ not$ permitted 

  tcp_local|*|*|@*:*@*.domain.com      $Y 

  tcp_local|*|*|@*:*@domain.com        $Y 

  tcp_local|*|*|@*:*@*                 $NRelaying$ not$ permitted 

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

In the above, the first thirteen entries are already coded in PMDF 6.0 or higher; and does not need to be included in the ORIG_SEND_ACCESS table.  This means you would only need to add the last entry. These entries are associated with blocking various forms of source routed addresses which might otherwise be used to thread a message through your channels. The fourteenth and final entry is the expected entry: the entry which states that messages cannot come in the tcp_local channel and go right back out it. That is, the last entry disallows external mail from coming in your SMTP server and being relayed right back out to the Internet. The updated table only needs:

 

ORIG_SEND_ACCESS 

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

 

The ORIG_SEND_ACCESS mapping table shown above should be added to your file of mapping tables. On UNIX systems that is the /pmdf/table/mappings file; on OpenVMS systems it is the file PMDF_TABLE:mappings.

After setting up the above ORIG_SEND_ACCESS mapping, you may find some desired forms of message traffic prohibited. Specifically, forwarding to another domain which is effected through a general database. Read on for details on how to permit this form of activity. If you do not use a general database, then you need not worry about this issue.

If you use a general database to redirect mail and some entries in that database forward mail outside of your domain, then those forwarded addresses will be affected by the above access controls. Specifically, a message sent by someone from outside your domain to an address which is immediately forwarded back out of your domain by the general database will appear to the ORIG_SEND_ACCESS mapping table as a message coming in the tcp_local channel and passing right back out the tcp_local channel. Hence, it will be blocked as a relay attempt. To prevent this difficulty, change the forwarding entry in the general database to pass through the process channel. For example, if Jane.Doe@domain.com used to forward out to jdoe@other.com,

Jane.Doe    jdoe%other.com 

then change the entry to be

Jane.Doe   jdoe%other.com@PROCESS-DAEMON 

Add to the end of your PMDF configuration file, the channel definition

<blank line>

process 

PROCESS-DAEMON 

An even better approach is to switch to using a FORWARD mapping table which then probes the general database. However, the exact details of how to set this up will depend somewhat on your current use of the general database and hence no attempt is made here to explain how to do this. See the V6.1 or higher PMDF System Manager's Guide for details. You can also consider switching from using a general database to using a directory channel.