This section describes various ways information that you may not wish to emit can leak out and describes ways of blocking this.
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, for example, 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 option file 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 option file causes the IMTA 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, the IMTA 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 option file causes the IMTA to disable responses to the IMTA SMTP server's private XADR command, which normally returns information about the channel an address matches.
Setting DISABLE_STATUS=1 in your Internet TCP/IP channel option file causes the IMTA to disable responses to the IMTA SMTP server's private XSTA command, which normally returns information about the numbers of messages in IMTA queues.
Setting DISABLE_GENERAL=1 in your Internet TCP/IP channel option file causes the IMTA to disable responses to the IMTA SMTP server's private XGEN command, which normally returns status information about whether an IMTA 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 the following example.
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 replyable and one is trying to figure out who might know how to respond to the message. Received: headers are also used by the IMTA 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 IMTA options RECEIVED_DOMAIN and ID_DOMAIN can be used on an IMTA 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 IMTA 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 the IMTA on internal systems also, the options may be of interest on those internal IMTA systems. In a similar spirit, the channel keyword noreceivedfor can be used on channels on an IMTA system to instruct the IMTA 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. 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: and Message-id: 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 systems 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: or 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), where the x depends upon the TCP/IP package you are using, 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 the following example.