Mailman 3 November 2002 - Mailman-Developers

hyperarch error w/2.1b4
by Ron Jarrell 08 Nov '02

08 Nov '02

I'd file a bug report on this, but I'm on my out the door and won't be online the rest of the night, and will likely forget about it until the next time I look at the errorlog... This is after applying updates *yesterday*, although nothing checked in so far today would seem to apply.. Only happened once, although plenty of messages have gone through different lists that would have archived. Nov 06 18:19:09 2002 qrunner(13969): Traceback (most recent call last): Nov 06 18:19:09 2002 qrunner(13969): File "/home/mailman/Mailman/Archiver/Archiver.py", line 213, in ArchiveMail Nov 06 18:19:09 2002 qrunner(13969): h.close() Nov 06 18:19:09 2002 qrunner(13969): File "/home/mailman/Mailman/Archiver/pipermail.py", line 303, in close Nov 06 18:19:09 2002 qrunner(13969): self.update_dirty_archives() Nov 06 18:19:09 2002 qrunner(13969): File "/home/mailman/Mailman/Archiver/HyperArch.py", line 1074, in update_dirty_archives Nov 06 18:19:09 2002 qrunner(13969): self.__super_update_dirty_archives() Nov 06 18:19:09 2002 qrunner(13969): File "/home/mailman/Mailman/Archiver/pipermail.py", line 517, in update_dirty_archives Nov 06 18:19:09 2002 qrunner(13969): self.update_archive(i) Nov 06 18:19:09 2002 qrunner(13969): File "/home/mailman/Mailman/Archiver/HyperArch.py", line 1077, in update_archive Nov 06 18:19:09 2002 qrunner(13969): self.__super_update_archive(archive) Nov 06 18:19:09 2002 qrunner(13969): File "/home/mailman/Mailman/Archiver/pipermail.py", line 423, in update_archive Nov 06 18:19:09 2002 qrunner(13969): self._update_simple_index(hdr, archive, arcdir) Nov 06 18:19:09 2002 qrunner(13969): File "/home/mailman/Mailman/Archiver/pipermail.py", line 439, in _update_simple_index Nov 06 18:19:09 2002 qrunner(13969): article = self.database.getArticle(self.archive, msgid) Nov 06 18:19:09 2002 qrunner(13969): File "/home/mailman/Mailman/Archiver/HyperDatabase.py", line 284, in getArticle Nov 06 18:19:09 2002 qrunner(13969): article = self.__cache[msgid] = pickle.loads(buf) Nov 06 18:19:09 2002 qrunner(13969): File "/home/mailman/Mailman/Archiver/HyperArch.py", line 314, in __setstate__ Nov 06 18:19:09 2002 qrunner(13969): if self._mlist is None: Nov 06 18:19:09 2002 qrunner(13969): AttributeError: Article instance has no attribute '_mlist'

3 7

[ mailman-Bugs-620032 ] cmd_confirm: no lstrip
by noreply＠sourceforge.net 08 Nov '02

08 Nov '02

Bugs item #620032, was opened at 2002-10-07 22:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=620032&group_i… Category: (un)subscribing Group: 2.1 beta >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Ron Jarrell (jarrell) Assigned to: Nobody/Anonymous (nobody) Summary: cmd_confirm: no lstrip Initial Comment: Sep 23 18:45:41 2002 (574) Uncaught runner exception: 'NoneType' object has no attribute 'lstrip' Sep 23 18:45:41 2002 (574) Traceback (most recent call last): File "/home/mailman/Mailman/Queue/Runner.py", line 105, in _oneloop self._onefile(msg, msgdata) File "/home/mailman/Mailman/Queue/Runner.py", line 154, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/home/mailman/Mailman/Queue/CommandRu nner.py", line 198, in _dispose res.process() File "/home/mailman/Mailman/Queue/CommandRu nner.py", line 93, in process stop = self.do_command(cmd, args) File "/home/mailman/Mailman/Queue/CommandRu nner.py", line 119, in do_command return handler.process(self, args) File "/home/mailman/Mailman/Commands/cmd_co nfirm.py", line 72, in process if line.lstrip() == match: AttributeError: 'NoneType' object has no attribute 'lstrip' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=620032&group_i…

1 0

[ mailman-Bugs-635227 ] [PATCH] CGI doesn't handle sigterm
by noreply＠sourceforge.net 08 Nov '02

08 Nov '02

Bugs item #635227, was opened at 2002-11-07 17:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=635227&group_i… Category: Web/CGI Group: 2.1 beta >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Terry Hardie (thardie) Assigned to: Nobody/Anonymous (nobody) Summary: [PATCH] CGI doesn't handle sigterm Initial Comment: If a connection is closed to a CGI script, the web server terminates the script with a sigterm, which results in a traceback. admin(6564): [----- Mailman Version: 2.1b4 -----] admin(6564): [----- Traceback ------] admin(6564): Traceback (most recent call last): admin(6564): File "/usr/local/mailman/scripts/driver", line 88, in run_main admin(6564): sys.__stdout__.write (tempstdout.getvalue()) admin(6564): File "/usr/local/mailman/Mailman/Cgi/options.py", line 322, in sigterm_handler admin(6564): sys.exit(0) admin(6564): NameError: global name 'sys' is not defined admin(6564): [----- Python Information -----] admin(6564): sys.version = 2.1.3 (#1, Jul 29 2002, 22:34:51) [GCC 2.95.4 20011002 (Debian prerelease)] admin(6564): sys.executable = /usr/bin/python admin(6564): sys.prefix = /usr admin(6564): sys.exec_prefix = /usr admin(6564): sys.path = /usr admin(6564): sys.platform = linux2 ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-11-07 18:14 Message: Logged In: YES user_id=12800 Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=635227&group_i…

1 0

[ mailman-Bugs-635227 ] [PATCH] CGI doesn't handle sigterm
by noreply＠sourceforge.net 08 Nov '02

08 Nov '02

Bugs item #635227, was opened at 2002-11-07 14:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=635227&group_i… Category: Web/CGI Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Terry Hardie (thardie) Assigned to: Nobody/Anonymous (nobody) Summary: [PATCH] CGI doesn't handle sigterm Initial Comment: If a connection is closed to a CGI script, the web server terminates the script with a sigterm, which results in a traceback. admin(6564): [----- Mailman Version: 2.1b4 -----] admin(6564): [----- Traceback ------] admin(6564): Traceback (most recent call last): admin(6564): File "/usr/local/mailman/scripts/driver", line 88, in run_main admin(6564): sys.__stdout__.write (tempstdout.getvalue()) admin(6564): File "/usr/local/mailman/Mailman/Cgi/options.py", line 322, in sigterm_handler admin(6564): sys.exit(0) admin(6564): NameError: global name 'sys' is not defined admin(6564): [----- Python Information -----] admin(6564): sys.version = 2.1.3 (#1, Jul 29 2002, 22:34:51) [GCC 2.95.4 20011002 (Debian prerelease)] admin(6564): sys.executable = /usr/bin/python admin(6564): sys.prefix = /usr admin(6564): sys.exec_prefix = /usr admin(6564): sys.path = /usr admin(6564): sys.platform = linux2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=635227&group_i…

1 0

[ mailman-Bugs-634274 ] Some digest seems to have a wrong
by noreply＠sourceforge.net 08 Nov '02

08 Nov '02

Bugs item #634274, was opened at 2002-11-06 01:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=634274&group_i… Category: mail delivery >Group: 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: divine rites (divinerites) Assigned to: Nobody/Anonymous (nobody) Summary: Some digest seems to have a wrong Initial Comment: Some Zope digests looks ugly with Evolution. Some digests on some lists are concerned. Not predictable. Digest should look like all normal ones (like for all digests who works fine in evolution) This link give the whole explanation for the digest problem from the evolution point of view. It seems that the mail has some wrong type. http://bugzilla.ximian.com/show_bug.cgi?id=33282 I don't know what Mailman version it is but i guess zope lists use a brand new mailman ;-)) ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-11-07 15:44 Message: Logged In: YES user_id=12800 Actually the Zope lists use Mailman 2.0. I've tested this for MM2.1 plaintext (RFC 1153) digest and can't verify it, so I suspct it's no longer a bug. If it's happening in MM2.0 I can't see it in the code, but I doubt it will get fixed in that branch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=634274&group_i…

1 0

[ mailman-Bugs-634737 ] <CRLF>.<CRLF> in message body
by noreply＠sourceforge.net 08 Nov '02

08 Nov '02

Bugs item #634737, was opened at 2002-11-06 19:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=634737&group_i… Category: mail delivery Group: 2.0.x >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Luca De Santis (lucadex) Assigned to: Nobody/Anonymous (nobody) Summary: <CRLF>.<CRLF> in message body Initial Comment: I looked in the bugs archive but couldn't find anything similar reported, so I write down something about it, hoping it could be of any help. I experienced a problem with Mailman 2.0.11 when a mail posted to the list contained the sequence <CRLF>.<CRLF> (eg. \n.\n) in the middle of the message body. This is the normal char sequence used to indicate the end of the body message (cfr RFC821). In my Mailman installation I use Sendmail for the actual delivery. If a similar message was sent to the list, the qrunner script crashed and I found the following errors in the log: Nov 06 02:05:02 2002 (16085) Delivery exception: [Errno 32] Broken pipe Nov 06 02:05:02 2002 (16085) Traceback (innermost last): File "/home/mailman/Mailman/Handlers/HandlerAPI.py", line 82, in do_pipeline func(mlist, msg, msgdata) File "/home/mailman/Mailman/Handlers/Sendmail.py", line 86, in process fp.write(msgtext) IOError: [Errno 32] Broken pipe It seems like the <CRLF>.<CRLF> in the body of the message was interpreted as the end of the message by Sendmail, so it closed the pipe causing the errors above. All the subscrivers of the list received only the portion of the mail just before the <CRLF>.<CRLF>. Now, since the message was not removed from the qfiles directory, it was resent over and over again to the list. To solve the problem I patched the Handlers/Sendmail.py script adding the following function: def cleanPeriod(str): pattern = re.compile(r"^\.$(.+)", re.DOTALL|re.MULTILINE) return (pattern.sub(r'. \1', str)) and changing line 80 from: msgtext = str(msg) to msgtext = cleanPeriod(str(msg)) ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-11-07 15:41 Message: Logged In: YES user_id=12800 Please note that Sendmail.py is not safe to use. Is there some reason why you can't switch to SMTPDeliver.py? Also, in MM2.1, Sendmail.py is deliberately sabotaged so you can't use it unless you hack the source (and acknowledge the security holes). ---------------------------------------------------------------------- Comment By: Greg Ward (gward) Date: 2002-11-07 12:27 Message: Logged In: YES user_id=14422 A possibly cleaner fix is to run sendmail with the "-oi" switch. I'm not sure if all MTAs recognize this, but I think at least Sendmail proper and Exim do. Here's what Exim's man page has to say: -oi This option, which has the same effect as -i, spec ifies that a dot on a line by itself should not terminate an incoming, non-SMTP message. This is the default if Exim is called as rmail. So maybe "-i" is the portable way to specify this option? I wonder how Mailman handles such messages when SMTP is used? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=634737&group_i…

1 0

[ mailman-Bugs-634737 ] <CRLF>.<CRLF> in message body
by noreply＠sourceforge.net 08 Nov '02

08 Nov '02

Bugs item #634737, was opened at 2002-11-06 19:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=634737&group_i… Category: mail delivery Group: 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: Luca De Santis (lucadex) Assigned to: Nobody/Anonymous (nobody) Summary: <CRLF>.<CRLF> in message body Initial Comment: I looked in the bugs archive but couldn't find anything similar reported, so I write down something about it, hoping it could be of any help. I experienced a problem with Mailman 2.0.11 when a mail posted to the list contained the sequence <CRLF>.<CRLF> (eg. \n.\n) in the middle of the message body. This is the normal char sequence used to indicate the end of the body message (cfr RFC821). In my Mailman installation I use Sendmail for the actual delivery. If a similar message was sent to the list, the qrunner script crashed and I found the following errors in the log: Nov 06 02:05:02 2002 (16085) Delivery exception: [Errno 32] Broken pipe Nov 06 02:05:02 2002 (16085) Traceback (innermost last): File "/home/mailman/Mailman/Handlers/HandlerAPI.py", line 82, in do_pipeline func(mlist, msg, msgdata) File "/home/mailman/Mailman/Handlers/Sendmail.py", line 86, in process fp.write(msgtext) IOError: [Errno 32] Broken pipe It seems like the <CRLF>.<CRLF> in the body of the message was interpreted as the end of the message by Sendmail, so it closed the pipe causing the errors above. All the subscrivers of the list received only the portion of the mail just before the <CRLF>.<CRLF>. Now, since the message was not removed from the qfiles directory, it was resent over and over again to the list. To solve the problem I patched the Handlers/Sendmail.py script adding the following function: def cleanPeriod(str): pattern = re.compile(r"^\.$(.+)", re.DOTALL|re.MULTILINE) return (pattern.sub(r'. \1', str)) and changing line 80 from: msgtext = str(msg) to msgtext = cleanPeriod(str(msg)) ---------------------------------------------------------------------- Comment By: Greg Ward (gward) Date: 2002-11-07 12:27 Message: Logged In: YES user_id=14422 A possibly cleaner fix is to run sendmail with the "-oi" switch. I'm not sure if all MTAs recognize this, but I think at least Sendmail proper and Exim do. Here's what Exim's man page has to say: -oi This option, which has the same effect as -i, spec ifies that a dot on a line by itself should not terminate an incoming, non-SMTP message. This is the default if Exim is called as rmail. So maybe "-i" is the portable way to specify this option? I wonder how Mailman handles such messages when SMTP is used? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=634737&group_i…

1 0

[ mailman-Bugs-634737 ] <CRLF>.<CRLF> in message body
by noreply＠sourceforge.net 07 Nov '02

07 Nov '02

Bugs item #634737, was opened at 2002-11-07 01:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=634737&group_i… Category: mail delivery Group: 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: Luca De Santis (lucadex) Assigned to: Nobody/Anonymous (nobody) Summary: <CRLF>.<CRLF> in message body Initial Comment: I looked in the bugs archive but couldn't find anything similar reported, so I write down something about it, hoping it could be of any help. I experienced a problem with Mailman 2.0.11 when a mail posted to the list contained the sequence <CRLF>.<CRLF> (eg. \n.\n) in the middle of the message body. This is the normal char sequence used to indicate the end of the body message (cfr RFC821). In my Mailman installation I use Sendmail for the actual delivery. If a similar message was sent to the list, the qrunner script crashed and I found the following errors in the log: Nov 06 02:05:02 2002 (16085) Delivery exception: [Errno 32] Broken pipe Nov 06 02:05:02 2002 (16085) Traceback (innermost last): File "/home/mailman/Mailman/Handlers/HandlerAPI.py", line 82, in do_pipeline func(mlist, msg, msgdata) File "/home/mailman/Mailman/Handlers/Sendmail.py", line 86, in process fp.write(msgtext) IOError: [Errno 32] Broken pipe It seems like the <CRLF>.<CRLF> in the body of the message was interpreted as the end of the message by Sendmail, so it closed the pipe causing the errors above. All the subscrivers of the list received only the portion of the mail just before the <CRLF>.<CRLF>. Now, since the message was not removed from the qfiles directory, it was resent over and over again to the list. To solve the problem I patched the Handlers/Sendmail.py script adding the following function: def cleanPeriod(str): pattern = re.compile(r"^\.$(.+)", re.DOTALL|re.MULTILINE) return (pattern.sub(r'. \1', str)) and changing line 80 from: msgtext = str(msg) to msgtext = cleanPeriod(str(msg)) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=634737&group_i…

1 0

Embarrasingly pre-Alpha LDAP Member Adaptor
by Martin Whinnery 07 Nov '02

07 Nov '02

Hi folks. First off - Thanks to Greg and Barry (in particular) for helping me get this far... Right. I've thrown together a first go at a pretty generic LDAP member adaptor for mailman 2.1b4. "It implements a read-only membership interface for a list, implemented as generically as possible, in an attempt to handle in a freindly way the various ways people handle grouping in general and mail grouping in particular with LDAP. WARNING!!!WARNING!!!WARNING!!!WARNING!!!WARNING!!!WARNING!!!WARNING!!! This is DEEPLY ALPHA code. It will almost certainly cause your genitalia to shrivel and your breath to smell, if used in a production environment. If this, or anything else bad happens because you ignored this, please let me know. I'll try not to say 'I told you so'." I'm looking for comments, whether on the assumptions I've made about how people want to handle the interface between LDAP and mailman lists, or on my coding. I am using this in a purely test environment at the moment. As soon as MM 2.1 gets to be stable, I'll be using this or something better at work, for real. So I suppose this is a call for help. Either help me get my code right, or save me having to use it!! Martin Whinnery 'Merely the Assistant' Network Manager South Birmingham College Whoah. Nearly forget the 'meat'. http://www.offal.homelinux.org/python/mailman/LDAPMemberAdaptor/V0.1/ind ex.html Is where the stuff's at.

1 0

Problem with my auto-bounce patch for 2.0.8 in 2.0.13
by Peter C. Norton 07 Nov '02

07 Nov '02

I applied the auto-bounce hack I created for 2.0.8 to 2.0.13, and the patch applied cleanly and the install went fine. However, I've created a bug in the privacy options page. For some reason, changes I made to the MailList class in MailList.py (adding the attribute self.auto_reject_nonmembers) isn't reflected in the HandlerAPI.py call to do_pipeline(mlist, msg, msgdata). Here's the message from the error log: Nov 06 00:27:02 2002 (23713) Delivery exception: auto_reject_nonmembers Nov 06 00:27:02 2002 (23713) Traceback (innermost last): File "/home/mailman/Mailman/Handlers/HandlerAPI.py", line 82, in do_pipeline func(mlist, msg, msgdata) File "/home/mailman/Mailman/Handlers/Hold.py", line 152, in process if mlist.auto_reject_nonmembers: AttributeError: auto_reject_nonmembers I'm not sure what a Delivery exception is caused by, but I'm inferring from the AttributeError that it can't find mlist.auto_reject_nonmembers. how cna this be? Is there somewhere else besides MailList.py where MailList objects are created? Or is there somewhere special that HandlerAPI.py or Hold.py is doing? Help? I can't suppress obnoxios posters for now, and the prospect of having to moderate posts from non-members is too horrible to contempate. -Peter -- The 5 year plan: In five years we'll make up another plan. Or just re-use this one.

2 3