Viktor Dukhovni:
> To bounce a message, the queue file is locked, bounce log entries
> are written for each remaining recipient, and the message is moved
> to the new queue. No unsafe (non-atomic) changes are made to the
> original queue file.
If this logfile update bypasses the queue manager or bounce daemon,
then 1) it suffers from race conditions, and 2) it results in the
massive code duplication that I must avoid.
First, you can't bypass the queue manager. If your stand-alone
program doesn't coordinate with the queue manager, then the bounce
daemon will delete a bounce logfile while your stand-alone program
updates it. Besides you are forgetting to clean up orphaned defer
logs, trace logs, etc. More race conditions.
Second, you can't bypass the bounce client because of note 3.
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.
But wait, there is more. Just like the queue manager a stand-alone
program would need to precisely parse queue files such as parsing
the DSN records, the original-recipient records, queue file flags,
and more, so that it can create a proper bounce request (or whatever
is appropriate given the kind of message). It's not sufficient to
do a half-assed parse like mailq/showq does.
Since we can't bypass the queue manager, bounce client and daemon,
and something has to parse queue files with approximately the
precision of the queue manager, it is better to leave those things
with the queue manager only and just set an atomic flag that this
file needs to be bounced. Writing the reason to a dedicated
subdirectory is not a problem.
Wietse
