PMDF System Manager's Guide

You can control which users can send to which users, what channels can send to what channels, and use hooks in PMDF to allow for dynamic, load-based rejection decisions.

28.4.5.1 Staticly Controlling e-mail Access

For instance, consider a PMDF firewall system with postmaster address postmaster@example.com and with channels and rewrite rules set up, as described in Section 28.4.1, to segregate internal SMTP traffic onto a different channel than the tcp_local channel handling external SMTP traffic. On such a system, minimal PORT_ACCESS and ORIG_SEND_ACCESS mapping tables might be along the lines of:

PORT_ACCESS TCP|*|25|*|* $Y TCP|*|*|*|* $N ORIG_SEND_ACCESS tcp_local|*|tcp_local|* $NRouting$ not$ allowed tcp_local|*|*|postmaster@example.com $Y tcp_local|*|l|* $N

The first PORT_ACCESS entry shown allows incoming SMTP connections (i.e., TCP connections to port 25) to PMDF's multithreaded SMTP server from anywhere. The second PORT_ACCESS entry shown disallows all other connections, e.g., connections to the PMDF HTTP server, POP server, or IMAP server.

The first ORIG_SEND_ACCESS entry shown disallows other sites from routing SMTP mail by way of your system. (Note that it is normal and useful to allow explicit routing through your system. However, if you are worried about external users attempting to forge e-mail so that it appears to originate from your site, you can want to disallow the ability for routing through your system from external sites.) For a more detailed discussion of SMTP relay blocking, and examples of more sophisticated entries for blocking various source-routed address variants, see Section 16.1.6. The second ORIG_SEND_ACCESS entry is very important, as it allows messages to be sent to your postmaster account. The third ORIG_SEND_ACCESS entry disallows messages to any other (than the postmaster) local mailboxes on the PMDF firewall system.

28.4.5.2 Sidelining Messages for Manual Inspection

Note that allowing the messages onto the PMDF e-mail firewall allows them to use disk space on the PMDF system, where they will sit until the PMDF postmaster manually intervenes. So sidelining techniques should not be used unless the PMDF postmaster will in fact be checking periodically for the presence of such sidelined messages and taking action on them.

The holdlimit keyword on, for instance, the incoming TCP/IP channel can be used to automatically sideline messages to greater than a specified number of envelope recipients. See Section 2.3.4.16 for details.

Rather than rejecting messages (either permanently or temporarily), SEND_ACCESS or related mappings can be used to sideline incoming messages via the $H flag.

28.4.5.3 Dynamically Controlling e-mail Access, and Defending Against Denial of Service Attacks

In some cases, adding a simple static entry to unconditionally reject messages from the problem address or site is a sufficient defense, particularly if you know ahead of time (or can quickly detect) that the attack is occurring; see Section 28.4.5.1 above. In other cases, however, you can either want to automate dynamic detection of message volume upswings sufficient to be considered an attack. Or you can not want to reject all messages from the problem address or site and instead want merely to "turn down the volume", i.e., slow down the flow to a level more easily managed by your users or system. For instance, you can be under a practical or legal mandate to accept certain messages, or good messages can be mixed in with the bad message flow; in such a case turning down the volume to a manageable level allows the good messages a chance to get into your system while preventing the bad messages from overloading your resources.

The PORT_ACCESS and SEND_ACCESS mapping tables described in Section 28.4.5 above---as well as related mapping tables discussed in Section 16.1---can be used in more sophisticated ways than simple unconditional entries to achieve such goals, and can indeed be hooked into dynamic, heuristic routines to decide "Yea" or "Nay" on accepting messages, should you choose to provide such routines.

First, on the most simple level, the PORT_ACCESS , SEND_ACCESS or related mapping tables can take a random argument, effectively having PMDF "flip a coin" each time it needs to decide whether to accept a connection or message, respectively, or in the case of SEND_ACCESS and related mapping tables whether to sideline a message; see Section 5.3.2.5 for details.

For more sophisticated needs, the PORT_ACCESS , SEND_ACCESS , or related mapping tables can call out to site-supplied shareable image routines; see Section 5.3.2.10 for details. Such routines can, if you want, use PMDF API calls to access PMDF counters information; this can allow for heuristic decisions based on recent message load, comparing PMDF counters levels at one sampled time with PMDF counters levels when checked a little later; e.g., "lots of messages came in to the tcp_local channel in the last few minutes, so let us reject additional connection attempts for the moment" or whatever decision basis you decide to implement.

On OpenVMS, it is also possible to capture a copy of PMDF's mail.log_current output in a mailbox device; so site supplied routines can use this information also, which is more detailed than the PMDF counters information, in making accept or reject decisions.

The heuristics for making dynamic decisions about accepting or rejecting messages tend to be very site specific, and involve a variety of critical issues. Note also that sites can want to keep the details of their own heuristic algorithms secure. Process Software recommends that sites interested in implementing their own denial of service prevention techniques obtain specialized consulting assistance.

Particularly when implementing dynamic rejection mechanisms, the TCP/IP channel options ALLOW_TRANSACTIONS_PER_SESSION and ALLOW_RECIPIENTS_PER_TRANSACTION can be of interest. The ALLOW_TRANSACTIONS_PER_SESSION option can be used to limit the number of messages accepted during a particular connection. After refusing a number of connection attempts from a particular site, once you do let them connect, they are liable to have a backlog of messages for your site which they will try to deliver during that connection. If you are attempting to "slow down" how much mail you accept from that site, you likely will want to use this option to say, in effect, "enough for now" after some point in the connection. Similarly, the ALLOW_RECIPIENTS_PER_TRANSACTION option can be used to limit the number of recipients allowed for a particular message; this can be useful in protecting against a denial of service attack in the form of messages blanketing large numbers of your users.