We have a fallback machine that probably receives ~20-40k messages per day,
and may have ~60k-~100k+ messages in its queue at any time.
It seems that flushing the queues are far more expensive than we had hoped,
and one contributing factor seems to be that for a queue run, with, say,
~100k messages in the queue, exim ends up moving onto a new message,
forking, and exiting after discovering that the retry time is not reached.
We want to run fast, regular queue flushes to try to get to those messages
whose retry periods have given the need for another delivery attempt to
run -- but not at the expense of 100k+ forks per flush! The _vast_ majority
of messages in a queue run will not result in a delivery attempt, and I'd
like to have the queue scanned somewhat regularly.
Is there any way to have the queue runner process examine the message
*before* forking a process to deliver it?
I also wouldn't mind turning off updating the msglog for "retry time not
reached", if that's possible.
