Messages are lost...I have followed FAQs 3.14
I have followed the steps (great job BTW) at http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq03.014.htp and I can't find the solution.
I have mailman version 2.1.6 installed with cPanel on RH 7.3, sending mail through exim. I have several lists running. All used to work just fine. Last week, 2 lists stopped sending mail. Each responds to commands, but posts are just not sent. I can't see where they are dying at. Messages sent to the lists by nonmembers are held as pending, and I get an email to approve or reject. When I approve, the message is never sent. Very weird. Any help, please? Chuck
Chuck Vohs wrote:
I have mailman version 2.1.6 installed with cPanel on RH 7.3, sending mail through exim.
I'm not sure if it's relevant, but see http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq06.011.htp
I have several lists running. All used to work just fine. Last week, 2 lists stopped sending mail. Each responds to commands, but posts are just not sent. I can't see where they are dying at. Messages sent to the lists by nonmembers are held as pending, and I get an email to approve or reject. When I approve, the message is never sent.
It seems you're saying that posts are being sent out from lists other than the specific 2 lists. If so, then it's probably not a qrunner problem unless you're running multiple 'slices' of qrunners and one has died.
Check Mailman's error log.
Check the mailman qfiles/ directory to see where the messages are piling up (shunt, retry, out ?).
Sometimes a corrupt file will cause a list to shut down in this way. Check the files in lists/<listname>/ for the two lists. In particular, if there is a digest.mbox file, try moving it aside and see if that helps.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Getting closer. Thanks.
Mark Sapiro wrote:
Chuck Vohs wrote:
I have mailman version 2.1.6 installed with cPanel on RH 7.3, sending mail through exim.
I'm not sure if it's relevant, but see http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq06.011.htp
Yeah, I had seen that, and they are working on it. I just was at such a lost, I figured I might find some hints or help here.
I have several lists running. All used to work just fine. Last week, 2 lists stopped sending mail. Each responds to commands, but posts are just not sent. I can't see where they are dying at. Messages sent to the lists by nonmembers are held as pending, and I get an email to approve or reject. When I approve, the message is never sent.
It seems you're saying that posts are being sent out from lists other than the specific 2 lists. If so, then it's probably not a qrunner problem unless you're running multiple 'slices' of qrunners and one has died.
Check Mailman's error log.
Check the mailman qfiles/ directory to see where the messages are piling up (shunt, retry, out ?).
Sometimes a corrupt file will cause a list to shut down in this way. Check the files in lists/<listname>/ for the two lists. In particular, if there is a digest.mbox file, try moving it aside and see if that helps.
Wow, that is good news, they are piling up in qfiles/shunt. So that means 1) the messages are getting to the server 2) mailman is trying to process them (it has given them really strange file names), so something is working, just not 100% yet. Thanks for the tip!!!
Chuck Vohs wrote:
Wow, that is good news, they are piling up in qfiles/shunt. So that means 1) the messages are getting to the server 2) mailman is trying to process them (it has given them really strange file names), so something is working, just not 100% yet.
The "really strange file names" are normal.
Somewhere in processing the message, Mailman is encountering an error which causes the message to be shunted. There should be messages in Mailman's error log giving more detail.
After the underlying problem is found and resolved, the shunted messages can be reprocessed with bin/unshunt if desired.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro wrote:
The "really strange file names" are normal.
Somewhere in processing the message, Mailman is encountering an error which causes the message to be shunted. There should be messages in Mailman's error log giving more detail.
After the underlying problem is found and resolved, the shunted messages can be reprocessed with bin/unshunt if desired.
Thanks so much Mark. You are right, in the error log, this entry repeats:
Aug 23 10:29:58 2005 (14333) SHUNTING: 1124807396.5748971+07b93b33553514b955399dacc91a5ca6df015192 Aug 23 10:34:53 2005 (14333) Uncaught runner exception: ASCII decoding error: ordinal not in range(128) Aug 23 10:34:53 2005 (14333) Traceback (most recent call last): File "/usr/local/cpanel/3rdparty/mailman/Mailman/Queue/Runner.py", line 111, in _oneloop self._onefile(msg, msgdata) File "/usr/local/cpanel/3rdparty/mailman/Mailman/Queue/Runner.py", line 167, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/usr/local/cpanel/3rdparty/mailman/Mailman/Queue/OutgoingRunner.py", line 73, in _dispose self._func(mlist, msg, msgdata) File "/usr/local/cpanel/3rdparty/mailman/Mailman/Handlers/SMTPDirect.py", line 131, in process Decorate.process(mlist, msg, msgdata) File "/usr/local/cpanel/3rdparty/mailman/Mailman/Handlers/Decorate.py", line 98, in process ufooter = unicode(footer, lcset) UnicodeError: ASCII decoding error: ordinal not in range(128)
I have tried reinstalling mailman. I'm not sure what to make of this error.
Chuck Vohs wrote:
Thanks so much Mark. You are right, in the error log, this entry repeats:
Aug 23 10:29:58 2005 (14333) SHUNTING: 1124807396.5748971+07b93b33553514b955399dacc91a5ca6df015192 Aug 23 10:34:53 2005 (14333) Uncaught runner exception: ASCII decoding error: ordinal not in range(128) Aug 23 10:34:53 2005 (14333) Traceback (most recent call last): File "/usr/local/cpanel/3rdparty/mailman/Mailman/Queue/Runner.py", line 111, in _oneloop self._onefile(msg, msgdata) File "/usr/local/cpanel/3rdparty/mailman/Mailman/Queue/Runner.py", line 167, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/usr/local/cpanel/3rdparty/mailman/Mailman/Queue/OutgoingRunner.py", line 73, in _dispose self._func(mlist, msg, msgdata) File "/usr/local/cpanel/3rdparty/mailman/Mailman/Handlers/SMTPDirect.py", line 131, in process Decorate.process(mlist, msg, msgdata) File "/usr/local/cpanel/3rdparty/mailman/Mailman/Handlers/Decorate.py", line 98, in process ufooter = unicode(footer, lcset) UnicodeError: ASCII decoding error: ordinal not in range(128)
I have tried reinstalling mailman. I'm not sure what to make of this error.
It looks like msg_footer (on the list's Non-digest options page), and possibly also digest_footer (on the list's Digest options page), has a non-ascii character in it.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro wrote:
It looks like msg_footer (on the list's Non-digest options page), and possibly also digest_footer (on the list's Digest options page), has a non-ascii character in it.
You rock! That was it...not sure how that happened, but I deleted the footers, and it works fine. Thanks so much.
Mark Sapiro wrote:
It looks like msg_footer (on the list's Non-digest options page), and possibly also digest_footer (on the list's Digest options page), has a non-ascii character in it.
Ahhh... yeah. The question is, what next? I run into this fairly often (a few times a month) when trying to delete spam that's awaiting my approval.
Looking at the archives to the mailing list, I've seen that different people have had this problem since 2003 in one form or another.
I've discovered if I clean out any list's list of pending mail, I can copy the appropriate files to the other lists and delete the offending pending files. However, this really isn't a good answer to the question.
Sure, non-ascii characters aren't legal in email addresses, subject lines, and so on. However, the spammers don't seem to mind... personally, I'd be just as happy of Mailman dropped those messages into the bit bucket without even telling me about it, though that may not really be a good answer.
Still, it seems Mailman should be able to handle the illegal data a bit more elegantly.... what's the old system designer mantra, "Never test for an error condition you don't know how to handle"?
Mike
-- ...The irony is that Bill Gates claims to be making a stable operating system and Linus Torvaldis claims to be trying to take over the world...
Mike Avery mavery at mail dot otherwhen dot com home baker ICQ 16241692 networking guru AIM mavery81230 wordsmith Yahoo mavery81230
"Mike" == Mike Avery <mavery@mail.otherwhen.com> writes:
Mike> Looking at the archives to the mailing list, I've seen that
Mike> different people have had this problem since 2003 in one
Mike> form or another.Actually, not. (See below.)
Mike> Still, it seems Mailman should be able to handle the illegal
Mike> data a bit more elegantly.... what's the old system designer
Mike> mantra, "Never test for an error condition you don't know
Mike> how to handle"?The error condition being tested for is "all other errors", and we know how to handle those ... "preserve the post, log the condition, and let someone burn real neurons figuring it out." Although I'm not a Mailman developer, I do know a little about I18N, and it seems to me from a brief look at the code that the problem is that there are a number of different ways that such data can leak out to where it needs to get processed, and the process has been to fix them in place as they are identified. (I've seen two or three of these bugs fixed in the last year, I suspect your spammers have found Yet Another Path to the error handler.)
What really needs to be done for Mailman 2.1 is a complete audit of all the places where headers are accessed, but you know how expensive that is. For Mailman 3, what probably should be done is to rip out all of the current just-in-time I18N processing of headers, and preprocess every header, tagging them with their charsets. Binary headers would be tagged as "bogus" rather than "binary."
Now if I could just beg, borrow, or steal a few "round tuits"....
-- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.
participants (4)
-
Chuck Vohs -
Mark Sapiro -
Mike Avery -
Stephen J. Turnbull