[Mailman-Users] Bounce exception
mso at ssc.com
Thu Aug 30 00:40:37 CEST 2001
I installed Mailman 2.0.6 (from the Debian package) last week, and
certain bounce messages are causing the qrunner to abort:
Aug 29 15:01:03 2001 qrunner(19529):
File "/usr/lib/mailman/Mailman/Bouncers/DSN.py", line 46, in process
if string.lower(msg.gettype()) <> 'multipart/report' or \
TypeError : read-only character buffer, None
When this happens, it seems to stop up all the other list messages and
they don't get through. My /var/lib/mailman/qfiles directory contains
212 pairs of *.db / *.msg files, which I assume are unprocessed messages
(mostly bounces it looks like).
I ran qrunner under pdb and found that the offending section is:
45 def process(msg):
46 -> if string.lower(msg.gettype()) <> 'multipart/report' or \
47 string.lower(msg.getparam('report-type')) <> 'delivery-status':
48 # then
49 return None
msg.getparam('report-type') is returning None, which string.lower() chokes on.
msg is a mimetools.Message instance. mimetools.py (Python 1.5.2) says
self.getparam() looks in self.plist , etc, like this:
1) Message.__init__() calls Message.parsetype(), which reads the
'content-type' header and sets self.plisttext.
(Pdb) p msg.getheader('content-type')
(Pdb) p msg.plisttext
2) Message.__init__() calls Message.parseplist(), which builds
self.plist from self.plisttext.
(Pdb) p msg.plist
3) Later, our unfortunate method calls self.getparam('report-type'),
does not find 'report-type' (since the list contains only 'boundary'),
returns None, and the qrunner dies.
The first time it happened, I went up a few steps in the debugger,
found that the "mlist.Unlock()" call [qrunner.py line 256 (main()]
contains a 'file' variable with the current message filename
('8e1e772dc6e98db0e84fec6e4d3444eab7ddfa1a.msg'), unsubscribed the
offending address, and deleted the message in /var/lib/mailman/qfiles .
Then the qrunner ran without error and one of my earlier messages made
it through. But then I looked in the logs a little later and found the
same error, this time from a different message.
Is this a known problem? Is it worth upgrading to 2.1a2 ? Is the
message header incorrect MIME? But shouldn't Mailman be able to handle
problems like this gracefully? Does anybody have any ideas, or do I
have to write myself a patch to work around this?
Mike Orr, mso at ssc.com | SSC, publishers of Linux Journal
Technical Staff | PO Box 55549, Seattle, WA 98155-0549
More information about the Mailman-Users