Noel Jones:
> On 2/26/2014 12:41 AM, Andreas Schulze wrote:
> > wietse:
> >
> >> I don't know what people are asking for:
> >> 1 - Bounce all recipients of one specific queue file
> >> 2 - Bouncing only specific recipients
> >
> > option 1 (for me)
> >
> > in case of trouble I do
> > - mailq for visual overview
> > - pfqgrep -r/-s address -i | postsuper -d -
> >
> > In this context it would sometimes be useful to
> > postbounce <queue-id> <reason>
> >
> > Andreas
>
> Same here, option 1. It would occasionally be useful to bounce all
> undelivered recipients of a queue file. But this isn't something I'd
> use every week.
This can in effect bounce only the remaining recipients. The other
ones (bounced or delivered) are already renamed to "done" and
therefore effectively hidden.
Note 1: this requires that Postfix daemons are available. If no
bounce message can be queued, then mail will not be bounced
and will stay queued.
Note 2: just like "postsuper -d" this may hit the wrong message when
the system is configured for short queue IDs, as those may be reused.
Note 3: like the queue manager this needs to distinguish between
regular mail, "sendmail -bv", address verification probes, VERP,
and so on. Only a few of these types are supposed to be returned
to the sender; the other types require different handling.
Note 4: like the queue manager this needs to lock a queue file
before starting work on it, mark a bounced recipient as "done", and
clean up defer logs, trace logs etc. before removing the queue
file.
There has to be a better way that avoids massive code duplication
and the resulting maintenance hell.
One possibility is to introduce a new one-byte flag in Postfix queue
files that is set when the email message must "bounce now", and to
introduce a new queue subdirectory with text files (same names as
message queue files) that say why the corresponding email message
is to be bounced. This can then be processed with the existing
queue manager after minimal modification.
With this, part of the work happens in "postsuper -b" (write the
reason to a text file in the new queue subdirectory, then flip the
message queue file bit that says "bounce this message"). The other
parts happen in the queue manager (read the new flag byte and pass
it on in some simplified bounce request, and in the bounce daemon
(read the bounce reason from the text file in the new queue
subdirectory).
This is less work, because it extends code that already works,
without duplicating existing logic into another program.
Wietse
