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  , in a  ,  or in a Recipient access mapping table such as  ,  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    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     MTA option),  and implementation of Sieve " " actions;  and in cases of LDAP directory unresponsiveness, submissions from  "local" users are normally deferred to the reprocess channel  (see the    MTA option). As of MS 6.3, a spam/virus filter package becoming unresponsive also optionally may cause such deferral; see the      MTA options.

If a message destined to an address of the form      is routed to the  reprocessing channel, (e.g., due to rewrite rules or the    channel option)  then the reprocessing channel will  simply re-enqueue the message to the channel associated with the domain   ; if a message destined to an address of  the form       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    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  channel handled  Sieve " " messages;  as of 8.0, Sieve " " messages instead go through the   channel.

See also:
 * 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
 * Channels
 * Available channels