Retrieving messages from the filter discard channel

One reason for configuring use of the   channel (rather  than simply having "discarded" messages immediately deleted  from disk) is that it permits the potential for the system  administrator to "retrieve" messages while they are still in  the   channel queue on disk. The general process for such "retrieval" is as follows:



 Move the message files in question manually to the   channel queue area (typically   ), changing the filename slightly (e.g., from   to   ) when doing so, and making sure to preserve the  proper ownership and protections on the message files. 

 Issue the command " " so that the Job Controller will do an immediate scan to notice the  moved message files. (If one is in no particular hurry for such messages to begin getting delivery attempts, this step can be omitted  in favor of waiting for the Job Controller to get around to noticing  such files on its own; the Job Controller normally scans automatically  every four hours per its    option.) 

 After the  has completed, one may  issue the command " " to run an extra   channel job immediately, rather than waiting  for the Job Controller to get around to scheduling a reprocess job to  process any messages (such as the recently moved messages) that it  might have due for processing. 



When the MTA applies a Sieve " " or  " " action, a bit in the message envelope  gets set; if the MTA subsequently sees a message file that has that bit  set, it will not again apply a Sieve " " or  " " action. The purpose of this is precisely so that the above sort of operation (moving a previously  discarded message from the    channel to the reprocessing channel)  can be used to get messages delivered, without the  " " getting re-applied.

Note that the discarding of a message can be caused by a " " or " "  actions arising from any of a number of locations, including a number  of potentially applicable Sieve filters (system, channel, user, group,  domain, etc.), or by address-based    mapping table,  ,  , or   flags. Wherever/whatever the source of the discarding action, the setting of the same  ignore-future-discard-actions bit occurs, and if such a message is  subsequently "retrieved" (reinjected into the MTA&#x27;s regular  channel queues typically being moved manually to the reprocess channel  queue area), then all such discarding actions that might  otherwise be applicable on this MTA will be henceforth ignored for the  message in question (on this MTA -- such delivery flags are not  normally transferred to other MTAs, though see the    channel option).

One more note: messages enqueued to the   channel always  get the username field for the message (the "owner" of the  message for access purposes) set to the string  " "; this value will, for instance,  show up in the    field of the  MTA message transaction log file.

See also:
 * Process and reprocess channels
 * flagtransfer Option
 * cache -sync utility
 * run utility
 * synch_time Option
 * Sieve discard and jettison actions
 * Recipient access mapping tables
 * log_username MTA Option
 * MTA transaction logging
 * filter_discard channel