Blocked queue after fight with Majordomo

[Nigel-users]

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.

[http://sourceforge.net/tracker/index.php?func=detail&aid=558633&group_id=103&atid=100103]

[Nigel-users (nigel-users)]

Other attachments

[Nigel-users (nigel-users)]

and other file

[Barry Warsaw (barry)]

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.

[Barry Warsaw (barry)]

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.

[Redgiant (redgiant)]

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 <email address hidden>
Send a mail from your mailman user (eg su to mailman id and type:

echo "test" | mail -s "test" <email address hidden>
 (where <email address hidden> is your moderated mailing list))

The mail gets sent to the mailing list and held for approval
(<email address hidden> isn't a subscriber). A
message gets sent back to <email address hidden> 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.

-----------------------------------------------------------------------------------------------
<email address hidden>: 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; <email address hidden>
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 <email address hidden>; 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: <email address hidden>
To: <email address hidden>
Message-ID: <email address hidden>
Date: Wed, 22 May 2002 16:02:44 +0100
X-BeenThere: <email address hidden>
X-Mailman-Version: 2.1b2+
Precedence: bulk
List-Id: <test2.hostname.dcu.ie>
X-List-Administrivia: yes
Sender: <email address hidden>
Errors-To: <email address hidden>
-----------------------------------------------------------------------------------------------

-----------------------------------------------------------------------------------------------
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...

[Barry Warsaw (barry)]

I have implemented something like what Norbert suggested for
MM2.1b3. I won't fix this for MM2.0.x.