On Wed, Feb 26, 2014 at 10:14:10PM +0100, Andreas Schulze wrote:
> >But wait, there is more....
>
> does not sound like an easy job.
The difficult parts are not in marking the queue file.
> just an idea: if the timestamp of a queuefile is relevant, could a
> changed time
> of a queuefile be interpreted as "bounce immediately" ?
> for example timestamp to a fixed date near 1.1.1970
Wietse proposal is a one-byte record in the queue that can be
updated to "bounce-me". The bounce reason is written to a separate
file stored in a suitable directory that shares the queue-file's
name.
This is easier than generating the per-recipient bounce logs, ...
It requires reserving 2-bytes in each queue file: a "don't yet
bounce me" record type and zero record length. The bounce tool
would update the record type to "bounce me" (a 1 byte marker
signalling this).
Best practice might be to put candidate files on hold first, and
bounce them from the hold, rather than active or deferred queues.
This reduces somewhat the opportunities for race conditions when
short (traditional) queue ids are used.
--
Viktor.
