PMDF System Manager's Guide
PMDF-REF-6.0

29.4.8 Restricting or controlling information emitted

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

29.4.8.1 Restricting access to PMDF information via the PMDF HTTP server

PMDF includes an HTTP server. This HTTP server is used to serve out PMDF version information, PMDF documentation, statistics on general PMDF operation (numbers of message moving through PMDF, etc.), statistics on the Dispatcher's operation (IP addresses of connections, etc.), and a web interface to LDAP or X.500 directories. The HTTP server also provides a CGI interface to configuring PMDF mailbox filters, a CGI interface to configuring PMDF-DIRSYNC, and CGI interfaces to the PMDF popstore for management, user access to their own popstore messages, and for users to change their own popstore passwords.

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

If you wish 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 may 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 wish to allow access to at least some of the facilities from within your site: for instance, you will probably wish to be able to access the PMDF monitoring information and mailbox filter configration from internal systems or at least your own workstation. You may even wish 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 wish 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 wish 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 popstore user interfaces 
! from external systems. 
! 
  *|*|*|7633|*/popstore_user/*    $Y 
  *|*|*|7633|*/popstore_pwd/*     $Y 
! 
! Disallow all other access 
! 
  *                               $N

29.4.8.2 SMTP probe commands

During an SMTP connection, a remote sending side (or a person manually telnetting to your SMTP port) can issue commands requesting information such as a check on the validity of addresses. This very useful information can, however, be subject to abuse, e.g., by automated search engines checking for valid email addresses on your firewall system. Therefore some sites may have an interest in disabling these helpful features.

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 29-1 .

Example 29-1 A sampletcp_local_optionfile disabling SMTP probes

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

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

29.4.8.3 Internal names in Received: headers

Received: headers are normally exceptionally useful headers for displaying the routing that a message really took. Their worth can be particularly apparent in cases of dealing with apparently forged email, or in cases where one is trying to track down what happened to a broken messages, or in cases where a message does not appear to be repliable and one is trying to figure out who might know how to respond to the message. Received: headers are also used by PMDF and other mailers to try to detect message loops.

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 may 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 may 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 may mean that the resulting message id's are no longer particularly useful). For instance, a site acme.com that wishes to ensure that no host.acme.com domains appear in message id's might use a REVERSE mapping such as:

REVERSE 
 
  *@*.acme.com      $:I$Y$0@acme.com

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 may wish to strip off those headers on messages going out to the Internet via header trimming on your outgoing TCP/IP channel.

Note:
Do not remove Received: headers or remove or simplify Message-id: headers on general principles or because your users do not like them. Removing such headers, among other things, (1) removes one of the best tracking mechanisms you have, (2) removes information that may be critical in tracking down and solving problems, (3) removes one of the few (and best) warnings of forged mail you may have, and (4) blocks the mail system's ability to detect and short-circuit message loops. Only remove such headers if you know your site needs them removed.

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 29-2 .

Example 29-2 A sampletcp_local_headers.optfile for stripping Received: headers

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

See Section 2.3.4.58 for more details on header trimming.

29.4.8.4 Centralized naming and internal addresses

One function that is often performed on an email firewall is the transformation of addresses from true, internal format to an external centralized naming format, e.g., from mailbox@host.acme.com to First.Last@acme.com. (Note that if you have a "smart" internal mailhub system, e.g., another PMDF system, you may choose to perform the centralized naming there, rather than on the e-mail firewall.) PMDF has flexible and varied facilities for performing such address transformations; see Chapter 3 for details. There are several points that may be of special interest when performing centralized naming on an e-mail firewall.

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).
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).
If you wish 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.
If you do not wish notification messages generated by the e-mail firewall system to include the internal address, then you may wish to use the suppressfinal keyword; see Section 2.3.4.27 .

Note

¹ User accounts are not generally implemented on an e-mail firewall system, but PMDF popstore accounts are a possible exception. For instance, PMDF popstore accounts might be set up specifically for use by users who are travelling out of the office.

Previous | Next | Contents

PMDF System Manager's GuidePMDF-REF-6.0