[Mailman-Developers] big list

[Barry A. Warsaw]

>>>>> "F" == Fil  <fil@rezo.net> writes:

    F> *First problem:* Although they are personalized (To: address
    F> ofg recipient), the messages sent were not VERPed (from the
    F> mail.log I saw only "from <listname-bounces@server>", not "from
    F> <listname-bounces+XXXX=XX>").

Fixed in cvs.


    F> *Second problem:* Then I did /etc/init.d/mailman start, but the
    F> sending of this message did not resume.

    F> The message is in qfiles/shunt, but the addresses not yet
    F> delivered to are nowhere to be seen. It seems to mean that, if
    F> the computer shuts down while Mailman is sending a batch of
    F> mails, a portion of the recipients will not receive their copy?

    F> I think the right way to do it would be, alongside the xxx.db
    F> and xxx.pck files in qfiles/shunt/ , to have a file xxx.dest
    F> containing all addresses not yet delived-to (in whatever
    F> format), that could be written one every x seconds to disk, in
    F> order to be able to resume sending if the computer has crashed,
    F> the power failed, or some dumb administrator tried to restart
    F> mailman at that moment.

Think of shunt as a safety net.  If Mailman has a bug that causes an
uncaught exception to occur while handling the message, it gets
shuffled off to shunt, so that once the bug is fixed, you ought to be
able to move the message back to qfiles/in and have it delivered
again.

I may do two additional things with shunt: first, I should probably
include a key in the metadata to indicate which queue the shunted file
came from, and second, I want to add a bin/unshunt command which will
re-queue shunted messages safely and correctly.

As to your other problem, I'm going to have to think about that.  I
agree that it's not good that if Mailman is shut down that messages
are delivered either twice or not at all.  A solution will likely
require some disk i/o, but the question is, how to do things robustly
without hammering the disk.

    F> *Third problem:* The "a message awaits your approval" mail is
    F> empty (the Mailman site is configured as French, maybe that's a
    F> source of trouble: I see this strange header : Content-Type:
    F> multipart/mixed; charset="fr";
    F> boundary="===============73517001808033933==" )

I'll look into that one too.
-Barry