On 2/26/2014 9:53 AM, Wietse Venema wrote: > 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 >
I expect this doesn't work the way I think, but what about pointing whatever the queue file uses for the content filter flag to the bounce or error transport? Wouldn't that cause the message to bounce on the next queue run without much new code? -- Noel Jones
