Process and reprocess channels
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
_optional MTA options.
If a message destined to an address of the form
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
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.
- CONVERSIONS mapping table
- CHARSET-CONVERSION mapping table
- Recipient access mapping tables
- Source channel-specific rewrites
- Destination channel-specific rewrites
- Notification messages
- expandlimit Option
- defer_group_processing MTA Option
- domain_failure MTA Option
- spamfilter1_optional MTA Option
- Local channel
- Sieve redirect action
- Reprocess channel operation as prior channel
- Available channels