Mailman 3 April 2005 - Mailman-coders

[ mailman-Patches-1182245 ] admin.py unicode error patch (shouldn't these all be fixed?)
by SourceForge.net 13 Apr '05

13 Apr '05

Patches item #1182245, was opened at 2005-04-13 16:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1182245&group_… Category: internationalization Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: peter gervai (grin) Assigned to: Nobody/Anonymous (nobody) Summary: admin.py unicode error patch (shouldn't these all be fixed?) Initial Comment: upgraded from 2.0 to 2.1.xx. mailman died some smaller deaths, and a larger one, biting customer with 8859-2 email addresses, which are valid, btw. *this is not a proper fix* (I guess) *a am not a python programmer* (I am pretty sure about this one) however, it solves the bug and It Works(tm). --- admin.py-orig Wed Apr 13 15:44:33 2005 +++ admin.py Wed Apr 13 16:14:27 2005 @@ -867,7 +867,13 @@ chunksz = mlist.admin_member_chunksize # The email addresses had /better/ be ASCII, but might be encoded in the # database as Unicodes. - all = [_m.encode() for _m in mlist.getMembers()] + all = [] + for _m in mlist.getMembers(): + try: + all.append( _m.encode() ) + except: + all.append( _m ) + #all = [_m.encode('utf-8','ignore') for _m in mlist.getMembers()] all.sort(lambda x, y: cmp(x.lower(), y.lower())) # See if the query has a regular expression regexp = cgidata.getvalue('findmember', '').strip() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1182245&group_…

1 0

[ mailman-Feature Requests-1182014 ] forum like interface to mailman
by SourceForge.net 13 Apr '05

13 Apr '05

Feature Requests item #1182014, was opened at 2005-04-12 22:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1182014&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: mariuz (mapopa) Assigned to: Nobody/Anonymous (nobody) Summary: forum like interface to mailman Initial Comment: one long term item would be creating an forum like interface for archives / mail The idea came to me after some users on mono list requested a forum for mono http://lists.ximian.com/mailman/listinfo/mono-list the basic forum interface (there are many others) http://www.gotmono.com/cgi-bin/yabb/YaBB.pl?board=ASPX ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1182014&group_…

1 0

[ mailman-Bugs-1181161 ] Approved: only removed from text/plain part
by SourceForge.net 12 Apr '05

12 Apr '05

Bugs item #1181161, was opened at 2005-04-12 09:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1181161&group_… Category: mail delivery Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Jim Tittsler (jtittsler) Assigned to: Nobody/Anonymous (nobody) Summary: Approved: only removed from text/plain part Initial Comment: If someone uses the "Approved: in the first line of the message" scheme, the line including the list password is only removed from the first text/plain part. It might be better to iterate over all text/* parts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1181161&group_…

1 0

[ mailman-Bugs-1180872 ] subscriber with colon in address can't be removed
by SourceForge.net 11 Apr '05

11 Apr '05

Bugs item #1180872, was opened at 2005-04-11 09:32 Message generated for change (Comment added) made by kiwimonster You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1180872&group_… Category: (un)subscribing Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Kirsten Petersen (kiwimonster) Assigned to: Nobody/Anonymous (nobody) Summary: subscriber with colon in address can't be removed Initial Comment: We are running Mailman 2.1.4 on debian. Somehow, one of our lists wound up with an improperly formatted address like this: mailto:username@domain.com The list administrator is not able to remove this member from the web interface. When I attempt to remove them with remove_members, I get this traceback: Traceback (most recent call last): File "./remove_members", line 186, in ? main() File "./remove_members", line 176, in main admin_notif, userack) File "/var/lib/mailman/Mailman/MailList.py", line 954, in ApprovedDeleteMember self.removeMember(emailaddr) File "/var/lib/mailman/Mailman/OldStyleMemberships.py", line 220, in removeMember self.__assertIsMember(member) File "/var/lib/mailman/Mailman/OldStyleMemberships.py", line 113, in __assertIsMember raise Errors.NotAMemberError, member >From reading rfc822, it looks like colon is not an allowed character in an email address. ---------------------------------------------------------------------- >Comment By: Kirsten Petersen (kiwimonster) Date: 2005-04-11 09:40 Message: Logged In: YES user_id=1122614 Incidentally, an easy way to fix this problem is to dump the membership to a file with list_members, modify the file to remove the improperly formatted address, and then use the file with sync_members. I usually do sync_members -n to see what changes it's going to make first. Of course, it would be ideal for Mailman to not allow bad characters in the email address in the first place. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1180872&group_…

1 0

[ mailman-Bugs-1180872 ] subscriber with colon in address can't be removed
by SourceForge.net 11 Apr '05

11 Apr '05

Bugs item #1180872, was opened at 2005-04-11 09:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1180872&group_… Category: (un)subscribing Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Kirsten Petersen (kiwimonster) Assigned to: Nobody/Anonymous (nobody) Summary: subscriber with colon in address can't be removed Initial Comment: We are running Mailman 2.1.4 on debian. Somehow, one of our lists wound up with an improperly formatted address like this: mailto:username@domain.com The list administrator is not able to remove this member from the web interface. When I attempt to remove them with remove_members, I get this traceback: Traceback (most recent call last): File "./remove_members", line 186, in ? main() File "./remove_members", line 176, in main admin_notif, userack) File "/var/lib/mailman/Mailman/MailList.py", line 954, in ApprovedDeleteMember self.removeMember(emailaddr) File "/var/lib/mailman/Mailman/OldStyleMemberships.py", line 220, in removeMember self.__assertIsMember(member) File "/var/lib/mailman/Mailman/OldStyleMemberships.py", line 113, in __assertIsMember raise Errors.NotAMemberError, member >From reading rfc822, it looks like colon is not an allowed character in an email address. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1180872&group_…

1 0

[ mailman-Feature Requests-1178486 ] Configurable default for Defer Accept Reject Discard options
by SourceForge.net 10 Apr '05

10 Apr '05

Feature Requests item #1178486, was opened at 2005-04-07 21:35 Message generated for change (Comment added) made by jtittsler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1178486&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Rodger Copp (rodger_copp) Assigned to: Nobody/Anonymous (nobody) Summary: Configurable default for Defer Accept Reject Discard options Initial Comment: One particular user from our organization regularly sends several emails to several moderated mailman lists. It is sufficient to simply see who the message is from and then "Accept" it. We have to approve each one separately and we have to change the "Defer" tick each time. It's becoming a pain and it would be nice not to make those extra mouse movements. Is it possible to have the Accept selection ticked by default instead of Defer for Mailman's Moderator Administration page? ---------------------------------------------------------------------- Comment By: Jim Tittsler (jtittsler) Date: 2005-04-10 21:54 Message: Logged In: YES user_id=1488 This would be *very* dangerous, since it could encourage a careless approval of a message to the lists. For your specific use case, it would be far better to add the user to the whitelist of each of the lists. If you really want to live dangerously, you can use the Javascript formula mentioned in the Mailman FAQ to set all of the options to "Accept" (1), instead of "Discard" (3) as in the example. <http://www.python.org/cgi-bin/faqw-mm.py? req=show&file=faq03.026.htp> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1178486&group_…

1 0

[ mailman-Bugs-1179487 ] denial of service security bug
by SourceForge.net 10 Apr '05

10 Apr '05

Bugs item #1179487, was opened at 2005-04-08 14:46 Message generated for change (Comment added) made by mrcrispin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1179487&group_… Category: mail delivery Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Mark Crispin (mrcrispin) Assigned to: Tokio Kikuchi (tkikuchi) Summary: denial of service security bug Initial Comment: We've had multiple incidents of this problem. If a digest gets a message containing an attachment using an RFC 2231 encoded parameter has a character set that is unknown to Python (in this case, "X- UNKNOWN"), then routine get_filename() in email/Message.py (not to be confused with Mailman/Message.py) calls unicode() without any error trap. The result is that digest delivery for that entire mailing list is suspended until that message is manually removed. It appears that passing an "ignore" as the errors parameter to unicode() won't stop Python from generating this error. I'm not sure as to the best way to fix this. I haven't worked much with Python at all, and Mailman support was just dumped on my lap. I can see that there are lots of unicode() calls throughout the Mailman source that don't have any error protection. I don't know which ones are also vulnerable to this attack. Traceback (most recent call last): File "/usr/local/mailman/cron/senddigests", line 94, in ? main() File "/usr/local/mailman/cron/senddigests", line 86, in main mlist.send_digest_now() File "/usr/local/mailman/Mailman/Digester.py", line 60, in send_digest_n ow ToDigest.send_digests(self, mboxfp) File "/usr/local/mailman/Mailman/Handlers/ToDigest.py", line 132, in sen d_digests send_i18n_digests(mlist, mboxfp) File "/usr/local/mailman/Mailman/Handlers/ToDigest.py", line 306, in sen d_i18n_digests msg = scrubber(mlist, msg) File "/usr/local/mailman/Mailman/Handlers/Scrubber.py", line 268, in pro cess url = save_attachment(mlist, part, dir) File "/usr/local/mailman/Mailman/Handlers/Scrubber.py", line 362, in sav e_attachment fnext = os.path.splitext(msg.get_filename(''))[1] File "/usr/local/mailman/pythonlib/email/Message.py", line 731, in get_f ilename return unicode(newvalue[2], newvalue[0] or 'us-ascii') LookupError: unknown encoding: X-UNKNOWN ---------------------------------------------------------------------- >Comment By: Mark Crispin (mrcrispin) Date: 2005-04-09 18:48 Message: Logged In: YES user_id=1255784 Our version of mailman is 2.1.5, the current release version, along with customizations made at UW by my predecessor for use with our web pubcookie authentication system. However, the fault occurs in unmodified Mailman code, and he insists that nothing he did would affect this. I call it a security issue because anyone can send a message to a mailman mailing list that will cause digests to fail and be stuck, just by using a bogus character set name in an attachment filename. Not only isn't the message in question sent, but all subsequent messages are also held because of the trap. A denial of service problem *is* a security problem. I don't know how extensive the problem is in Mailman, but I see numerous unicode() calls in the Mailman source that have no protection from error traps. So maybe more than just digests are affected. If you can't reproduce the problem, I'll be happy to provide some of the messages which hung our digests. The problem definitely happens with charset names in encoded- parameters in MIME (attachment filenames). Thank you in advance for your rapid attention. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2005-04-09 13:57 Message: Logged In: YES user_id=67709 What is your mailman version? I believe i18n charset issues are greatly improved in 2.1.6 beta. BTW, I don't like to call this a security issue. ---------------------------------------------------------------------- Comment By: Mark Crispin (mrcrispin) Date: 2005-04-09 09:38 Message: Logged In: YES user_id=1255784 We've kept copies of the messages which caused the problem in the most recent incident, so if you need help in reproducing/testing we'll be happy to supply them as test data. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1179487&group_…

1 0

[ mailman-Bugs-1179487 ] denial of service security bug
by SourceForge.net 09 Apr '05

09 Apr '05

Bugs item #1179487, was opened at 2005-04-08 21:46 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1179487&group_… Category: mail delivery Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Mark Crispin (mrcrispin) >Assigned to: Tokio Kikuchi (tkikuchi) Summary: denial of service security bug Initial Comment: We've had multiple incidents of this problem. If a digest gets a message containing an attachment using an RFC 2231 encoded parameter has a character set that is unknown to Python (in this case, "X- UNKNOWN"), then routine get_filename() in email/Message.py (not to be confused with Mailman/Message.py) calls unicode() without any error trap. The result is that digest delivery for that entire mailing list is suspended until that message is manually removed. It appears that passing an "ignore" as the errors parameter to unicode() won't stop Python from generating this error. I'm not sure as to the best way to fix this. I haven't worked much with Python at all, and Mailman support was just dumped on my lap. I can see that there are lots of unicode() calls throughout the Mailman source that don't have any error protection. I don't know which ones are also vulnerable to this attack. Traceback (most recent call last): File "/usr/local/mailman/cron/senddigests", line 94, in ? main() File "/usr/local/mailman/cron/senddigests", line 86, in main mlist.send_digest_now() File "/usr/local/mailman/Mailman/Digester.py", line 60, in send_digest_n ow ToDigest.send_digests(self, mboxfp) File "/usr/local/mailman/Mailman/Handlers/ToDigest.py", line 132, in sen d_digests send_i18n_digests(mlist, mboxfp) File "/usr/local/mailman/Mailman/Handlers/ToDigest.py", line 306, in sen d_i18n_digests msg = scrubber(mlist, msg) File "/usr/local/mailman/Mailman/Handlers/Scrubber.py", line 268, in pro cess url = save_attachment(mlist, part, dir) File "/usr/local/mailman/Mailman/Handlers/Scrubber.py", line 362, in sav e_attachment fnext = os.path.splitext(msg.get_filename(''))[1] File "/usr/local/mailman/pythonlib/email/Message.py", line 731, in get_f ilename return unicode(newvalue[2], newvalue[0] or 'us-ascii') LookupError: unknown encoding: X-UNKNOWN ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2005-04-09 20:57 Message: Logged In: YES user_id=67709 What is your mailman version? I believe i18n charset issues are greatly improved in 2.1.6 beta. BTW, I don't like to call this a security issue. ---------------------------------------------------------------------- Comment By: Mark Crispin (mrcrispin) Date: 2005-04-09 16:38 Message: Logged In: YES user_id=1255784 We've kept copies of the messages which caused the problem in the most recent incident, so if you need help in reproducing/testing we'll be happy to supply them as test data. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1179487&group_…

1 0

[ mailman-Bugs-1179487 ] denial of service security bug
by SourceForge.net 09 Apr '05

09 Apr '05

Bugs item #1179487, was opened at 2005-04-08 14:46 Message generated for change (Comment added) made by mrcrispin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1179487&group_… Category: mail delivery Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Mark Crispin (mrcrispin) Assigned to: Barry A. Warsaw (bwarsaw) Summary: denial of service security bug Initial Comment: We've had multiple incidents of this problem. If a digest gets a message containing an attachment using an RFC 2231 encoded parameter has a character set that is unknown to Python (in this case, "X- UNKNOWN"), then routine get_filename() in email/Message.py (not to be confused with Mailman/Message.py) calls unicode() without any error trap. The result is that digest delivery for that entire mailing list is suspended until that message is manually removed. It appears that passing an "ignore" as the errors parameter to unicode() won't stop Python from generating this error. I'm not sure as to the best way to fix this. I haven't worked much with Python at all, and Mailman support was just dumped on my lap. I can see that there are lots of unicode() calls throughout the Mailman source that don't have any error protection. I don't know which ones are also vulnerable to this attack. Traceback (most recent call last): File "/usr/local/mailman/cron/senddigests", line 94, in ? main() File "/usr/local/mailman/cron/senddigests", line 86, in main mlist.send_digest_now() File "/usr/local/mailman/Mailman/Digester.py", line 60, in send_digest_n ow ToDigest.send_digests(self, mboxfp) File "/usr/local/mailman/Mailman/Handlers/ToDigest.py", line 132, in sen d_digests send_i18n_digests(mlist, mboxfp) File "/usr/local/mailman/Mailman/Handlers/ToDigest.py", line 306, in sen d_i18n_digests msg = scrubber(mlist, msg) File "/usr/local/mailman/Mailman/Handlers/Scrubber.py", line 268, in pro cess url = save_attachment(mlist, part, dir) File "/usr/local/mailman/Mailman/Handlers/Scrubber.py", line 362, in sav e_attachment fnext = os.path.splitext(msg.get_filename(''))[1] File "/usr/local/mailman/pythonlib/email/Message.py", line 731, in get_f ilename return unicode(newvalue[2], newvalue[0] or 'us-ascii') LookupError: unknown encoding: X-UNKNOWN ---------------------------------------------------------------------- >Comment By: Mark Crispin (mrcrispin) Date: 2005-04-09 09:38 Message: Logged In: YES user_id=1255784 We've kept copies of the messages which caused the problem in the most recent incident, so if you need help in reproducing/testing we'll be happy to supply them as test data. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1179487&group_…

1 0

[ mailman-Bugs-1179487 ] denial of service security bug
by SourceForge.net 09 Apr '05

09 Apr '05

Bugs item #1179487, was opened at 2005-04-08 17:46 Message generated for change (Settings changed) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1179487&group_… Category: mail delivery Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Mark Crispin (mrcrispin) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: denial of service security bug Initial Comment: We've had multiple incidents of this problem. If a digest gets a message containing an attachment using an RFC 2231 encoded parameter has a character set that is unknown to Python (in this case, "X- UNKNOWN"), then routine get_filename() in email/Message.py (not to be confused with Mailman/Message.py) calls unicode() without any error trap. The result is that digest delivery for that entire mailing list is suspended until that message is manually removed. It appears that passing an "ignore" as the errors parameter to unicode() won't stop Python from generating this error. I'm not sure as to the best way to fix this. I haven't worked much with Python at all, and Mailman support was just dumped on my lap. I can see that there are lots of unicode() calls throughout the Mailman source that don't have any error protection. I don't know which ones are also vulnerable to this attack. Traceback (most recent call last): File "/usr/local/mailman/cron/senddigests", line 94, in ? main() File "/usr/local/mailman/cron/senddigests", line 86, in main mlist.send_digest_now() File "/usr/local/mailman/Mailman/Digester.py", line 60, in send_digest_n ow ToDigest.send_digests(self, mboxfp) File "/usr/local/mailman/Mailman/Handlers/ToDigest.py", line 132, in sen d_digests send_i18n_digests(mlist, mboxfp) File "/usr/local/mailman/Mailman/Handlers/ToDigest.py", line 306, in sen d_i18n_digests msg = scrubber(mlist, msg) File "/usr/local/mailman/Mailman/Handlers/Scrubber.py", line 268, in pro cess url = save_attachment(mlist, part, dir) File "/usr/local/mailman/Mailman/Handlers/Scrubber.py", line 362, in sav e_attachment fnext = os.path.splitext(msg.get_filename(''))[1] File "/usr/local/mailman/pythonlib/email/Message.py", line 731, in get_f ilename return unicode(newvalue[2], newvalue[0] or 'us-ascii') LookupError: unknown encoding: X-UNKNOWN ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1179487&group_…

1 0