From noreply at sourceforge.net Sat Apr 2 22:25:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Apr 2 22:25:21 2005 Subject: [ mailman-Bugs-1175507 ] Wrong encoding in localized monthly reminders Message-ID: Bugs item #1175507, was opened at 2005-04-02 23:25 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=1175507&group_id=103 Category: command line scripts Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Laurynas Biveinis (lauras) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong encoding in localized monthly reminders Initial Comment: The character encoding in translated monthly reminder headers is different from the actual body text encoding, resulting in garbled diacritics. For example, Lithuanian reminder is present in the server in ISO 8859-13, sent out converted to UTF-8, yet the headers still say Content-Type: text/plain; charset="iso-8859-13" A cursory look at mailpasswds script suggests that it simply forgets to update encoding in headers after translating text to UTF-8. Version information: -bash-3.00# cat /etc/redhat-release Fedora Core release 3 (Heidelberg) -bash-3.00# uname -a Linux aldona 2.6.10-1.770_FC3 #1 Thu Feb 24 14:00:06 EST 2005 i686 i686 i386 GNU/Linux -bash-3.00# rpm -q mailman mailman-2.1.5-32.fc3 Thanks, Laurynas ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1175507&group_id=103 From noreply at sourceforge.net Mon Apr 4 05:39:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Apr 4 05:39:34 2005 Subject: [ mailman-Bugs-1176138 ] permission denied Message-ID: Bugs item #1176138, was opened at 2005-04-04 11:39 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=1176138&group_id=103 Category: bounce detection Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: brian (irabufan) Assigned to: Nobody/Anonymous (nobody) Summary: permission denied Initial Comment: mailman was installed from rpm package in redhat fedora core 3 cd (system also running redhat fedora 3), but it hits the following bug while trying to create a mailing list via cgi... any solutions? -------------------------------------------------- Bug in Mailman version 2.1.5 We're sorry, we hit a bug! If you would like to help us identify the problem, please email a copy of this page to the webmaster for this site with a description of what happened. Thanks! Traceback: Traceback (most recent call last): File "/usr/lib/mailman/scripts/driver", line 87, in run_main main() File "/usr/src/build/471806- i386/install/usr/lib/mailman/Mailman/Cgi/create.py", line 55, in main File "/usr/src/build/471806- i386/install/usr/lib/mailman/Mailman/Cgi/create.py", line 187, in process_request File "/usr/src/build/471806- i386/install/usr/lib/mailman/Mailman/MailList.py", line 454, in Create File "/usr/src/build/471806- i386/install/usr/lib/mailman/Mailman/Site.py", line 65, in get_listpath File "/usr/src/build/471806- i386/install/usr/lib/mailman/Mailman/Site.py", line 40, in _makedir File "/usr/src/build/475206- i386/install/usr/lib/python2.3/os.py", line 154, in makedirs mkdir(name, mode) OSError: [Errno 13] Permission denied: '/var/lib/mailman/lists/balist' -------------------------------------------------------------------------------- Python information: Variable Value sys.version 2.3.4 (#1, Oct 26 2004, 16:42:40) [GCC 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)] sys.executable /usr/bin/python sys.prefix /usr sys.exec_prefix /usr sys.path /usr sys.platform linux2 -------------------------------------------------------------------------------- Environment variables: Variable Value HTTP_COOKIE sid=703d3666104d114f75802d8faf257720 SERVER_SOFTWARE Apache/2.0.52 (Fedora) SCRIPT_NAME /mailman/create SERVER_SIGNATURE Apache/2.0.52 (Fedora) Server at 10.3.1.89 Port 80 REQUEST_METHOD POST SERVER_PROTOCOL HTTP/1.1 QUERY_STRING CONTENT_LENGTH 136 HTTP_USER_AGENT Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) HTTP_CONNECTION Keep-Alive HTTP_REFERER http://10.3.1.89/mailman/create SERVER_NAME 10.3.1.89 REMOTE_ADDR 10.3.1.55 SERVER_PORT 80 SERVER_ADDR 10.3.1.89 DOCUMENT_ROOT /var/www/html PYTHONPATH /usr/lib/mailman SCRIPT_FILENAME /usr/lib/mailman/cgi-bin/create SERVER_ADMIN root@localhost HTTP_HOST 10.3.1.89 HTTP_CACHE_CONTROL no-cache REQUEST_URI /mailman/create HTTP_ACCEPT image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms- powerpoint, application/msword, application/x-icq, */* GATEWAY_INTERFACE CGI/1.1 REMOTE_PORT 1443 HTTP_ACCEPT_LANGUAGE en-us CONTENT_TYPE application/x-www-form-urlencoded HTTP_ACCEPT_ENCODING gzip, deflate ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1176138&group_id=103 From noreply at sourceforge.net Mon Apr 4 12:47:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Apr 4 12:47:19 2005 Subject: [ mailman-Patches-1176278 ] HeaderParseError Message-ID: Patches item #1176278, was opened at 2005-04-04 13:47 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=1176278&group_id=103 Category: mail delivery Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Myroslav Opyr (interra) Assigned to: Nobody/Anonymous (nobody) Summary: HeaderParseError Initial Comment: Hi, The error was reported several times at maillists (Users and Developers). It look like email library started producing this Exception and Mailman never got to handle it in addition to LookupError, and UnicodeError. In my case the problem was in ugly headers. I was with Email 2.5.5 and 3.0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1176278&group_id=103 From noreply at sourceforge.net Mon Apr 4 13:01:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Apr 4 13:01:26 2005 Subject: [ mailman-Patches-1176284 ] CommandRunner-UnicodeDecodeError Message-ID: Patches item #1176284, was opened at 2005-04-04 14:01 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=1176284&group_id=103 Category: mail delivery Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Myroslav Opyr (interra) Assigned to: Nobody/Anonymous (nobody) Summary: CommandRunner-UnicodeDecodeError Initial Comment: Another two messages got stuck in my shunt folder: Apr 04 13:48:45 2005 (31466) Traceback (most recent call last): File "/usr/local/mailman/Mailman/Queue/Runner.py", line 111, in _oneloop self._onefile(msg, msgdata) File "/usr/local/mailman/Mailman/Queue/Runner.py", line 167, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/usr/local/mailman/Mailman/Queue/CommandRunner.py", line 224, in _dispose res = Results(mlist, msg, msgdata) File "/usr/local/mailman/Mailman/Queue/CommandRunner.py", line 78, in __init__ subj = make_header(decode_header(subj)).__unicode__() File "/usr/local/lib/python2.3/site-packages/email/Header.py", line 124, in make_header h.append(s, charset) File "/usr/local/lib/python2.3/site-packages/email/Header.py", line 252, in append ustr = unicode(s, incodec, errors) UnicodeDecodeError: 'ascii' codec can't decode byte 0xd5 in position 0: ordinal not in range(128) Attached patch pushed them. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1176284&group_id=103 From noreply at sourceforge.net Mon Apr 4 13:02:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Apr 4 13:02:42 2005 Subject: [ mailman-Patches-1176278 ] HeaderParseError Message-ID: Patches item #1176278, was opened at 2005-04-04 13:47 Message generated for change (Comment added) made by interra You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1176278&group_id=103 Category: mail delivery Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Myroslav Opyr (interra) Assigned to: Nobody/Anonymous (nobody) Summary: HeaderParseError Initial Comment: Hi, The error was reported several times at maillists (Users and Developers). It look like email library started producing this Exception and Mailman never got to handle it in addition to LookupError, and UnicodeError. In my case the problem was in ugly headers. I was with Email 2.5.5 and 3.0. ---------------------------------------------------------------------- >Comment By: Myroslav Opyr (interra) Date: 2005-04-04 14:02 Message: Logged In: YES user_id=327208 Forgot to attach :( it should be automagically turned on when I fill the upload box! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1176278&group_id=103 From noreply at sourceforge.net Tue Apr 5 02:08:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Apr 5 02:08:37 2005 Subject: [ mailman-Bugs-1176706 ] error when doing bin/newlist mailman Message-ID: Bugs item #1176706, was opened at 2005-04-05 02:08 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=1176706&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: BuGoFf (bugoff) Assigned to: Nobody/Anonymous (nobody) Summary: error when doing bin/newlist mailman Initial Comment: I installed mailman like it is said in the INSTALL file but when i have to make the newlist it gives an error: mailman@bleu_top:~$ ./bin/newlist mailman Enter the email of the person running the list: admin@blue-top.be Initial mailman password: Traceback (most recent call last): File "./bin/newlist", line 219, in ? main() File "./bin/newlist", line 160, in main mlist.Create(listname, owner_mail, pw) File "/usr/local/mailman/Mailman/MailList.py", line 457, in Create self.InitVars(name, admin, crypted_password) File "/usr/local/mailman/Mailman/MailList.py", line 296, in InitVars self.web_page_url = ( TypeError: not all arguments converted during string formatting Is there a solution for this problem? Thanks in advance for your help Bram ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1176706&group_id=103 From noreply at sourceforge.net Thu Apr 7 02:37:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 7 02:37:15 2005 Subject: [ mailman-Bugs-1178199 ] 2.1.6B4: encode_ascii_prefixes error Message-ID: Bugs item #1178199, was opened at 2005-04-07 02:37 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=1178199&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jan Kellermann (werk21) Assigned to: Nobody/Anonymous (nobody) Summary: 2.1.6B4: encode_ascii_prefixes error Initial Comment: Hi! Mailman seems not to encode the subject prefix correctly. Options: Language: german (iso-8859-1) encode_ascii_prefixes: Always Prefix: ??? my mailsubject: ??? result: =?utf-8?b?W8OEw7bDnF0=?= =?iso-8859-1?q? =E4=F6=FC?= my Mailsubject: test result: =?utf-8?b?W8OEw7bDnF0=?= test Mailman seems to convert always in utf regardless of which language is chosen. The result is a subject-line with two different encodings if you have special chars in prefix and the subject-line. A lot of mailcleints do not support this so that in the display (not in the mailheader) the subject after the prefix is lost. And the space between prefix and subject will be lost because it is not encoded. This problem we did not have before using mailman version 2.2a. The MTA is postfix. I dont know if postfix is doing this encoding to utf or mailman. In this case mailman fails to convert the prefix. If I choose encode_ascii_prefixes: Needed I get the same result. If I choose encode_ascii_prefixes: Never I get the same result. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1178199&group_id=103 From noreply at sourceforge.net Thu Apr 7 12:45:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 7 12:45:17 2005 Subject: [ mailman-Bugs-969613 ] double-quotes handled inconsistent for list's description Message-ID: Bugs item #969613, was opened at 2004-06-09 15:54 Message generated for change (Comment added) made by windl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=969613&group_id=103 >Category: configuring/installing Group: 2.1 (stable) Status: Open Resolution: None Priority: 8 Submitted By: Ulrich Windl (windl) Assigned to: Nobody/Anonymous (nobody) >Summary: double-quotes handled inconsistent for list's description Initial Comment: (I'll use a double exclamation mark (!!) instead of a double-quote here, because it seems the double-quotes are converted to """ here by mistake) If I enter a short description like the following line for a mailing list: List about !!something interesting!! mailman-2.1.4 cunnecessarily converts the double quotes (!!) to " in EMail header values. Example: List-Id: !!List about "something interesting" !! I think that the quoting in font of an EMail address enclosed by anglr brackets (<...>) is not necessary, and using HTML is wron and not portable. I might work with some broken clients however. ---------------------------------------------------------------------- >Comment By: Ulrich Windl (windl) Date: 2005-04-07 12:45 Message: Logged In: YES user_id=181779 I've learned that "&quit;" is stored in mailman's list configuration file like this: description = 'Talking about "this"' where description = 'Talking about "this"' would work. Actually when using config_list to make that change, it tuns out that the Web interface can't handle that, producing just 'Talking about '. list_lists however would print the correct strings. Summary: This is not just a problem in mail headers. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=969613&group_id=103 From noreply at sourceforge.net Thu Apr 7 13:32:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 7 13:32:36 2005 Subject: [ mailman-Bugs-1178453 ] allow setting max# or autoexpire pending administration Message-ID: Bugs item #1178453, was opened at 2005-04-07 11: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=1178453&group_id=103 Category: None Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Ken Yee (kenyee) Assigned to: Nobody/Anonymous (nobody) Summary: allow setting max# or autoexpire pending administration Initial Comment: Some mailing lists gets spammed a lot, so the "tend to pending administration work" gets huge after a few weeks, especially if you forget about it for a while :-) I'd suggest one of two things: 1) set a max# of pending admin items and autodelete the ones that are oldest 2) set an automatic purge of items older than N days I have a list I'm on where I can't even load the "tend to pending admin work" page any more because it's so huge. The browser just sits there and spins while the server tries to send everything down. Of course, I've neglected deleting spam (it's a list where only list members can post) for a few months.... ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1178453&group_id=103 From noreply at sourceforge.net Thu Apr 7 14:35:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 7 14:35:18 2005 Subject: [ mailman-Feature Requests-1178486 ] Configurable default for Defer Accept Reject Discard options Message-ID: Feature Requests item #1178486, was opened at 2005-04-07 12:35 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=1178486&group_id=103 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? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1178486&group_id=103 From noreply at sourceforge.net Fri Apr 8 23:46:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 8 23:46:29 2005 Subject: [ mailman-Bugs-1179487 ] denial of service security bug Message-ID: Bugs item #1179487, was opened at 2005-04-08 14: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=1179487&group_id=103 Category: mail delivery Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Mark Crispin (mrcrispin) Assigned to: Nobody/Anonymous (nobody) 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_id=103 From noreply at sourceforge.net Sat Apr 9 12:14:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Apr 9 12:14:57 2005 Subject: [ mailman-Patches-839386 ] MySQL MemberAdaptor for Mailman 2.1 Message-ID: Patches item #839386, was opened at 2003-11-10 19:04 Message generated for change (Comment added) made by egervary You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=839386&group_id=103 Category: configure/install Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Kev Green (kyrian) Assigned to: Nobody/Anonymous (nobody) Summary: MySQL MemberAdaptor for Mailman 2.1 Initial Comment: A MemberAdaptor "plugin" which should allow Mailman list members to be loaded from a MySQL database, rather than just a Mailman "pickle" file. Provided as-is, and without warranty, this "plugin" may destroy your server, soul, scalp, house, and life. Please use it with caution. Kev Green, oRe Net. http://www.orenet.co.uk/ ---------------------------------------------------------------------- Comment By: Gergely EGERVARY (egervary) Date: 2005-04-09 12:14 Message: Logged In: YES user_id=1255996 Thank you for your good work. FYI: there's a missing "AND" in MysqlMemberships.py in line 494. ---------------------------------------------------------------------- Comment By: simboforge (simboforge) Date: 2005-03-12 00:22 Message: Logged In: YES user_id=1226150 excellent. can you please give me a list of the files modified from the original distro? grep sees six that grep have msyql in them. thx ---------------------------------------------------------------------- Comment By: Kev Green (kyrian) Date: 2005-03-11 23:56 Message: Logged In: YES user_id=99923 The flat file databases are unused when you put the MySQL adaptor in place, and they are untouched (and indeed not deleted) by it, the MySQL adaptor only queries the MySQL tables for membership information, without trying to force you into using it fulltime by deleting anything, etc. Once you unconfigure the MySQL adaptor, Mailman should revert back to your existing flat file databases. Of course, I could have missed something, etc. so do back up your flat file databases before installing the MySQL adaptor, and then you can just migrate back to them by restoring the backups. Either way, you have come up with a good question for an FAQ on the SQL adaptor :-) K. ---------------------------------------------------------------------- Comment By: simboforge (simboforge) Date: 2005-03-11 23:42 Message: Logged In: YES user_id=1226150 neat. just what i was looking for. i have a couple of live lists running on version version 2.1.5. i am a bit leary about unzipping this distrobution over the top of my working mailman as i am not sure how to backup the existing flat file databases. i would prefer to experiment with dropping the adapter into my existing installation. any pointers as to where to start? thx ---------------------------------------------------------------------- Comment By: Kev Green (kyrian) Date: 2004-12-13 19:34 Message: Logged In: YES user_id=99923 Oh, btw. v1.57 hasn't been tested yet, so it might kill your server, eat your dog, and stick your wife in the oven. Be careful using it! ---------------------------------------------------------------------- Comment By: Kev Green (kyrian) Date: 2004-12-13 19:33 Message: Logged In: YES user_id=99923 Version 1.57: 2004/12/13 * Merge in Daniel Shriver patch/code for a flat table architecture. [ Suggested by Kevin McCann , but I hadn't found time to do it myself... ] * Add bugfix information from Jinhyok Heo * Add in mksqlmailman script from TheSin * Follow Barry Warsaw's suggestion on delivery status timestamp. ---------------------------------------------------------------------- Comment By: Kev Green (kyrian) Date: 2004-01-08 12:38 Message: Logged In: YES user_id=99923 Latest version incorporates automated generation of the necessary tables, cleaner error reporting, and updated documentation. ---------------------------------------------------------------------- Comment By: Kev Green (kyrian) Date: 2003-11-11 12:14 Message: Logged In: YES user_id=99923 Bit of an oops in version 1.49, 1.50 now uploaded, which should fix it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=839386&group_id=103 From noreply at sourceforge.net Sat Apr 9 17:29:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Apr 9 17:29:44 2005 Subject: [ mailman-Bugs-1179789 ] error in documentation? Message-ID: 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_id=103 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_id=103 From noreply at sourceforge.net Sat Apr 9 18:15:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Apr 9 18:15:19 2005 Subject: [ mailman-Bugs-1179487 ] denial of service security bug Message-ID: 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_id=103 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_id=103 From noreply at sourceforge.net Sat Apr 9 18:38:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Apr 9 18:38:44 2005 Subject: [ mailman-Bugs-1179487 ] denial of service security bug Message-ID: 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_id=103 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_id=103 From noreply at sourceforge.net Sat Apr 9 22:57:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Apr 9 22:57:53 2005 Subject: [ mailman-Bugs-1179487 ] denial of service security bug Message-ID: 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_id=103 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_id=103 From noreply at sourceforge.net Sun Apr 10 03:48:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Apr 10 03:48:46 2005 Subject: [ mailman-Bugs-1179487 ] denial of service security bug Message-ID: 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_id=103 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_id=103 From noreply at sourceforge.net Sun Apr 10 14:54:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Apr 10 14:54:32 2005 Subject: [ mailman-Feature Requests-1178486 ] Configurable default for Defer Accept Reject Discard options Message-ID: 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_id=103 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1178486&group_id=103 From noreply at sourceforge.net Mon Apr 11 18:32:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Apr 11 18:32:45 2005 Subject: [ mailman-Bugs-1180872 ] subscriber with colon in address can't be removed Message-ID: 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_id=103 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_id=103 From noreply at sourceforge.net Mon Apr 11 18:40:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Apr 11 18:40:45 2005 Subject: [ mailman-Bugs-1180872 ] subscriber with colon in address can't be removed Message-ID: 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_id=103 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_id=103 From noreply at sourceforge.net Tue Apr 12 02:54:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Apr 12 02:54:50 2005 Subject: [ mailman-Bugs-1181161 ] Approved: only removed from text/plain part Message-ID: 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_id=103 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_id=103 From noreply at sourceforge.net Wed Apr 13 08:40:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Apr 13 08:40:42 2005 Subject: [ mailman-Feature Requests-1182014 ] forum like interface to mailman Message-ID: 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_id=103 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_id=103 From noreply at sourceforge.net Wed Apr 13 16:20:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Apr 13 16:20:14 2005 Subject: [ mailman-Patches-1182245 ] admin.py unicode error patch (shouldn't these all be fixed?) Message-ID: 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_id=103 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_id=103 From noreply at sourceforge.net Wed Apr 13 16:33:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Apr 13 16:33:12 2005 Subject: [ mailman-Patches-1182245 ] admin.py unicode error patch (shouldn't these all be fixed?) Message-ID: Patches item #1182245, was opened at 2005-04-13 16:20 Message generated for change (Comment added) made by grin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1182245&group_id=103 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() ---------------------------------------------------------------------- >Comment By: peter gervai (grin) Date: 2005-04-13 16:33 Message: Logged In: YES user_id=9622 ...but I must comment that it is likely the users will enter 8859-2 ancoded local parts, and maybe I10L'ised domains (IDN) too. Mailman is not supposed to choke and die on these. I guess... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1182245&group_id=103 From noreply at sourceforge.net Thu Apr 14 00:55:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 14 00:55:26 2005 Subject: [ mailman-Bugs-1182604 ] HTML archive permissions block mail delivery Message-ID: Bugs item #1182604, was opened at 2005-04-13 22:55 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=1182604&group_id=103 Category: mail delivery Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Gregory Mokhin (mokhin) Assigned to: Nobody/Anonymous (nobody) Summary: HTML archive permissions block mail delivery Initial Comment: Mailman version 2.1.6b4. Mail delivery stopped suddenly after one week of normal operation and silently, mails being sent to shunt queue. Here is the error log: Apr 13 22:02:28 2005 (3585) Uncaught runner exception: [Errno 5] Input/output error Apr 13 22:02:28 2005 (3585) Traceback (most recent call last): File "/usr/local/mailman/Mailman/Queue/Runner.py", line 111, in _oneloop self._onefile(msg, msgdata) File "/usr/local/mailman/Mailman/Queue/Runner.py", line 167, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/usr/local/mailman/Mailman/Queue/IncomingRunner .py", line 130, in _dispose more = self._dopipeline(mlist, msg, msgdata, pipeline) File "/usr/local/mailman/Mailman/Queue/IncomingRunner .py", line 153, in _dopipeline sys.modules[modname].process(mlist, msg, msgdata) File "/usr/local/mailman/Mailman/Handlers/ToDigest.py", line 92, in process send_digests(mlist, mboxfp) File "/usr/local/mailman/Mailman/Handlers/ToDigest.py", line 133, in send_digests send_i18n_digests(mlist, mboxfp) File "/usr/local/mailman/Mailman/Handlers/ToDigest.py", line 315, in send_i18n_digests msg = scrubber(mlist, msg) File "/usr/local/mailman/Mailman/Handlers/Scrubber.py", line 287, in process payload = part.get_payload(decode=True) File "/usr/local/mailman/pythonlib/email/Message.py", line 224, in get_payload uu.decode(StringIO(payload+'\n'), sfp) File "/usr/lib/python2.4/uu.py", line 139, in decode sys.stderr.write("Warning: %s\n" % str(v)) File "/usr/local/mailman/Mailman/Logging/MultiLogger.py ", line 45, in write _logexc(logger, msg) File "/usr/local/mailman/Mailman/Logging/Utils.py", line 22, in _logexc sys.__stderr__.write('Logging error: %s\n' % logger) IOError: [Errno 5] Input/output error Apr 13 22:02:28 2005 (3585) SHUNTING: 1113416328.560488+2f3b68b63b63f76dde7ced44494dc0 79153ff3d0 I found that the reason was that HTML archives were handled by an external archiver that sets its own file permissions for HTML archives (worked for earlier versions). Mailman archiving was limited to mbox only and was not affected by file permissions issue. After upgrading to 2.1.6b this problem manifested, but unfortunately not immediately, but after one week of normal operation, and silently (I was warned by a list moderator that approved mail is not sent out). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1182604&group_id=103 From noreply at sourceforge.net Sun Apr 17 12:43:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Apr 17 12:43:07 2005 Subject: [ mailman-Patches-1184595 ] setregid() to prevent group mismatch error with any MTA Message-ID: Patches item #1184595, was opened at 2005-04-17 12:43 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=1184595&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: SvR Marty (svrmarty) Assigned to: Nobody/Anonymous (nobody) Summary: setregid() to prevent group mismatch error with any MTA Initial Comment: mailman should run with its own gid apart from the MTA. The mail wrapper is setgid to mailmain to allow this: rwxr-sr-x 1 mailman mailman 7856 Mar 21 03:13 /usr/local/mailman/mail/mailman However, the gid check in the wrapper checks the real gid (the gid of the MTA) instead of the effective gid (mailman). One fix is to have the wrapper set its real gid to the effective gid as done by the attached mailman- 2.1.5-setregid.patch. This patch has been verified to work with postfix and should work with all other MTAs. see also http://bugs.gentoo.org/show_bug.cgi?id=45439 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1184595&group_id=103 From noreply at sourceforge.net Sun Apr 17 14:28:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Apr 17 14:29:02 2005 Subject: [ mailman-Patches-1184595 ] setregid() to prevent group mismatch error with any MTA Message-ID: Patches item #1184595, was opened at 2005-04-17 10:43 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1184595&group_id=103 Category: None Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: SvR Marty (svrmarty) >Assigned to: Tokio Kikuchi (tkikuchi) Summary: setregid() to prevent group mismatch error with any MTA Initial Comment: mailman should run with its own gid apart from the MTA. The mail wrapper is setgid to mailmain to allow this: rwxr-sr-x 1 mailman mailman 7856 Mar 21 03:13 /usr/local/mailman/mail/mailman However, the gid check in the wrapper checks the real gid (the gid of the MTA) instead of the effective gid (mailman). One fix is to have the wrapper set its real gid to the effective gid as done by the attached mailman- 2.1.5-setregid.patch. This patch has been verified to work with postfix and should work with all other MTAs. see also http://bugs.gentoo.org/show_bug.cgi?id=45439 ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2005-04-17 12:28 Message: Logged In: YES user_id=67709 Patch is not uploaded but the discussion above is invalid. The script wrapper checks gid to confirm that it is invoked by a proper user. Or, anyone on the system can maliciously invoke the script to forge a post or something like that. Remember that if you are to check the egid, you do not have to check anything at all because the wrapper is already set sgid flag. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1184595&group_id=103 From noreply at sourceforge.net Wed Apr 20 13:17:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Apr 20 13:17:57 2005 Subject: [ mailman-Bugs-1186599 ] Bug in Mailman version 2.1.5 Message-ID: Bugs item #1186599, was opened at 2005-04-20 11: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=1186599&group_id=103 Category: Web/CGI Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Michel Brouckaert (mathhacker) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in Mailman version 2.1.5 Initial Comment: Bug in Mailman version 2.1.5 We're sorry, we hit a bug! If you would like to help us identify the problem, please email a copy of this page to the webmaster for this site with a description of what happened. Thanks! Traceback: Traceback (most recent call last): File "/var/mailman/scripts/driver", line 87, in run_main main() File "/var/mailman/Mailman/Cgi/admin.py", line 72, in main mlist = MailList.MailList(listname, lock=0) File "/var/mailman/Mailman/MailList.py", line 128, in __init__ self.Load() File "/var/mailman/Mailman/MailList.py", line 593, in Load dict, e = self.__load(file) File "/var/mailman/Mailman/MailList.py", line 559, in __load fp = open(dbfile) IOError: [Errno 13] Permission denied: '/var/mailman/lists/news_joc/config.pck' Python information: Variable Value sys.version 2.2.3 (#1, Oct 15 2003, 23:33:35) [GCC 3.3.1 20030930 (Red Hat Linux 3.3.1-6)] sys.executable /usr/bin/python sys.prefix /usr sys.exec_prefix /usr sys.path /usr sys.platform linux2 Environment variables: Variable Value PATH_INFO /news_joc PYTHONPATH /var/mailman SCRIPT_FILENAME /var/mailman/cgi-bin/admin SERVER_SOFTWARE Apache/2.0.50 (Fedora) SERVER_ADMIN info@1-eurohost.com SCRIPT_NAME /mailman/admin SERVER_SIGNATURE Apache/2.0.50 (Fedora) Server at lists.jocdirksen.be Port 80 REQUEST_METHOD GET HTTP_HOST lists.jocdirksen.be HTTP_KEEP_ALIVE 300 SERVER_PROTOCOL HTTP/1.1 QUERY_STRING PATH_TRANSLATED /home/httpd/vhosts/default/htdocs/news_joc REQUEST_URI /mailman/admin/news_joc HTTP_ACCEPT text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 HTTP_ACCEPT_CHARSET ISO-8859-1,utf-8;q=0.7,*;q=0.7 HTTP_USER_AGENT Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 HTTP_CONNECTION keep-alive SERVER_NAME lists.jocdirksen.be REMOTE_PORT 6134 REMOTE_ADDR 193.191.9.22 HTTP_ACCEPT_LANGUAGE en-us,en;q=0.5 UNIQUE_ID Z8yi2cOMj2wAAEs3DA4AAABW SERVER_PORT 80 GATEWAY_INTERFACE CGI/1.1 HTTP_ACCEPT_ENCODING gzip,deflate SERVER_ADDR 195.140.143.108 DOCUMENT_ROOT /home/httpd/vhosts/default/htdocs ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1186599&group_id=103 From noreply at sourceforge.net Wed Apr 20 13:41:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Apr 20 13:41:53 2005 Subject: [ mailman-Bugs-1186599 ] Bug in Mailman version 2.1.5 Message-ID: Bugs item #1186599, was opened at 2005-04-20 07:17 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1186599&group_id=103 Category: Web/CGI Group: 2.1 (stable) >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Michel Brouckaert (mathhacker) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in Mailman version 2.1.5 Initial Comment: Bug in Mailman version 2.1.5 We're sorry, we hit a bug! If you would like to help us identify the problem, please email a copy of this page to the webmaster for this site with a description of what happened. Thanks! Traceback: Traceback (most recent call last): File "/var/mailman/scripts/driver", line 87, in run_main main() File "/var/mailman/Mailman/Cgi/admin.py", line 72, in main mlist = MailList.MailList(listname, lock=0) File "/var/mailman/Mailman/MailList.py", line 128, in __init__ self.Load() File "/var/mailman/Mailman/MailList.py", line 593, in Load dict, e = self.__load(file) File "/var/mailman/Mailman/MailList.py", line 559, in __load fp = open(dbfile) IOError: [Errno 13] Permission denied: '/var/mailman/lists/news_joc/config.pck' Python information: Variable Value sys.version 2.2.3 (#1, Oct 15 2003, 23:33:35) [GCC 3.3.1 20030930 (Red Hat Linux 3.3.1-6)] sys.executable /usr/bin/python sys.prefix /usr sys.exec_prefix /usr sys.path /usr sys.platform linux2 Environment variables: Variable Value PATH_INFO /news_joc PYTHONPATH /var/mailman SCRIPT_FILENAME /var/mailman/cgi-bin/admin SERVER_SOFTWARE Apache/2.0.50 (Fedora) SERVER_ADMIN info@1-eurohost.com SCRIPT_NAME /mailman/admin SERVER_SIGNATURE Apache/2.0.50 (Fedora) Server at lists.jocdirksen.be Port 80 REQUEST_METHOD GET HTTP_HOST lists.jocdirksen.be HTTP_KEEP_ALIVE 300 SERVER_PROTOCOL HTTP/1.1 QUERY_STRING PATH_TRANSLATED /home/httpd/vhosts/default/htdocs/news_joc REQUEST_URI /mailman/admin/news_joc HTTP_ACCEPT text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 HTTP_ACCEPT_CHARSET ISO-8859-1,utf-8;q=0.7,*;q=0.7 HTTP_USER_AGENT Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 HTTP_CONNECTION keep-alive SERVER_NAME lists.jocdirksen.be REMOTE_PORT 6134 REMOTE_ADDR 193.191.9.22 HTTP_ACCEPT_LANGUAGE en-us,en;q=0.5 UNIQUE_ID Z8yi2cOMj2wAAEs3DA4AAABW SERVER_PORT 80 GATEWAY_INTERFACE CGI/1.1 HTTP_ACCEPT_ENCODING gzip,deflate SERVER_ADDR 195.140.143.108 DOCUMENT_ROOT /home/httpd/vhosts/default/htdocs ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-04-20 07:41 Message: Logged In: YES user_id=12800 Run bin/check_perms ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1186599&group_id=103 From noreply at sourceforge.net Wed Apr 20 18:59:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Apr 20 18:59:09 2005 Subject: [ mailman-Bugs-1186819 ] Bug with non-ascii characters during subscribe Message-ID: Bugs item #1186819, was opened at 2005-04-20 09:59 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=1186819&group_id=103 Category: Web/CGI Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Aaron (appleaaron) Assigned to: Nobody/Anonymous (nobody) Summary: Bug with non-ascii characters during subscribe Initial Comment: We have users from all over the world that access our mailing lists. Recently we have found an error with users that include their full name if it includes non-ascii characters such as ? ? and ?. Here is the traceback: Traceback (most recent call last): File "/Volumes/ngs/app/listsp/mailman/scripts/driver", line 87, in run_main main() File "/Volumes/ngs/app/listsp/mailman/Mailman/Cgi/ subscribe.py", line 96, in main process_form(mlist, doc, cgidata, language) File "/Volumes/ngs/app/listsp/mailman/Mailman/Cgi/ subscribe.py", line 176, in process_form mlist.AddMember(userdesc, remote) File "/Volumes/ngs/app/listsp/mailman/Mailman/MailList.py", line 887, in AddMember self.internal_name(), who, by) File "/Volumes/ngs/app/listsp/mailman/Mailman/Logging/ Syslog.py", line 40, in write self.write_ex(kind, msg, args, kws) File "/Volumes/ngs/app/listsp/mailman/Mailman/Logging/ Syslog.py", line 58, in write_ex logf.write(msg + '\n') File "/Volumes/ngs/app/listsp/mailman/Mailman/Logging/ StampedLogger.py", line 73, in write Logger.write(self, "%s %s" % (prefix, msg)) File "/Volumes/ngs/app/listsp/mailman/Mailman/Logging/ Logger.py", line 91, in write f.write(msg) UnicodeEncodeError: 'ascii' codec can't encode character '\ue6' in position 51: ordinal not in range(128) Python information: Variable Value sys.version 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] sys.executable /usr/bin/python sys.prefix /System/Library/Frameworks/Python.framework/ Versions/2.3 sys.exec_prefix /System/Library/Frameworks/ Python.framework/Versions/2.3 sys.path /System/Library/Frameworks/Python.framework/ Versions/2.3 sys.platform darwin ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1186819&group_id=103 From noreply at sourceforge.net Thu Apr 21 16:58:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 21 16:58:26 2005 Subject: [ mailman-Bugs-1187438 ] Bug if bounced message canceled after being discarded Message-ID: Bugs item #1187438, was opened at 2005-04-21 14:58 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=1187438&group_id=103 Category: bounce detection Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: James Newton (openspark) Assigned to: Nobody/Anonymous (nobody) Summary: Bug if bounced message canceled after being discarded Initial Comment: Steps to Reproduce: 1. Create a mailing list with Mailman 2.1.4, and set yourself up as administrator. 2. Send a message to a list which is bigger than the maximum message size. This will make the message bounce. 2. As sender, you will receive a message such as: Your mail to 'mailingList' with the subject Oversized Is being held until the list moderator can review it for approval. The reason it is being held: Message body is too big: 14292 bytes with a limit of 10 KB Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: http://yadayada... 3. Click on the link, but do not cancel the message in the browser window which opens. 4. As mailing list administrator, you will receive a message asking you to approve the Oversized message. Visit the link provided and discard or reject the message. 5. As sender, now try to cancel the message which has now been discarded. Result: The error output cited below will be displayed in your browser window. Bug in Mailman version 2.1.4 We're sorry, we hit a bug! If you would like to help us identify the problem, please email a copy of this page to the webmaster for this site with a description of what happened. Thanks! Traceback: Traceback (most recent call last): File "/home/mailman/scripts/driver", line 87, in run_main main() File "/home/mailman/Mailman/Cgi/confirm.py", line 146, in main heldmsg_confirm(mlist, doc, cookie) File "/home/mailman/Mailman/Cgi/confirm.py", line 595, in heldmsg_confirm ign, sender, msgsubject, ign, ign, ign = mlist.GetRecord(id) File "/home/mailman/Mailman/ListAdmin.py", line 170, in GetRecord type, data = self.__db[id] KeyError: 2 Python information: Variable Value sys.version 2.3.3 (#1, Apr 17 2005, 22:14:25) [GCC 2.95.3 20010315 (release)] sys.executable /usr/local/bin/python sys.prefix /usr/local sys.exec_prefix /usr/local sys.path /usr/local sys.platform linux2 Environment variables: Variable Value HTTP_REFERER http://mailman.openspark.com/mailman/confirm/ directorwiki-l/77a461e3e6bb858614b1af732f81ab8ee9ae374b SERVER_SOFTWARE Apache/1.3.29 Sun Cobalt (Unix) mod_jk mod_ssl/2.8.16 OpenSSL/0.9.6m PHP/4.0.6 FrontPage/ 5.0.2.2510 mod_perl/1.26 SCRIPT_NAME /mailman/confirm SERVER_SIGNATURE REQUEST_METHOD POST PATH_INFO /directorwiki-l SERVER_PROTOCOL HTTP/1.1 QUERY_STRING CONTENT_LENGTH 69 HTTP_USER_AGENT Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-gb) AppleWebKit/312.1 (KHTML, like Gecko) Safari/312 HTTP_CONNECTION close HTTP_COOKIE directorwiki- l+admin=28020000006920b76742732800000064333737393134 666635643736613163386163336564643566353261363532343 535366131386462 SERVER_NAME mailman.openspark.com REMOTE_ADDR 217.41.35.10 PATH_TRANSLATED /home/.sites/143/site2/web/directorwiki-l SERVER_PORT 80 SERVER_ADDR 212.20.236.194 DOCUMENT_ROOT /home/.sites/143/site2/web PYTHONPATH /home/mailman SCRIPT_FILENAME /home/mailman/cgi-bin/confirm SERVER_ADMIN admin SCRIPT_URI http://mailman.openspark.com/mailman/confirm/ directorwiki-l HTTP_HOST mailman.openspark.com SCRIPT_URL /mailman/confirm/directorwiki-l REQUEST_URI /mailman/confirm/directorwiki-l HTTP_ACCEPT */* GATEWAY_INTERFACE CGI/1.1 REMOTE_PORT 52531 HTTP_ACCEPT_LANGUAGE en-gb CONTENT_TYPE application/x-www-form-urlencoded REMOTE_HOST host217-41-35-10.in-addr.btopenworld.com HTTP_ACCEPT_ENCODING gzip, deflate UNIQUE_ID Qme6fdQU7MIAAFFv60M ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1187438&group_id=103 From noreply at sourceforge.net Fri Apr 22 16:58:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 22 16:58:41 2005 Subject: [ mailman-Bugs-1188133 ] CGI group id not properly tested Message-ID: Bugs item #1188133, was opened at 2005-04-22 15:58 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=1188133&group_id=103 Category: Web/CGI Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Graham Klyne (grahamk) Assigned to: Nobody/Anonymous (nobody) Summary: CGI group id not properly tested Initial Comment: [I tried to send this to mailman-developers, but my message was discarded] I've just downloaded and installed the latest mailman 2.1.6rc1 and encountered a CGI permissions problem (running with Apache 2.0 on Scientific Linux 3.04), for which a patch is described in: http://minaret.biz/tips/mailman.html (briefly, replace getgid with getegid in common.c) Applying this patch resolves the problem I was experiencing. Is there any reason this isn't applied in the mailman distribution? #g ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1188133&group_id=103 From noreply at sourceforge.net Fri Apr 22 20:26:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 22 20:27:09 2005 Subject: [ mailman-Patches-1188237 ] build correct links, if webserver is forwarded Message-ID: Patches item #1188237, was opened at 2005-04-22 18:26 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=1188237&group_id=103 Category: Web UI Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: pille (zaarkov) Assigned to: Nobody/Anonymous (nobody) Summary: build correct links, if webserver is forwarded Initial Comment: in my setup there are two servers. one ist the mail-server, the other one the webserver. the mail-server uses an own apache on itself to display the web UI, but it is only accessible throu the webserver that forwards connections to it (using mod_proxy's ProxyPass-directive). the links that are generated on sites like http://.../listinfo that don't know anything about virtual hosts refer to the HTTP_HOST environment variable, which represents the mail-server and not the webserver. therefore this patch tries to evaluate the HTTP_X_FORWARDED_HOST and use it if it exists. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1188237&group_id=103 From noreply at sourceforge.net Fri Apr 22 20:29:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 22 20:29:35 2005 Subject: [ mailman-Patches-1188237 ] build correct links, if webserver is forwarded Message-ID: Patches item #1188237, was opened at 2005-04-22 18:26 Message generated for change (Settings changed) made by zaarkov You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1188237&group_id=103 Category: Web UI Group: Mailman 2.1 >Status: Deleted Resolution: None Priority: 5 Submitted By: pille (zaarkov) Assigned to: Nobody/Anonymous (nobody) Summary: build correct links, if webserver is forwarded Initial Comment: in my setup there are two servers. one ist the mail-server, the other one the webserver. the mail-server uses an own apache on itself to display the web UI, but it is only accessible throu the webserver that forwards connections to it (using mod_proxy's ProxyPass-directive). the links that are generated on sites like http://.../listinfo that don't know anything about virtual hosts refer to the HTTP_HOST environment variable, which represents the mail-server and not the webserver. therefore this patch tries to evaluate the HTTP_X_FORWARDED_HOST and use it if it exists. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1188237&group_id=103 From noreply at sourceforge.net Fri Apr 22 20:32:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 22 20:32:28 2005 Subject: [ mailman-Patches-1188240 ] correct links, if webserver is forwarded Message-ID: Patches item #1188240, was opened at 2005-04-22 18:32 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=1188240&group_id=103 Category: Web UI Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: pille (zaarkov) Assigned to: Nobody/Anonymous (nobody) Summary: correct links, if webserver is forwarded Initial Comment: in my setup there are two servers. one ist the mail-server, the other one the webserver. the mail-server uses an own apache on itself to display the web UI, but it is only accessible throu the webserver that forwards connections to it (using mod_proxy's ProxyPass-directive). the links that are generated on sites like http://.../listinfo that don't know anything about virtual hosts refer to the HTTP_HOST environment variable, which represents the mail-server and not the webserver. therefore this patch tries to evaluate the HTTP_X_FORWARDED_HOST and use it if it exists. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1188240&group_id=103 From noreply at sourceforge.net Sun Apr 24 01:49:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Apr 24 01:49:23 2005 Subject: [ mailman-Bugs-1188133 ] CGI group id not properly tested Message-ID: Bugs item #1188133, was opened at 2005-04-22 14:58 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1188133&group_id=103 Category: Web/CGI Group: 2.1 (stable) >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Graham Klyne (grahamk) Assigned to: Nobody/Anonymous (nobody) Summary: CGI group id not properly tested Initial Comment: [I tried to send this to mailman-developers, but my message was discarded] I've just downloaded and installed the latest mailman 2.1.6rc1 and encountered a CGI permissions problem (running with Apache 2.0 on Scientific Linux 3.04), for which a patch is described in: http://minaret.biz/tips/mailman.html (briefly, replace getgid with getegid in common.c) Applying this patch resolves the problem I was experiencing. Is there any reason this isn't applied in the mailman distribution? #g ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2005-04-23 23:49 Message: Logged In: YES user_id=67709 The 'patch' and discussion in the page was invalid and updated by the author. In general, you should not patch the wrapper program. You can also read a good article on the mailman security mechanism by John Dennis here: http://mail.python.org/pipermail/mailman-developers/2005-April/017996.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1188133&group_id=103 From noreply at sourceforge.net Sun Apr 24 14:21:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Apr 24 14:21:50 2005 Subject: [ mailman-Patches-1160353 ] XHTML Compliant Web UI Message-ID: Patches item #1160353, was opened at 2005-03-09 21:40 Message generated for change (Comment added) made by carbonnb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1160353&group_id=103 Category: Web UI Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Bryan Carbonnell (carbonnb) Assigned to: Nobody/Anonymous (nobody) Summary: XHTML Compliant Web UI Initial Comment: This is a patch that will make the Web UI XHTML 1.0 Strict compliant. Currently I only have the listinfo pages XHTML compliant, but as time goes by I'm going to make the entire UI compliant. This also allows some small amount of CSS formatting as well. Hopefully this will be of use to somebody. ---------------------------------------------------------------------- >Comment By: Bryan Carbonnell (carbonnb) Date: 2005-04-24 08:21 Message: Logged In: YES user_id=449953 The patch for MM 2.1.6-RC1 and above makes the entire WEB UI XHTML1 compliant, except for the archive pages, since they are HTM 3.2 compliant already. To use this patch, unzip it, switch to your source directory and issue the command patch -p1 Patches item #1189243, was opened at 2005-04-24 21:16 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=1189243&group_id=103 Category: None Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Jon Parise (jparise) Assigned to: Nobody/Anonymous (nobody) Summary: Unhandle exception in Message.get_content_charset() Initial Comment: Message.get_content_charset() can encounter an unhandled exception "(TypeError: unicode() argument 2 must be string, not None") when charset is None. This can can only occur when the call to email.Message.Message.get_content_charset(self, failobj) itself returns None, but, not being acquainted with the email package, I don't understand the circumstances which can cause this situation. Regardless, when charset is None, the call to unicode() will throw the TypeError exception. The attached patch recognizes this as a valid failure case such that failobj will be returned. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1189243&group_id=103 From noreply at sourceforge.net Mon Apr 25 06:50:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Apr 25 06:50:11 2005 Subject: [ mailman-Patches-1189243 ] Unhandle exception in Message.get_content_charset() Message-ID: Patches item #1189243, was opened at 2005-04-25 04:16 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1189243&group_id=103 Category: None Group: Mailman 2.1 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Jon Parise (jparise) Assigned to: Nobody/Anonymous (nobody) Summary: Unhandle exception in Message.get_content_charset() Initial Comment: Message.get_content_charset() can encounter an unhandled exception "(TypeError: unicode() argument 2 must be string, not None") when charset is None. This can can only occur when the call to email.Message.Message.get_content_charset(self, failobj) itself returns None, but, not being acquainted with the email package, I don't understand the circumstances which can cause this situation. Regardless, when charset is None, the call to unicode() will throw the TypeError exception. The attached patch recognizes this as a valid failure case such that failobj will be returned. ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2005-04-25 04:50 Message: Logged In: YES user_id=67709 Thank you! I just fixed in CVS. (I'd rather make it bare except ...) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1189243&group_id=103 From noreply at sourceforge.net Mon Apr 25 16:32:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Apr 25 16:32:36 2005 Subject: [ mailman-Patches-1189243 ] Unhandle exception in Message.get_content_charset() Message-ID: Patches item #1189243, was opened at 2005-04-25 00:16 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1189243&group_id=103 Category: None Group: Mailman 2.1 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Jon Parise (jparise) Assigned to: Nobody/Anonymous (nobody) Summary: Unhandle exception in Message.get_content_charset() Initial Comment: Message.get_content_charset() can encounter an unhandled exception "(TypeError: unicode() argument 2 must be string, not None") when charset is None. This can can only occur when the call to email.Message.Message.get_content_charset(self, failobj) itself returns None, but, not being acquainted with the email package, I don't understand the circumstances which can cause this situation. Regardless, when charset is None, the call to unicode() will throw the TypeError exception. The attached patch recognizes this as a valid failure case such that failobj will be returned. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-04-25 10:32 Message: Logged In: YES user_id=12800 Is there any possibility that you have a sample message that exhibits this problem? I would /really/ like to add a test case for this to the email package, which is where the patch really belongs. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2005-04-25 00:50 Message: Logged In: YES user_id=67709 Thank you! I just fixed in CVS. (I'd rather make it bare except ...) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1189243&group_id=103 From noreply at sourceforge.net Mon Apr 25 17:46:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Apr 25 17:46:28 2005 Subject: [ mailman-Patches-1189243 ] Unhandle exception in Message.get_content_charset() Message-ID: Patches item #1189243, was opened at 2005-04-24 21:16 Message generated for change (Comment added) made by jparise You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1189243&group_id=103 Category: None Group: Mailman 2.1 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Jon Parise (jparise) Assigned to: Nobody/Anonymous (nobody) Summary: Unhandle exception in Message.get_content_charset() Initial Comment: Message.get_content_charset() can encounter an unhandled exception "(TypeError: unicode() argument 2 must be string, not None") when charset is None. This can can only occur when the call to email.Message.Message.get_content_charset(self, failobj) itself returns None, but, not being acquainted with the email package, I don't understand the circumstances which can cause this situation. Regardless, when charset is None, the call to unicode() will throw the TypeError exception. The attached patch recognizes this as a valid failure case such that failobj will be returned. ---------------------------------------------------------------------- >Comment By: Jon Parise (jparise) Date: 2005-04-25 08:46 Message: Logged In: YES user_id=485579 Sorry, I don't. Those messages were unshunted as a result of my fix. I could try to instrument a collection mechanism by trapping that exception and storing a copy of the offensive message, however. Would that still be useful? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-04-25 07:32 Message: Logged In: YES user_id=12800 Is there any possibility that you have a sample message that exhibits this problem? I would /really/ like to add a test case for this to the email package, which is where the patch really belongs. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2005-04-24 21:50 Message: Logged In: YES user_id=67709 Thank you! I just fixed in CVS. (I'd rather make it bare except ...) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1189243&group_id=103 From noreply at sourceforge.net Mon Apr 25 19:02:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Apr 25 19:02:11 2005 Subject: [ mailman-Patches-1189243 ] Unhandle exception in Message.get_content_charset() Message-ID: Patches item #1189243, was opened at 2005-04-25 00:16 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1189243&group_id=103 Category: None Group: Mailman 2.1 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Jon Parise (jparise) Assigned to: Nobody/Anonymous (nobody) Summary: Unhandle exception in Message.get_content_charset() Initial Comment: Message.get_content_charset() can encounter an unhandled exception "(TypeError: unicode() argument 2 must be string, not None") when charset is None. This can can only occur when the call to email.Message.Message.get_content_charset(self, failobj) itself returns None, but, not being acquainted with the email package, I don't understand the circumstances which can cause this situation. Regardless, when charset is None, the call to unicode() will throw the TypeError exception. The attached patch recognizes this as a valid failure case such that failobj will be returned. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-04-25 13:02 Message: Logged In: YES user_id=12800 If it's not too much trouble. I'd love to have a test case in the email package for the TypeError exception. If you can't, no worries. ---------------------------------------------------------------------- Comment By: Jon Parise (jparise) Date: 2005-04-25 11:46 Message: Logged In: YES user_id=485579 Sorry, I don't. Those messages were unshunted as a result of my fix. I could try to instrument a collection mechanism by trapping that exception and storing a copy of the offensive message, however. Would that still be useful? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-04-25 10:32 Message: Logged In: YES user_id=12800 Is there any possibility that you have a sample message that exhibits this problem? I would /really/ like to add a test case for this to the email package, which is where the patch really belongs. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2005-04-25 00:50 Message: Logged In: YES user_id=67709 Thank you! I just fixed in CVS. (I'd rather make it bare except ...) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1189243&group_id=103 From noreply at sourceforge.net Tue Apr 26 09:30:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Apr 26 09:30:46 2005 Subject: [ mailman-Bugs-1168999 ] OutgoingRunner gets in expensive recursive loop Message-ID: Bugs item #1168999, was opened at 2005-03-23 18:30 Message generated for change (Comment added) made by kjd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1168999&group_id=103 Category: mail delivery Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Kim Davies (kjd) Assigned to: Nobody/Anonymous (nobody) Summary: OutgoingRunner gets in expensive recursive loop Initial Comment: I have had a problem spring up the past few weeks where the OutgoingRunner gets in a loop which effectively brings down the machine by spiking the CPU to 99%. Running "strace" on the process I see it constantly deleting and reimplanting the same queue file in qfiles/out/ over and over, many times per second. The initial problem inurred with a 2.1.2 install, but installing 2.1.6b4 shows the same. Unfortunately the problem is somewhat ephemeral when trying to diagnose it - if I manage to kill the OutgoingRunner between a read and write, the queue file gets lost the the problem disappears for a while. I don't know if it is useful, but attached is the strace output of a complete read/write cycle. I haven't had the opportunity to further debug it (by stepping through the python) as currently I am not in this state. I am not sure how long it will be until it is triggered again, but it has happened about 4 times in the past two weeks. It has never occured before this over 3 years. I consider this issue fairly problematic - the machine becomes unusable when it reaches this state due to CPU exhaustion. Any tips of helping isolate the problem are welcome. I have modified mailmanctl to run all queuerunners with a verbose flag, so next time maybe there will be useful information logged. ---------------------------------------------------------------------- >Comment By: Kim Davies (kjd) Date: 2005-04-26 15:30 Message: Logged In: YES user_id=168657 I have managed to captures a number of qfiles that are causing this phenomenon (which is recurring more often the past few weeks). They have the following properties: - They are all "Post by non-member to a members-only list " responses to spam that has gone to a moderated list. - They come from non-existant domains. Here is a sample dump of one of the .db files from the queue that is looping: $ /usr/local/mailman/bin/dumpdb 1114500259.9807329+a1518ee474d8edb0e83615df60270885165d5f83.db { 'deliver_after': 1114503867.0899999, 'deliver_until': 1114932267.0899999, 'lang': 'en', 'last_recip_count': 1, 'listname': 'ga', 'nodecorate': 1, 'original_sender': 'ga-bounces@lists.centr.org', 'personalize': 1, 'pipeline': [], 'received_time': 1114500259.9807329, 'recips': ['sidfks@sklfislxkd.com'], 'reduced_list_headers': 1, 'verp': 1, 'version': 3} ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1168999&group_id=103 From noreply at sourceforge.net Tue Apr 26 18:33:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Apr 26 18:33:10 2005 Subject: [ mailman-Bugs-1190404 ] Editing HTML/Text file option sets bad file permissions Message-ID: Bugs item #1190404, was opened at 2005-04-26 08:33 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=1190404&group_id=103 Category: Web/CGI Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Chris Candreva (ccandreva) Assigned to: Nobody/Anonymous (nobody) Summary: Editing HTML/Text file option sets bad file permissions Initial Comment: System is Solaris 8, gcc 3.4.0, python 2.4, Apache 1.3.33 On mailman 2.1.6rc1 and rc2, when I use the "Edit the HTML pages and text files" option, the directories and files created are mode 600 , owned by nobody.mailman . After this, subscriptions fail with a permissions error. Since the listname/en directory is unreadable, there is a permissions error for the e-mail script that tries to send a confirmation message back to the user. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1190404&group_id=103 From noreply at sourceforge.net Fri Apr 29 02:02:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 29 02:52:23 2005 Subject: [ mailman-Patches-1189243 ] Unhandle exception in Message.get_content_charset() Message-ID: Patches item #1189243, was opened at 2005-04-25 04:16 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1189243&group_id=103 Category: None Group: Mailman 2.1 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Jon Parise (jparise) Assigned to: Nobody/Anonymous (nobody) Summary: Unhandle exception in Message.get_content_charset() Initial Comment: Message.get_content_charset() can encounter an unhandled exception "(TypeError: unicode() argument 2 must be string, not None") when charset is None. This can can only occur when the call to email.Message.Message.get_content_charset(self, failobj) itself returns None, but, not being acquainted with the email package, I don't understand the circumstances which can cause this situation. Regardless, when charset is None, the call to unicode() will throw the TypeError exception. The attached patch recognizes this as a valid failure case such that failobj will be returned. ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2005-04-29 00:02 Message: Logged In: YES user_id=67709 Barry, TypeError is already avoided in email package by this statement: pcharset = charset[0] or 'us-ascii' I want to keep the latter try/except in Mailman/Message.py to assure the charset is known to mailman so that it can serve as security precaution to future mailman code changes, even after the email package is updated to 2.5.6. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-04-25 17:02 Message: Logged In: YES user_id=12800 If it's not too much trouble. I'd love to have a test case in the email package for the TypeError exception. If you can't, no worries. ---------------------------------------------------------------------- Comment By: Jon Parise (jparise) Date: 2005-04-25 15:46 Message: Logged In: YES user_id=485579 Sorry, I don't. Those messages were unshunted as a result of my fix. I could try to instrument a collection mechanism by trapping that exception and storing a copy of the offensive message, however. Would that still be useful? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-04-25 14:32 Message: Logged In: YES user_id=12800 Is there any possibility that you have a sample message that exhibits this problem? I would /really/ like to add a test case for this to the email package, which is where the patch really belongs. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2005-04-25 04:50 Message: Logged In: YES user_id=67709 Thank you! I just fixed in CVS. (I'd rather make it bare except ...) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1189243&group_id=103 From noreply at sourceforge.net Fri Apr 29 07:33:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 29 07:33:37 2005 Subject: [ mailman-Feature Requests-1192175 ] provide filtered log access via web Message-ID: Feature Requests item #1192175, was opened at 2005-04-29 14:33 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=1192175&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stephen J. Turnbull (yaseppochi) Assigned to: Nobody/Anonymous (nobody) Summary: provide filtered log access via web Initial Comment: ... and queuefile summary data, too! Suggested interface: new toplevel menu item for a TROUBLESHOOTING page. The page would contain query boxes for (a) logfiles and (b) queue summaries. The LOG QUERY would have a checkbox (not radio button) interface listing the available logs. Filters would include (a) timestamp range (b) general Python regexp at least. The QUEUE QUERY would have a checkbox listing the queues. Rather than have filters (at least at first) the QUEUE QUERY might just provide age distributions, say < 1 hour, < 5 hours, < 1 day, > 1 day for each requested queue. I'm of two minds as to whether an interface to access data about individual messages would be useful. The thing is, generally to do anything useful about the queues you need shell and privileged access to the host. It might be useful to have a MiniFAQ on this page that just points to the MFAQs on the FAQWizard. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1192175&group_id=103 From noreply at sourceforge.net Fri Apr 29 15:30:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 29 15:30:18 2005 Subject: [ mailman-Patches-1189243 ] Unhandle exception in Message.get_content_charset() Message-ID: Patches item #1189243, was opened at 2005-04-25 00:16 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1189243&group_id=103 Category: None Group: Mailman 2.1 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Jon Parise (jparise) Assigned to: Nobody/Anonymous (nobody) Summary: Unhandle exception in Message.get_content_charset() Initial Comment: Message.get_content_charset() can encounter an unhandled exception "(TypeError: unicode() argument 2 must be string, not None") when charset is None. This can can only occur when the call to email.Message.Message.get_content_charset(self, failobj) itself returns None, but, not being acquainted with the email package, I don't understand the circumstances which can cause this situation. Regardless, when charset is None, the call to unicode() will throw the TypeError exception. The attached patch recognizes this as a valid failure case such that failobj will be returned. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-04-29 09:30 Message: Logged In: YES user_id=12800 Tokio, I don't like having duplicate code, so I think it's best to fix the problem in one place and not keep the workaround in Mailman's copy. I've installed email 2.5.6 now and will release Mailman 2.1.6rc3 in a little while. At my own site, all the shunted messages that were broken because of this problem have now been fixed and properly unshunted. I will be updating python.org hopefully this weekend. Let's give rc3 a couple of weeks to shake out. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2005-04-28 20:02 Message: Logged In: YES user_id=67709 Barry, TypeError is already avoided in email package by this statement: pcharset = charset[0] or 'us-ascii' I want to keep the latter try/except in Mailman/Message.py to assure the charset is known to mailman so that it can serve as security precaution to future mailman code changes, even after the email package is updated to 2.5.6. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-04-25 13:02 Message: Logged In: YES user_id=12800 If it's not too much trouble. I'd love to have a test case in the email package for the TypeError exception. If you can't, no worries. ---------------------------------------------------------------------- Comment By: Jon Parise (jparise) Date: 2005-04-25 11:46 Message: Logged In: YES user_id=485579 Sorry, I don't. Those messages were unshunted as a result of my fix. I could try to instrument a collection mechanism by trapping that exception and storing a copy of the offensive message, however. Would that still be useful? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-04-25 10:32 Message: Logged In: YES user_id=12800 Is there any possibility that you have a sample message that exhibits this problem? I would /really/ like to add a test case for this to the email package, which is where the patch really belongs. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2005-04-25 00:50 Message: Logged In: YES user_id=67709 Thank you! I just fixed in CVS. (I'd rather make it bare except ...) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1189243&group_id=103 From noreply at sourceforge.net Fri Apr 29 23:27:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 29 23:27:39 2005 Subject: [ mailman-Bugs-871050 ] Uncought runner exception: Empty module name Message-ID: Bugs item #871050, was opened at 2004-01-05 09:03 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=871050&group_id=103 Category: mail delivery Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Fernando Barajas (fbarajas) Assigned to: Nobody/Anonymous (nobody) Summary: Uncought runner exception: Empty module name Initial Comment: Hi! I run several lists on mailman, and all of the lists are working OK, but suddently one of them (named fc_general) stopped working, and I get the following in logs/error every time I try to post to the fc_general list: Jan 05 11:03:48 2004 (8451) Uncaught runner exception: Empty module name Jan 05 11:03:48 2004 (8451) 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 155, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/home/mailman/Mailman/Queue/IncomingRunner.py", line 130, in _dispose more = self._dopipeline(mlist, msg, msgdata, pipeline) File "/home/mailman/Mailman/Queue/IncomingRunner.py", line 153, in _dopipeline sys.modules[modname].process(mlist, msg, msgdata) File "/home/mailman/Mailman/Handlers/ToDigest.py", line 89, in process send_digests(mlist, mboxfp) File "/home/mailman/Mailman/Handlers/ToDigest.py", line 130, in send_digests send_i18n_digests(mlist, mboxfp) File "/home/mailman/Mailman/Handlers/ToDigest.py", line 303, in send_i18n_dige sts msg = scrubber(mlist, msg) File "/home/mailman/Mailman/Handlers/Scrubber.py", line 308, in process t = t.encode(charset, 'replace') File "/var/tmp/python2-2.2.3- root/usr/lib/python2.2/encodings/__init__.py", li ne 51, in search_function ValueError: Empty module name Jan 05 11:03:48 2004 (8451) SHUNTING: 1073322225.130398+2e61b88872c9af343bce1927 de7443b7500f2622 The rest of my lists work correctly. I was using 2.1.2, but today I upgraded to 2.1.4 and it's still failing. What can I do? Thanks! ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-04-29 14:27 Message: Logged In: NO I also experienced a similar problem, but was able to fix it. In my case, it appears to have been related to a python version number: the qrunner program was running against one python version, but was actually using features defined in a later version. In my case, I had Python 2.2 installed with the operating system, but had subsequently installed version 2.4.1. I fixed the problem by re-installing mailman with an explicit reference to the later python version (./configure --with-python=...), and then rebooting the system. After that, it was fine. (The reboot was to get qrunner running against the later python version: it seemed the old version was running whatever I might do with chkconfig or /etc/init.d/mailman. Rebooting was maybe a sledgehammer to crack a nut.) ---------------------------------------------------------------------- Comment By: James Hammett (james968) Date: 2005-03-14 07:32 Message: Logged In: YES user_id=310971 Running version 2.1.2. I get : Mar 14 09:30:49 2005 (28471) Traceback (most recent call last): File "/usr/share/mailman/Mailman/Queue/Runner.py", line 105, in _oneloop self._onefile(msg, msgdata) File "/usr/share/mailman/Mailman/Queue/Runner.py", line 155, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/usr/share/mailman/Mailman/Queue/IncomingRunner.py", line 130, in _dispose more = self._dopipeline(mlist, msg, msgdata, pipeline) File "/usr/share/mailman/Mailman/Queue/IncomingRunner.py", line 153, in _dopipeline sys.modules[modname].process(mlist, msg, msgdata) File "/usr/share/mailman/Mailman/Handlers/ToDigest.py", line 89, in process send_digests(mlist, mboxfp) File "/usr/share/mailman/Mailman/Handlers/ToDigest.py", line 130, in send_digests send_i18n_digests(mlist, mboxfp) File "/usr/share/mailman/Mailman/Handlers/ToDigest.py", line 303, in send_i18n_digests msg = scrubber(mlist, msg) File "/usr/share/mailman/Mailman/Handlers/Scrubber.py", line 308, in process t = t.encode(charset, 'replace') File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/encodings/__init__.py", line 84, in search_function globals(), locals(), _import_tail) ValueError: Empty module name ---- I've attempted removing the digest files and cleaning them up, but this hasn't helped. ---------------------------------------------------------------------- Comment By: Charles Hall (hallcp) Date: 2004-08-02 10:34 Message: Logged In: YES user_id=747417 In my case the quick fix was to delete the existing "digest.mbox" file. (Look in ~mailman/lists/your_list/digest.mbox) I guess a bogus email snuck in there that breaks Python's character handling. Your digest subscribers will be unhappy but at least your list is up again. ---------------------------------------------------------------------- Comment By: Dan Langille (junkmale) Date: 2004-02-05 08:10 Message: Logged In: YES user_id=27858 I am having a simlar problem. Mail comes in, but never goes out to the list. Everthing is shunted. I found this "patch" http://www.mail-archive.com/mailman-developers@python. org/msg06317.html and applied it. Then I ran unshunt. That's when this appeared in mailman/logs/error Feb 05 07:57:07 2004 (27060) Dequeuing message destined for missing list: planners Feb 05 07:57:07 2004 (27060) Uncaught runner exception: Empty module name Feb 05 07:57:07 2004 (27060) Traceback (most recent call last): File "/usr/local/mailman/Mailman/Queue/Runner.py", line 110, in _oneloop self._onefile(msg, msgdata) File "/usr/local/mailman/Mailman/Queue/Runner.py", line 160, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/usr/local/mailman/Mailman/Queue/IncomingRunner.py", line 130, in _dispose more = self._dopipeline(mlist, msg, msgdata, pipeline) File "/usr/local/mailman/Mailman/Queue/IncomingRunner.py", line 153, in _dopipeline sys.modules[modname].process(mlist, msg, msgdata) File "/usr/local/mailman/Mailman/Handlers/ToDigest.py", line 90, in process send_digests(mlist, mboxfp) File "/usr/local/mailman/Mailman/Handlers/ToDigest.py", line 131, in send_digests send_i18n_digests(mlist, mboxfp) File "/usr/local/mailman/Mailman/Handlers/ToDigest.py", line 304, in send_i18n_digests msg = scrubber(mlist, msg) File "/usr/local/mailman/Mailman/Handlers/Scrubber.py", line 311, in process t = t.encode(charset, 'replace') File "/usr/local/lib/python2.3/encodings/__init__.py", line 84, in search_function globals(), locals(), _import_tail) ValueError: Empty module name ---------------------------------------------------------------------- Comment By: Jochen Witte (zebaoth) Date: 2004-01-27 03:09 Message: Logged In: YES user_id=565663 I use 2.1.3 and have the same problem. Any solution in sight? ---------------------------------------------------------------------- Comment By: Marcel Meyer (meyerm) Date: 2004-01-14 02:56 Message: Logged In: YES user_id=66911 Hi, was this somehow resolved?? I just found to have the same problems! What can I do that the messages (the shunt directory is now 1,5 MB big! [not the contents of the dir, but the dir inode itself...!!] ) are written into the archives without loosing anything? unshunt just puts them back into the shunt directory. Is there some patch - anything? Thanks a lot Marcel ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=871050&group_id=103 From noreply at sourceforge.net Fri Apr 29 23:59:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 29 23:59:58 2005 Subject: [ mailman-Patches-1192757 ] Mail Archive mirroring Message-ID: Patches item #1192757, was opened at 2005-04-29 14:59 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=1192757&group_id=103 Category: list administration Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Jeff Marshall (marshman) Assigned to: Nobody/Anonymous (nobody) Summary: Mail Archive mirroring Initial Comment: New third party archiving option that uses The Mail Archive. The implementation subscribes or unsubscribes the archive@mail-archive.com address from the subscriber list. This gives list admins an easy setup option to provide mirroring and searchable public archives. Patch is based on branch Release_2_1-maint version 2.1.6rc3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1192757&group_id=103 From noreply at sourceforge.net Sat Apr 30 00:24:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Apr 30 00:24:44 2005 Subject: [ mailman-Patches-1192757 ] Mail Archive mirroring Message-ID: Patches item #1192757, was opened at 2005-04-29 14:59 Message generated for change (Comment added) made by marshman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1192757&group_id=103 Category: list administration Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Jeff Marshall (marshman) Assigned to: Nobody/Anonymous (nobody) Summary: Mail Archive mirroring Initial Comment: New third party archiving option that uses The Mail Archive. The implementation subscribes or unsubscribes the archive@mail-archive.com address from the subscriber list. This gives list admins an easy setup option to provide mirroring and searchable public archives. Patch is based on branch Release_2_1-maint version 2.1.6rc3. ---------------------------------------------------------------------- >Comment By: Jeff Marshall (marshman) Date: 2005-04-29 15:24 Message: Logged In: YES user_id=118832 Updated the patch to account for existing mailing lists that are still using the old archive@jab.org address, rather than the archive@mail-archive.com address. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1192757&group_id=103 From noreply at sourceforge.net Sat Apr 30 09:10:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Apr 30 09:11:01 2005 Subject: [ mailman-Feature Requests-1192175 ] provide filtered log access via web Message-ID: Feature Requests item #1192175, was opened at 2005-04-29 14:33 Message generated for change (Comment added) made by yaseppochi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1192175&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stephen J. Turnbull (yaseppochi) Assigned to: Nobody/Anonymous (nobody) Summary: provide filtered log access via web Initial Comment: ... and queuefile summary data, too! Suggested interface: new toplevel menu item for a TROUBLESHOOTING page. The page would contain query boxes for (a) logfiles and (b) queue summaries. The LOG QUERY would have a checkbox (not radio button) interface listing the available logs. Filters would include (a) timestamp range (b) general Python regexp at least. The QUEUE QUERY would have a checkbox listing the queues. Rather than have filters (at least at first) the QUEUE QUERY might just provide age distributions, say < 1 hour, < 5 hours, < 1 day, > 1 day for each requested queue. I'm of two minds as to whether an interface to access data about individual messages would be useful. The thing is, generally to do anything useful about the queues you need shell and privileged access to the host. It might be useful to have a MiniFAQ on this page that just points to the MFAQs on the FAQWizard. ---------------------------------------------------------------------- >Comment By: Stephen J. Turnbull (yaseppochi) Date: 2005-04-30 16:10 Message: Logged In: YES user_id=88738 As pointed out by Brad Knowles, Mailman can't unilaterally provide access to MTA queues. That will depend on the privileges the host gives to the list admins. It would be useful on the troubleshooting page to point to FAQs that help the list admins provide the MTA admins with the info they need to troubleshoot problems on the MTA side. For newbie list+MTA admins, pointers to the MTA mailing lists. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1192175&group_id=103 From noreply at sourceforge.net Sat Apr 30 09:12:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Apr 30 09:12:09 2005 Subject: [ mailman-Feature Requests-1192175 ] provide filtered log access via web Message-ID: Feature Requests item #1192175, was opened at 2005-04-29 14:33 Message generated for change (Comment added) made by yaseppochi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1192175&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stephen J. Turnbull (yaseppochi) Assigned to: Nobody/Anonymous (nobody) Summary: provide filtered log access via web Initial Comment: ... and queuefile summary data, too! Suggested interface: new toplevel menu item for a TROUBLESHOOTING page. The page would contain query boxes for (a) logfiles and (b) queue summaries. The LOG QUERY would have a checkbox (not radio button) interface listing the available logs. Filters would include (a) timestamp range (b) general Python regexp at least. The QUEUE QUERY would have a checkbox listing the queues. Rather than have filters (at least at first) the QUEUE QUERY might just provide age distributions, say < 1 hour, < 5 hours, < 1 day, > 1 day for each requested queue. I'm of two minds as to whether an interface to access data about individual messages would be useful. The thing is, generally to do anything useful about the queues you need shell and privileged access to the host. It might be useful to have a MiniFAQ on this page that just points to the MFAQs on the FAQWizard. ---------------------------------------------------------------------- >Comment By: Stephen J. Turnbull (yaseppochi) Date: 2005-04-30 16:12 Message: Logged In: YES user_id=88738 As pointed out by Brad Knowles, Mailman can't unilaterally provide access to MTA queues. That will depend on the privileges the host gives to the list admins. It would be useful on the troubleshooting page to point to FAQs that help the list admins provide the MTA admins with the info they need to troubleshoot problems on the MTA side. For newbie list+MTA admins, pointers to the MTA mailing lists. ---------------------------------------------------------------------- Comment By: Stephen J. Turnbull (yaseppochi) Date: 2005-04-30 16:10 Message: Logged In: YES user_id=88738 As pointed out by Brad Knowles, Mailman can't unilaterally provide access to MTA queues. That will depend on the privileges the host gives to the list admins. It would be useful on the troubleshooting page to point to FAQs that help the list admins provide the MTA admins with the info they need to troubleshoot problems on the MTA side. For newbie list+MTA admins, pointers to the MTA mailing lists. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1192175&group_id=103