[Fwd: URGENT: Something in message is breaking mailman!]
I sent this to mailman-users and now I'm sending this to you to see if anyone has any insight into this.
Actually, I've been able to track this down to a problem in the python library mimetools.py. The message that causes problems has a header as such:
Content-Type: multipart/report; report-type=delivery-status boundary="-------=_2EF51FF1.3FFF45E0"
And if you notice, the report-type value is not terminated with a ';' character. As a result, the value gets set to:
"delivery-status
boundary=...."
So when ~mailman/Mailman/Bouncers/Netscape.py (or whatever) goes to run (in the process routine):
boundary = msg.getparam('boundary')
it gets back None which gets pushed onto the stack. Later, when str is popped off the stack python fails because it can't do a string operation on None.
If you look at the mimetools.py in the python library, and look at the parsetype method of the Message class, you'll see that the problem is in the assumption that each of the variable declarations in the Content-Type: header of the mime encoded message are always terminated by a semicolon. Just as a test, I hand modified the message in the qfiles directory and change the above Content-Type: header to read:
Content-Type: multipart/report; report-type=delivery-status; boundary="-------=_2EF51FF1.3FFF45E0"
and the message was processed. So, what is the fix? Occasionally, a message will come back and end up in the qfiles directory that has the header as described above. As a result, qrunner fails (errors out) and NONE of the email on the system is processed. This is a critical problem. Could you please help out with this?
Thanks Kambiz
ps. Please reply directly to me, as I am not on this list. Thanks
--
\o__O o -=< Kambiz Aghaiepour - (919)593-1964 >=- o o
\_ /|\ -=< Senior Consultant - The Collective >=- //\ //
|\ |\ -=< mailto:kambiz@collectivetech.com >=- // //
/ / |/ -=< http://www.collectivetech.com/ >=- |\ ||
"KA" == Kambiz Aghaiepour <kambiz@colltech.com> writes:
KA> Actually, I've been able to track this down to a problem in KA> the python library mimetools.py. The message that causes KA> problems has a header as such: | Content-Type: multipart/report; report-type=delivery-status | boundary="-------=_2EF51FF1.3FFF45E0" KA> And if you notice, the report-type value is not terminated KA> with a ';' character. As a result, the value gets set to: I'd call this a bug in the Netscape.py bounce detector, not in mimetools.py. The reason is that your message is not compliant with the MIME RFC 1341, which requires the semi-colon separator between parameters. It is correct that rfc822.Message.getparam('boundary') returns None in this case. What's broken is that Netscape.py should make sure the boundary is not None before it tries to use pass it to mimetools. Here's a patch against Mailman 2.0.1. -Barry -------------------- snip snip -------------------- Index: Netscape.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Bouncers/Netscape.py,v retrieving revision 1.5 diff -u -r1.5 Netscape.py --- Netscape.py 2000/06/20 05:40:36 1.5 +++ Netscape.py 2001/02/20 23:23:06 @@ -51,6 +51,8 @@ if msg.getmaintype() <> 'multipart': return None boundary = msg.getparam('boundary') + if boundary is None: + return None msg.fp.seek(0) mfile = multifile.MultiFile(msg.fp) mfile.push(boundary)
Simple! Thanks. That does the trick. Now I need to send the postmaster of the site generating the broken headers an email letting them know of the problem. Do you think this change in Netscape.py will be made permanently for future releases of Mailman? Kambiz "Barry A. Warsaw" wrote:
"KA" == Kambiz Aghaiepour <kambiz@colltech.com> writes:
KA> Actually, I've been able to track this down to a problem in KA> the python library mimetools.py. The message that causes KA> problems has a header as such:
| Content-Type: multipart/report; report-type=delivery-status | boundary="-------=_2EF51FF1.3FFF45E0"
KA> And if you notice, the report-type value is not terminated KA> with a ';' character. As a result, the value gets set to:
I'd call this a bug in the Netscape.py bounce detector, not in mimetools.py. The reason is that your message is not compliant with the MIME RFC 1341, which requires the semi-colon separator between parameters. It is correct that rfc822.Message.getparam('boundary') returns None in this case.
What's broken is that Netscape.py should make sure the boundary is not None before it tries to use pass it to mimetools.
Here's a patch against Mailman 2.0.1. -Barry
-------------------- snip snip -------------------- Index: Netscape.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Bouncers/Netscape.py,v retrieving revision 1.5 diff -u -r1.5 Netscape.py --- Netscape.py 2000/06/20 05:40:36 1.5 +++ Netscape.py 2001/02/20 23:23:06 @@ -51,6 +51,8 @@ if msg.getmaintype() <> 'multipart': return None boundary = msg.getparam('boundary') + if boundary is None: + return None msg.fp.seek(0) mfile = multifile.MultiFile(msg.fp) mfile.push(boundary)
-- \o__O o -=< Kambiz Aghaiepour - (919)593-1964 >=- o o \_ /|\ -=< Senior Consultant - The Collective >=- //\ //\ |\ |\ -=< mailto:kambiz@collectivetech.com >=- // // / / |/ -=< http://www.collectivetech.com/ >=- |\ ||
"KA" == Kambiz Aghaiepour <kambiz@colltech.com> writes:
KA> Simple! Thanks. That does the trick. Now I need to send the
KA> postmaster of the site generating the broken headers an email
KA> letting them know of the problem.
Cool.
KA> Do you think this change in Netscape.py will be made
KA> permanently for future releases of Mailman?
If there is a 2.0.2 release, it'll be part of it. The patch is unnecessary for 2.1.
-Barry
participants (2)
-
barry@digicool.com
-
Kambiz Aghaiepour