[ mailman-Bugs-558633 ] Blocked queue after fight with Majordomo
Bugs item #558633, was opened at 2002-05-21 08:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100103&aid=558633&group_id=103
Category: mail delivery Group: 2.0.x
Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nigel Metheringham (nigel) Assigned to: Nobody/Anonymous (nobody) Summary: Blocked queue after fight with Majordomo
Initial Comment: On Mailman 2.0.8 (was honestly going to upgrade today!).
It appears that a couple of messages were boucing between the mailman request addresses and a Majordomo server, with more error transcript being added to the message on each bounce. This then appeared to completely block the qrunner. Removing the 2 huge messages from the qfiles directory fixed it.
Broken message qfiles attached.
Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-05-27 22:17
Message: Logged In: YES user_id=12800
I have implemented something like what Norbert suggested for MM2.1b3. I won't fix this for MM2.0.x.
Comment By: Donal Hunt (redgiant) Date: 2002-05-22 11:40
Message: Logged In: YES user_id=551025
It actually gets worse! I finally figured out what has been crashing my machine for the past few days... and it's related to this bug i think.
To reproduce:
Create a moderated mailing list. eg test@hostanme.com Send a mail from your mailman user (eg su to mailman id and type:
echo "test" | mail -s "test" test@hostname.com (where test@hostname.com is your moderated mailing list))
The mail gets sent to the mailing list and held for approval (mailman@hostname.com isn't a subscriber). A message gets sent back to mailman@hostname.com saying the message is held for approval (which mailman tries to post to the mailman list).
At this stage stuff starts to stop working on the machine (smtp, telnet and syslogd mainly). What I've got from stracing syslogd (I originally thought it was a syslogd problem) and a mail from root are below:
The thing is not that mailman is going to be sending mails to lists locally, but more someone could spoof a mail and DOS your machine. not nice!!! From what I've seen (evidence below) - there isn't a fight between the two lists 0 but i may be wrong.
Quick fix: set "respond_to_post_requests" to No.
System info: Suse Linux 7.0, Syslogd 1.3-3, Mailman 2.1b (cvs - may 9th)
If this has been fixed already or is a seperate bug I apologise in advance for the long comment.
<mailman@hostname.dcu.ie>: Command died with status 1: "/usr/local/mailman/mail/wrapper post mailman"
Reporting-MTA: dns; hostname.dcu.ie Arrival-Date: Wed, 22 May 2002 16:02:45 +0100 (IST)
Final-Recipient: rfc822; mailman@hostname.dcu.ie Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; Command died with status 1: "/usr/local/mailman/mail/wrapper post mailman"
Received: from hostname.dcu.ie (localhost [127.0.0.1]) by hostname.dcu.ie (Postfix) with ESMTP id DB02D5DFEA for <mailman@hostname.dcu.ie>; Wed, 22 May 2002 16:02:45 +0100 (IST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to Test2 awaits moderator approval From: test2-bounces@hostname.dcu.ie To: mailman@hostname.dcu.ie Message-ID: <mailman.16.1022079764.11428.test2@hostname.dcu.ie> Date: Wed, 22 May 2002 16:02:44 +0100 X-BeenThere: test2@hostname.dcu.ie X-Mailman-Version: 2.1b2+ Precedence: bulk List-Id: <test2.hostname.dcu.ie> X-List-Administrivia: yes Sender: test2-bounces@hostname.dcu.ie Errors-To: test2-bounces@hostname.dcu.ie
writev(1, [{"May 22 02:36:40", 15}, {" ", 1}, {"hostname", 7}, {" ", 1}, {"local[6728]: fatal: execvp /usr/"..., 85}, {"\r\n", 2}], 6) = ?ERESTARTSYS (To be restarted) --- SIGALRM (Alarm clock) --- time(NULL) = 1022032087 rt_sigaction(SIGALRM, {0x405304, [], SA_RESTART}, {0x405304, [], SA_RESTART}, 8) = 0 alarm(30) = 0 sigreturn() = ? (mask now []) writev(1, [{"May 22 02:36:40", 15}, {" ", 1}, {"hostname", 7}, {" ", 1},{"local[6728]: fatal: execvp /usr/"..., 85}, {"\r\n", 2}], 6) = ?ERESTARTSYS (To be restarted) --- SIGALRM (Alarm clock) --- time(NULL) = 1022032117 rt_sigaction(SIGALRM, {0x405304, [], SA_RESTART}, {0x405304, [],SA_RESTART}, 8) = 0 alarm(30) = 0 sigreturn() = ? (mask now []) writev(1, [{"May 22 02:36:40", 15}, {" ", 1}, {"linux28", 7}, {" ", 1}, {"local[6728]: fatal: execvp /usr/"..., 85}, {"\r\n", 2}], 6 <unfinished
Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-05-21 22:38
Message: Logged In: YES user_id=12800
Norbert Bollow gives this very good idea:
Rate limiting can do a lot to prevent things from getting out of hand. For example, respond at most ten times to essentially the same request from the same email address.
On any given day, when Mailman gets the tenth message from the same email address without valid commands, it could reply "This is the tenth message of this type today from you. It order to avoid problems like mail loops between email robots, any further messages of this type will be ignored today. Please try again tomorrow." And then any further messages from that address with no valid commands will be just discarded.
Similarly, Mailman would reply only to ten subscription requests for the same list from the same user on any given day. And only to ten unsubscription requests for the same list from the same user on any given day. And only to ten requests to change the subscription options in the same way. Etc.
Since most loops (with the exception of some bounce loops) iterate more quickly than ten times per day, this will kill most loops between robots before they create serious problems.
Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-05-21 16:47
Message: Logged In: YES user_id=12800
Heh, I think this is a general problem when you get two email robots talking to each other! In MM2.1cvs the robot will refuse to respond to a message marked Precedence: bulk|junk|list -- but it looks like that wouldn't have even helped in this case (since the Majordomo server isnt' setting that header ;/ )
The only other solution I can think of is to add a config variable which is a blacklist of known addresses (regexps) that Mailman should not respond too. You'd still get into the robot infloop the first time, but at least you'd have a hope of avoiding subsequent replybot storms for the same address.
Comment By: Nigel Metheringham (nigel) Date: 2002-05-21 08:03
Message: Logged In: YES user_id=31288
and other file
You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100103&aid=558633&group_id=103
Why is this being repeatedly mailed over and over again, redundantly?
On Monday 27 May 2002 10:17 pm, noreply@sourceforge.net wrote:
Bugs item #558633, was opened at 2002-05-21 08:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100103&aid=558633&gr oup_id=103
Category: mail delivery Group: 2.0.x
Status: Closed Resolution: Fixed
Priority: 5 Submitted By: Nigel Metheringham (nigel) Assigned to: Nobody/Anonymous (nobody) Summary: Blocked queue after fight with Majordomo
Initial Comment: On Mailman 2.0.8 (was honestly going to upgrade today!).
It appears that a couple of messages were boucing between the mailman request addresses and a Majordomo server, with more error transcript being added to the message on each bounce. This then appeared to completely block the qrunner. Removing the 2 huge messages from the qfiles directory fixed it.
Broken message qfiles attached.
Comment By: Barry A. Warsaw (bwarsaw)
Date: 2002-05-27 22:17
Message: Logged In: YES user_id=12800
I have implemented something like what Norbert suggested for MM2.1b3. I won't fix this for MM2.0.x.
Comment By: Donal Hunt (redgiant) Date: 2002-05-22 11:40
Message: Logged In: YES user_id=551025
It actually gets worse! I finally figured out what has been crashing my machine for the past few days... and it's related to this bug i think.
To reproduce:
Create a moderated mailing list. eg test@hostanme.com Send a mail from your mailman user (eg su to mailman id and type:
echo "test" | mail -s "test" test@hostname.com (where test@hostname.com is your moderated mailing list))
The mail gets sent to the mailing list and held for approval (mailman@hostname.com isn't a subscriber). A message gets sent back to mailman@hostname.com saying the message is held for approval (which mailman tries to post to the mailman list).
At this stage stuff starts to stop working on the machine (smtp, telnet and syslogd mainly). What I've got from stracing syslogd (I originally thought it was a syslogd problem) and a mail from root are below:
The thing is not that mailman is going to be sending mails to lists locally, but more someone could spoof a mail and DOS your machine. not nice!!! From what I've seen (evidence below) - there isn't a fight between the two lists 0 but i may be wrong.
Quick fix: set "respond_to_post_requests" to No.
System info: Suse Linux 7.0, Syslogd 1.3-3, Mailman 2.1b (cvs - may 9th)
If this has been fixed already or is a seperate bug I apologise in advance for the long comment.
-------------------------- <mailman@hostname.dcu.ie>: Command died with status 1: "/usr/local/mailman/mail/wrapper post mailman"
Reporting-MTA: dns; hostname.dcu.ie Arrival-Date: Wed, 22 May 2002 16:02:45 +0100 (IST)
Final-Recipient: rfc822; mailman@hostname.dcu.ie Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; Command died with status 1: "/usr/local/mailman/mail/wrapper post mailman"
Received: from hostname.dcu.ie (localhost [127.0.0.1]) by hostname.dcu.ie (Postfix) with ESMTP id DB02D5DFEA for <mailman@hostname.dcu.ie>; Wed, 22 May 2002 16:02:45 +0100 (IST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to Test2 awaits moderator approval From: test2-bounces@hostname.dcu.ie To: mailman@hostname.dcu.ie Message-ID: <mailman.16.1022079764.11428.test2@hostname.dcu.ie> Date: Wed, 22 May 2002 16:02:44 +0100 X-BeenThere: test2@hostname.dcu.ie X-Mailman-Version: 2.1b2+ Precedence: bulk List-Id: <test2.hostname.dcu.ie> X-List-Administrivia: yes Sender: test2-bounces@hostname.dcu.ie Errors-To: test2-bounces@hostname.dcu.ie
-------------------------- writev(1, [{"May 22 02:36:40", 15}, {" ", 1}, {"hostname", 7}, {" ", 1}, {"local[6728]: fatal: execvp /usr/"..., 85}, {"\r\n", 2}], 6) = ?ERESTARTSYS (To be restarted) --- SIGALRM (Alarm clock) --- time(NULL) = 1022032087 rt_sigaction(SIGALRM, {0x405304, [], SA_RESTART}, {0x405304, [], SA_RESTART}, 8) = 0 alarm(30) = 0 sigreturn() = ? (mask now []) writev(1, [{"May 22 02:36:40", 15}, {" ", 1}, {"hostname", 7}, {" ", 1},{"local[6728]: fatal: execvp /usr/"..., 85}, {"\r\n", 2}], 6) = ?ERESTARTSYS (To be restarted) --- SIGALRM (Alarm clock) --- time(NULL) = 1022032117 rt_sigaction(SIGALRM, {0x405304, [], SA_RESTART}, {0x405304, [],SA_RESTART}, 8) = 0 alarm(30) = 0 sigreturn() = ? (mask now []) writev(1, [{"May 22 02:36:40", 15}, {" ", 1}, {"linux28", 7}, {" ", 1}, {"local[6728]: fatal: execvp /usr/"..., 85}, {"\r\n", 2}], 6 <unfinished
Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-05-21 22:38
Message: Logged In: YES user_id=12800
Norbert Bollow gives this very good idea:
Rate limiting can do a lot to prevent things from getting out of hand. For example, respond at most ten times to essentially the same request from the same email address.
On any given day, when Mailman gets the tenth message from the same email address without valid commands, it could reply "This is the tenth message of this type today from you. It order to avoid problems like mail loops between email robots, any further messages of this type will be ignored today. Please try again tomorrow." And then any further messages from that address with no valid commands will be just discarded.
Similarly, Mailman would reply only to ten subscription requests for the same list from the same user on any given day. And only to ten unsubscription requests for the same list from the same user on any given day. And only to ten requests to change the subscription options in the same way. Etc.
Since most loops (with the exception of some bounce loops) iterate more quickly than ten times per day, this will kill most loops between robots before they create serious problems.
Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-05-21 16:47
Message: Logged In: YES user_id=12800
Heh, I think this is a general problem when you get two email robots talking to each other! In MM2.1cvs the robot will refuse to respond to a message marked Precedence: bulk|junk|list -- but it looks like that wouldn't have even helped in this case (since the Majordomo server isnt' setting that header ;/ )
The only other solution I can think of is to add a config variable which is a blacklist of known addresses (regexps) that Mailman should not respond too. You'd still get into the robot infloop the first time, but at least you'd have a hope of avoiding subsequent replybot storms for the same address.
Comment By: Nigel Metheringham (nigel) Date: 2002-05-21 08:03
Message: Logged In: YES user_id=31288
and other file
You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100103&aid=558633&gr oup_id=103
Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman-21/listinfo/mailman-developers
"PB" == Phil Barnett <philb@philb.us> writes:
PB> Why is this being repeatedly mailed over and over again,
PB> redundantly?
Check the messages carefully. Each new copy should have something different, a new comment, a changed status, etc.
-Barry
On Mon, May 27, 2002 at 11:16:25PM -0400, Barry A. Warsaw wrote:
"PB" == Phil Barnett <philb@philb.us> writes: PB> Why is this being repeatedly mailed over and over again, PB> redundantly?
Check the messages carefully. Each new copy should have something different, a new comment, a changed status, etc.
Yeah, and unlike BugZilla, sourceFnords' thing puts the mods at the *bottom* of the message...
Cheers, -- jra
Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274
"If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk")
participants (4)
-
barry@zope.com
-
Jay R. Ashworth
-
noreply@sourceforge.net
-
Phil Barnett