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…
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_…
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_…
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_…
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_…
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_…
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_…
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_…
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_…
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_…