Mailman-coders June 2005

mailman-coders@python.org

1 participants
21 discussions

[ mailman-Bugs-698609 ] qrunner infinitely queries name server

by SourceForge.net

Bugs item #698609, was opened at 2003-03-06 11:31 Message generated for change (Settings changed) made by skaus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=698609&group_i… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: 2.1 (stable) >Status: Deleted Resolution: None Priority: 5 Submitted By: Steffen Kaiser (skaus) Assigned to: Nobody/Anonymous (nobody) Summary: qrunner infinitely queries name server Initial Comment: Hi, on a test machine I installed mailman to run locally; sendmail didn't start up however. In result, qrunner caused approx. 300Kbit/s downstream and 150Kbit/s upstream during communication with the name server for at least 10 minutes (seen via sniffer). Eventually I started sendmail and the I/O transfer dropped down to zero almost immediately. Environment: + Linux 2.4.20 + Mailman v2.1.1 + Python 2.2.1 Bye, ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=698609&group_i…

16 years

[ mailman-Bugs-1179487 ] denial of service security bug

by SourceForge.net

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_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. 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-06-26 05:33 Message: Logged In: YES user_id=67709 It looks like the current scheme of sending digest during the course of regular delivery was a bad idea. Workaround may be to enclose the send_digest part in try - except clause. Please try the latest CVS code. ---------------------------------------------------------------------- Comment By: Mark Crispin (mrcrispin) Date: 2005-04-10 01: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 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_…

16 years

[ mailman-Bugs-1222090 ] InterScan Messaging Security Suite bounce message

by SourceForge.net

Bugs item #1222090, was opened at 2005-06-16 20:46 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=1222090&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: bounce detection Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Sub Zero (subzero5) Assigned to: Nobody/Anonymous (nobody) Summary: InterScan Messaging Security Suite bounce message Initial Comment: Here is the original bounce message: From: InterScan MSS Notification [sseri@HIDDENDOMAIN] Subject: Mail could not be delivered --------------------START-------------------- ****** Message from InterScan Messaging Security Suite ****** Sent <<< RCPT TO:<HIDDENRCPT@HIDDENDOMAIN> Received >>> 554 mail for HIDDENRCPT@HIDDENDOMAIN rejected for policy reasons. Unable to deliver message to <HIDDENRCPT@HIDDENDOMAIN>. ************************ End of message ********************** ---------------------END--------------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1222090&group_…

16 years, 1 month

[ mailman-Bugs-1222089 ] atlas.net.tr mail bounce message

by SourceForge.net

Bugs item #1222089, was opened at 2005-06-16 20:41 Message generated for change (Comment added) made by subzero5 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1222089&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: bounce detection Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Sub Zero (subzero5) Assigned to: Nobody/Anonymous (nobody) Summary: atlas.net.tr mail bounce message Initial Comment: Here is the original bounce message: From: Mail Delivery Subsystem [MAILER-DAEMON(a)mailhost2.atlas.net.tr] Subject: Delivery unsuccessful: Mailbox has exceeded the limit --------------------START-------------------- Delivery unsuccessful: Mailbox has exceeded the limit ----- The following addresses had permanent fatal errors ----- <HIDDENRCPT@HIDDENDOMAIN> The size of this mailbox has exceeded the mailbox limit ---------------------END--------------------- ---------------------------------------------------------------------- >Comment By: Sub Zero (subzero5) Date: 2005-06-16 20:42 Message: Logged In: YES user_id=564695 ...t fatal errors -... this was a single-line text :( ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1222089&group_…

16 years, 1 month

[ mailman-Bugs-1222089 ] atlas.net.tr mail bounce message

by SourceForge.net

Bugs item #1222089, was opened at 2005-06-16 20:41 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=1222089&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: bounce detection Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Sub Zero (subzero5) Assigned to: Nobody/Anonymous (nobody) Summary: atlas.net.tr mail bounce message Initial Comment: Here is the original bounce message: From: Mail Delivery Subsystem [MAILER-DAEMON(a)mailhost2.atlas.net.tr] Subject: Delivery unsuccessful: Mailbox has exceeded the limit --------------------START-------------------- Delivery unsuccessful: Mailbox has exceeded the limit ----- The following addresses had permanent fatal errors ----- <HIDDENRCPT@HIDDENDOMAIN> The size of this mailbox has exceeded the mailbox limit ---------------------END--------------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1222089&group_…

16 years, 1 month

[ mailman-Bugs-1221840 ] superonline.com mail bounce message

by SourceForge.net

Bugs item #1221840, was opened at 2005-06-16 14:17 Message generated for change (Comment added) made by subzero5 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1221840&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: bounce detection Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Sub Zero (subzero5) Assigned to: Nobody/Anonymous (nobody) Summary: superonline.com mail bounce message Initial Comment: Here is the original bounce message: From: MAILER-DAEMON(a)superonline.com Subject: Mesajiniz iletilemedi / Delivery failure -------------------------------- Bu mesaj superonline.com posta sunucusu tarafından gönderilen otomatik bilgilendirme mesajıdır. Ekli mesajınız alıcıya ulaşmamıştır.Ulaşmama sebebini aşağıda bulabilirsiniz. English: This is the qmail-send program at superonline.com. I'm afraid I wasn't able to deliver your message to the following addresses. <HIDDENRCPT(a)superonline.com>: The users mailfolder is over the allowed quota (size). --- Below this line is a copy of the message. Return-Path: <LISTNAME-bounces@LISTDOMAIN> Received: (qmail 8414 invoked from network); 16 Jun 2005 11:04:03 -0000 Received: from unknown ([212.252.122.207]) (envelope-sender <>) by qsol03.superonline.com (qmail-ldap-1.03) with QMQP for <>; 16 Jun 2005 11:04:03 -0000 Delivered-To: CLUSTERHOST virus03.superonline.com HIDDENRCPT(a)superonline.com Received: (qmail 15483 invoked from network); 16 Jun 2005 11:04:02 -0000 Received: from HIDDENSENDER (HELO HIDDENSENDER) ([HIDDENIP]) (envelope-sender <LISTNAME-bounces@LISTDOMAIN>) by vfep07.superonline.com (qmail-ldap-1.03) with SMTP for <HIDDENRCPT(a)superonline.com>; 16 Jun 2005 11:04:02 -0000 Received: from localhost ([127.0.0.1]:40102 helo=HIDDENIP) by HIDDENIP with esmtp (Exim 4.51) id 1DirUt-00077g-U6 for HIDDENRCPT(a)superonline.com; Thu, 16 Jun 2005 13:21:19 +0300 Received: from [85.101.173.26] (port=1769 helo=HIDDENSENDER) by HIDDENSENDER with esmtp (Exim 4.51) id 1DirFx-00030q-DU for LISTNAME@LISTDOMAIN; Thu, 16 Jun 2005 13:05:54 +0300 Message-ID: <20050616130549.82FFA3F7AD2F8429@LISTDOMAIN> From: =?ISO-8859-9?B?RUdFTUVO?= <sales@LISTDOMAIN> Subject: =?ISO-8859-9?B?SGFuZ2kgS/1ybf16/T8=?= Date: 16 Jun 2005 13:05:49 +0300 MIME-Version: 1.0 X-Message-Flag: =?ISO-8859-9?B?Rm9sbG93IHVw?= Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_829326A3.E6C7D5C3" X-Antivirus: Kaspersky AV V5.0.5.13/R (hourly updates) X-Mailman-Approved-At: Thu, 16 Jun 2005 13:14:18 +0300 X-BeenThere: LISTNAME@LISTDOMAIN X-Mailman-Version: 2.1.6 Precedence: list Reply-To: sales@LISTDOMAIN -------------------------------- ---------------------------------------------------------------------- >Comment By: Sub Zero (subzero5) Date: 2005-06-16 14:19 Message: Logged In: YES user_id=564695 PS: ı and ş are single characters in iso-8859-9. the sf.net just wrote them wrong. FYI... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1221840&group_…

16 years, 1 month

[ mailman-Bugs-1221840 ] superonline.com mail bounce message

by SourceForge.net

Bugs item #1221840, was opened at 2005-06-16 14:17 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=1221840&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: bounce detection Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Sub Zero (subzero5) Assigned to: Nobody/Anonymous (nobody) Summary: superonline.com mail bounce message Initial Comment: Here is the original bounce message: From: MAILER-DAEMON(a)superonline.com Subject: Mesajiniz iletilemedi / Delivery failure -------------------------------- Bu mesaj superonline.com posta sunucusu tarafından gönderilen otomatik bilgilendirme mesajıdır. Ekli mesajınız alıcıya ulaşmamıştır.Ulaşmama sebebini aşağıda bulabilirsiniz. English: This is the qmail-send program at superonline.com. I'm afraid I wasn't able to deliver your message to the following addresses. <HIDDENRCPT(a)superonline.com>: The users mailfolder is over the allowed quota (size). --- Below this line is a copy of the message. Return-Path: <LISTNAME-bounces@LISTDOMAIN> Received: (qmail 8414 invoked from network); 16 Jun 2005 11:04:03 -0000 Received: from unknown ([212.252.122.207]) (envelope-sender <>) by qsol03.superonline.com (qmail-ldap-1.03) with QMQP for <>; 16 Jun 2005 11:04:03 -0000 Delivered-To: CLUSTERHOST virus03.superonline.com HIDDENRCPT(a)superonline.com Received: (qmail 15483 invoked from network); 16 Jun 2005 11:04:02 -0000 Received: from HIDDENSENDER (HELO HIDDENSENDER) ([HIDDENIP]) (envelope-sender <LISTNAME-bounces@LISTDOMAIN>) by vfep07.superonline.com (qmail-ldap-1.03) with SMTP for <HIDDENRCPT(a)superonline.com>; 16 Jun 2005 11:04:02 -0000 Received: from localhost ([127.0.0.1]:40102 helo=HIDDENIP) by HIDDENIP with esmtp (Exim 4.51) id 1DirUt-00077g-U6 for HIDDENRCPT(a)superonline.com; Thu, 16 Jun 2005 13:21:19 +0300 Received: from [85.101.173.26] (port=1769 helo=HIDDENSENDER) by HIDDENSENDER with esmtp (Exim 4.51) id 1DirFx-00030q-DU for LISTNAME@LISTDOMAIN; Thu, 16 Jun 2005 13:05:54 +0300 Message-ID: <20050616130549.82FFA3F7AD2F8429@LISTDOMAIN> From: =?ISO-8859-9?B?RUdFTUVO?= <sales@LISTDOMAIN> Subject: =?ISO-8859-9?B?SGFuZ2kgS/1ybf16/T8=?= Date: 16 Jun 2005 13:05:49 +0300 MIME-Version: 1.0 X-Message-Flag: =?ISO-8859-9?B?Rm9sbG93IHVw?= Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_829326A3.E6C7D5C3" X-Antivirus: Kaspersky AV V5.0.5.13/R (hourly updates) X-Mailman-Approved-At: Thu, 16 Jun 2005 13:14:18 +0300 X-BeenThere: LISTNAME@LISTDOMAIN X-Mailman-Version: 2.1.6 Precedence: list Reply-To: sales@LISTDOMAIN -------------------------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1221840&group_…

16 years, 1 month

[ mailman-Bugs-1221451 ] privacy issue with subscribers on deferred status

by SourceForge.net

Bugs item #1221451, was opened at 2005-06-15 15:00 Message generated for change (Comment added) made by wheeltrish You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1221451&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: security/privacy Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: wheeltrish (wheeltrish) Assigned to: Nobody/Anonymous (nobody) Summary: privacy issue with subscribers on deferred status Initial Comment: I own a mailman listserver which is hosted on Dreamhost and they are currently running ver. 2.1.5 of mailman. My list is set to require approval of membership requests, which sends the requesters into a "deferred" status in the "Tend to Pending Moderator Requests" area. I've discovered recently that individuals on "Deferred" status CAN in fact post to my list, and their postings are seen by all approved members. The individuals on "Deferred" status do not receive the postings themselves, however. Is this right? Shouldn't an individual who is marked "Deferred" not be able to post until being approved? This prevents me from ever stopping individuals who would send malicious posts to my list from allowing them to do so. My list is a high volume list and increasing the level of moderation would be cumbersome. Is there a way to ensure that members can't post to a list until they are approved, or is this problem an actual bug in the software? Thanks. ---------------------------------------------------------------------- >Comment By: wheeltrish (wheeltrish) Date: 2005-06-15 20:03 Message: Logged In: YES user_id=1297461 When a person requests to subscribe to my list, they go on "deferred" status and are not approved until I click approved in the administrative interface. SINCE posting this message I had another individual post to my list without even trying to subscribe. All she needed was the e-mail address for posting to my list and she was able to post. (Incidentally, my list is not listed in the directory of mailman lists either, so how she even found the information page with the "post to list" address on it is still a mystery, and WHY THE POST WAS NOT REJECTED is baffling me even further. I'm growing concerned about protecting the privacy of my members and I've done what I can to do that, but apparently there are holes in the system somewhere. ideas? Thanks. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-06-15 15:39 Message: Logged In: YES user_id=12800 People waiting to be approved are not members, so the non-member posting policy is what applies to them. They become members only when approved. Perhaps you are not holding non-member posting for approval? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1221451&group_…

16 years, 1 month

[ mailman-Bugs-1221451 ] privacy issue with subscribers on deferred status

by SourceForge.net

Bugs item #1221451, was opened at 2005-06-15 15:00 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1221451&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: security/privacy Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: wheeltrish (wheeltrish) Assigned to: Nobody/Anonymous (nobody) Summary: privacy issue with subscribers on deferred status Initial Comment: I own a mailman listserver which is hosted on Dreamhost and they are currently running ver. 2.1.5 of mailman. My list is set to require approval of membership requests, which sends the requesters into a "deferred" status in the "Tend to Pending Moderator Requests" area. I've discovered recently that individuals on "Deferred" status CAN in fact post to my list, and their postings are seen by all approved members. The individuals on "Deferred" status do not receive the postings themselves, however. Is this right? Shouldn't an individual who is marked "Deferred" not be able to post until being approved? This prevents me from ever stopping individuals who would send malicious posts to my list from allowing them to do so. My list is a high volume list and increasing the level of moderation would be cumbersome. Is there a way to ensure that members can't post to a list until they are approved, or is this problem an actual bug in the software? Thanks. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-06-15 15:39 Message: Logged In: YES user_id=12800 People waiting to be approved are not members, so the non-member posting policy is what applies to them. They become members only when approved. Perhaps you are not holding non-member posting for approval? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1221451&group_…

16 years, 1 month

[ mailman-Bugs-1221451 ] privacy issue with subscribers on deferred status

by SourceForge.net

Bugs item #1221451, was opened at 2005-06-15 15:00 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=1221451&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: security/privacy Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: wheeltrish (wheeltrish) Assigned to: Nobody/Anonymous (nobody) Summary: privacy issue with subscribers on deferred status Initial Comment: I own a mailman listserver which is hosted on Dreamhost and they are currently running ver. 2.1.5 of mailman. My list is set to require approval of membership requests, which sends the requesters into a "deferred" status in the "Tend to Pending Moderator Requests" area. I've discovered recently that individuals on "Deferred" status CAN in fact post to my list, and their postings are seen by all approved members. The individuals on "Deferred" status do not receive the postings themselves, however. Is this right? Shouldn't an individual who is marked "Deferred" not be able to post until being approved? This prevents me from ever stopping individuals who would send malicious posts to my list from allowing them to do so. My list is a high volume list and increasing the level of moderation would be cumbersome. Is there a way to ensure that members can't post to a list until they are approved, or is this problem an actual bug in the software? Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1221451&group_…

16 years, 1 month

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

Mailman-coders June 2005