Process and reprocess channels

From Messaging Server Technical Reference Wiki
Jump to: navigation, search


Process and Reprocess channels

The processing and reprocessing channels are essentially the intersection of all other channel programs --- they perform only those operations that are shared among all other channels. In other words, such a channel is simply a channel queue whose contents are processed and requeued to other channels. Messages receive no special processing whatsoever.

The difference between a reprocessing channel and a processing channel is that a reprocessing channel is normally "invisible" as a source or destination channel, as for instance in a CONVERSIONS, in a CHARSET-CONVERSION, or in a Recipient access mapping table such as SEND_ACCESS, or in a source channel or destination channel specific rewrite rule. A processing channel, on the other hand, is visible like other MTA channels.

It may appear that such a channel is effectively useless, but this turns out to be untrue. For example, the act of processing message bodies or generating message files for a message with a large number of recipients may be very time-consuming. Timeouts may occur if this is done during the operation of a channel slave program with an open network connection. So the MTA provides the expandlimit channel option, which forces requeuing of the message to the reprocessing channel. Address expansion is then done as the reprocessing channel runs, free of any network timing constraints. The reprocess channel is also normally used to achieve deferred ("off-line") processing of expansion of mailing lists (see the defer_group_processing MTA option), and implementation of Sieve "redirect" actions; and in cases of LDAP directory unresponsiveness, submissions from "local" users are normally deferred to the reprocess channel (see the domain_failure MTA option). As of MS 6.3, a spam/virus filter package becoming unresponsive also optionally may cause such deferral; see the spamfilterN_optional MTA options.

If a message destined to an address of the form user@domain is routed to the reprocessing channel, (e.g., due to rewrite rules or the expandlimit channel option) then the reprocessing channel will simply re-enqueue the message to the channel associated with the domain domain; if a message destined to an address of the form user@reprocessing-domain is routed to the reprocessing channel, (e.g., as may be the case for mailing lists using deferred expansion), then the reprocessing channel will re-enqueue the message to the local channel. In either case, the reprocessing channel performs any necessary expansion of the user part of the address.

When an MTA channel has to generate a notification (bounce) message, such a notification message is initially enqueued to the processing channel.

A processing channel and a reprocessing channel are produced automatically by the MTA configuration generator. Note: Furthermore, for its own uses, the MTA will act as if process and reprocess channels are defined even if they are not explicitly present in your configuration. But if you wish to make any site specific uses of such channels, explicitly addressing or rewriting to such channels, then you will need to have the channels explicitly present in your configuration.

Prior to the 8.0 release, the reprocess channel handled Sieve "redirect" messages; as of 8.0, Sieve "redirect" messages instead go through the process channel.


See also: