"GM" == Gergely Madarasz <gorgo at 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
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.