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.
18.104.22.168 Staticly Controlling e-mail Access
PORT_ACCESS mapping table can be used to control from
what IP numbers PMDF servers will accept connection attempts; the PMDF
multithreaded SMTP server, POP3 server, IMAP server, and HTTP server
check this table when a connection attempt comes in.
SEND_ACCESS and similar mapping tables can be used to
control, based on
and source and destination channel, what messages PMDF allows to pass
through. See Section 23.2.1 for details on the
mapping table, and see Section 16.1 for details on the
SEND_ACCESS and similar mapping tables.
For instance, consider a PMDF firewall system with postmaster address
email@example.com and with channels and rewrite rules
set up, as described in Section 30.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
tables might be along the lines of:
PORT_ACCESS TCP|*|25|*|* $Y TCP|*|*|*|* $N ORIG_SEND_ACCESS tcp_local|*|tcp_local|* $NRouting$ not$ allowed firstname.lastname@example.org $Y tcp_local|*|l|* $N
PORT_ACCESSentry shown allows incoming SMTP connections (i.e., TCP connections to port 25) to PMDF's multithreaded SMTP server from anywhere. The second
PORT_ACCESSentry shown disallows all other connections, e.g., connections to the PMDF HTTP server, POP server, or IMAP server.
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.
22.214.171.124 Sidelining Messages for Manual Inspection
In some cases, it can be useful to allow in but sideline certain
suspicious incoming messages (such as suspected junk e-mail)---perhaps
messages to suspiciously large numbers of recipients or messages from
particular suspicious sources---rather than simply rejecting them on
either a temporary or permanent basis. The PMDF postmaster can then
manually inspect the messages and determine the proper course:
releasing the messages for delivery processing, bouncing them back to
the original sender, or simply deleting them, if appropriate.
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.
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 126.96.36.199 for details.
Rather than rejecting messages (either permanently or temporarily),
SEND_ACCESS or related mappings can be used to sideline
incoming messages via the
188.8.131.52 Dynamically Controlling e-mail Access, and Defending Against Denial of Service Attacks
A denial of service attack is where an attacker tries (intentionally or
inadvertently) to overwhelm your system by flooding you with e-mail.
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 184.108.40.206 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.
tables described in Section 30.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
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 220.127.116.11 for
For more sophisticated needs, the
SEND_ACCESS, or related mapping tables can call out to
site-supplied shareable image routines; see Section 18.104.22.168 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
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
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.
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.