PMDF System Manager's Guide

This section describes various ways information that you can not want to emit can "leak out" and describes ways of blocking this.

28.4.8.1 Restricting Access to PMDF Information via the PMDF HTTP Server

You should consider which, if any, of this information you want to allow access to from outside your site and which, if any, of this information you want to access on the PMDF e-mail firewall from within your site.

If you want to take advantage of absolutely none of this information even from within your site, then on the principle of "everything not permitted is forbidden" you can choose to simply disable PMDF's HTTP server entirely. To do so, edit your Dispatcher configuration file and remove or comment out the entire HTTP service definition section, see Section 12.1.1, and then restart the Dispatcher.

The more common case, however, is that you will want to allow access to at least some of the facilities from within your site: for instance, you will probably want to be able to access the PMDF monitoring information and mailbox filter configration from internal systems or at least your own workstation. You can even want to allow external access to a few selected facilities, such as the web interface to LDAP or X.500 directory information (if you are running an LDAP or X.500 directory which you want to be visible externally) or perhaps user-level access to the PMDF popstore¹ (if you are using the PMDF popstore to provide e-mail accounts for external users). In this case, you should make sure that your HTTP_ACCESS mapping is set up to allow only the access you want to permit, and to block all other access.

For instance, at a site whose internal addresses comprise the [1.2.3.0] subnet and where the PMDF HTTP server has been configured to run on its normal default port of 7633, then an HTTP_ACCESS mapping to allow full access to the PMDF HTTP server facilities from internal systems, allow access only to the PMDF popstore from external systems, and block all other access by external systems would be:

HTTP_ACCESS ! Allow full access from systems in the [1.2.3.0] subnet. ! $(1.2.3.0/24)|*|*|7633|*|* $Y ! ! Allow access to user interfaces ! from external systems. ! *|*|*|7633|*|/msps_user/* $Y *|*|*|7633|*|/chng_pwd/* $Y ! ! Disallow all other access ! * $N

28.4.8.2 SMTP Probe Commands

Setting DISABLE_EXPAND=1 in your Internet TCP/IP channel disables the SMTP EXPN command. The SMTP EXPN command is normally used to expand (get the membership of) mailing lists.

Setting HIDE_VERIFY=1 in your Internet TCP/IP channel causes PMDF to return a "generic" response to the SMTP VRFY command. The SMTP VRFY command is normally used to check whether an address is a legitimate address on the local system. (Note that as it is required that SMTP servers support the VRFY command, PMDF has to return some sort of response; with HIDE_VERIFY=1 , this response is simply a "maybe" sort of response rather than an explicit yes or no.)

Setting DISABLE_ADDRESS=1 in your Internet TCP/IP channel causes PMDF to disable responses to the PMDF SMTP server's private XADR command, which normally returns information about the channel an address matches.

Setting DISABLE_CIRCUIT=1 in your Internet TCP/IP channel causes PMDF to disable responses to the PMDF SMTP server's private XCIR command, which normally returns information about the PMDF message circuit checking facility.

Setting DISABLE_STATUS=1 in your Internet TCP/IP channel causes PMDF to disable responses to the PMDF SMTP server's private XSTA command, which normally returns information about the numbers of messages in PMDF queues.

Setting DISABLE_GENERAL=1 in your Internet TCP/IP channel option file causes PMDF to disable responses to the PMDF SMTP server's private XGEN command, which normally returns status information about whether a PMDF compiled configuration and character set are in use.

A sample TCP/IP channel option file to disable probing via the SMTP server, for a site using a tcp_local channel, would be as shown in Example 28-1.

Example 28-1 A Sample tcp_local_option File Disabling SMTP Probes

DISABLE_EXPAND=1 HIDE_VERIFY=1 DISABLE_ADDRESS=1 DISABLE_CIRCUIT=1 DISABLE_STATUS=1 DISABLE_GENERAL=1

See Section 21.1.2.2 for more details on TCP/IP channel options.

28.4.8.3 Internal Names in Received: Headers

Message-id: headers are normally useful for message tracking and correlation.

However, on the converse side, Received: headers on messages you send out give the message recipient information about the routing that a message really took through your internal systems and tend to include internal system names and possibly an envelope recipient address. And Message-id: headers tend to include internal system names. At some sites, this can be considered a security exposure.

If your site is concerned about this information being emitted, first see if you can configure your internal systems to control what information they put in these headers. For instance, the PMDF options RECEIVED_DOMAIN and ID_DOMAIN can be used on a PMDF system to specify the domain name to use when constructing Received: headers and Message-id: headers, respectively. Although these options are not usually particularly relevant on the PMDF firewall system itself --- after all, the firewall system is by definition a system whose name is intended to be visible to the outside world --- if you have PMDF on internal systems also, the options can be of interest on those internal PMDF systems. See Section 7.2 for details on these options. In a similar spirit, the channel keyword noreceivedfor can be used on channels on a PMDF system to instruct PMDF not to include the envelope recipient address in the Received: header it constructs, if limiting the exposure of internal routing addresses is a concern for your site. And for those rare cases where the inclusion of original envelope From: information in Received: headers constructed is of concern, the channel keyword noreceivedfrom can be used on channels on a PMDF system to instruct PMDF not to include envelope From: information in Received: headers it constructs in those cases (involving changing the envelope From:, such as certain sorts of mailing list expansions) where PMDF would normally include the envelope From: address.

If necessary, address reversal on the PMDF firewall system can be used to "canonicalize" message id's, to remove undesired information, (though note that this removal of information can mean that the resulting message id's are no longer particularly useful). Note that the USE_REVERSE_DATABASE PMDF option (in the option.dat file) must have bit 6 (value 64) set in order for address reversal to apply to message id's; for instance, if the option was previously set to the default value of 5, it must be set to 69 to apply to message id's. For instance, a site example.com that wants to ensure that no host.example.com domains appear in message id's might use a REVERSE mapping such as:

REVERSE *@*.example.com $C$:I$0@example.com$Y$E

This REVERSE mapping only applies to message id's, due to the $:I flag.

As to Received: headers, only if you cannot configure your internal systems to control such sorts of information should you consider resorting to stripping such headers off entirely. Received: headers should not be removed lightly, due to their many and important uses, but if the internal routing and system name information in them is sensitive for your site and if you cannot configure your internal sytems to control what information appears in these headers, then you can want to strip off those headers on messages going out to the Internet via header trimming on your outgoing TCP/IP channel.

To implement header trimming, put the headertrim keyword --- you will probably want the innertrim keyword as well --- on your outgoing external TCP/IP channel or channels, generally tcp_local and possibly other tcp_* channels (possibly every tcp_* channel except your internal channel, tcp_internal), and create a header trimming file for each such channel. The headertrim keyword causes header trimming to be applied to the outer message headers; the innertrim keyword causes the header trimming to be applied also to embedded message parts (message/rfc822 parts) within the message. A sample header trimming file for a site using a tcp_local channel is shown in Example 28-2.

Example 28-2 A Sample tcp_local_headers.opt File for Stripping Received: Headers

Received: MAXIMUM=-1 MR-Received: MAXIMUM=-1 X400-Received: MAXIMUM=-1

See Section 2.3.4.59 for more details on header trimming.

28.4.8.4 Centralized Naming and Internal Addresses

1. Put the inner keyword on (at least) your channels outgoing to the external world so that address rewriting will be applied to address in embedded message parts (message/rfc822 parts).
2. For the forward direction of address transformation, the directory channel with a directory database lookup offers the potential for more control via channel specific rewrite rules or a SEND_ACCESS mapping table than similar transformations performed via the PMDF alias file, alias database, or general database. The separate channel processing step that the directory channel incurs allows both for more control, and incurs more overhead, than the "inline" transformations performed via the alias file, alias database, or general database. The directory channel with directory database lookup, being a separate channel processing step rather than being performed inline, also provides more insulation of the forward direction of address transformation from any potential for external SMTP probing and allows for more precise control with channel specific rewrite rules, should you have a use for them; the flip side of this is that in some cases PMDF will have to accept a message onto the system and then do a separate channel run to discover that an address is bad, rather than being able to reject a message immediately during the actual SMTP dialogue before the message ever comes onto the PMDF system (using PMDF system resources).
3. If you want to do LDAP or X.500 or CCSO directory lookups from the e-mail firewall system, say as part of your centralized naming scheme, note that either of these involves a network access to the directory. You should either put a good deal of effort into securing that network connection, to prevent spoofing at that network level, or alternatively, instead do the LDAP or X.500 or CCSO directory lookup from an internal "secure" system.
4. If you do not want notification messages generated by the e-mail firewall system to include the internal address, then you can want to use the suppressfinal keyword; see Section 2.3.4.27.