This section describes various ways information that you can not want to emit can "leak out" and describes ways of blocking this.
18.104.22.168 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
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 popstore1 (if you are using
the PMDF popstore to provide e-mail accounts for external users). In
this case, you should make sure that your
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 [22.214.171.124]
subnet and where the PMDF HTTP server has been configured to run on its
normal default port of 7633, then an
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 [126.96.36.199] subnet. ! $(188.8.131.52/24)|*|*|7633|*|* $Y ! ! Allow access to user interfaces ! from external systems. ! *|*|*|7633|*|/msps_user/* $Y *|*|*|7633|*|/chng_pwd/* $Y ! ! Disallow all other access ! * $N
184.108.40.206 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 can have an interest in disabling
these helpful features.
DISABLE_EXPAND=1 in your Internet TCP/IP channel
disables the SMTP
EXPN command. The SMTP
command is normally used to expand (get the membership of) mailing
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
VRFY command, PMDF has to return some sort of
HIDE_VERIFY=1, this response is simply a
"maybe" sort of response rather than an explicit yes or no.)
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
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.
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.
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 30-1.
|Example 30-1 A Sample
DISABLE_EXPAND=1 HIDE_VERIFY=1 DISABLE_ADDRESS=1 DISABLE_CIRCUIT=1 DISABLE_STATUS=1 DISABLE_GENERAL=1
See Section 220.127.116.11 for more details on TCP/IP channel options.
18.104.22.168 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
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 can be considered a security
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
ID_DOMAIN can be used on
a PMDF system to specify the domain name to use when constructing
Received: headers and
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
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
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
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
REVERSE mapping such as:
REVERSE *@*.example.com $C$:Ifirstname.lastname@example.org$Y$E
REVERSEmapping only applies to message id's, due to the
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
Do not remove Received: headers or remove or simplify
To implement header trimming, put the
--- 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_* channel except your internal
channel, tcp_internal), and create a header trimming file for each such
headertrim keyword causes header trimming to
be applied to the outer message headers; the
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
is shown in Example 30-2.
|Example 30-2 A Sample
Received: MAXIMUM=-1 MR-Received: MAXIMUM=-1 X400-Received: MAXIMUM=-1
See Section 22.214.171.124 for more details on header trimming.
126.96.36.199 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
First.Last@example.com. (Note that if you have a
"smart" internal mailhub system, e.g., another PMDF
system, you can 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 can be of special interest when
performing centralized naming on an e-mail firewall.
innerkeyword 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).
suppressfinalkeyword; see Section 188.8.131.52.
1 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.