PMDF System Manager's Guide

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 28.4.7.1 above.
• LOG_CONNECTION, LOG_FILENAME, LOG_FORMAT, LOG_MESSAGE_ID, LOG_SNDOPR, LOG_USERNAME: See also the discussion in Section 28.4.3.1 above.
• 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 28.4.8.3 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 regularly.
• 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 recommended.
• 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.