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_…
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_…
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_…
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_…
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_…
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_…
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_…
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_…
Bugs item #1179789, was opened at 2005-04-09 11:29
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=1179789&group_…
Category: documentation
Group: 2.1 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: regis (rmd1023)
Assigned to: Nobody/Anonymous (nobody)
Summary: error in documentation?
Initial Comment:
in the online documentation at
http://www.gnu.org/software/mailman/mailman-install/node43.html
it says the following:
"You should check the values for DEFAULT_EMAIL_HOST and
DEFAULT_URL_HOST in Defaults.py. Make any necessary
changes in the mm_cfg.py file, not in the mm_cfg.py file."
I assume the second "mm_cfg.py" should actually be
"Defaults.py"
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1179789&group_…