The last followup to bug #117015 by deejster provided what I think is the critical clue to the strange duplication problem. Given that recipe I was indeed able to reproduce the bug:
- a message gets held for whatever reason
- the message is approved, but there are smtp errors during delivery
- the message gets re-queued, but with a file name composed of the old filebase, not the new filebase.
- fwap! you've now got a duplicate of the original message
Here's a fix for this problem. It removes the filebase value from the original msgdata, so that this will be recalculated when the file is re-queued after approval. For those of you seeing duplicates, please apply this patch and let me know if it fixes your dup problem.
This is important enough to spin a second release candidate.
-Barry
Index: ListAdmin.py
RCS file: /cvsroot/mailman/mailman/Mailman/ListAdmin.py,v retrieving revision 1.46 diff -u -r1.46 ListAdmin.py --- ListAdmin.py 2000/10/10 06:33:31 1.46 +++ ListAdmin.py 2000/11/02 23:05:57 @@ -208,6 +208,12 @@ return LOST msg = Message.Message(fp) msgdata['approved'] = 1
# Calculate a new filebase for the approved message, otherwise# delivery errors will cause duplicates.try:del msgdata['filebase']except KeyError:pass # Queue the file for delivery by qrunner. Trying to deliver the # message directly here can lead to a huge delay in web # turnaround.
Thanks Barry.
We figured out our problem, which I think is different from what you are talking about.
Details:
our aborted upgrade to mailman 2.0rc1 left behind a few files.
somehow these files interfered with normal exception handling.
when mailman decides a message must be held for moderation, it sends the user a "held for moderation" message and raises an special exception.
but this exception was no longer handled appropriately, so it got passed all the way up to qmail.
qmail therefore thought the delivery was a failure, and would schedule another attempt. And so on.
Deleting the leftover files from 2.0rc1 seems to have fixed it.
This was certainly a very bizarre interaction... I'm not sure if a patch to mailman is appropriate.
Perhaps the action of sending the 'held for moderation', or similar, email, should be deferred as late as possible. That way if there are problems, at least it won't be sent out an infinite number of times. Or alternatively, close the connection to the MTA sooner.
-- Neil Kandalgaonkar NeilK@ActiveState.com Web Application Developer, ActiveState
"NK" == Neil K NeilK@ActiveState.com writes:
NK> We figured out our problem, which I think is different from
NK> what you are talking about.
Oh, whoops! I missed this in my inbox. Looks like you've largely solved the problem, so ignore my last message.
NK> - our aborted upgrade to mailman 2.0rc1 left behind a few
NK> files.
I'd still /really/ like to know what problems you all had with rc1. It's a release candidate, so if there are bugs, better to catch them now than before 2.0 final goes out!
NK> This was certainly a very bizarre interaction... I'm not sure
NK> if a patch to mailman is appropriate.
Probably not. Rolling back is a bad idea (and definitely "unsupported")!
-Barry
participants (2)
-
barry＠wooz.org -
Neil K