BoundaryError: No terminating boundary and no trailing empty line
freebsd-4.11 sendmail-8.13.8 mailman-2.1.9_1 python-2.4.3
any clues why mailman keeps dumping the following error trace in /usr/local/mailman/logs/error ? Happens about every hour or so or sometimes minutes apart.
--- snip ---
Dec 26 08:27:28 2006 (75889) Ignoring unparseable message: 1166121349.6141329+c811d30798575d4ca57b9a0552a1d394a95c8ff1 Dec 26 08:27:28 2006 (75889) Uncaught runner exception: No terminating boundary and no trailing empty line Dec 26 08:27:28 2006 (75889) Traceback (most recent call last): File "/usr/local/mailman/Mailman/Queue/Runner.py", line 100, in _oneloop msg, msgdata = self._switchboard.dequeue(filebase) File "/usr/local/mailman/Mailman/Queue/Switchboard.py", line 164, in dequeue msg = email.message_from_string(msg, Message.Message) File "/usr/local/mailman/pythonlib/email/__init__.py", line 51, in message_from_string return Parser(_class, strict=strict).parsestr(s) File "/usr/local/mailman/pythonlib/email/Parser.py", line 75, in parsestr return self.parse(StringIO(text), headersonly=headersonly) File "/usr/local/mailman/pythonlib/email/Parser.py", line 64, in parse self._parsebody(root, fp, firstbodyline) File "/usr/local/mailman/pythonlib/email/Parser.py", line 240, in _parsebody msgobj = self.parsestr(part) File "/usr/local/mailman/pythonlib/email/Parser.py", line 75, in parsestr return self.parse(StringIO(text), headersonly=headersonly) File "/usr/local/mailman/pythonlib/email/Parser.py", line 64, in parse self._parsebody(root, fp, firstbodyline) File "/usr/local/mailman/pythonlib/email/Parser.py", line 265, in _parsebody msg = self.parse(fp) File "/usr/local/mailman/pythonlib/email/Parser.py", line 64, in parse self._parsebody(root, fp, firstbodyline) File "/usr/local/mailman/pythonlib/email/Parser.py", line 206, in _parsebody raise Errors.BoundaryError( BoundaryError: No terminating boundary and no trailing empty line
--- snip ---
Noah writes:
any clues why mailman keeps dumping the following error trace in /usr/local/mailman/logs/error ? Happens about every hour or so or sometimes minutes apart.
Probably for the same reason you repeatedly post to Mailman Users: it wants attention to its pain.
For future reference, the folks (not me! I show up when I feel like it) who monitor this list are knowledgeable and conscientious, in the extreme, and it is *very* rare that posts get dropped on the floor. Typical response times are in the range 30 minutes to 36 hours, depending on random factors.
Check that your post has appeared in the archives, and if so, give it a day at least. Don't waste the interval; read the FAQ[1], search the list archives (a search for the error message, in this case "Ignoring unparseable message", is strongly recommended), collect more log data, etc. If your post doesn't appear within a day, you may wish to send mail to the list administrator. It's possible that your post got inadvertantly snagged by a spam filter, and you'll need help getting past that.
Dec 26 08:27:28 2006 (75889) Ignoring unparseable message: 1166121349.6141329+c811d30798575d4ca57b9a0552a1d394a95c8ff1
The hash code above identified the problem message. I believe you will find a file by that name (with extension .pck) in the "qfiles" directory of your Mailman data area, and if you move it somewhere else, Mailman will stop complaining. It happens regularly because Mailman tries to process the files in that directory on a regular basis, until all deliveries scheduled for it are complete.
It's possible that you are the target of a spambot, in which case you may not find the file (because it's been shunted to the "shunt" directory), and you will see that all the message IDs are different in the logs, because the spambot is sending a new copy at hourly intervals.
Dec 26 08:27:28 2006 (75889) Uncaught runner exception: No terminating boundary and no trailing empty line
You've got a badly-formed MIME message in the queue. It could be spam, it could simply be the product of a Microsoft mail client, it could be broken by a relay MTA, or it could be that you ran out of diskspace and it got truncated (seems unlikely, given the care that Postfix and Mailman take to not do such things).
Use the bin/show_qfiles script to examine the contents of that file. Simply changing to the mailman data area (on my Debian system it's /var/lib/mailman, YMMV) running bin/show_qfiles without arguments will give you a usage message.
Footnotes: [1] The whole thing, both the static one and the FAQ Wizard. If it's not important enough to read the whole FAQ, which isn't as much fun as a Sidney Sheldon novel but is also much shorter, it probably can wait a day or a week.
At 12:21 PM +0900 12/27/06, Stephen J. Turnbull wrote:
For future reference, the folks (not me! I show up when I feel like it) who monitor this list are knowledgeable and conscientious, in the extreme, and it is *very* rare that posts get dropped on the floor. Typical response times are in the range 30 minutes to 36 hours, depending on random factors.
This is the day after Christmas. Any time anyone is posting to any mailing list for the two to three week period of time starting a few days before Christmas and ending a few days after the first of January, it's going to be slow. During these times, people who post to the list can count on replies taking a lot longer to be posted.
-- Brad Knowles, brad@shub-internet.org
Trend Micro has announced that they will cancel the stop.mail-abuse.org mail forwarding service as of 15 November 2006. If you have an old e-mail account for me at this domain, please make sure you correct that with the current address.
Noah wrote:
any clues why mailman keeps dumping the following error trace in /usr/local/mailman/logs/error ? Happens about every hour or so or sometimes minutes apart.
--- snip ---
Dec 26 08:27:28 2006 (75889) Ignoring unparseable message: 1166121349.6141329+c811d30798575d4ca57b9a0552a1d394a95c8ff1 Dec 26 08:27:28 2006 (75889) Uncaught runner exception: No terminating boundary and no trailing empty line
The 'ignoring' message and the associated exception and traceback occur because a 'defective' message has been sent to a Mailman address (a list posting address or a list -request, -bounces, etc address) and has been queued in the appropriate queue. When the appropriate runner attempts to dequeue the message for processing, the dequeueing mechanism attempts to parse the message into a Python email Message object and gets the exception because the message has an unparseable MIME structure.
Such messages are almost certainly unwanted spam in any case. This is what we say about it in the code
# It's possible to get here if the message was stored in the # pickle in plain text, and the metadata had a _parsemsg key # that was true, /and/ if the message had some bogosity in # it. It's almost always going to be spam or bounced spam. # There's not much we can do (and we didn't even get the # metadata, so just log the exception and continue.
-- Mark Sapiro msapiro@value.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (4)
-
Brad Knowles -
Mark Sapiro -
Noah -
Stephen J. Turnbull