On Wed, Feb 26, 2014 at 02:00:47PM -0600, Noel Jones wrote:
> 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?
Queue files never grow after they are created. All subsequent
modifications are atomic in-place updates of 1-byte recipient
recipient record type markers (from "recipient" to "done-recipient").
While the part of the intent of this design (not needing more space
to finish processing a message) is not always effective, with say
COW filesystems such as ZFS, it is a design feature that should
not be changed since the atomicity of the updates is also important.
It may be simpler to create a queue sub-directory, that is scanned
whenever the deferred queue is scanned, such that all messages
found there are automatically bounced with bounce messages per the
bounce logs for each message.
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.
--
Viktor.
