PMDF System Manager's Guide
30.5.4 PMDF Options
The following describes special considerations for the following
options on an e-mail firewall. For a detailed general discussion of
these options, see Chapter 7.
- ACCESS_ERRORS: Note that if you do use rightslist identifiers
(OpenVMS) or group ids (UNIX) for PMDF channel usage control, then the
default ACCESS_ERRORS=0 is almost certainly desirable.
- BLOCK_LIMIT, BLOCK_SIZE, LINE_LIMIT: See also the discussion in
Section 184.108.40.206 above.
- LOG_CONNECTION, LOG_FILENAME, LOG_FORMAT, LOG_MESSAGE_ID,
LOG_SNDOPR, LOG_USERNAME: See also the discussion in Section 220.127.116.11
- MAX_HEADER_BLOCK_USE and MAX_HEADER_LINE_USE: These options are
used to control when PMDF automatically fragments messages. If you are
using a conversion channel for message filtering, message fragmentation
and defragmentation is an issue to consider.
- MAX_LOCAL_RECEIVED_LINES, MAX_MR_RECEIVED_LINES,
MAX_RECEIVED_LINES, MAX_TOTAL_RECEIVED_LINES, MAX_X400_RECEIVED_LINES:
These options specify after how many Received: lines PMDF decides that
a message is looping. Once PMDF has decided that a message is looping,
the message is renamed to a
.HELD file and sidelined,
thereby breaking the cycle of the looping, until the PMDF system
manager intervenes manually. See Section 18.104.22.168 above for a discussion
of Received: headers. Adjusting these values can affect which system
(if any) detects that the message is looping and sidelines it, which
can be of interest if the PMDF e-mail firewall is not a system checked
- The NON_URGENT_BLOCK_LIMIT, NORMAL_BLOCK_LIMIT, and
URGENT_BLOCK_LIMIT PMDF options can be used to set global thresholds
for when to downgrade message priority. Message priority, in turn, can
affect whether PMDF attempts to send a message immediately, or whether
PMDF lets the message wait until the next time the PMDF periodic
delivery job runs. Depending upon your needs and circumstances, having
large messages wait on the firewall system until a periodic job runs
can be either beneficial, by not using resources that could be used to
send small messages immediately, or can expose your firewall system to
the potential for getting its disk space "clogged up" with
pending large messages in between runs of the periodic job.
- NAME_TABLE_NAME: Using logical names for address transformations is
not recommended in any case, as it allows senders to "probe"
for logical names, and is distinctly not a good idea on an e-mail
firewall. The default where this option is not specified is strongly
- RETURN_ADDRESS: If you are directing postmaster mail to somewhere
other than the PMDF e-mail firewall system itself, then you can want to
consider setting this option to match. However, consider with caution:
as noted in the discussion above, using such a non-local address (and
in particular, changing the return address used on messages
from the postmaster by setting this option) can lead to rapid
mail looping and pile-ups of huge numbers of spurious error messages.
- RETURN_DELIVERY_HISTORY and HISTORY_TO_RETURN: These control how
much information PMDF includes in returned messages about why the
message could not be delivered. This can be very useful information to
the recipient of the returned message, but in some cases this helpful
information canc include information that you prefer recipients not
see, e.g., internal system names.
- REVERSE_ENVELOPE: Note that if you are performing address reversal,
say with a REVERSE mapping or reverse database, then the default
REVERSE_ENVELOPE=1 is almost certainly desirable.