Alternate channel routing via the CONVERSIONS mapping

One of the  mapping table template keyword clauses is    ,  causing routing (if the    mapping table pattern matched the probe) through the  specified   without any change to the  message&#x27;s recipient addresses; see the   mapping table. This   mapping table facility to cause routing via some alternate channel  (without alteration of a message&#x27;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   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 ! &#x5b;IP-address-of-virusscanner&#x5d;   $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  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  or    channel, the "side hop" routing should be configured via the    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   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:
 * CONVERSIONS mapping table
 * aliasdetourhost Option
 * allowswitchchannel Option
 * Notification message routing
 * Spam and virus filtering