Alternate channel routing via the CONVERSIONS mapping
One of the CONVERSIONS
mapping table template keyword clauses is Channel=
channel-name
, causing routing (if the CONVERSIONS
mapping table pattern matched the probe) through the specified channel-name
without any change to the message's recipient addresses; see the CONVERSIONS
mapping table. This CONVERSIONS
mapping table facility to cause routing via some alternate channel (without alteration of a message's recipient addresses) turns out to be extremely useful for a number of scenarios. Originally conceived as a convenience for hooking in third-party or site-developed message processing channels, e.g.,
CONVERSIONS IN-CHAN=tcp_local;OUT-CHAN=ims-ms;CONVERT \ Yes,Channel=third-party-processing-channel
alternate conversion channel configuration also functions perfectly well to route messages out via SMTP to some third-party spam/virus filtering SMTP box (presumably itself configured to send processed messages back to the MTA to further delivery). For instance, if the MTA has been configured with a special tcp_*
channel for sending to, and receiving from, a third-party spam/virus filtering SMTP host, with rewrite rule:
! Rewrite rule to recognize source IP of virus scanner box and "switch" ! messages coming from it to be considered to come in tcp_virusscanner channel ! [IP-address-of-virusscanner] $E$R$U%$H@TCP-VIRUSSCANNER-DAEMON
and channel definition:
! Channel for sending to virus scanner box. ! Set with "allowswitchchannel" so that it can also be considered the source ! channel for messages coming back in from virus scanner box. ! tcp_virusscanner smtp daemon host-name-of-virusscanner \ allowswitchchannel ...additional-keywords... TCP-VIRUSSCANNER-DAEMON
then a corresponding CONVERSIONS
mapping table on a front end MTA might be along the lines of:
CONVERSIONS IN-CHAN=tcp_local;OUT-CHAN=tcp_intranet;CONVERT Yes,Channel=tcp_virusscanner
to cause all messages coming directly in from the Internet, destined for an internal host, to get a "side hop" through the virus scanner box. (Note that for users hosted-on-this-MTA, recipients on ims-ms
or tcp_lmtpcs
channel, the "side hop" routing should be configured via the aliasdetourhost
channel option as the timing of its effect has better implications for local-to-this-host users; but "alternate conversion channel" routing is generally used in conjunction with aliasdetourhost
in order to handle the cases of messages to remote users.)
Such "alternate conversion channel" routing has also found an important application in causing special routing of notification messages; see notification message routing.
See also: