"GM" == Gergely Madarasz gorgo@caesar.elte.hu writes:
GM> Does this mean that message delivery is not handled at all
GM> when the incoming mail is passed to mailman, and every message
GM> needs to wait for a cronjob to run ?
Yes. The reasons for the change are manyfold, but all are based on my primary goal for 2.0 - delivery reliability. By that I mean, no messages should ever get lost, if they are deliverable at all, and no duplicates should ever be sent.
In 2.0 we're stuck with the lack of a database with transactions, necessitating the use of lockfiles. This means that there is a significant chance that messages can be delivered to the `post' script, but cannot be delivered because the list lock could not be acquired. If Mailman didn't queue the message, it could get bitbucketed. Other situations could cause the message to be not-completely-delivered within the command time limit that some MTAs (e.g. Postfix) have.
It turns out that queuing the message immediately is a huge boon to debugging too, because I can now inspect messages before they've gone out.
The penalty for the improved reliability is 1) there's more disk I/O; 2) messages get held for up to 1 minute + the time it takes qrunner to reach the message during its loop.
I think both are acceptable give then benefits.
-Barry