Internal host names in Received: and Message-Id: header lines

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 the Messaging Server MTA (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 MTA options    and    can be used on a Messaging Server 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 an edge MTA system -- an edge system is by definition a system whose name is  intended to be visible to the outside world --- if you have the MTA on  internal systems also, the options may be of interest on those internal  MTA systems. In a similar spirit, the channel keyword   can  be used on channels on an MTA system to instruct the MTA 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     can be used on channels on an MTA system to instruct the MTA 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  the MTA would normally include the envelope From: address. New in MS 7.0.5.37, the    channel option

Note that for messages that web clients submit through the MSHTTPD server to the MTA, the MSHTTPD server will (as of iMS 5.2p2) use any  original client source IP present in an X-Forwarded-for: or Client-ip:  or (as of MS 6.3) Proxy-ip: HTTP header to construct a  "(Forwarded-for: source-ip)" comment clause in the  Received: header line it (MSHTTP) submits to the MTA.

If necessary, address reversal on an MTA system can be used to "canonicalize" message id&#x27;s, to remove undesired  information, (though note that this removal of information may mean  that the resulting message id&#x27;s are no longer particularly useful). Note that the   MTA  option  must have bit 6 (value 64) set in order  for address reversal to apply to message id&#x27;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&#x27;s. For instance, a site domain.com that wishes to ensure that no host.domain.com domains appear in message id&#x27;s  might use a    mapping such as: REVERSE &#x2a;@&#x2a;.domain.com     $C$:I$0@domain.com$Y$E This  mapping only applies to message id&#x27;s, due to the    flag.

As regards 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&#x27;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   channel option --- you will probably want the    channel option as well  --- on your outgoing external TCP/IP channel or channels, generally     and possibly other   channels  (possibly every    channel except your internal channel,  ), and create a  header trimming file for each such channel. The   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   channel is shown below: Received: MAXIMUM=-1 MR-Received: MAXIMUM=-1 X400-Received: MAXIMUM=-1 See the  channel option for more details on header trimming.

As of MS 6.3, the Sieve " " and " " actions provide another approach -- very powerful, so use with caution! -- to modifying header lines to limit emission of internal host names.

See also:
 * received_domain MTA Option
 * id_domain MTA Option
 * noreceivedfor Option
 * noreceivedfrom Option
 * forcedreceivedfrom Option
 * use_reverse_database MTA Option
 * REVERSE mapping table
 * headertrim Option
 * innertrim Option
 * Sieve editheader extension
 * The MTA