From noreply at sourceforge.net Wed Sep 1 03:27:12 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 1 03:27:15 2004 Subject: [ mailman-Patches-1020102 ] fix for spam filter removed (bugid:1013079/1020013) Message-ID: Patches item #1020102, was opened at 2004-09-01 01:27 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=1020102&group_id=103 Category: Web UI Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: fix for spam filter removed (bugid:1013079/1020013) Initial Comment: spam rules should be updated only if the subcategory is 'spam'. The patch looks weird but it adds only one 'if' statement and indent for the if block. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1020102&group_id=103 From noreply at sourceforge.net Wed Sep 1 03:31:31 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 1 03:31:45 2004 Subject: [ mailman-Bugs-1013079 ] spam filters get removed when changing other privacy pages Message-ID: Bugs item #1013079, was opened at 2004-08-20 19:23 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1013079&group_id=103 Category: security/privacy Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Ralph Siemsen (ralphs) Assigned to: Nobody/Anonymous (nobody) Summary: spam filters get removed when changing other privacy pages Initial Comment: Error report on behalf of Russell King (rmk+bugzilla@arm.linux.org.uk): Description of problem: If you enter some header_filter_rules in the mailman admin pages (Privacy->Spam filters) and click "submit" they are added to the list configuration database. However, if you now go to one of the other Privacy pages and click "submit" and return to the Spam Filters page, you'll find that your header_filter_rules settings have been removed. This appears to be caused by the handleForm function in ~mailman/Mailman/Gui/Privacy.py not checking to see which subsection is being submitted before processing the data for and setting the mlist.header_filter_rules list configuration variable. Version-Release number of selected component (if applicable): mailman-2.1.5-7 How reproducible: Always Steps to Reproduce: 1. Create list. 2. Go to the Privacy->Spam filters page, add some header_filter_rules and hit submit. 3. Go to the Privacy->Sender filters page but don't hit submit 4. Go back to Spam filters and note that they're still present 5. Return to Sender filters and hit submit 6. Go back to Spam filters and note that they've been removed. Actual Results: All spam filters are removed. Expected Results: Spam filter settings should be retained. Also reported to redhat bugzilla: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=130479 ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-09-01 01:31 Message: Logged In: YES user_id=67709 a patch was uploaded (id:1020102) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1013079&group_id=103 From noreply at sourceforge.net Wed Sep 1 03:33:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 1 03:33:05 2004 Subject: [ mailman-Bugs-1020013 ] spam filters get removed when changing other privacy pages Message-ID: Bugs item #1020013, was opened at 2004-08-31 21:10 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1020013&group_id=103 Category: Web/CGI Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: John Dennis (johndennis) Assigned to: Nobody/Anonymous (nobody) Summary: spam filters get removed when changing other privacy pages Initial Comment: This was filed in the Red Hat bugzilla as: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=130479 Promoting to upstream Summary is: If you enter some header_filter_rules in the mailman admin pages (Privacy->Spam filters) and click "submit" they are added to the list configuration database. However, if you now go to one of the other Privacy pages and click "submit" and return to the Spam Filters page, you'll find that your header_filter_rules settings have been removed. This appears to be caused by the handleForm function in ~mailman/Mailman/Gui/Privacy.py not checking to see which subsection is being submitted before processing the data for and setting the mlist.header_filter_rules list configuration variable. Version-Release number of selected component (if applicable): mailman-2.1.5 How reproducible: Always Steps to Reproduce: 1. Create list. 2. Go to the Privacy->Spam filters page, add some header_filter_rules and hit submit. 3. Go to the Privacy->Sender filters page but don't hit submit 4. Go back to Spam filters and note that they're still present 5. Return to Sender filters and hit submit 6. Go back to Spam filters and note that they've been removed. Actual Results: All spam filters are removed. Expected Results: Spam filter settings should be retained. ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-09-01 01:33 Message: Logged In: YES user_id=67709 a patch is uploaded (id 1020102) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1020013&group_id=103 From masoomy at gmail.com Wed Sep 1 12:21:20 2004 From: masoomy at gmail.com (Ehsan) Date: Wed Sep 1 12:21:31 2004 Subject: Mailman-coders Digest, Vol 21, Issue 1 In-Reply-To: <20040901100053.663B11E4007@bag.python.org> References: <20040901100053.663B11E4007@bag.python.org> Message-ID: http://masoomy2000.persianblog.com On Wed, 1 Sep 2004 12:00:53 +0200 (CEST), mailman-coders-request@python.org wrote: > Send Mailman-coders mailing list submissions to > mailman-coders@python.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.python.org/mailman/listinfo/mailman-coders > or, via email, send a message with subject or body 'help' to > mailman-coders-request@python.org > > You can reach the person managing the list at > mailman-coders-owner@python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Mailman-coders digest..." > > Today's Topics: > > 1. [ mailman-Bugs-1019550 ] Bug in base64MIME.py (SourceForge.net) > 2. [ mailman-Bugs-1020013 ] spam filters get removed when > changing other privacy pages (SourceForge.net) > 3. [ mailman-Patches-1020102 ] fix for spam filter removed > (bugid:1013079/1020013) (SourceForge.net) > 4. [ mailman-Bugs-1013079 ] spam filters get removed when > changing other privacy pages (SourceForge.net) > 5. [ mailman-Bugs-1020013 ] spam filters get removed when > changing other privacy pages (SourceForge.net) > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 31 Aug 2004 03:16:50 -0700 > From: "SourceForge.net" > Subject: [ mailman-Bugs-1019550 ] Bug in base64MIME.py > To: noreply@sourceforge.net > Message-ID: > Content-Type: text/plain; charset="ISO-8859-1" > > Bugs item #1019550, was opened at 2004-08-31 12:16 > 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=1019550&group_id=103 > > Category: Web/CGI > Group: 2.1 (stable) > Status: Open > Resolution: None > Priority: 5 > Submitted By: Manuel Pedreira (kour) > Assigned to: Nobody/Anonymous (nobody) > Summary: Bug in base64MIME.py > > 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 "/usr/local/mailman/scripts/driver", line 80, in > run_main > pkg = __import__('Mailman.Cgi', globals(), locals(), > [scriptname]) > File "/usr/local/mailman/Mailman/Cgi/listinfo.py", line 26, > in ? > from Mailman import Utils > File "/usr/local/mailman/Mailman/Utils.py", line 37, in ? > import email.Header > File "/usr/local/mailman/pythonlib/email/Header.py", line > 11, in ? > import email.base64MIME > > File "/usr/local/mailman/pythonlib/email/base64MIME.py", > line 31, in ? > from email._compat22 import _floordiv > ImportError: cannot import name _floordiv > > ------------------------------------------------------- > ------------------------- > > Python information: > Variable Value > sys.version 2.1.3 (#1, Sep 7 2002, 15:29:56) [GCC > 2.95.4 20011002 (Debian prerelease)] > sys.executable /usr/bin/python2.1 > sys.prefix /usr > sys.exec_prefix /usr > sys.path /usr > sys.platform linux2 > > ------------------------------------------------------- > ------------------------- > > Environment variables: > Variable Value > DOCUMENT_ROOT /wwroot/listas.gulo.org/ > SERVER_ADDR 193.147.87.51 > SERVER_PORT 80 > REMOTE_ADDR **.**.**.** > SERVER_SOFTWARE Apache/2.0.48 (Unix) PHP/4.3.3 > mod_ssl/2.0.48 OpenSSL/0.9.6c > HTTP_VIA 1.0 VENUS1 > HTTP_ACCEPT_LANGUAGE es > GATEWAY_INTERFACE CGI/1.1 > SERVER_NAME listas.gulo.org > HTTP_CONNECTION Keep-Alive > HTTP_USER_AGENT Mozilla/4.0 (compatible; MSIE 6.0; > Windows NT 5.0; MyIE2; .NET CLR 1.1.4322) > HTTP_ACCEPT */* > REQUEST_URI /mailman/listinfo > QUERY_STRING > SERVER_PROTOCOL HTTP/1.0 > HTTP_HOST listas.gulo.org > REQUEST_METHOD GET > SERVER_SIGNATURE > HTTP_IF_MODIFIED_SINCE Tue, 31 Aug 2004 09:41:13 > GMT > SCRIPT_NAME /mailman/listinfo > SERVER_ADMIN admin(at)gulo.org > SCRIPT_FILENAME /usr/local/mailman/cgi-bin/listinfo > PYTHONPATH /usr/local/mailman > HTTP_COOKIE > PHPSESSID=0fb5eb2692415f078d387a9225b8086e > REMOTE_PORT 36105 > > ---------------------------------------------------------------------- > > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1019550&group_id=103 > > ------------------------------ > > Message: 2 > Date: Tue, 31 Aug 2004 14:10:29 -0700 > From: "SourceForge.net" > Subject: [ mailman-Bugs-1020013 ] spam filters get removed when > changing other privacy pages > To: noreply@sourceforge.net > Message-ID: > Content-Type: text/plain; charset="ISO-8859-1" > > Bugs item #1020013, was opened at 2004-08-31 16:10 > 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=1020013&group_id=103 > > Category: Web/CGI > Group: 2.1 (stable) > Status: Open > Resolution: None > Priority: 5 > Submitted By: John Dennis (johndennis) > Assigned to: Nobody/Anonymous (nobody) > Summary: spam filters get removed when changing other privacy pages > > Initial Comment: > This was filed in the Red Hat bugzilla as: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=130479 > > Promoting to upstream > > Summary is: > > If you enter some header_filter_rules in the mailman > admin pages > (Privacy->Spam filters) and click "submit" they are > added to the > list configuration database. > > However, if you now go to one of the other Privacy > pages and click > "submit" and return to the Spam Filters page, you'll > find that your > header_filter_rules settings have been removed. > > This appears to be caused by the handleForm function in > ~mailman/Mailman/Gui/Privacy.py not checking to see > which subsection > is being submitted before processing the data for and > setting the > mlist.header_filter_rules list configuration variable. > > Version-Release number of selected component (if > applicable): > mailman-2.1.5 > > How reproducible: > Always > > Steps to Reproduce: > 1. Create list. > 2. Go to the Privacy->Spam filters page, add some > header_filter_rules > and hit submit. > 3. Go to the Privacy->Sender filters page but don't hit > submit > 4. Go back to Spam filters and note that they're still > present > 5. Return to Sender filters and hit submit > 6. Go back to Spam filters and note that they've been > removed. > > Actual Results: All spam filters are removed. > > Expected Results: Spam filter settings should be retained. > > ---------------------------------------------------------------------- > > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1020013&group_id=103 > > ------------------------------ > > Message: 3 > Date: Tue, 31 Aug 2004 18:27:12 -0700 > From: "SourceForge.net" > Subject: [ mailman-Patches-1020102 ] fix for spam filter removed > (bugid:1013079/1020013) > To: noreply@sourceforge.net > Message-ID: > Content-Type: text/plain; charset="ISO-8859-1" > > Patches item #1020102, was opened at 2004-09-01 01:27 > 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=1020102&group_id=103 > > Category: Web UI > Group: Mailman 2.1 > Status: Open > Resolution: None > Priority: 5 > Submitted By: Tokio Kikuchi (tkikuchi) > Assigned to: Nobody/Anonymous (nobody) > Summary: fix for spam filter removed (bugid:1013079/1020013) > > Initial Comment: > spam rules should be updated only if the subcategory is > 'spam'. The patch looks weird but it adds only one 'if' > statement and indent for the if block. > > ---------------------------------------------------------------------- > > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1020102&group_id=103 > > ------------------------------ > > Message: 4 > Date: Tue, 31 Aug 2004 18:31:31 -0700 > From: "SourceForge.net" > Subject: [ mailman-Bugs-1013079 ] spam filters get removed when > changing other privacy pages > To: noreply@sourceforge.net > Message-ID: > Content-Type: text/plain; charset="ISO-8859-1" > > Bugs item #1013079, was opened at 2004-08-20 19:23 > Message generated for change (Comment added) made by tkikuchi > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1013079&group_id=103 > > Category: security/privacy > Group: 2.1 beta > Status: Open > Resolution: None > Priority: 5 > Submitted By: Ralph Siemsen (ralphs) > Assigned to: Nobody/Anonymous (nobody) > Summary: spam filters get removed when changing other privacy pages > > Initial Comment: > Error report on behalf of Russell King > (rmk+bugzilla@arm.linux.org.uk): > > Description of problem: > If you enter some header_filter_rules in the mailman > admin pages (Privacy->Spam filters) and click "submit" > they are added to the list configuration database. > > However, if you now go to one of the other Privacy > pages and click "submit" and return to the Spam Filters > page, you'll find that your header_filter_rules > settings have been removed. > > This appears to be caused by the handleForm function in > ~mailman/Mailman/Gui/Privacy.py not checking to see > which subsection is being submitted before processing > the data for and setting the mlist.header_filter_rules > list configuration variable. > > Version-Release number of selected component (if > applicable): mailman-2.1.5-7 > > How reproducible: > Always > > Steps to Reproduce: > 1. Create list. > 2. Go to the Privacy->Spam filters page, add some > header_filter_rules and hit submit. > 3. Go to the Privacy->Sender filters page but don't hit > submit > 4. Go back to Spam filters and note that they're still > present > 5. Return to Sender filters and hit submit > 6. Go back to Spam filters and note that they've been > removed. > > Actual Results: All spam filters are removed. > > Expected Results: Spam filter settings should be retained. > > Also reported to redhat bugzilla: > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=130479 > > ---------------------------------------------------------------------- > > >Comment By: Tokio Kikuchi (tkikuchi) > Date: 2004-09-01 01:31 > > Message: > Logged In: YES > user_id=67709 > > a patch was uploaded (id:1020102) > > ---------------------------------------------------------------------- > > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1013079&group_id=103 > > ------------------------------ > > Message: 5 > Date: Tue, 31 Aug 2004 18:33:01 -0700 > From: "SourceForge.net" > Subject: [ mailman-Bugs-1020013 ] spam filters get removed when > changing other privacy pages > To: noreply@sourceforge.net > Message-ID: > Content-Type: text/plain; charset="ISO-8859-1" > > Bugs item #1020013, was opened at 2004-08-31 21:10 > Message generated for change (Comment added) made by tkikuchi > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1020013&group_id=103 > > Category: Web/CGI > Group: 2.1 (stable) > Status: Open > Resolution: None > Priority: 5 > Submitted By: John Dennis (johndennis) > Assigned to: Nobody/Anonymous (nobody) > Summary: spam filters get removed when changing other privacy pages > > Initial Comment: > This was filed in the Red Hat bugzilla as: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=130479 > > Promoting to upstream > > Summary is: > > If you enter some header_filter_rules in the mailman > admin pages > (Privacy->Spam filters) and click "submit" they are > added to the > list configuration database. > > However, if you now go to one of the other Privacy > pages and click > "submit" and return to the Spam Filters page, you'll > find that your > header_filter_rules settings have been removed. > > This appears to be caused by the handleForm function in > ~mailman/Mailman/Gui/Privacy.py not checking to see > which subsection > is being submitted before processing the data for and > setting the > mlist.header_filter_rules list configuration variable. > > Version-Release number of selected component (if > applicable): > mailman-2.1.5 > > How reproducible: > Always > > Steps to Reproduce: > 1. Create list. > 2. Go to the Privacy->Spam filters page, add some > header_filter_rules > and hit submit. > 3. Go to the Privacy->Sender filters page but don't hit > submit > 4. Go back to Spam filters and note that they're still > present > 5. Return to Sender filters and hit submit > 6. Go back to Spam filters and note that they've been > removed. > > Actual Results: All spam filters are removed. > > Expected Results: Spam filter settings should be retained. > > ---------------------------------------------------------------------- > > >Comment By: Tokio Kikuchi (tkikuchi) > Date: 2004-09-01 01:33 > > Message: > Logged In: YES > user_id=67709 > > a patch is uploaded (id 1020102) > > ---------------------------------------------------------------------- > > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1020013&group_id=103 > > ------------------------------ > > _______________________________________________ > Mailman-coders mailing list > Mailman-coders@python.org > http://mail.python.org/mailman/listinfo/mailman-coders > > End of Mailman-coders Digest, Vol 21, Issue 1 > ********************************************* > From noreply at sourceforge.net Wed Sep 1 14:48:27 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 1 14:48:31 2004 Subject: [ mailman-Bugs-1020372 ] Mailman reminders causing overloaded mailboxes. Message-ID: Bugs item #1020372, was opened at 2004-09-01 12:48 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=1020372&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dave Wilson (dmw) Assigned to: Nobody/Anonymous (nobody) Summary: Mailman reminders causing overloaded mailboxes. Initial Comment: Hi there, I'm sure you're aware of this problem, and I know there is a manual fix for it (changing the reminder date), however I feel that this should be randomised at installation time, or at least forceably requested from the administrator at installation time, as too many administrators leave it set to the first of the month. As a matter of diligence, putting a warning in the installation docs about changing the date should (IMHO) be the least you do. Requiring an extra argument to ./configure would get you bonus points (--with-reminder-date ?). If there is interest in this, but no-one wants to implement it, I could be cadgered into providing a patch if you like. Thanks for your time, David. A happy and satisfied Mailman user, albeit one that gets bombarded monthly. :) PS: Aware of the option to disable reminders, but again, it's non-default. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1020372&group_id=103 From noreply at sourceforge.net Wed Sep 1 21:22:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 1 21:22:08 2004 Subject: [ mailman-Patches-1020672 ] Prevent display of owner e-mail Message-ID: Patches item #1020672, was opened at 2004-09-01 12:22 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=1020672&group_id=103 Category: Web UI Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Joe Rhett (jrhett) Assigned to: Nobody/Anonymous (nobody) Summary: Prevent display of owner e-mail Initial Comment: Don't display the owner's e-mail address to the user. Instead display the listname-owner link. I'm surprised that this isn't a configuration option. A better patch would be to make a configuration option on a per-list basis and if() this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1020672&group_id=103 From noreply at sourceforge.net Wed Sep 1 21:35:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 1 21:35:38 2004 Subject: [ mailman-Bugs-969613 ] double-quotes incorrectly converted to HTML in header values Message-ID: Bugs item #969613, was opened at 2004-06-09 09:54 Message generated for change (Settings changed) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=969613&group_id=103 Category: mail delivery Group: 2.1 (stable) Status: Open Resolution: None >Priority: 8 Submitted By: Ulrich Windl (windl) Assigned to: Nobody/Anonymous (nobody) Summary: double-quotes incorrectly converted to HTML in header values 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=969613&group_id=103 From noreply at sourceforge.net Wed Sep 1 21:45:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 1 21:45:46 2004 Subject: [ mailman-Bugs-657443 ] Header and footer in multipart Message-ID: Bugs item #657443, was opened at 2002-12-22 03:08 Message generated for change (Settings changed) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=657443&group_id=103 Category: mail delivery Group: 2.1 (stable) >Status: Closed >Resolution: Out of Date Priority: 7 Submitted By: Demeilliez Bruno (dive_bruno) Assigned to: Nobody/Anonymous (nobody) Summary: Header and footer in multipart Initial Comment: Hi, I have install mailman 2.1b6 on redhat 7.1. My mailling list is in french and when I received mail from the list with theBat, the header and the footer is in multipart (like at the end). I would like the bady and the footer was in the same message. Can you tell me if it's a bug or a configuration problem ? And how I can resolve it ? Thank's for your help. Bruno Example : .... From: Bruno Demeilliez <webmaster@aquanaute.com> X-Mailer: The Bat! (v1.62 Christmas Edition) Organization: Aquanaute.com X-Priority: 3 (Normal) Message-ID: <11916819925.20021222110418@aquanaute.com> To: test2@aquanaute.com MIME-Version: 1.0 Subject: Test X-BeenThere: test2@aquanaute.com X-Mailman-Version: 2.1b6 Precedence: list Reply-To: Bruno Demeilliez <webmaster@aquanaute.com>, test2@aquanaute.com List-Id: <test2.aquanaute.com> List-Help: <mailto:test2-request@aquanaute.com?subject=help> List-Post: <mailto:test2@aquanaute.com> List-Subscribe: <http://www.aquanaute.com/mailman/listinfo/test2>, <mailto:test2-request@aquanaute.com?subject=subscribe> List-Archive: <http://www.aquanaute.com/pipermail/test2> List-Unsubscribe: <http://www.aquanaute.com/mailman/listinfo/test2>, <mailto:test2-request@aquanaute.com?subject=unsubscribe> Content-Type: multipart/mixed; boundary="===============2617006012765839==" Sender: test2-bounces@aquanaute.com Errors-To: test2-bounces@aquanaute.com --===============2617006012765839== Content-Transfer-Encoding: 8bit content-type: text/plain Bonjour test2, Amicalement, Bruno --- Pour l'?quipe d'Aquanaute.com http://www.aquanaute.com SARL de presse Aquanaute.com 8 rue Duploy? 38100 Grenoble France T?l et Fax : 04 76 99 93 77 --===============2617006012765839== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit _______________________________________________ Liste de discussion Test2 Liste h?berg?e et administr?e gratuitement par Aquanaute.com Pr?sentation de la liste, Abonnement / D?sabonnement : http://www.aquanaute.com/mailman/listinfo/test2 Archives de la liste : http://aquanaute.com/listes/Test2/ --===============2617006012765839==-- ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-09-01 15:45 Message: Logged In: YES user_id=12800 This happens when the charset or content-type of the footer is not compatible with the charset or content-type of the message. In those cases, the footer cannot be appended, so it's added as an attachment. However, this functionality has been improved in newer versions of Mailman so you should upgrade to 2.1.5 and see if the problem still exists. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=657443&group_id=103 From noreply at sourceforge.net Fri Sep 3 03:15:05 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 3 03:15:10 2004 Subject: [ mailman-Patches-1021548 ] Provide subscription information to reject lists Message-ID: Patches item #1021548, was opened at 2004-09-02 18:15 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=1021548&group_id=103 Category: list administration Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Joe Rhett (jrhett) Assigned to: Nobody/Anonymous (nobody) Summary: Provide subscription information to reject lists Initial Comment: This patch provides useful subscription instructions to people who receive a rejection notice on a subscriber-only list. This really should be a per-list configuration option, or even better yet an editable field that the list admin can use to provide information to users. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1021548&group_id=103 From noreply at sourceforge.net Fri Sep 3 04:32:26 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 3 04:32:31 2004 Subject: [ mailman-Patches-1021548 ] Provide subscription information to reject lists Message-ID: Patches item #1021548, was opened at 2004-09-02 18:15 Message generated for change (Comment added) made by jrhett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1021548&group_id=103 Category: list administration Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Joe Rhett (jrhett) Assigned to: Nobody/Anonymous (nobody) Summary: Provide subscription information to reject lists Initial Comment: This patch provides useful subscription instructions to people who receive a rejection notice on a subscriber-only list. This really should be a per-list configuration option, or even better yet an editable field that the list admin can use to provide information to users. ---------------------------------------------------------------------- >Comment By: Joe Rhett (jrhett) Date: 2004-09-02 19:32 Message: Logged In: YES user_id=104595 Oops, wrong case on method invocation. Fix is here... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1021548&group_id=103 From noreply at sourceforge.net Sun Sep 5 12:59:13 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 5 12:59:17 2004 Subject: [ mailman-Bugs-1022515 ] wrong location for Fedora Core 2 sendmail in Defaults.py Message-ID: Bugs item #1022515, was opened at 2004-09-05 06: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=1022515&group_id=103 Category: configuring/installing Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Jonathan Baron (jonbaron1944) Assigned to: Nobody/Anonymous (nobody) Summary: wrong location for Fedora Core 2 sendmail in Defaults.py Initial Comment: On Fedora Core 2, using the RPM (which may not be your problem, but you may know whose problem it is), the location for sendmail in /var/mailman/Mailman/Default.py is /usr/lib/sendmail. Mailman would not send mail until I changed it to /usr/bin/sendmail in mm_cfg.py and restarted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1022515&group_id=103 From noreply at sourceforge.net Sun Sep 5 15:27:04 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 5 15:27:08 2004 Subject: [ mailman-Bugs-1022562 ] news_moderation should be ignored when no gateway is used Message-ID: Bugs item #1022562, was opened at 2004-09-05 15:27 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=1022562&group_id=103 Category: nntp/news Group: Out of Date Status: Open Resolution: None Priority: 5 Submitted By: Alex Schroeder (kensanata) Assigned to: Nobody/Anonymous (nobody) Summary: news_moderation should be ignored when no gateway is used Initial Comment: Using version 2.1.4.ber1... When news_moderation is set to Moderated, but both gateway_to_news and gateway_to_mail are set to No, all mails (even by members) require moderator approval. I think that news_moderation should be ignored when News server settings indicate that no Mail<->News gateway is active. We are two moderators, one newbie and me. The newbie had played around with the settings, and I tried to fix it. It hadn't occured to me to check the Mail<->News gateways section, because we don't use a gateway. A member on #mailman pointed me to the keyword "newsgroup" in the reason given: From: alex@emacswiki.org Subject: Re: SWPAT-action in Switzerland Reason: Posting to a moderated newsgroup ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1022562&group_id=103 From noreply at sourceforge.net Sun Sep 5 23:40:41 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 5 23:40:44 2004 Subject: [ mailman-Bugs-1022762 ] common.c is using getgid() instead of getegid Message-ID: Bugs item #1022762, was opened at 2004-09-05 17:40 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=1022762&group_id=103 Category: security/privacy Group: None Status: Open Resolution: None Priority: 5 Submitted By: Geoff Mottram (gmottram) Assigned to: Nobody/Anonymous (nobody) Summary: common.c is using getgid() instead of getegid Initial Comment: The mailman wrapper that is used with its set group id set is checking the real group id in src/common.c (line 121). This will only work if mailman is configured to use the group "mail" as that is the only time the real and effective group of mailman will match the configuration. Any programs run by sendmail are real user id of "mail" and real group id of "mail". When using the set group id or set user id flags on an executable file, the program's real group and user values do not change, only their effective group and user id's. I am running Fedora core release 1 (kernel version 2.4.22), mailman version 2.1.5 and sendmail 8.12.10 with "smrsh". The fix is to change line 121 in src/common.c from: mygid = getgid() to mygid = getegid() With this change mailman can be installed as group "mailman" (or any other group besides "mail") instead of group "mail" (which is probably a security issue). Best, Geoff Mottram ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1022762&group_id=103 From noreply at sourceforge.net Tue Sep 7 08:35:57 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 7 08:36:02 2004 Subject: [ mailman-Bugs-1022762 ] common.c is using getgid() instead of getegid Message-ID: Bugs item #1022762, was opened at 2004-09-05 17:40 Message generated for change (Comment added) made by gmottram You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1022762&group_id=103 Category: security/privacy Group: None Status: Open Resolution: None Priority: 5 Submitted By: Geoff Mottram (gmottram) Assigned to: Nobody/Anonymous (nobody) Summary: common.c is using getgid() instead of getegid Initial Comment: The mailman wrapper that is used with its set group id set is checking the real group id in src/common.c (line 121). This will only work if mailman is configured to use the group "mail" as that is the only time the real and effective group of mailman will match the configuration. Any programs run by sendmail are real user id of "mail" and real group id of "mail". When using the set group id or set user id flags on an executable file, the program's real group and user values do not change, only their effective group and user id's. I am running Fedora core release 1 (kernel version 2.4.22), mailman version 2.1.5 and sendmail 8.12.10 with "smrsh". The fix is to change line 121 in src/common.c from: mygid = getgid() to mygid = getegid() With this change mailman can be installed as group "mailman" (or any other group besides "mail") instead of group "mail" (which is probably a security issue). Best, Geoff Mottram ---------------------------------------------------------------------- >Comment By: Geoff Mottram (gmottram) Date: 2004-09-07 02:35 Message: Logged In: YES user_id=1116625 I have more fully documented a fix to the above problem here: http://minaret.biz/tips/mailman.html In addition to the change from getgid() to getegid(), you must re-run configure with the "--with-cgi-gid=mailman" option for the cgi-bin scripts to work. Geoff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1022762&group_id=103 From noreply at sourceforge.net Tue Sep 7 21:55:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 7 21:55:46 2004 Subject: [ mailman-Bugs-1023942 ] No "Date:" line in digest header Message-ID: Bugs item #1023942, was opened at 2004-09-07 14: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=1023942&group_id=103 Category: mail delivery Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Todd K. Watson (tkdubs) Assigned to: Nobody/Anonymous (nobody) Summary: No "Date:" line in digest header Initial Comment: I am running Mailman-2.1.5. Mailman fails to insert the "Date:" line in the header, which can cause problems for MTA's which do not inject a "Date:" line (such as qmail). Each individual message within the digest has a date line in its header, but the digest itself is missing the Date line. This causes mail readers like Thunderbird to label the message as being sent on Dec. 31, 1969. Most MTA's and MUA's inject a Date line, but I'm using Qmail as an MTA -- which doesn't inject one. It is the job of the MUA (Mailman in this case) to create the Date: line according to RFC-2822. This was fixed for non-digested messages delivered to lists in 2.1-beta-1 of Mailman according to the NEWS file, but has not yet been addressed for delivery of digests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1023942&group_id=103 From noreply at sourceforge.net Wed Sep 8 12:35:55 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 8 12:35:59 2004 Subject: [ mailman-Patches-1024289 ] Add support for $Orig and $REF for Lotus Notes < 5.0.9 Message-ID: Patches item #1024289, was opened at 2004-09-08 15:35 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=1024289&group_id=103 Category: Pipermail Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: shobhan challa (shobhanc) Assigned to: Nobody/Anonymous (nobody) Summary: Add support for $Orig and $REF for Lotus Notes < 5.0.9 Initial Comment: Lotus Notes below 6.25 doesnt set the 'In-Reply-To' or 'References' header. but it sets 'Orig' and 'REF' headers. Mailman should be able to process 'Orig' and 'REF' headers if 'In-Reply-To' is not set for Lotus Notes. Does anyone have any idea how to do this..? Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1024289&group_id=103 From noreply at sourceforge.net Thu Sep 9 22:02:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 9 22:02:53 2004 Subject: [ mailman-Bugs-1025372 ] empty Cc: Message-ID: Bugs item #1025372, was opened at 2004-09-09 16:02 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=1025372&group_id=103 Category: mail delivery Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Rob Ellis (robellis) Assigned to: Nobody/Anonymous (nobody) Summary: empty Cc: Initial Comment: In lists migrated from 2.0.13, new messages without a Cc: header end up with an empty one when delivered by mailman (2.1.5). Freshly created lists don't seem to have the problem ? This is on a freebsd 4 stable machine running postfix 2.0.19,1 with mailman set up to use SMTPDirect. Python 2.3.3. The attached patch to AvoidDuplicates.py/CookHeaders.py seems to fix it... - rob ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1025372&group_id=103 From noreply at sourceforge.net Sat Sep 11 20:04:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 11 20:05:11 2004 Subject: [ mailman-Patches-891491 ] Scrubber.py patch Message-ID: Patches item #891491, was opened at 2004-02-06 02:26 Message generated for change (Comment added) made by ber You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=891491&group_id=103 Category: Pipermail Group: Mailman 2.1 Status: Open Resolution: None Priority: 8 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: Scrubber.py patch Initial Comment: Scrubber.py has number of bugs for processing various types of attachment and languages and many have submitted patches to fix them. This patch item is opened to collect such patches for convenience. This patch corrects: - if an attached text is composed by win notepad, it has no charset specified and actual charset may be different from message/list charset. This sometimes cause error in composing digest message. - sometimes, null charset is represented by '' as well as None. - embedded rfc-2822 message is lost if you don't use msg.walk() - special problem with japanese charsets. - t (stringfied part) may be None which you can't append a '\n'. ---------------------------------------------------------------------- Comment By: Bernhard Reiter (ber) Date: 2004-09-11 20:04 Message: Logged In: YES user_id=113859 scrubber.patch 2004-08-24 has a problem. Charset(lcset).output_charset can return None according to the documentation. E.g. when no conversion is needed. This would assign Non to lcset_out . Later this leads to an exception in try: if len(charset) == 0: charset = 'us-ascii' t = t.encode(charset, 'replace') except (UnicodeError, LookupError, ValueError): t = t.encode(lcset, 'replace') because: TypeError: len() of unsized object ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-08-24 09:58 Message: Logged In: YES user_id=67709 added a fix for the case of lcset_out <> lcset. ---------------------------------------------------------------------- Comment By: Bernhard Reiter (ber) Date: 2004-04-14 20:53 Message: Logged In: YES user_id=113859 Thanks for working on the patch. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-02-25 11:42 Message: Logged In: YES user_id=67709 uploading revised patch. Now fixes a few more bugs which try to decode scrub plain text message and result in mojibake. Also, japanese filename tend to become so long that system limit may exceeded because of mime encoding, so add an option not to use the filename in the message but to use 'attachment' as filename. Because this patch spans two files (Defaults.py.in and Handlers/Scrubber.py) you have to cd mailman and patch -p1 < this_patch. (Well, I think it is -p1. If it didn't work, try -p0 ;-) ---------------------------------------------------------------------- Comment By: Jonathan Larmour (jifl) Date: 2004-02-22 18:25 Message: Logged In: YES user_id=817601 I strongly recommend applying this patch. I received a mail bounce on a list with an empty charset in a part (i.e. "charset=") and it caused /var/mailman/cron/senddigest and thus all digest processing to fail because of this error: Traceback (most recent call last): File "/var/mailman/cron/senddigests", line 94, in ? main() File "/var/mailman/cron/senddigests", line 86, in main mlist.send_digest_now() File "/var/mailman/Mailman/Digester.py", line 60, in send_digest_now ToDigest.send_digests(self, mboxfp) File "/var/mailman/Mailman/Handlers/ToDigest.py", line 123, in send_digests send_i18n_digests(mlist, mboxfp) File "/var/mailman/Mailman/Handlers/ToDigest.py", line 295, in send_i18n_digests msg = scrubber(mlist, msg) File "/var/mailman/Mailman/Handlers/Scrubber.py", line 308, in process t = t.encode(charset, 'replace') File "/usr/lib/python2.2/encodings/__init__.py", line 51, in search_function mod = __import__(modname,globals(),locals(),'*') which is something this patch fixes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=891491&group_id=103 From noreply at sourceforge.net Sun Sep 12 01:45:55 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 12 01:46:09 2004 Subject: [ mailman-Patches-891491 ] Scrubber.py patch Message-ID: Patches item #891491, was opened at 2004-02-06 01:26 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=891491&group_id=103 Category: Pipermail Group: Mailman 2.1 Status: Open Resolution: None Priority: 8 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: Scrubber.py patch Initial Comment: Scrubber.py has number of bugs for processing various types of attachment and languages and many have submitted patches to fix them. This patch item is opened to collect such patches for convenience. This patch corrects: - if an attached text is composed by win notepad, it has no charset specified and actual charset may be different from message/list charset. This sometimes cause error in composing digest message. - sometimes, null charset is represented by '' as well as None. - embedded rfc-2822 message is lost if you don't use msg.walk() - special problem with japanese charsets. - t (stringfied part) may be None which you can't append a '\n'. ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-09-11 23:45 Message: Logged In: YES user_id=67709 Sorry for the problem. I have updated this patch (2004-09-12 version) Please try and report this patch because I can't fully reproduce the problem (in Japanese environment). ---------------------------------------------------------------------- Comment By: Bernhard Reiter (ber) Date: 2004-09-11 18:04 Message: Logged In: YES user_id=113859 scrubber.patch 2004-08-24 has a problem. Charset(lcset).output_charset can return None according to the documentation. E.g. when no conversion is needed. This would assign Non to lcset_out . Later this leads to an exception in try: if len(charset) == 0: charset = 'us-ascii' t = t.encode(charset, 'replace') except (UnicodeError, LookupError, ValueError): t = t.encode(lcset, 'replace') because: TypeError: len() of unsized object ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-08-24 07:58 Message: Logged In: YES user_id=67709 added a fix for the case of lcset_out <> lcset. ---------------------------------------------------------------------- Comment By: Bernhard Reiter (ber) Date: 2004-04-14 18:53 Message: Logged In: YES user_id=113859 Thanks for working on the patch. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-02-25 10:42 Message: Logged In: YES user_id=67709 uploading revised patch. Now fixes a few more bugs which try to decode scrub plain text message and result in mojibake. Also, japanese filename tend to become so long that system limit may exceeded because of mime encoding, so add an option not to use the filename in the message but to use 'attachment' as filename. Because this patch spans two files (Defaults.py.in and Handlers/Scrubber.py) you have to cd mailman and patch -p1 < this_patch. (Well, I think it is -p1. If it didn't work, try -p0 ;-) ---------------------------------------------------------------------- Comment By: Jonathan Larmour (jifl) Date: 2004-02-22 17:25 Message: Logged In: YES user_id=817601 I strongly recommend applying this patch. I received a mail bounce on a list with an empty charset in a part (i.e. "charset=") and it caused /var/mailman/cron/senddigest and thus all digest processing to fail because of this error: Traceback (most recent call last): File "/var/mailman/cron/senddigests", line 94, in ? main() File "/var/mailman/cron/senddigests", line 86, in main mlist.send_digest_now() File "/var/mailman/Mailman/Digester.py", line 60, in send_digest_now ToDigest.send_digests(self, mboxfp) File "/var/mailman/Mailman/Handlers/ToDigest.py", line 123, in send_digests send_i18n_digests(mlist, mboxfp) File "/var/mailman/Mailman/Handlers/ToDigest.py", line 295, in send_i18n_digests msg = scrubber(mlist, msg) File "/var/mailman/Mailman/Handlers/Scrubber.py", line 308, in process t = t.encode(charset, 'replace') File "/usr/lib/python2.2/encodings/__init__.py", line 51, in search_function mod = __import__(modname,globals(),locals(),'*') which is something this patch fixes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=891491&group_id=103 From noreply at sourceforge.net Mon Sep 13 04:01:25 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 13 04:01:28 2004 Subject: [ mailman-Patches-1026977 ] check attachment header by SpamDetect.py Message-ID: Patches item #1026977, was opened at 2004-09-13 02: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=1026977&group_id=103 Category: list administration Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: check attachment header by SpamDetect.py Initial Comment: SpamDetect.py and Privacy -> Spam interface can check incoming message haeder by regular expressions and discard/reject/hold the message. It can prevent viruses by blocking multipart messages but many users are now want to pass multipart. This patch extents the check into the attachment header so that viruses which have .exe/.pif file can be prevented by the same interface. Note that cheking is limited to the second level of multiparts because collecting all the header will cause infinite loop because owner notification message is also checked by this module. Usage: after applying this patch and restart mailman, go to the privacy/spam admin page and insert a rule content-.*name.*\.(exe|pif|com|vbs) to be discarded. Cheers, ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1026977&group_id=103 From noreply at sourceforge.net Mon Sep 13 14:30:54 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 13 14:31:00 2004 Subject: [ mailman-Bugs-975768 ] senddigests doesn't handle consecutive unparseable messages Message-ID: Bugs item #975768, was opened at 2004-06-19 09:07 Message generated for change (Comment added) made by thomas_ah You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=975768&group_id=103 Category: mail delivery Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Andreas Voegele (voegelas) Assigned to: Nobody/Anonymous (nobody) Summary: senddigests doesn't handle consecutive unparseable messages Initial Comment: The following code fragment in send_i18n_digests in Mailman/ Handlers/ToDigest.py doesn't take into account that there could be several consecutive messages that are unparseable: msg = mbox.next() while msg is not None: if msg == '': # It was an unparseable message msg = mbox.next() [...] # Get the next message in the digest mailbox msg = mbox.next() I'm not that familiar with Python but I think that the following code should fix the problem: while 1: msg = mbox.next() if msg is None: break if msg == '': # It was an unparseable message continue [...] ---------------------------------------------------------------------- Comment By: Thomas Arendsen Hein (thomas_ah) Date: 2004-09-13 14:30 Message: Logged In: YES user_id=839582 This bug is still present and hit our mailman installation last friday. The problem occurs if the unparseable message is the last one, too. Here is a patch against current CVS, effectively doing the same as Andreas Voegele suggested, but with cleaner code. Unfortunately this tracker doesn't allow me to attach it, because I didn't submit this bug. diff -u -r2.28 ToDigest.py --- Mailman/Handlers/ToDigest.py 15 Aug 2003 21:06:28 -0000 2.28 +++ Mailman/Handlers/ToDigest.py 13 Sep 2004 12:22:03 -0000 @@ -210,6 +210,7 @@ if msg == '': # It was an unparseable message msg = mbox.next() + continue msgcount += 1 messages.append(msg) # Get the Subject header ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=975768&group_id=103 From noreply at sourceforge.net Mon Sep 13 20:23:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 13 20:23:33 2004 Subject: [ mailman-Patches-891491 ] Scrubber.py patch Message-ID: Patches item #891491, was opened at 2004-02-06 02:26 Message generated for change (Comment added) made by ber You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=891491&group_id=103 Category: Pipermail Group: Mailman 2.1 Status: Open Resolution: None Priority: 8 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: Scrubber.py patch Initial Comment: Scrubber.py has number of bugs for processing various types of attachment and languages and many have submitted patches to fix them. This patch item is opened to collect such patches for convenience. This patch corrects: - if an attached text is composed by win notepad, it has no charset specified and actual charset may be different from message/list charset. This sometimes cause error in composing digest message. - sometimes, null charset is represented by '' as well as None. - embedded rfc-2822 message is lost if you don't use msg.walk() - special problem with japanese charsets. - t (stringfied part) may be None which you can't append a '\n'. ---------------------------------------------------------------------- Comment By: Bernhard Reiter (ber) Date: 2004-09-13 20:23 Message: Logged In: YES user_id=113859 The patch looks better, but I probably can only test it when I updated my Mailman patches again. I have directly send you an email that should trigger the bug so you can test. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-09-12 01:45 Message: Logged In: YES user_id=67709 Sorry for the problem. I have updated this patch (2004-09-12 version) Please try and report this patch because I can't fully reproduce the problem (in Japanese environment). ---------------------------------------------------------------------- Comment By: Bernhard Reiter (ber) Date: 2004-09-11 20:04 Message: Logged In: YES user_id=113859 scrubber.patch 2004-08-24 has a problem. Charset(lcset).output_charset can return None according to the documentation. E.g. when no conversion is needed. This would assign Non to lcset_out . Later this leads to an exception in try: if len(charset) == 0: charset = 'us-ascii' t = t.encode(charset, 'replace') except (UnicodeError, LookupError, ValueError): t = t.encode(lcset, 'replace') because: TypeError: len() of unsized object ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-08-24 09:58 Message: Logged In: YES user_id=67709 added a fix for the case of lcset_out <> lcset. ---------------------------------------------------------------------- Comment By: Bernhard Reiter (ber) Date: 2004-04-14 20:53 Message: Logged In: YES user_id=113859 Thanks for working on the patch. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-02-25 11:42 Message: Logged In: YES user_id=67709 uploading revised patch. Now fixes a few more bugs which try to decode scrub plain text message and result in mojibake. Also, japanese filename tend to become so long that system limit may exceeded because of mime encoding, so add an option not to use the filename in the message but to use 'attachment' as filename. Because this patch spans two files (Defaults.py.in and Handlers/Scrubber.py) you have to cd mailman and patch -p1 < this_patch. (Well, I think it is -p1. If it didn't work, try -p0 ;-) ---------------------------------------------------------------------- Comment By: Jonathan Larmour (jifl) Date: 2004-02-22 18:25 Message: Logged In: YES user_id=817601 I strongly recommend applying this patch. I received a mail bounce on a list with an empty charset in a part (i.e. "charset=") and it caused /var/mailman/cron/senddigest and thus all digest processing to fail because of this error: Traceback (most recent call last): File "/var/mailman/cron/senddigests", line 94, in ? main() File "/var/mailman/cron/senddigests", line 86, in main mlist.send_digest_now() File "/var/mailman/Mailman/Digester.py", line 60, in send_digest_now ToDigest.send_digests(self, mboxfp) File "/var/mailman/Mailman/Handlers/ToDigest.py", line 123, in send_digests send_i18n_digests(mlist, mboxfp) File "/var/mailman/Mailman/Handlers/ToDigest.py", line 295, in send_i18n_digests msg = scrubber(mlist, msg) File "/var/mailman/Mailman/Handlers/Scrubber.py", line 308, in process t = t.encode(charset, 'replace') File "/usr/lib/python2.2/encodings/__init__.py", line 51, in search_function mod = __import__(modname,globals(),locals(),'*') which is something this patch fixes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=891491&group_id=103 From noreply at sourceforge.net Tue Sep 14 02:25:26 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 14 02:25:34 2004 Subject: [ mailman-Patches-891491 ] Scrubber.py patch Message-ID: Patches item #891491, was opened at 2004-02-06 01:26 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=891491&group_id=103 Category: Pipermail Group: Mailman 2.1 Status: Open Resolution: None Priority: 8 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: Scrubber.py patch Initial Comment: Scrubber.py has number of bugs for processing various types of attachment and languages and many have submitted patches to fix them. This patch item is opened to collect such patches for convenience. This patch corrects: - if an attached text is composed by win notepad, it has no charset specified and actual charset may be different from message/list charset. This sometimes cause error in composing digest message. - sometimes, null charset is represented by '' as well as None. - embedded rfc-2822 message is lost if you don't use msg.walk() - special problem with japanese charsets. - t (stringfied part) may be None which you can't append a '\n'. ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-09-14 00:25 Message: Logged In: YES user_id=67709 Your sample email did not reproduce error. Anyway, I managed to make a message which can cause the error and confirmed the last fix was valid. Thank you for your cooperation. ---------------------------------------------------------------------- Comment By: Bernhard Reiter (ber) Date: 2004-09-13 18:23 Message: Logged In: YES user_id=113859 The patch looks better, but I probably can only test it when I updated my Mailman patches again. I have directly send you an email that should trigger the bug so you can test. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-09-11 23:45 Message: Logged In: YES user_id=67709 Sorry for the problem. I have updated this patch (2004-09-12 version) Please try and report this patch because I can't fully reproduce the problem (in Japanese environment). ---------------------------------------------------------------------- Comment By: Bernhard Reiter (ber) Date: 2004-09-11 18:04 Message: Logged In: YES user_id=113859 scrubber.patch 2004-08-24 has a problem. Charset(lcset).output_charset can return None according to the documentation. E.g. when no conversion is needed. This would assign Non to lcset_out . Later this leads to an exception in try: if len(charset) == 0: charset = 'us-ascii' t = t.encode(charset, 'replace') except (UnicodeError, LookupError, ValueError): t = t.encode(lcset, 'replace') because: TypeError: len() of unsized object ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-08-24 07:58 Message: Logged In: YES user_id=67709 added a fix for the case of lcset_out <> lcset. ---------------------------------------------------------------------- Comment By: Bernhard Reiter (ber) Date: 2004-04-14 18:53 Message: Logged In: YES user_id=113859 Thanks for working on the patch. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-02-25 10:42 Message: Logged In: YES user_id=67709 uploading revised patch. Now fixes a few more bugs which try to decode scrub plain text message and result in mojibake. Also, japanese filename tend to become so long that system limit may exceeded because of mime encoding, so add an option not to use the filename in the message but to use 'attachment' as filename. Because this patch spans two files (Defaults.py.in and Handlers/Scrubber.py) you have to cd mailman and patch -p1 < this_patch. (Well, I think it is -p1. If it didn't work, try -p0 ;-) ---------------------------------------------------------------------- Comment By: Jonathan Larmour (jifl) Date: 2004-02-22 17:25 Message: Logged In: YES user_id=817601 I strongly recommend applying this patch. I received a mail bounce on a list with an empty charset in a part (i.e. "charset=") and it caused /var/mailman/cron/senddigest and thus all digest processing to fail because of this error: Traceback (most recent call last): File "/var/mailman/cron/senddigests", line 94, in ? main() File "/var/mailman/cron/senddigests", line 86, in main mlist.send_digest_now() File "/var/mailman/Mailman/Digester.py", line 60, in send_digest_now ToDigest.send_digests(self, mboxfp) File "/var/mailman/Mailman/Handlers/ToDigest.py", line 123, in send_digests send_i18n_digests(mlist, mboxfp) File "/var/mailman/Mailman/Handlers/ToDigest.py", line 295, in send_i18n_digests msg = scrubber(mlist, msg) File "/var/mailman/Mailman/Handlers/Scrubber.py", line 308, in process t = t.encode(charset, 'replace') File "/usr/lib/python2.2/encodings/__init__.py", line 51, in search_function mod = __import__(modname,globals(),locals(),'*') which is something this patch fixes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=891491&group_id=103 From noreply at sourceforge.net Tue Sep 14 08:16:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 14 08:16:25 2004 Subject: [ mailman-Patches-601117 ] add sequencial number in subject prefix Message-ID: Patches item #601117, was opened at 2002-08-28 10:07 Message generated for change (Comment added) made by shobhanc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=601117&group_id=103 Category: mail delivery Group: Mailman 2.2 / 3.0 Status: Open Resolution: None Priority: 7 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: add sequencial number in subject prefix Initial Comment: This patch for 'CookHeaders.py' add an ability to add a sequencial number in the subject prefix. You can define a subject prefix like: [listname %d] Then, the subject line of delivered mail becomes: Subject: [listname 123] Hoge hoge When someone replied this mail, mailman receives a messages with: Subject: Re: [listname 123] Hoge hoge Then, this patch removes [listname \d+] part and deliver it with: Subject: [listname 124] Re: Hoge hoge And next, another person replies with Subject: Re: [listname 124] Re: Hoge hoge Then, (magically!) you get: Subject: [listname 125] Re: Hoge hoge Not with Re: Re: Hoge hoge. Looks like complicated but this patch has been working well with Japanese-enhanced Mailman for more than a year. Without %d, this patch works like current version, I believe. ---------------------------------------------------------------------- Comment By: shobhan challa (shobhanc) Date: 2004-09-14 11:16 Message: Logged In: YES user_id=598275 Hi tkikuchi, There are some gibberish text within the patch, are they Japanesh chars..?? If possible can you look at this tracker and give your suggestions.https://sourceforge.net/tracker/index.php?func=detail&aid=1024289&group_id=103&atid=300103 This is basically I want to implement threading in Mailman. Yes Mailman implements threading I agree but when the mail replies are sent using Lotus Notes 5.0.8/5.0.9 the threading doesn't work because Lotus Notes doesn't set the "In-Reply-To" header. Thanks for your time ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-05-25 02:28 Message: Logged In: YES user_id=67709 You can download the patch for 2.1.5 from http://mm.tkikuchi.net/mailman-2.1.5+patch.20040516.gz TK ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-02-08 11:10 Message: Logged In: YES user_id=67709 This patch for 2.1.3 is also applicable to 2.1.4. Though one patch fails to apply, it can safely be neglected. You can also get a newer and more convenient patch at: http://mm.tkikuchi.net/mailman-2.1.4+patch.20040123.gz Cheers, TK ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2003-09-29 06:21 Message: Logged In: YES user_id=67709 Now the patch includes instruction in General admin page. (in detail part). In source dir you should type: patch -p0 < /path/to/seqnum.patch ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2003-05-18 07:01 Message: Logged In: YES user_id=67709 Here is update of my patch for 2.1.2 ---------------------------------------------------------------------- Comment By: Mitchell Marks (jojoba2) Date: 2003-05-17 22:42 Message: Logged In: YES user_id=718482 Is there a version vor MM 2.1.2? I'm trying the older one but doesn't seem to work. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2003-02-27 10:33 Message: Logged In: YES user_id=67709 sorry for daily update but there was an error in i18n handling of '(no subject)' ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2003-02-26 06:25 Message: Logged In: YES user_id=67709 update of patch for 2.1.1 if the subject is all ascii, then cat the prefix and subject before it is instantiated. Hope to solve prefix only subject 1st line. Note: with this patch without $d, Re: [prefix] is now mungled to [prefix] Re:. This is useful if someone post new issue as follow up to old subject like; New subject bah bah was Re: [prefix] foo ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2003-02-14 16:33 Message: Logged In: YES user_id=67709 Hi, I am pleased you like this patch. Here is my current version attached. ---------------------------------------------------------------------- Comment By: Fabio Rossetti (fabiorossetti) Date: 2003-02-14 15:02 Message: Logged In: YES user_id=693899 If you need a quick fix to make the patch work with 2.1.1 here's my take (it's the diff file adapted to work with 2.1.1 CookHeaders.py) 17a18 > (sequence version) 221c222,223 < prefix = mlist.subject_prefix --- > prefix = mlist.subject_prefix.strip(); > if not prefix: return 237,243c239,250 < if prefix and subject: < pattern = re.escape(prefix.strip()) < for decodedsubj, charset in headerbits: < if re.search(pattern, decodedsubj, re.IGNORECASE): < # The subject's already got the prefix, so don't change it < return < del msg['subject'] --- > headerstring = '' > fws = '' > cset = None > for (s, c) in headerbits: > headerstring += fws + s > if c == None or c == 'us-ascii': > fws = ' ' > cset = Utils.GetCharSet(mlist.preferred_language) > else: > fws = '' > cset = c > # Note: searching prefix in subject is REMOVED. (seq version) 245a253,275 > else: > subject = headerstring > # If the subject_prefix contains '%d', it is replaced with the > # mailing list sequential number. Also, if the prefix is closed with > # [],(), or {}, the prefix in the responding post subject will be cared. > # sequential number format allows '%05d' like pattern. > p = re.compile('%\d*d') > if p.search(prefix,1): > # prefix have number, so we should search prefix w/number > # in subject. > prefix_pattern = p.sub(r'\s*\d+\s*', prefix) > else: > prefix_pattern = prefix > prefix_pattern = re.sub('([\[\(\{])', '\\\g<1>', prefix_pattern) > subject = re.sub(prefix_pattern, '', subject) > subject = re.compile('(RE:\s*)+', re.I).sub('Re: ', subject, 1) > # and substitute %d in prefix with post_id > try: > prefix = prefix % mlist.post_id > except: > pass > # Note that trailing space was stripped in seq version (TK) > prefix += ' ' 248,262c278,288 < for s, c in headerbits: < # Once again, convert the string to unicode. < if c is None: < c = Charset('iso-8859-1') < if not isinstance(c, Charset): < c = Charset(c) < if not _isunicode(s): < codec = c.input_codec or 'ascii' < try: < s = unicode(s, codec, 'replace') < except LookupError: < # Unknown codec, is this default reasonable? < s = unicode(s, Utils.GetCharSet (mlist.preferred_language), < 'replace') < h.append(s, c) --- > # in seq version, subject header is already concatnated > if not _isunicode(subject): > try: > subject = unicode(subject, cset, 'replace') > except LookupError: > # unknown codec > cset = Utils.GetCharSet(mlist.preferred_language) > subject = unicode(subject, cset, 'replace') > subject = subject.encode(cset) > h.append(subject, cset) > del msg['subject'] ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2002-12-20 09:31 Message: Logged In: YES user_id=67709 update for 2.1b6+ ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2002-10-31 10:59 Message: Logged In: YES user_id=67709 I have uploaded the patch with the same name as the old one. Please download the upper one because it's newer. Sorry for the inconvenience. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2002-10-31 10:53 Message: Logged In: YES user_id=67709 Patch ID 625482 (i18n List-Id) and this was merged for 2.1b4+ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=601117&group_id=103 From noreply at sourceforge.net Tue Sep 14 14:55:56 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 14 14:55:58 2004 Subject: [ mailman-Patches-1027882 ] filter attachments by filename extensions Message-ID: Patches item #1027882, was opened at 2004-09-14 12:55 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=1027882&group_id=103 Category: mail delivery Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: filter attachments by filename extensions Initial Comment: Mailman's filter attachment feature is useful but many MUA's are sending same application files with different content-type: eg. application/pdf or application/octet-stream for PDF. Viruses also fake the content-type for executables as audio etc. So, we need to filter attachments by filename extensions by which windows assumes their associated applications. This patch enables list owners to define filename extensions to filter (block) or pass the attached file. After applying patch, configure and make install, you may have to 'bin/update -f' to force the list attribute upgrading. You may also have to check the config.pck schema version (DATA_FILE_VERSION) in Version.py and make sure the number is incremented. (90 -> 91) The old number may be different if you have applied other patches. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1027882&group_id=103 From noreply at sourceforge.net Tue Sep 14 15:04:41 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 14 15:04:44 2004 Subject: [ mailman-Patches-1024289 ] Add support for $Orig and $REF for Lotus Notes < 5.0.9 Message-ID: Patches item #1024289, was opened at 2004-09-08 10:35 Message generated for change (Settings changed) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1024289&group_id=103 Category: Pipermail Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: yoda (shobhanc) >Assigned to: Tokio Kikuchi (tkikuchi) Summary: Add support for $Orig and $REF for Lotus Notes < 5.0.9 Initial Comment: Lotus Notes below 6.25 doesnt set the 'In-Reply-To' or 'References' header. but it sets 'Orig' and 'REF' headers. Mailman should be able to process 'Orig' and 'REF' headers if 'In-Reply-To' is not set for Lotus Notes. Does anyone have any idea how to do this..? Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1024289&group_id=103 From noreply at sourceforge.net Tue Sep 14 15:06:11 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 14 15:06:15 2004 Subject: [ mailman-Feature Requests-1024289 ] Add support for $Orig and $REF for Lotus Notes < 5.0.9 Message-ID: Feature Requests item #1024289, was opened at 2004-09-08 10:35 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1024289&group_id=103 >Category: None >Group: None Status: Open Resolution: None Priority: 5 Submitted By: yoda (shobhanc) >Assigned to: Nobody/Anonymous (nobody) Summary: Add support for $Orig and $REF for Lotus Notes < 5.0.9 Initial Comment: Lotus Notes below 6.25 doesnt set the 'In-Reply-To' or 'References' header. but it sets 'Orig' and 'REF' headers. Mailman should be able to process 'Orig' and 'REF' headers if 'In-Reply-To' is not set for Lotus Notes. Does anyone have any idea how to do this..? Thanks ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-09-14 13:06 Message: Logged In: YES user_id=67709 No patch. Requesting a feature. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1024289&group_id=103 From noreply at sourceforge.net Tue Sep 14 16:37:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 14 16:37:19 2004 Subject: [ mailman-Feature Requests-1024289 ] Add support for $Orig and $REF for Lotus Notes < 5.0.9 Message-ID: Feature Requests item #1024289, was opened at 2004-09-08 15:35 Message generated for change (Comment added) made by shobhanc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1024289&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: yoda (shobhanc) Assigned to: Nobody/Anonymous (nobody) Summary: Add support for $Orig and $REF for Lotus Notes < 5.0.9 Initial Comment: Lotus Notes below 6.25 doesnt set the 'In-Reply-To' or 'References' header. but it sets 'Orig' and 'REF' headers. Mailman should be able to process 'Orig' and 'REF' headers if 'In-Reply-To' is not set for Lotus Notes. Does anyone have any idea how to do this..? Thanks ---------------------------------------------------------------------- >Comment By: yoda (shobhanc) Date: 2004-09-14 19:37 Message: Logged In: YES user_id=598275 Thanks tkikuchi, Any idea whats the alternative to thread the mails if $REF header is not set in the reply mail from Lotus Notes, like an autogenerated number be added to the subject line and check the number in the reply mail and generate a thread likewise..?? Thanks for your time. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-09-14 18:06 Message: Logged In: YES user_id=67709 No patch. Requesting a feature. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1024289&group_id=103 From noreply at sourceforge.net Wed Sep 15 04:25:53 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 15 04:25:56 2004 Subject: [ mailman-Feature Requests-1024289 ] Add support for $Orig and $REF for Lotus Notes < 5.0.9 Message-ID: Feature Requests item #1024289, was opened at 2004-09-08 10:35 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1024289&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: yoda (shobhanc) Assigned to: Nobody/Anonymous (nobody) Summary: Add support for $Orig and $REF for Lotus Notes < 5.0.9 Initial Comment: Lotus Notes below 6.25 doesnt set the 'In-Reply-To' or 'References' header. but it sets 'Orig' and 'REF' headers. Mailman should be able to process 'Orig' and 'REF' headers if 'In-Reply-To' is not set for Lotus Notes. Does anyone have any idea how to do this..? Thanks ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-09-15 02:25 Message: Logged In: YES user_id=67709 Sorry but I have no Notes users around. So, this is low priority. I suggest you upload relevant message header example in case some one is interested. ---------------------------------------------------------------------- Comment By: yoda (shobhanc) Date: 2004-09-14 14:37 Message: Logged In: YES user_id=598275 Thanks tkikuchi, Any idea whats the alternative to thread the mails if $REF header is not set in the reply mail from Lotus Notes, like an autogenerated number be added to the subject line and check the number in the reply mail and generate a thread likewise..?? Thanks for your time. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-09-14 13:06 Message: Logged In: YES user_id=67709 No patch. Requesting a feature. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1024289&group_id=103 From noreply at sourceforge.net Wed Sep 15 07:16:37 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 15 07:16:45 2004 Subject: [ mailman-Feature Requests-1024289 ] Add threading support for Lotus Notes < 5.0.9 Message-ID: Feature Requests item #1024289, was opened at 2004-09-08 15:35 Message generated for change (Comment added) made by shobhanc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1024289&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: yoda (shobhanc) Assigned to: Nobody/Anonymous (nobody) >Summary: Add threading support for Lotus Notes < 5.0.9 Initial Comment: Lotus Notes below 6.25 doesnt set the 'In-Reply-To' or 'References' header. but it sets 'Orig' and 'REF' headers. Mailman should be able to process 'Orig' and 'REF' headers if 'In-Reply-To' is not set for Lotus Notes. Does anyone have any idea how to do this..? Thanks ---------------------------------------------------------------------- >Comment By: yoda (shobhanc) Date: 2004-09-15 10:16 Message: Logged In: YES user_id=598275 ok, here are the headers generated by Lotus Notes 5.0.8. 1) The headers of the first mail sent from Lotus Notes: Return-path: Envelope-to: root@sfeng00.lotussoft.com Received: from lotus-testing.com ([11.1.30.111]) by sfeng00.lotussoft.com with esmtp (Exim 3.36 #1 (GForge)) id 1C7RyW-0004Zg-00; Wed, 15 Sep 2004 10:35:00 +0530 Subject: Test mail To: lotus-thread-mail@sfeng00.lotussoft.com Cc: root@sfeng00.lotussoft.com X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: postmaster@lotus-testing.com Date: Wed, 15 Sep 2004 10:33:51 +0530 X-MIMETrack: Serialize by Router on lotus-testing/LOTUSTesting(Release 5.0.8 |June 18, 2001) at 09/15/2004 10:33:51 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii This is the test mail 2) The reply headers for the original mail from Lotus Notes: Return-path: Envelope-to: root@sfeng00.lotussoft.com Received: from lotus-testing.com ([11.1.30.111]) by sfeng00.lotussoft.com with esmtp (Exim 3.36 #1 (GForge)) id 1C7S3q-0004an-00; Wed, 15 Sep 2004 10:40:30 +0530 Subject: Re: [Lotus-thread-mail] Test mail To: postmaster@lotus-testing.com Cc: lotus-thread-mail@sfeng00.lotussoft.com, lotus-thread-mail-admin@sfeng00.lotussoft.com, X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: postmaster@lotus-testing.com Date: Wed, 15 Sep 2004 10:39:21 +0530 X-MIMETrack: Serialize by Router on lotus-testing/LOTUSTesting(Release 5.0.8 |June 18, 2001) at 09/15/2004 10:39:21 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Reply to the test mail. Thanks ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-09-15 07:25 Message: Logged In: YES user_id=67709 Sorry but I have no Notes users around. So, this is low priority. I suggest you upload relevant message header example in case some one is interested. ---------------------------------------------------------------------- Comment By: yoda (shobhanc) Date: 2004-09-14 19:37 Message: Logged In: YES user_id=598275 Thanks tkikuchi, Any idea whats the alternative to thread the mails if $REF header is not set in the reply mail from Lotus Notes, like an autogenerated number be added to the subject line and check the number in the reply mail and generate a thread likewise..?? Thanks for your time. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-09-14 18:06 Message: Logged In: YES user_id=67709 No patch. Requesting a feature. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1024289&group_id=103 From noreply at sourceforge.net Wed Sep 15 10:08:11 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 15 10:08:22 2004 Subject: [ mailman-Patches-891491 ] Scrubber.py patch Message-ID: Patches item #891491, was opened at 2004-02-06 02:26 Message generated for change (Comment added) made by ber You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=891491&group_id=103 Category: Pipermail Group: Mailman 2.1 Status: Open Resolution: None Priority: 8 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: Scrubber.py patch Initial Comment: Scrubber.py has number of bugs for processing various types of attachment and languages and many have submitted patches to fix them. This patch item is opened to collect such patches for convenience. This patch corrects: - if an attached text is composed by win notepad, it has no charset specified and actual charset may be different from message/list charset. This sometimes cause error in composing digest message. - sometimes, null charset is represented by '' as well as None. - embedded rfc-2822 message is lost if you don't use msg.walk() - special problem with japanese charsets. - t (stringfied part) may be None which you can't append a '\n'. ---------------------------------------------------------------------- Comment By: Bernhard Reiter (ber) Date: 2004-09-15 10:08 Message: Logged In: YES user_id=113859 Maybe that was because I was using my patches for preventing to break the signature, too. Those patches keep the charset lines correct and not reformatted. However that is just a guess. Thanks for testing and fixing the patch. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-09-14 02:25 Message: Logged In: YES user_id=67709 Your sample email did not reproduce error. Anyway, I managed to make a message which can cause the error and confirmed the last fix was valid. Thank you for your cooperation. ---------------------------------------------------------------------- Comment By: Bernhard Reiter (ber) Date: 2004-09-13 20:23 Message: Logged In: YES user_id=113859 The patch looks better, but I probably can only test it when I updated my Mailman patches again. I have directly send you an email that should trigger the bug so you can test. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-09-12 01:45 Message: Logged In: YES user_id=67709 Sorry for the problem. I have updated this patch (2004-09-12 version) Please try and report this patch because I can't fully reproduce the problem (in Japanese environment). ---------------------------------------------------------------------- Comment By: Bernhard Reiter (ber) Date: 2004-09-11 20:04 Message: Logged In: YES user_id=113859 scrubber.patch 2004-08-24 has a problem. Charset(lcset).output_charset can return None according to the documentation. E.g. when no conversion is needed. This would assign Non to lcset_out . Later this leads to an exception in try: if len(charset) == 0: charset = 'us-ascii' t = t.encode(charset, 'replace') except (UnicodeError, LookupError, ValueError): t = t.encode(lcset, 'replace') because: TypeError: len() of unsized object ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-08-24 09:58 Message: Logged In: YES user_id=67709 added a fix for the case of lcset_out <> lcset. ---------------------------------------------------------------------- Comment By: Bernhard Reiter (ber) Date: 2004-04-14 20:53 Message: Logged In: YES user_id=113859 Thanks for working on the patch. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-02-25 11:42 Message: Logged In: YES user_id=67709 uploading revised patch. Now fixes a few more bugs which try to decode scrub plain text message and result in mojibake. Also, japanese filename tend to become so long that system limit may exceeded because of mime encoding, so add an option not to use the filename in the message but to use 'attachment' as filename. Because this patch spans two files (Defaults.py.in and Handlers/Scrubber.py) you have to cd mailman and patch -p1 < this_patch. (Well, I think it is -p1. If it didn't work, try -p0 ;-) ---------------------------------------------------------------------- Comment By: Jonathan Larmour (jifl) Date: 2004-02-22 18:25 Message: Logged In: YES user_id=817601 I strongly recommend applying this patch. I received a mail bounce on a list with an empty charset in a part (i.e. "charset=") and it caused /var/mailman/cron/senddigest and thus all digest processing to fail because of this error: Traceback (most recent call last): File "/var/mailman/cron/senddigests", line 94, in ? main() File "/var/mailman/cron/senddigests", line 86, in main mlist.send_digest_now() File "/var/mailman/Mailman/Digester.py", line 60, in send_digest_now ToDigest.send_digests(self, mboxfp) File "/var/mailman/Mailman/Handlers/ToDigest.py", line 123, in send_digests send_i18n_digests(mlist, mboxfp) File "/var/mailman/Mailman/Handlers/ToDigest.py", line 295, in send_i18n_digests msg = scrubber(mlist, msg) File "/var/mailman/Mailman/Handlers/Scrubber.py", line 308, in process t = t.encode(charset, 'replace') File "/usr/lib/python2.2/encodings/__init__.py", line 51, in search_function mod = __import__(modname,globals(),locals(),'*') which is something this patch fixes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=891491&group_id=103 From noreply at sourceforge.net Wed Sep 15 14:46:55 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 15 14:47:08 2004 Subject: [ mailman-Bugs-1013079 ] spam filters get removed when changing other privacy pages Message-ID: Bugs item #1013079, was opened at 2004-08-20 19:23 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1013079&group_id=103 Category: security/privacy Group: 2.1 beta >Status: Closed Resolution: None Priority: 5 Submitted By: Ralph Siemsen (ralphs) Assigned to: Nobody/Anonymous (nobody) Summary: spam filters get removed when changing other privacy pages Initial Comment: Error report on behalf of Russell King (rmk+bugzilla@arm.linux.org.uk): Description of problem: If you enter some header_filter_rules in the mailman admin pages (Privacy->Spam filters) and click "submit" they are added to the list configuration database. However, if you now go to one of the other Privacy pages and click "submit" and return to the Spam Filters page, you'll find that your header_filter_rules settings have been removed. This appears to be caused by the handleForm function in ~mailman/Mailman/Gui/Privacy.py not checking to see which subsection is being submitted before processing the data for and setting the mlist.header_filter_rules list configuration variable. Version-Release number of selected component (if applicable): mailman-2.1.5-7 How reproducible: Always Steps to Reproduce: 1. Create list. 2. Go to the Privacy->Spam filters page, add some header_filter_rules and hit submit. 3. Go to the Privacy->Sender filters page but don't hit submit 4. Go back to Spam filters and note that they're still present 5. Return to Sender filters and hit submit 6. Go back to Spam filters and note that they've been removed. Actual Results: All spam filters are removed. Expected Results: Spam filter settings should be retained. Also reported to redhat bugzilla: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=130479 ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-09-15 12:46 Message: Logged In: YES user_id=67709 Fixed in CVS Gui/Privacy.py Revision 2.15.2.4 ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-09-01 01:31 Message: Logged In: YES user_id=67709 a patch was uploaded (id:1020102) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1013079&group_id=103 From noreply at sourceforge.net Wed Sep 15 14:48:45 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 15 14:48:50 2004 Subject: [ mailman-Bugs-1020013 ] spam filters get removed when changing other privacy pages Message-ID: Bugs item #1020013, was opened at 2004-08-31 21:10 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1020013&group_id=103 Category: Web/CGI Group: 2.1 (stable) >Status: Closed Resolution: None Priority: 5 Submitted By: John Dennis (johndennis) Assigned to: Nobody/Anonymous (nobody) Summary: spam filters get removed when changing other privacy pages Initial Comment: This was filed in the Red Hat bugzilla as: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=130479 Promoting to upstream Summary is: If you enter some header_filter_rules in the mailman admin pages (Privacy->Spam filters) and click "submit" they are added to the list configuration database. However, if you now go to one of the other Privacy pages and click "submit" and return to the Spam Filters page, you'll find that your header_filter_rules settings have been removed. This appears to be caused by the handleForm function in ~mailman/Mailman/Gui/Privacy.py not checking to see which subsection is being submitted before processing the data for and setting the mlist.header_filter_rules list configuration variable. Version-Release number of selected component (if applicable): mailman-2.1.5 How reproducible: Always Steps to Reproduce: 1. Create list. 2. Go to the Privacy->Spam filters page, add some header_filter_rules and hit submit. 3. Go to the Privacy->Sender filters page but don't hit submit 4. Go back to Spam filters and note that they're still present 5. Return to Sender filters and hit submit 6. Go back to Spam filters and note that they've been removed. Actual Results: All spam filters are removed. Expected Results: Spam filter settings should be retained. ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-09-15 12:48 Message: Logged In: YES user_id=67709 Fixed in CVS Gui/Privacy.py Revision 2.15.2.4 ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-09-01 01:33 Message: Logged In: YES user_id=67709 a patch is uploaded (id 1020102) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1020013&group_id=103 From noreply at sourceforge.net Wed Sep 15 14:49:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 15 14:49:53 2004 Subject: [ mailman-Patches-1020102 ] fix for spam filter removed (bugid:1013079/1020013) Message-ID: Patches item #1020102, was opened at 2004-09-01 01:27 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1020102&group_id=103 Category: Web UI Group: Mailman 2.1 >Status: Closed Resolution: None Priority: 5 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: fix for spam filter removed (bugid:1013079/1020013) Initial Comment: spam rules should be updated only if the subcategory is 'spam'. The patch looks weird but it adds only one 'if' statement and indent for the if block. ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-09-15 12:49 Message: Logged In: YES user_id=67709 Fixed in CVS Gui/Privacy.py Revision 2.15.2.4 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1020102&group_id=103 From noreply at sourceforge.net Wed Sep 15 15:27:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 15 15:27:39 2004 Subject: [ mailman-Patches-755045 ] discard all button for pending posts administration Message-ID: Patches item #755045, was opened at 2003-06-15 22:22 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=755045&group_id=103 Category: list administration Group: Mailman 2.1 >Status: Closed Resolution: None Priority: 5 Submitted By: matze (indygena) Assigned to: Nobody/Anonymous (nobody) Summary: discard all button for pending posts administration Initial Comment: adds a 'discard all' button at the bottom of the pending posts page, usefull for lists with high spam rate. not sure if this feature is of general interest, people in the projects where we applied this patch feel confortable with it. ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-09-15 13:27 Message: Logged In: YES user_id=67709 Closing this item because similar feature is included in 2.1.5 ---------------------------------------------------------------------- Comment By: Zoran Dzelajlija (followme) Date: 2004-07-05 13:12 Message: Logged In: YES user_id=106281 Could this perhaps be closed as it's quite similar in effect to 810675, which was included in 2.1.5? ---------------------------------------------------------------------- Comment By: Pabs (pabs3) Date: 2004-01-28 11:15 Message: Logged In: YES user_id=35028 ppl interested in this may also want the default action patch: http://sourceforge.net/tracker/index.php?func=detail&aid=886124&group_id=103&atid=300103 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=755045&group_id=103 From noreply at sourceforge.net Wed Sep 15 23:16:37 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 15 23:16:41 2004 Subject: [ mailman-Bugs-1028829 ] Memory error???? Message-ID: Bugs item #1028829, was opened at 2004-09-15 23:16 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=1028829&group_id=103 Category: mail delivery Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: tyro (sgasshole) Assigned to: Nobody/Anonymous (nobody) Summary: Memory error???? Initial Comment: Hiya, we have a list of approx. 38000 subscribers, here the result of a post: 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/local/mailman/scripts/driver", line 87, in run_main main() File "/usr/local/mailman/Mailman/Cgi/admindb.py", line 248, in main mlist.Save() File "/usr/local/mailman/Mailman/MailList.py", line 525, in Save self.__save(dict) File "/usr/local/mailman/Mailman/MailList.py", line 482, in __save cPickle.dump(dict, fp, 1) MemoryError ---------------------------------------------------------------------------- ---- Python information: Variable Value sys.version 2.3.4 (#1, Aug 31 2004, 14:32:37) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] sys.executable /usr/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://www.films-festivals.com/mailman/admin/newsletter SERVER_SOFTWARE Apache/1.3.11 (Unix) ApacheJServ/1.1 PHP/4.0.5 mod_perl/1.25 mod_layout/2.5 SCRIPT_NAME /mailman/admindb QUERY_STRING SERVER_SIGNATURE Apache/1.3.11 Server at www.films-festivals.com Port 80 REQUEST_METHOD GET PATH_INFO /newsletter SERVER_PROTOCOL HTTP/1.1 HTTP_EXTENSION Security/Remote-Passphrase LANG en_US HTTP_USER_AGENT Mozilla/4.0 (compatible; MSIE 6.0; Windows 98; .NET CLR 1.1.4322) HTTP_CONNECTION Keep-Alive HTTP_COOKIE ffctest+admin=280200000069b0f64741732800000037333062626535303966656266313131 663536326638343064373139386561646262353963323936; newsletter+admin=2802000000699b374841732800000065363864303630366539356465616 165336437326566393561366261323135653863623465336163 SERVER_NAME www.films-festivals.com REMOTE_ADDR 81.64.76.173 SYBASE /opt/sybase-11.9.2/ PATH_TRANSLATED /home/ffanet/htdocs/newsletter SERVER_PORT 80 SERVER_ADDR 62.210.160.22 DOCUMENT_ROOT /home/ffanet/htdocs PYTHONPATH /usr/local/mailman SCRIPT_FILENAME /usr/local/mailman/cgi-bin/admindb SERVER_ADMIN sg@a34.net HTTP_HOST www.films-festivals.com REQUEST_URI /mailman/admindb/newsletter HTTP_ACCEPT image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-powerpoint, application/vnd.ms-excel, application/msword, application/x-shockwave-flash, */* GATEWAY_INTERFACE CGI/1.1 REMOTE_PORT 3499 HTTP_ACCEPT_LANGUAGE fr REMOTE_HOST m173.net81-64-76.noos.fr HTTP_ACCEPT_ENCODING gzip, deflate ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1028829&group_id=103 From noreply at sourceforge.net Thu Sep 16 01:45:45 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 16 01:45:50 2004 Subject: [ mailman-Bugs-1025372 ] empty Cc: Message-ID: Bugs item #1025372, was opened at 2004-09-09 20:02 Message generated for change (Comment added) made by potstickr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1025372&group_id=103 Category: mail delivery Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Rob Ellis (robellis) Assigned to: Nobody/Anonymous (nobody) Summary: empty Cc: Initial Comment: In lists migrated from 2.0.13, new messages without a Cc: header end up with an empty one when delivered by mailman (2.1.5). Freshly created lists don't seem to have the problem ? This is on a freebsd 4 stable machine running postfix 2.0.19,1 with mailman set up to use SMTPDirect. Python 2.3.3. The attached patch to AvoidDuplicates.py/CookHeaders.py seems to fix it... - rob ---------------------------------------------------------------------- Comment By: Morgan Fletcher (potstickr) Date: 2004-09-15 23:45 Message: Logged In: YES user_id=459672 I tried this patch on a netbsd machine recently upgraded from 2.0.8 to 2.1.5. After applying the patch and a 'make install' I still see the empty Cc header. This bug is causing some trouble for some our list members, so I was really hoping this fix would work. Let me know if you need debugging info or testing of possible patches. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1025372&group_id=103 From noreply at sourceforge.net Thu Sep 16 01:53:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 16 01:53:19 2004 Subject: [ mailman-Bugs-1025372 ] empty Cc: Message-ID: Bugs item #1025372, was opened at 2004-09-09 20:02 Message generated for change (Comment added) made by potstickr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1025372&group_id=103 Category: mail delivery Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Rob Ellis (robellis) Assigned to: Nobody/Anonymous (nobody) Summary: empty Cc: Initial Comment: In lists migrated from 2.0.13, new messages without a Cc: header end up with an empty one when delivered by mailman (2.1.5). Freshly created lists don't seem to have the problem ? This is on a freebsd 4 stable machine running postfix 2.0.19,1 with mailman set up to use SMTPDirect. Python 2.3.3. The attached patch to AvoidDuplicates.py/CookHeaders.py seems to fix it... - rob ---------------------------------------------------------------------- Comment By: Morgan Fletcher (potstickr) Date: 2004-09-15 23:53 Message: Logged In: YES user_id=459672 Er, spoke too soon. Did a 'mailmanctl restart' and then sent a test message, and did not see an empty cc header. Thanks! ---------------------------------------------------------------------- Comment By: Morgan Fletcher (potstickr) Date: 2004-09-15 23:45 Message: Logged In: YES user_id=459672 I tried this patch on a netbsd machine recently upgraded from 2.0.8 to 2.1.5. After applying the patch and a 'make install' I still see the empty Cc header. This bug is causing some trouble for some our list members, so I was really hoping this fix would work. Let me know if you need debugging info or testing of possible patches. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1025372&group_id=103 From noreply at sourceforge.net Thu Sep 16 02:27:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 16 02:33:42 2004 Subject: [ mailman-Patches-665569 ] make Postfix bounce detection work with newer postfix Message-ID: Patches item #665569, was opened at 2003-01-10 09:33 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=665569&group_id=103 Category: bounce processing Group: Mailman 2.1 >Status: Closed Resolution: None Priority: 5 Submitted By: James Henstridge (jhenstridge) Assigned to: Nobody/Anonymous (nobody) Summary: make Postfix bounce detection work with newer postfix Initial Comment: Mailman does not recognise bounce messages from newer versions of Postfix. The content-type header on bounce messages looks like this: Content-Type: multipart/report; report-type=delivery-status; boundary="2892E4C0CF.1042189077/quoll.daa.com.au" Mailman only looks for bounce messages with type multipart/mixed, so skips them. The simple solution is to check for both content types (which should allow mailman to continue to work with old postfixes. The attached patch is against 2.0.x (haven't upgraded to MM2.1 yet), but the code is almost identical for 2.1 so the patch should be easy to apply. ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-09-16 00:27 Message: Logged In: YES user_id=67709 fixed in the CVS (Postfix.py 2.6.2.2) ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2003-03-16 02:57 Message: Logged In: YES user_id=146903 Not sure if this code is applicable to MM2.1. I guess the generic DSN bounce detection handles it. If there is another MM2.0.x bug fix release, it may be nice to apply. ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2003-01-10 09:36 Message: Logged In: YES user_id=146903 Hmm. It seems to have lost the attachment ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=665569&group_id=103 From noreply at sourceforge.net Thu Sep 16 03:06:46 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 16 03:06:51 2004 Subject: [ mailman-Patches-970383 ] moderator -1 admin requests pending Message-ID: Patches item #970383, was opened at 2004-06-10 13:57 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=970383&group_id=103 Category: list administration Group: Mailman 2.1 >Status: Closed Resolution: None Priority: 5 Submitted By: Jim Tittsler (jtittsler) Assigned to: Nobody/Anonymous (nobody) Summary: moderator -1 admin requests pending Initial Comment: ListAdmin.NumRequestsPending() presumes that the request database always has at least one entry... a dummy "request" containing the version number of the request database. bin/newlist does not create a request database for each list, so the moderator gets a daily mail saying there are -1 requests pending. I propose that when __opendb() fails because the file didn't exist, the version number be added to the __db dict. Two additional points: - perhaps __open_db should ALWAYS add the version to the db, in case a request.pck somehow was created without a version key (especially since the version isn't currently checked) - the closedb setting of the version could *probably* be safely removed ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-09-16 01:06 Message: Logged In: YES user_id=67709 fixed in CVS: revision: 2.41.2.7 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=970383&group_id=103 From noreply at sourceforge.net Thu Sep 16 03:30:12 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 16 03:30:16 2004 Subject: [ mailman-Patches-1025372 ] empty Cc: Message-ID: Patches item #1025372, was opened at 2004-09-09 20:02 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1025372&group_id=103 >Category: None >Group: None Status: Open Resolution: None >Priority: 7 Submitted By: Rob Ellis (robellis) Assigned to: Nobody/Anonymous (nobody) Summary: empty Cc: Initial Comment: In lists migrated from 2.0.13, new messages without a Cc: header end up with an empty one when delivered by mailman (2.1.5). Freshly created lists don't seem to have the problem ? This is on a freebsd 4 stable machine running postfix 2.0.19,1 with mailman set up to use SMTPDirect. Python 2.3.3. The attached patch to AvoidDuplicates.py/CookHeaders.py seems to fix it... - rob ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-09-16 01:30 Message: Logged In: YES user_id=67709 Okey, I take this one for testing at my site and merge into CVS if no problem. Looks like the latter part (CookHeaders.py) is unnecessary because at least one cc is registered. ---------------------------------------------------------------------- Comment By: Morgan Fletcher (potstickr) Date: 2004-09-15 23:53 Message: Logged In: YES user_id=459672 Er, spoke too soon. Did a 'mailmanctl restart' and then sent a test message, and did not see an empty cc header. Thanks! ---------------------------------------------------------------------- Comment By: Morgan Fletcher (potstickr) Date: 2004-09-15 23:45 Message: Logged In: YES user_id=459672 I tried this patch on a netbsd machine recently upgraded from 2.0.8 to 2.1.5. After applying the patch and a 'make install' I still see the empty Cc header. This bug is causing some trouble for some our list members, so I was really hoping this fix would work. Let me know if you need debugging info or testing of possible patches. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1025372&group_id=103 From noreply at sourceforge.net Thu Sep 16 03:33:13 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 16 03:33:17 2004 Subject: [ mailman-Patches-1025372 ] empty Cc: Message-ID: Patches item #1025372, was opened at 2004-09-09 20:02 Message generated for change (Settings changed) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1025372&group_id=103 >Category: mail delivery >Group: Mailman 2.1 Status: Open >Resolution: Later Priority: 7 Submitted By: Rob Ellis (robellis) >Assigned to: Tokio Kikuchi (tkikuchi) Summary: empty Cc: Initial Comment: In lists migrated from 2.0.13, new messages without a Cc: header end up with an empty one when delivered by mailman (2.1.5). Freshly created lists don't seem to have the problem ? This is on a freebsd 4 stable machine running postfix 2.0.19,1 with mailman set up to use SMTPDirect. Python 2.3.3. The attached patch to AvoidDuplicates.py/CookHeaders.py seems to fix it... - rob ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-09-16 01:30 Message: Logged In: YES user_id=67709 Okey, I take this one for testing at my site and merge into CVS if no problem. Looks like the latter part (CookHeaders.py) is unnecessary because at least one cc is registered. ---------------------------------------------------------------------- Comment By: Morgan Fletcher (potstickr) Date: 2004-09-15 23:53 Message: Logged In: YES user_id=459672 Er, spoke too soon. Did a 'mailmanctl restart' and then sent a test message, and did not see an empty cc header. Thanks! ---------------------------------------------------------------------- Comment By: Morgan Fletcher (potstickr) Date: 2004-09-15 23:45 Message: Logged In: YES user_id=459672 I tried this patch on a netbsd machine recently upgraded from 2.0.8 to 2.1.5. After applying the patch and a 'make install' I still see the empty Cc header. This bug is causing some trouble for some our list members, so I was really hoping this fix would work. Let me know if you need debugging info or testing of possible patches. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1025372&group_id=103 From noreply at sourceforge.net Thu Sep 16 06:40:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 16 06:40:37 2004 Subject: [ mailman-Bugs-1028975 ] checkdbs remainders for not existing requests Message-ID: Bugs item #1028975, was opened at 2004-09-16 06:40 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=1028975&group_id=103 Category: command line scripts Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Alberto Marconi (albertomarconi) Assigned to: Nobody/Anonymous (nobody) Summary: checkdbs remainders for not existing requests Initial Comment: checkdbs sends remainders to list owners concerning pending requests which do not exist. It happens on new lists which are missing the request.pck file. The count of the pending requests is -1. The NumRequestsPending() function returns -1 if the request.pck file is missing. The following patch correct this problem: --- checkdbs.orig 2004-09-13 18:36:31.000000000 +0200 +++ checkdbs 2004-09-16 05:33:27.000000000 +0200 @@ -96,7 +96,7 @@ del mlist.hold_and_cmd_autoresponses [sender] # Only here have we changed the list's database mlist.Save() - if count: + if count > 0: i18n.set_language(mlist.preferred_language) realname = mlist.real_name text = Utils.maketext( ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1028975&group_id=103 From noreply at sourceforge.net Thu Sep 16 17:31:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 16 17:32:03 2004 Subject: [ mailman-Patches-1029275 ] Maximum number of members per list. Message-ID: Patches item #1029275, was opened at 2004-09-16 12:31 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=1029275&group_id=103 Category: list administration Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: iamstratus (iamstratus) Assigned to: Nobody/Anonymous (nobody) Summary: Maximum number of members per list. Initial Comment: With this patch site administrators can control the maximum number of members per list. I really need this feature but it's my first attempt changing mailman code so i don't known if it's the best way to handle this situation and if a list administrator can override 'max_members'.Comments, anyone? I've patched mailman 2.1.5 and the mailman 2.1.5 official debian source package (through dpatch) and it seems to be working fine on my test server. The lists that doesn't have 'max_members'[*] or where it's 0 are unlimited and i've created (based on change_pw) the change_maxmembers script where you can change and print the 'max_members' attribute from a list (or many). [*] = How the new attributes situation is handled? On upgrade you add what's missing with the upgrade script or what? Hope that helps, Gustavo Franco -- RITS - http://www.rits.org.br/ p.s: It's being accepted i guess that we can ack some of the suggestions at the RFE #403310. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1029275&group_id=103 From noreply at sourceforge.net Fri Sep 17 05:03:00 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 17 05:03:14 2004 Subject: [ mailman-Patches-891491 ] Scrubber.py patch Message-ID: Patches item #891491, was opened at 2004-02-06 01:26 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=891491&group_id=103 Category: Pipermail Group: Mailman 2.1 >Status: Closed Resolution: None Priority: 8 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: Scrubber.py patch Initial Comment: Scrubber.py has number of bugs for processing various types of attachment and languages and many have submitted patches to fix them. This patch item is opened to collect such patches for convenience. This patch corrects: - if an attached text is composed by win notepad, it has no charset specified and actual charset may be different from message/list charset. This sometimes cause error in composing digest message. - sometimes, null charset is represented by '' as well as None. - embedded rfc-2822 message is lost if you don't use msg.walk() - special problem with japanese charsets. - t (stringfied part) may be None which you can't append a '\n'. ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-09-17 03:02 Message: Logged In: YES user_id=67709 Merged in CVS. Defaults.py.in new revision: 2.112.2.17; Scrubber.py new revision: 2.18.2.7; ---------------------------------------------------------------------- Comment By: Bernhard Reiter (ber) Date: 2004-09-15 08:08 Message: Logged In: YES user_id=113859 Maybe that was because I was using my patches for preventing to break the signature, too. Those patches keep the charset lines correct and not reformatted. However that is just a guess. Thanks for testing and fixing the patch. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-09-14 00:25 Message: Logged In: YES user_id=67709 Your sample email did not reproduce error. Anyway, I managed to make a message which can cause the error and confirmed the last fix was valid. Thank you for your cooperation. ---------------------------------------------------------------------- Comment By: Bernhard Reiter (ber) Date: 2004-09-13 18:23 Message: Logged In: YES user_id=113859 The patch looks better, but I probably can only test it when I updated my Mailman patches again. I have directly send you an email that should trigger the bug so you can test. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-09-11 23:45 Message: Logged In: YES user_id=67709 Sorry for the problem. I have updated this patch (2004-09-12 version) Please try and report this patch because I can't fully reproduce the problem (in Japanese environment). ---------------------------------------------------------------------- Comment By: Bernhard Reiter (ber) Date: 2004-09-11 18:04 Message: Logged In: YES user_id=113859 scrubber.patch 2004-08-24 has a problem. Charset(lcset).output_charset can return None according to the documentation. E.g. when no conversion is needed. This would assign Non to lcset_out . Later this leads to an exception in try: if len(charset) == 0: charset = 'us-ascii' t = t.encode(charset, 'replace') except (UnicodeError, LookupError, ValueError): t = t.encode(lcset, 'replace') because: TypeError: len() of unsized object ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-08-24 07:58 Message: Logged In: YES user_id=67709 added a fix for the case of lcset_out <> lcset. ---------------------------------------------------------------------- Comment By: Bernhard Reiter (ber) Date: 2004-04-14 18:53 Message: Logged In: YES user_id=113859 Thanks for working on the patch. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-02-25 10:42 Message: Logged In: YES user_id=67709 uploading revised patch. Now fixes a few more bugs which try to decode scrub plain text message and result in mojibake. Also, japanese filename tend to become so long that system limit may exceeded because of mime encoding, so add an option not to use the filename in the message but to use 'attachment' as filename. Because this patch spans two files (Defaults.py.in and Handlers/Scrubber.py) you have to cd mailman and patch -p1 < this_patch. (Well, I think it is -p1. If it didn't work, try -p0 ;-) ---------------------------------------------------------------------- Comment By: Jonathan Larmour (jifl) Date: 2004-02-22 17:25 Message: Logged In: YES user_id=817601 I strongly recommend applying this patch. I received a mail bounce on a list with an empty charset in a part (i.e. "charset=") and it caused /var/mailman/cron/senddigest and thus all digest processing to fail because of this error: Traceback (most recent call last): File "/var/mailman/cron/senddigests", line 94, in ? main() File "/var/mailman/cron/senddigests", line 86, in main mlist.send_digest_now() File "/var/mailman/Mailman/Digester.py", line 60, in send_digest_now ToDigest.send_digests(self, mboxfp) File "/var/mailman/Mailman/Handlers/ToDigest.py", line 123, in send_digests send_i18n_digests(mlist, mboxfp) File "/var/mailman/Mailman/Handlers/ToDigest.py", line 295, in send_i18n_digests msg = scrubber(mlist, msg) File "/var/mailman/Mailman/Handlers/Scrubber.py", line 308, in process t = t.encode(charset, 'replace') File "/usr/lib/python2.2/encodings/__init__.py", line 51, in search_function mod = __import__(modname,globals(),locals(),'*') which is something this patch fixes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=891491&group_id=103 From noreply at sourceforge.net Sat Sep 18 07:28:00 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 18 07:28:03 2004 Subject: [ mailman-Bugs-1030228 ] Mass Subscribe address with control character - can't delete Message-ID: Bugs item #1030228, was opened at 2004-09-17 22:28 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=1030228&group_id=103 Category: (un)subscribing Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Mark Sapiro (msapiro) Assigned to: Nobody/Anonymous (nobody) Summary: Mass Subscribe address with control character - can't delete Initial Comment: Mailman 2.1.4 We mass subscribed an automatically generated list of addresses. One of these contained an ascii Vertical-Tab character. The (somewhat munged for privacy) address in the mass subscribe list was lauxxxxxher@comcast.netrixxxxxher where represents ascii Vertical Tab (hex 0B). The address was subscribed OK and then noticed to be bad. We followed the link from the member list to that member's option page an attempted to unsubscribe it and "encountered a bug". This happened twice in succession and then a third time about an hour later. The error log entry from the first try is attached (with the same address munging). Another list administrator tried the same thing the next morning and that time it worked. We don't know why what we think was the same unsubscribe procedure didn't work 3 times and then worked the next day. the following is in Utils.py # TBD: what other characters should be disallowed? _badchars = re.compile(r'[][()<>|;^,/\200-\377]') A fix might be to add the range \000-\037 to the _badchars re, but this may not be correct. It is not clear whether they should be allowed. RFC 2822 allows "non white space" control characters in domain-literals, but not in local-parts of addresses. However, RFC 2821 (SMTP) says: A domain (or domain name) consists of one or more dot-separated components. These components ("labels" in DNS terminology) are restricted for SMTP purposes to consist of a sequence of letters, digits, and hyphens drawn from the ASCII character set. Thus, it seems that for Mailman purposes it would be safe to not allow any of \000-\037 in addresses. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1030228&group_id=103 From noreply at sourceforge.net Sat Sep 18 07:54:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 18 07:54:40 2004 Subject: [ mailman-Bugs-1030228 ] Mass Subscribe address with control character - can't delete Message-ID: Bugs item #1030228, was opened at 2004-09-18 01:28 Message generated for change (Comment added) made by spot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1030228&group_id=103 Category: (un)subscribing Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Mark Sapiro (msapiro) Assigned to: Nobody/Anonymous (nobody) Summary: Mass Subscribe address with control character - can't delete Initial Comment: Mailman 2.1.4 We mass subscribed an automatically generated list of addresses. One of these contained an ascii Vertical-Tab character. The (somewhat munged for privacy) address in the mass subscribe list was lauxxxxxher@comcast.netrixxxxxher where represents ascii Vertical Tab (hex 0B). The address was subscribed OK and then noticed to be bad. We followed the link from the member list to that member's option page an attempted to unsubscribe it and "encountered a bug". This happened twice in succession and then a third time about an hour later. The error log entry from the first try is attached (with the same address munging). Another list administrator tried the same thing the next morning and that time it worked. We don't know why what we think was the same unsubscribe procedure didn't work 3 times and then worked the next day. the following is in Utils.py # TBD: what other characters should be disallowed? _badchars = re.compile(r'[][()<>|;^,/\200-\377]') A fix might be to add the range \000-\037 to the _badchars re, but this may not be correct. It is not clear whether they should be allowed. RFC 2822 allows "non white space" control characters in domain-literals, but not in local-parts of addresses. However, RFC 2821 (SMTP) says: A domain (or domain name) consists of one or more dot-separated components. These components ("labels" in DNS terminology) are restricted for SMTP purposes to consist of a sequence of letters, digits, and hyphens drawn from the ASCII character set. Thus, it seems that for Mailman purposes it would be safe to not allow any of \000-\037 in addresses. ---------------------------------------------------------------------- Comment By: Terri Oda (spot) Date: 2004-09-18 01:54 Message: Logged In: YES user_id=110886 As a side note, if you have problems with illegal characters in subscribed addresses, here's the relevant FAQ entry: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq03.013.htp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1030228&group_id=103 From noreply at sourceforge.net Sat Sep 18 10:41:56 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Sep 18 10:42:12 2004 Subject: [ mailman-Patches-872068 ] Decorate.py patch Message-ID: Patches item #872068, was opened at 2004-01-07 00:46 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=872068&group_id=103 Category: internationalization Group: Mailman 2.1 >Status: Closed Resolution: None Priority: 7 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: Decorate.py patch Initial Comment: Here is a patch which was defered and not included in 2.1.4 for Decorate.py. This fixes most of the footer-in-the-attachment problem by 1. convert header, body and footer into unicode 2. then concatnate them 3. try encode with the list charset 4. if fail, encode with the message charset 5. if both attempts fail, make the footer attachment. ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-09-18 08:41 Message: Logged In: YES user_id=67709 committed (new revision: 2.21.2.4) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=872068&group_id=103 From noreply at sourceforge.net Sun Sep 19 08:54:41 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 19 08:54:52 2004 Subject: [ mailman-Bugs-1004091 ] "-1 Mailman moderator request(s) waiting" Message-ID: Bugs item #1004091, was opened at 2004-08-05 19:54 Message generated for change (Comment added) made by neth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1004091&group_id=103 Category: Web/CGI Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Lucian Smith (luciansmith) Assigned to: Nobody/Anonymous (nobody) Summary: "-1 Mailman moderator request(s) waiting" Initial Comment: Mailman mailed this to me today. I have no idea why. I'm running 2.1.5: --------- From: mailman-bounces@evolution.genetics.washington.edu To: mailman-owner@evolution.genetics.washington.edu Subject: -1 Mailman moderator request(s) waiting Date: Thu, 05 Aug 2004 08:00:01 -0700 Sender: mailman-bounces@gs.washington.edu Message-ID: The Mailman@evolution.genetics.washington.edu mailing list has -1 request(s) waiting for your consideration at: http://evolution.genetics.washington.edu/mailman/admindb/mailman Please attend to this at your earliest convenience. This notice of pending requests, if any, will be sent out daily. --------- First of all, the URL given doesn't work (it takes me to the general http://evolution.gs.washington.edu/mailman/listinfo page), secondly, I don't think 'mailman' is an actual mailing list that we have, and thirdly, 'negative one'? That's just wacky. ---------------------------------------------------------------------- Comment By: neth (neth) Date: 2004-09-19 08:54 Message: Logged In: YES user_id=1124447 Same problem here. I even got an empty subscription request. Has somebody any idea, what is causing this problem? We're using Mailman 2.1.5 on debian. One of the mails i got: >From mailman-bounces@www.XXX.de Sun Sep 19 08:00:08 2004 Return-path: Envelope-to: XXX@XXX.de Received: from localhost ([127.0.0.1] helo=project.UTUM.local ident=mailman) by project.UTUM.local with esmtp (Exim 3.35 #1 (Debian)) id 1C8uk4-00062l-00 for ; Sun, 19 Sep 2004 08:00:08 +0200 Received: from localhost ([127.0.0.1] helo=project.UTUM.local ident=mailman) by project.UTUM.local with esmtp (Exim 3.35 #1 (Debian)) id 1C8uk2-00061X-00 for ; Sun, 19 Sep 2004 08:00:06 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: -1 Ws2005 moderator request(s) waiting From: ws2005-bounces@XXX.de To: ws2005-owner@XXX.de Message-ID: Date: Sun, 19 Sep 2004 08:00:02 +0200 Precedence: bulk X-BeenThere: ws2005@XXX.de X-Mailman-Version: 2.1.5 List-Id: ws2005.XXX.de X-List-Administrivia: yes Sender: mailman-bounces@XXX.de Errors-To: mailman-bounces@XXX.de X-UID: 79 X-Length: 1469 The Ws2005@XXX.de mailing list has -1 request(s) waiting for your consideration at: https://www.XXX.de/mailman/admindb/ws2005 Please attend to this at your earliest convenience. This notice of pending requests, if any, will be sent out daily. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1004091&group_id=103 From noreply at sourceforge.net Sun Sep 19 11:26:21 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 19 11:26:36 2004 Subject: [ mailman-Bugs-1004091 ] "-1 Mailman moderator request(s) waiting" Message-ID: Bugs item #1004091, was opened at 2004-08-05 17:54 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1004091&group_id=103 Category: Web/CGI Group: 2.1 (stable) >Status: Closed Resolution: None Priority: 5 Submitted By: Lucian Smith (luciansmith) Assigned to: Nobody/Anonymous (nobody) Summary: "-1 Mailman moderator request(s) waiting" Initial Comment: Mailman mailed this to me today. I have no idea why. I'm running 2.1.5: --------- From: mailman-bounces@evolution.genetics.washington.edu To: mailman-owner@evolution.genetics.washington.edu Subject: -1 Mailman moderator request(s) waiting Date: Thu, 05 Aug 2004 08:00:01 -0700 Sender: mailman-bounces@gs.washington.edu Message-ID: The Mailman@evolution.genetics.washington.edu mailing list has -1 request(s) waiting for your consideration at: http://evolution.genetics.washington.edu/mailman/admindb/mailman Please attend to this at your earliest convenience. This notice of pending requests, if any, will be sent out daily. --------- First of all, the URL given doesn't work (it takes me to the general http://evolution.gs.washington.edu/mailman/listinfo page), secondly, I don't think 'mailman' is an actual mailing list that we have, and thirdly, 'negative one'? That's just wacky. ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-09-19 09:26 Message: Logged In: YES user_id=67709 See http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq03.038.htp This bug is fixed in CVS. ---------------------------------------------------------------------- Comment By: neth (neth) Date: 2004-09-19 06:54 Message: Logged In: YES user_id=1124447 Same problem here. I even got an empty subscription request. Has somebody any idea, what is causing this problem? We're using Mailman 2.1.5 on debian. One of the mails i got: >From mailman-bounces@www.XXX.de Sun Sep 19 08:00:08 2004 Return-path: Envelope-to: XXX@XXX.de Received: from localhost ([127.0.0.1] helo=project.UTUM.local ident=mailman) by project.UTUM.local with esmtp (Exim 3.35 #1 (Debian)) id 1C8uk4-00062l-00 for ; Sun, 19 Sep 2004 08:00:08 +0200 Received: from localhost ([127.0.0.1] helo=project.UTUM.local ident=mailman) by project.UTUM.local with esmtp (Exim 3.35 #1 (Debian)) id 1C8uk2-00061X-00 for ; Sun, 19 Sep 2004 08:00:06 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: -1 Ws2005 moderator request(s) waiting From: ws2005-bounces@XXX.de To: ws2005-owner@XXX.de Message-ID: Date: Sun, 19 Sep 2004 08:00:02 +0200 Precedence: bulk X-BeenThere: ws2005@XXX.de X-Mailman-Version: 2.1.5 List-Id: ws2005.XXX.de X-List-Administrivia: yes Sender: mailman-bounces@XXX.de Errors-To: mailman-bounces@XXX.de X-UID: 79 X-Length: 1469 The Ws2005@XXX.de mailing list has -1 request(s) waiting for your consideration at: https://www.XXX.de/mailman/admindb/ws2005 Please attend to this at your earliest convenience. This notice of pending requests, if any, will be sent out daily. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1004091&group_id=103 From noreply at sourceforge.net Sun Sep 19 11:27:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Sep 19 11:27:48 2004 Subject: [ mailman-Bugs-1028975 ] checkdbs remainders for not existing requests Message-ID: Bugs item #1028975, was opened at 2004-09-16 04:40 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1028975&group_id=103 Category: command line scripts Group: 2.1 (stable) >Status: Closed Resolution: None Priority: 5 Submitted By: Alberto Marconi (albertomarconi) Assigned to: Nobody/Anonymous (nobody) Summary: checkdbs remainders for not existing requests Initial Comment: checkdbs sends remainders to list owners concerning pending requests which do not exist. It happens on new lists which are missing the request.pck file. The count of the pending requests is -1. The NumRequestsPending() function returns -1 if the request.pck file is missing. The following patch correct this problem: --- checkdbs.orig 2004-09-13 18:36:31.000000000 +0200 +++ checkdbs 2004-09-16 05:33:27.000000000 +0200 @@ -96,7 +96,7 @@ del mlist.hold_and_cmd_autoresponses [sender] # Only here have we changed the list's database mlist.Save() - if count: + if count > 0: i18n.set_language(mlist.preferred_language) realname = mlist.real_name text = Utils.maketext( ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-09-19 09:27 Message: Logged In: YES user_id=67709 see http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq03.038.htp this is fixed in CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1028975&group_id=103 From noreply at sourceforge.net Mon Sep 20 07:20:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 20 07:20:33 2004 Subject: [ mailman-Bugs-1030228 ] Mass Subscribe address with control character - can't delete Message-ID: Bugs item #1030228, was opened at 2004-09-18 05:28 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1030228&group_id=103 Category: (un)subscribing Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Mark Sapiro (msapiro) >Assigned to: Tokio Kikuchi (tkikuchi) Summary: Mass Subscribe address with control character - can't delete Initial Comment: Mailman 2.1.4 We mass subscribed an automatically generated list of addresses. One of these contained an ascii Vertical-Tab character. The (somewhat munged for privacy) address in the mass subscribe list was lauxxxxxher@comcast.netrixxxxxher where represents ascii Vertical Tab (hex 0B). The address was subscribed OK and then noticed to be bad. We followed the link from the member list to that member's option page an attempted to unsubscribe it and "encountered a bug". This happened twice in succession and then a third time about an hour later. The error log entry from the first try is attached (with the same address munging). Another list administrator tried the same thing the next morning and that time it worked. We don't know why what we think was the same unsubscribe procedure didn't work 3 times and then worked the next day. the following is in Utils.py # TBD: what other characters should be disallowed? _badchars = re.compile(r'[][()<>|;^,/\200-\377]') A fix might be to add the range \000-\037 to the _badchars re, but this may not be correct. It is not clear whether they should be allowed. RFC 2822 allows "non white space" control characters in domain-literals, but not in local-parts of addresses. However, RFC 2821 (SMTP) says: A domain (or domain name) consists of one or more dot-separated components. These components ("labels" in DNS terminology) are restricted for SMTP purposes to consist of a sequence of letters, digits, and hyphens drawn from the ASCII character set. Thus, it seems that for Mailman purposes it would be safe to not allow any of \000-\037 in addresses. ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-09-20 05:20 Message: Logged In: YES user_id=67709 uploading a patch to fix this and other. ---------------------------------------------------------------------- Comment By: Terri Oda (spot) Date: 2004-09-18 05:54 Message: Logged In: YES user_id=110886 As a side note, if you have problems with illegal characters in subscribed addresses, here's the relevant FAQ entry: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq03.013.htp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1030228&group_id=103 From noreply at sourceforge.net Mon Sep 20 07:27:00 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 20 07:27:06 2004 Subject: [ mailman-Bugs-998609 ] can subscribe with CR+LF in email address Message-ID: Bugs item #998609, was opened at 2004-07-27 10:13 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=998609&group_id=103 Category: (un)subscribing Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Thomas Arendsen Hein (thomas_ah) Assigned to: Nobody/Anonymous (nobody) Summary: can subscribe with CR+LF in email address Initial Comment: With Mailman 2.1.3 (didn't test with newer versions) it is possible to subscribe with an email address which ends with CR+LF. A browser bug made it possible to enter this into the single line entry field, but Mailman should check this. A quick test shows that CR+LF is possible in the middle of an email address, too, but of course this only works when confirmation check is disabled. Unsubscribing or changing the email address wasn't possible, because there are checks against this strange address. Only manually removing all dictionary entries with 'withlist' helped. ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-09-20 05:27 Message: Logged In: YES user_id=67709 A patch is uploaded in: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1030228&group_id=103 Can you test it ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=998609&group_id=103 From noreply at sourceforge.net Mon Sep 20 14:23:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 20 14:23:46 2004 Subject: [ mailman-Patches-1003070 ] Decode original subject in post acknowledgement Message-ID: Patches item #1003070, was opened at 2004-08-04 06:26 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1003070&group_id=103 Category: internationalization Group: Mailman 2.1 >Status: Closed Resolution: None Priority: 5 Submitted By: Hatuka*nezumi (hatukanezumi) >Assigned to: Tokio Kikuchi (tkikuchi) Summary: Decode original subject in post acknowledgement Initial Comment: Original subject line in post acknowledgement message will be decoded and be converted. ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-09-20 12:23 Message: Logged In: YES user_id=67709 Fixed in CVS: revision: 2.14.2.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1003070&group_id=103 From noreply at sourceforge.net Mon Sep 20 22:47:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Sep 20 22:47:43 2004 Subject: [ mailman-Bugs-1030228 ] Mass Subscribe address with control character - can't delete Message-ID: Bugs item #1030228, was opened at 2004-09-17 22:28 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1030228&group_id=103 Category: (un)subscribing Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Mark Sapiro (msapiro) Assigned to: Tokio Kikuchi (tkikuchi) Summary: Mass Subscribe address with control character - can't delete Initial Comment: Mailman 2.1.4 We mass subscribed an automatically generated list of addresses. One of these contained an ascii Vertical-Tab character. The (somewhat munged for privacy) address in the mass subscribe list was lauxxxxxher@comcast.netrixxxxxher where represents ascii Vertical Tab (hex 0B). The address was subscribed OK and then noticed to be bad. We followed the link from the member list to that member's option page an attempted to unsubscribe it and "encountered a bug". This happened twice in succession and then a third time about an hour later. The error log entry from the first try is attached (with the same address munging). Another list administrator tried the same thing the next morning and that time it worked. We don't know why what we think was the same unsubscribe procedure didn't work 3 times and then worked the next day. the following is in Utils.py # TBD: what other characters should be disallowed? _badchars = re.compile(r'[][()<>|;^,/\200-\377]') A fix might be to add the range \000-\037 to the _badchars re, but this may not be correct. It is not clear whether they should be allowed. RFC 2822 allows "non white space" control characters in domain-literals, but not in local-parts of addresses. However, RFC 2821 (SMTP) says: A domain (or domain name) consists of one or more dot-separated components. These components ("labels" in DNS terminology) are restricted for SMTP purposes to consist of a sequence of letters, digits, and hyphens drawn from the ASCII character set. Thus, it seems that for Mailman purposes it would be safe to not allow any of \000-\037 in addresses. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2004-09-20 13:47 Message: Logged In: YES user_id=1123998 I see the patch changes Utils.py as follows: -_badchars = re.compile(r'[][()<>|;^,/\200-\377]') +_badchars = re.compile(r'[][()<>|;^,\000-\037\200-\377]') Per discussion on mailman-developers list, I think \177 should also be disallowed: +_badchars = re.compile(r'[][()<>|;^,\000-\037\177-\377]') ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-09-19 22:20 Message: Logged In: YES user_id=67709 uploading a patch to fix this and other. ---------------------------------------------------------------------- Comment By: Terri Oda (spot) Date: 2004-09-17 22:54 Message: Logged In: YES user_id=110886 As a side note, if you have problems with illegal characters in subscribed addresses, here's the relevant FAQ entry: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq03.013.htp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1030228&group_id=103 From noreply at sourceforge.net Tue Sep 21 02:55:41 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 21 02:55:45 2004 Subject: [ mailman-Bugs-1030228 ] Mass Subscribe address with control character - can't delete Message-ID: Bugs item #1030228, was opened at 2004-09-18 05:28 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1030228&group_id=103 Category: (un)subscribing Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Mark Sapiro (msapiro) Assigned to: Tokio Kikuchi (tkikuchi) Summary: Mass Subscribe address with control character - can't delete Initial Comment: Mailman 2.1.4 We mass subscribed an automatically generated list of addresses. One of these contained an ascii Vertical-Tab character. The (somewhat munged for privacy) address in the mass subscribe list was lauxxxxxher@comcast.netrixxxxxher where represents ascii Vertical Tab (hex 0B). The address was subscribed OK and then noticed to be bad. We followed the link from the member list to that member's option page an attempted to unsubscribe it and "encountered a bug". This happened twice in succession and then a third time about an hour later. The error log entry from the first try is attached (with the same address munging). Another list administrator tried the same thing the next morning and that time it worked. We don't know why what we think was the same unsubscribe procedure didn't work 3 times and then worked the next day. the following is in Utils.py # TBD: what other characters should be disallowed? _badchars = re.compile(r'[][()<>|;^,/\200-\377]') A fix might be to add the range \000-\037 to the _badchars re, but this may not be correct. It is not clear whether they should be allowed. RFC 2822 allows "non white space" control characters in domain-literals, but not in local-parts of addresses. However, RFC 2821 (SMTP) says: A domain (or domain name) consists of one or more dot-separated components. These components ("labels" in DNS terminology) are restricted for SMTP purposes to consist of a sequence of letters, digits, and hyphens drawn from the ASCII character set. Thus, it seems that for Mailman purposes it would be safe to not allow any of \000-\037 in addresses. ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-09-21 00:55 Message: Logged In: YES user_id=67709 sorry, I am now updating the patch. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2004-09-20 20:47 Message: Logged In: YES user_id=1123998 I see the patch changes Utils.py as follows: -_badchars = re.compile(r'[][()<>|;^,/\200-\377]') +_badchars = re.compile(r'[][()<>|;^,\000-\037\200-\377]') Per discussion on mailman-developers list, I think \177 should also be disallowed: +_badchars = re.compile(r'[][()<>|;^,\000-\037\177-\377]') ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-09-20 05:20 Message: Logged In: YES user_id=67709 uploading a patch to fix this and other. ---------------------------------------------------------------------- Comment By: Terri Oda (spot) Date: 2004-09-18 05:54 Message: Logged In: YES user_id=110886 As a side note, if you have problems with illegal characters in subscribed addresses, here's the relevant FAQ entry: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq03.013.htp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1030228&group_id=103 From noreply at sourceforge.net Tue Sep 21 10:13:04 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Sep 21 10:13:08 2004 Subject: [ mailman-Bugs-1031729 ] Messages with empty subject line will not be delivered Message-ID: Bugs item #1031729, was opened at 2004-09-21 08:13 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=1031729&group_id=103 Category: mail delivery Group: 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: Ralf Laue (laue) Assigned to: Nobody/Anonymous (nobody) Summary: Messages with empty subject line will not be delivered Initial Comment: In MailCommandHandler.py, splitsubj = string.split(subject) is called. If, however subject is empty, this leads to an error like: File "/usr/lib/mailman/Mailman/MailCommandHandler.py", line 163, in ParseMailCommands splitsubj = string.split(subject) File "/usr/lib/python2.2/string.py", line 117, in split return s.split(sep, maxsplit) AttributeError : 'NoneType' object has no attribute 'split' A possible solution could be to insert if (subject == None): subject = ''" before string.split(subject) is called. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1031729&group_id=103 From noreply at sourceforge.net Wed Sep 22 10:39:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 22 10:40:02 2004 Subject: [ mailman-Patches-1032434 ] make KNOWN_SPAMMERS work for headers appearing mult. times Message-ID: Patches item #1032434, was opened at 2004-09-22 10:39 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=1032434&group_id=103 Category: mail delivery Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Alexander Bergolth (bergolth) Assigned to: Nobody/Anonymous (nobody) Summary: make KNOWN_SPAMMERS work for headers appearing mult. times Initial Comment: Hi! Currently the header check against the KNOWN_SPAMMERS config option in SpamDetect.py uses msg[header], i.e. __getitem__. This method only checks against the first matching header: Note that if the header appeared multiple times, exactly which occurrance gets returned is undefined. Use getall() to get all the values matching a header field name. I've changed the code to use msg.get_all() instead. --leo ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1032434&group_id=103 From noreply at sourceforge.net Wed Sep 22 16:04:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 22 16:04:51 2004 Subject: [ mailman-Bugs-953320 ] bad handling From header in archiver Message-ID: Bugs item #953320, was opened at 2004-05-13 14:32 Message generated for change (Comment added) made by desrod You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=953320&group_id=103 Category: Pipermail Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Tibor Pittich (phuture) Assigned to: Nobody/Anonymous (nobody) Summary: bad handling From header in archiver Initial Comment: 2.1.4 mailman version - there is problem with archiver. when body of message contains blank line and continued with text 'From ' at beggining of line, then archiver thing that this is a new message and split it. i see, there is a cleanarch script, which can escape non-header From line but why i must change original post adding "escape character"? is there possibility to check only header of message instead of whole message including body? ---------------------------------------------------------------------- Comment By: David A. Desrosiers (desrod) Date: 2004-09-22 14:04 Message: Logged In: YES user_id=3078 I can confirm that this affects the public/stable release version of 2.1.5. Running bin/cleanarch on the suspect mbox DOES NOT fix the problem. I have a list with messages back in 2002, which have "parts" showing up at the end of my September 2004 archives. The messages contain "parts" of the body, and are missing most of the headers. Every time arch runs, it reduplicates the trashed/truncated messages from 2002 onto the end of the September 2004 archive. This is a MAJOR MAJOR MAJOR MAJOR blocker, and cleanarch is not a proper solution. There are reasons why valid messages can start with the word "From" at the beginning of a line, and not be part of the "From:" header. Here are two examples: http://lists.pilot-link.org/pipermail/pilot-link-general/2002-September/016304.html http://lists.pilot-link.org/pipermail/pilot-link-general/2002-June/016144.html I haven't yet found a fix for this, and adding the > in front of the "From" words at the beginning of the lines, DOES NOT fix the problem. In fact, deleting those messages (remember, they're from TWO YEARS AGO) from the .mbox, rm'ing the .html files, and re-running arch on the list, DOES NOT fix the problem. ---------------------------------------------------------------------- Comment By: David A. Desrosiers (desrod) Date: 2004-05-13 17:04 Message: Logged In: YES user_id=3078 I can confirm this bug in 2.1.4, and that it is also in 2.1.5c2.. MAJOR BLOCKER! Please assign to someone and fix! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=953320&group_id=103 From noreply at sourceforge.net Wed Sep 22 16:11:16 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 22 16:11:22 2004 Subject: [ mailman-Bugs-953320 ] bad handling From header in archiver Message-ID: Bugs item #953320, was opened at 2004-05-13 16:32 Message generated for change (Settings changed) made by phuture You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=953320&group_id=103 Category: Pipermail Group: 2.1 (stable) Status: Open Resolution: None >Priority: 8 Submitted By: Tibor Pittich (phuture) Assigned to: Nobody/Anonymous (nobody) Summary: bad handling From header in archiver Initial Comment: 2.1.4 mailman version - there is problem with archiver. when body of message contains blank line and continued with text 'From ' at beggining of line, then archiver thing that this is a new message and split it. i see, there is a cleanarch script, which can escape non-header From line but why i must change original post adding "escape character"? is there possibility to check only header of message instead of whole message including body? ---------------------------------------------------------------------- Comment By: David A. Desrosiers (desrod) Date: 2004-09-22 16:04 Message: Logged In: YES user_id=3078 I can confirm that this affects the public/stable release version of 2.1.5. Running bin/cleanarch on the suspect mbox DOES NOT fix the problem. I have a list with messages back in 2002, which have "parts" showing up at the end of my September 2004 archives. The messages contain "parts" of the body, and are missing most of the headers. Every time arch runs, it reduplicates the trashed/truncated messages from 2002 onto the end of the September 2004 archive. This is a MAJOR MAJOR MAJOR MAJOR blocker, and cleanarch is not a proper solution. There are reasons why valid messages can start with the word "From" at the beginning of a line, and not be part of the "From:" header. Here are two examples: http://lists.pilot-link.org/pipermail/pilot-link-general/2002-September/016304.html http://lists.pilot-link.org/pipermail/pilot-link-general/2002-June/016144.html I haven't yet found a fix for this, and adding the > in front of the "From" words at the beginning of the lines, DOES NOT fix the problem. In fact, deleting those messages (remember, they're from TWO YEARS AGO) from the .mbox, rm'ing the .html files, and re-running arch on the list, DOES NOT fix the problem. ---------------------------------------------------------------------- Comment By: David A. Desrosiers (desrod) Date: 2004-05-13 19:04 Message: Logged In: YES user_id=3078 I can confirm this bug in 2.1.4, and that it is also in 2.1.5c2.. MAJOR BLOCKER! Please assign to someone and fix! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=953320&group_id=103 From noreply at sourceforge.net Wed Sep 22 16:44:13 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 22 16:44:17 2004 Subject: [ mailman-Bugs-1014750 ] need to sort by domain before submitting to MTA Message-ID: Bugs item #1014750, was opened at 2004-08-23 17:39 Message generated for change (Comment added) made by jaredmauch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1014750&group_id=103 Category: mail delivery Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: jared mauch (jaredmauch) Assigned to: Nobody/Anonymous (nobody) Summary: need to sort by domain before submitting to MTA Initial Comment: I have a number of (large) lists that have a number of users at the same domain, but are submitted to the MTA in chunks of 10 to insure the list performs reasonably. The users at the same domain end up in different queue files of my MTA, and spark a large number of SMTP connections to their SMTP servers that could be minimized if the @ that is passed to the MTA is sorted by domain. Then I could have one SMTP transaction with them that delivers 10 messages. I'm no python expert, but figure sorting of this type should be fairly simple, and will reduce the amount my SMTP server abuses these other SMTP servers, which will be a good thing(tm), as well as save bandwidth.. ---------------------------------------------------------------------- >Comment By: jared mauch (jaredmauch) Date: 2004-09-22 10:44 Message: Logged In: YES user_id=131445 SMTPDirect.py def domsort(uida, uidb): ## sort by domain ## usage foo.sort(domsort) i = uida.rfind('@') if i >= 0: doma = uida[i+1:] i = uidb.rfind('@') if i >= 0: domb = uidb[i+1:] return cmp(doma, domb) } # Need to sort by domain name. if we split to chunks it is possible # some well-known domains will be interspersed as we sort by # userid by default instead of by domain. (jared mauch) r.sort(domsort) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1014750&group_id=103 From noreply at sourceforge.net Wed Sep 22 16:52:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 22 16:52:21 2004 Subject: [ mailman-Bugs-953320 ] bad handling From header in archiver Message-ID: Bugs item #953320, was opened at 2004-05-13 07:32 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=953320&group_id=103 Category: Pipermail Group: 2.1 (stable) Status: Open Resolution: None Priority: 8 Submitted By: Tibor Pittich (phuture) Assigned to: Nobody/Anonymous (nobody) Summary: bad handling From header in archiver Initial Comment: 2.1.4 mailman version - there is problem with archiver. when body of message contains blank line and continued with text 'From ' at beggining of line, then archiver thing that this is a new message and split it. i see, there is a cleanarch script, which can escape non-header From line but why i must change original post adding "escape character"? is there possibility to check only header of message instead of whole message including body? ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2004-09-22 07:52 Message: Logged In: YES user_id=1123998 I had this problem on 2.1.4 after importing a large archive from another service. I then fixed the "^From .*$" lines that were in the bodies of a few messages and ran "bin/arch --wipe" to rebuild the archive and that absolutely DID fix the problem. ---------------------------------------------------------------------- Comment By: David A. Desrosiers (desrod) Date: 2004-09-22 07:04 Message: Logged In: YES user_id=3078 I can confirm that this affects the public/stable release version of 2.1.5. Running bin/cleanarch on the suspect mbox DOES NOT fix the problem. I have a list with messages back in 2002, which have "parts" showing up at the end of my September 2004 archives. The messages contain "parts" of the body, and are missing most of the headers. Every time arch runs, it reduplicates the trashed/truncated messages from 2002 onto the end of the September 2004 archive. This is a MAJOR MAJOR MAJOR MAJOR blocker, and cleanarch is not a proper solution. There are reasons why valid messages can start with the word "From" at the beginning of a line, and not be part of the "From:" header. Here are two examples: http://lists.pilot-link.org/pipermail/pilot-link-general/2002-September/016304.html http://lists.pilot-link.org/pipermail/pilot-link-general/2002-June/016144.html I haven't yet found a fix for this, and adding the > in front of the "From" words at the beginning of the lines, DOES NOT fix the problem. In fact, deleting those messages (remember, they're from TWO YEARS AGO) from the .mbox, rm'ing the .html files, and re-running arch on the list, DOES NOT fix the problem. ---------------------------------------------------------------------- Comment By: David A. Desrosiers (desrod) Date: 2004-05-13 10:04 Message: Logged In: YES user_id=3078 I can confirm this bug in 2.1.4, and that it is also in 2.1.5c2.. MAJOR BLOCKER! Please assign to someone and fix! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=953320&group_id=103 From noreply at sourceforge.net Wed Sep 22 16:59:41 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Sep 22 16:59:45 2004 Subject: [ mailman-Bugs-1014750 ] need to sort by domain before submitting to MTA Message-ID: Bugs item #1014750, was opened at 2004-08-23 17:39 Message generated for change (Comment added) made by jaredmauch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1014750&group_id=103 Category: mail delivery Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: jared mauch (jaredmauch) Assigned to: Nobody/Anonymous (nobody) Summary: need to sort by domain before submitting to MTA Initial Comment: I have a number of (large) lists that have a number of users at the same domain, but are submitted to the MTA in chunks of 10 to insure the list performs reasonably. The users at the same domain end up in different queue files of my MTA, and spark a large number of SMTP connections to their SMTP servers that could be minimized if the @ that is passed to the MTA is sorted by domain. Then I could have one SMTP transaction with them that delivers 10 messages. I'm no python expert, but figure sorting of this type should be fairly simple, and will reduce the amount my SMTP server abuses these other SMTP servers, which will be a good thing(tm), as well as save bandwidth.. ---------------------------------------------------------------------- >Comment By: jared mauch (jaredmauch) Date: 2004-09-22 10:59 Message: Logged In: YES user_id=131445 that should be recips not r.sort fyi ---------------------------------------------------------------------- Comment By: jared mauch (jaredmauch) Date: 2004-09-22 10:44 Message: Logged In: YES user_id=131445 SMTPDirect.py def domsort(uida, uidb): ## sort by domain ## usage foo.sort(domsort) i = uida.rfind('@') if i >= 0: doma = uida[i+1:] i = uidb.rfind('@') if i >= 0: domb = uidb[i+1:] return cmp(doma, domb) } # Need to sort by domain name. if we split to chunks it is possible # some well-known domains will be interspersed as we sort by # userid by default instead of by domain. (jared mauch) r.sort(domsort) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1014750&group_id=103 From noreply at sourceforge.net Thu Sep 23 02:44:17 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 23 02:44:36 2004 Subject: [ mailman-Patches-873035 ] subject handling in -request mail Message-ID: Patches item #873035, was opened at 2004-01-08 12:32 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=873035&group_id=103 Category: mail delivery Group: Mailman 2.1 >Status: Closed Resolution: None Priority: 7 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: subject handling in -request mail Initial Comment: Since spammers get one of our '-request' mail command address as target, we frequently get following error log and many such messages shunted. Jan 08 10:17:02 2004 (11705) Uncaught runner exception: ASCII decoding error: ordinal not in range(128) Jan 08 10:17:02 2004 (11705) 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/CommandRunner.py", line 223, in _dispose res = Results(mlist, msg, msgdata) File "/usr/local/mailman/Mailman/Queue/CommandRunner.py", line 77, in __init__ subj = make_header(decode_header(subj)).__unicode__() File "/usr/local/mailman/pythonlib/email/Header.py", line 144, in make_header h.append(s, charset) File "/usr/local/mailman/pythonlib/email/Header.py", line 272, in append ustr = unicode(s, incodec, errors) UnicodeError: ASCII decoding error: ordinal not in range(128) Jan 08 10:17:02 2004 (11705) SHUNTING: 1073506489.162806+2102abfa360c02ffb7bebbce12c1b9f09d8139f9 Apparently, following patch to Queue/CommandRunner.py may solve this problem. ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-09-23 00:44 Message: Logged In: YES user_id=67709 Fixed in CVS revision: 2.26.2.5 ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-03-04 02:32 Message: Logged In: YES user_id=67709 Ok, I double-posted this item. So, raise the priority. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=873035&group_id=103 From noreply at sourceforge.net Thu Sep 23 17:45:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Sep 23 17:45:37 2004 Subject: [ mailman-Bugs-1033469 ] attachment appears in archive with extension changed to .exe Message-ID: Bugs item #1033469, was opened at 2004-09-23 17:45 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=1033469&group_id=103 Category: Pipermail Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alexis Dimitriadis (alexis3) Assigned to: Nobody/Anonymous (nobody) Summary: attachment appears in archive with extension changed to .exe Initial Comment: I posted a message with an attached pdf document, which arrived intact to listmembers. But the link in the archived version appears with a somewhat mangled name and the extension .exe (which confuses browsers). The link points to the intact pdf file. >From the way the name was mangled, I suspect that the problem is caused by a space in the filename of the attachment. The bottom of the archived message looks like this: -------------- next part -------------- A non-text attachment was scrubbed... Name: LTRC-Typology metadata-3.pdf Type: application/octet-stream Size: 121962 bytes Desc: not available Url : .../LTRC-Typologymetadata-3-0001.exe Alexis ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1033469&group_id=103 From noreply at sourceforge.net Fri Sep 24 04:20:57 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 24 04:21:04 2004 Subject: [ mailman-Patches-1032434 ] make KNOWN_SPAMMERS work for headers appearing mult. times Message-ID: Patches item #1032434, was opened at 2004-09-22 08:39 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1032434&group_id=103 Category: mail delivery Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Alexander Bergolth (bergolth) >Assigned to: Tokio Kikuchi (tkikuchi) Summary: make KNOWN_SPAMMERS work for headers appearing mult. times Initial Comment: Hi! Currently the header check against the KNOWN_SPAMMERS config option in SpamDetect.py uses msg[header], i.e. __getitem__. This method only checks against the first matching header: Note that if the header appeared multiple times, exactly which occurrance gets returned is undefined. Use getall() to get all the values matching a header field name. I've changed the code to use msg.get_all() instead. --leo ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-09-24 02:20 Message: Logged In: YES user_id=67709 Looks like resonable to me. So, testing in my site. Do you have example to catch spam with this patch enabled. (received: ??) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1032434&group_id=103 From noreply at sourceforge.net Fri Sep 24 10:11:26 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Sep 24 10:11:35 2004 Subject: [ mailman-Patches-1032434 ] make KNOWN_SPAMMERS work for headers appearing mult. times Message-ID: Patches item #1032434, was opened at 2004-09-22 10:39 Message generated for change (Comment added) made by bergolth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1032434&group_id=103 Category: mail delivery Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Alexander Bergolth (bergolth) Assigned to: Tokio Kikuchi (tkikuchi) Summary: make KNOWN_SPAMMERS work for headers appearing mult. times Initial Comment: Hi! Currently the header check against the KNOWN_SPAMMERS config option in SpamDetect.py uses msg[header], i.e. __getitem__. This method only checks against the first matching header: Note that if the header appeared multiple times, exactly which occurrance gets returned is undefined. Use getall() to get all the values matching a header field name. I've changed the code to use msg.get_all() instead. --leo ---------------------------------------------------------------------- >Comment By: Alexander Bergolth (bergolth) Date: 2004-09-24 10:11 Message: Logged In: YES user_id=24695 I'm using spamassassin and amavisd to tag spam and viruses. The header lines added by the virus-check look like the following: ---------- snipp! ---------- X-Amavis-Alert: INFECTED, message contains virus: Worm.SomeFool.Gen-1 X-Amavis-Alert: BANNED FILENAME, message contains part named: .exe ---------- snipp! ---------- I.e. there are multiple "X-Amavis-Alert" headers to be considered. --leo ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-09-24 04:20 Message: Logged In: YES user_id=67709 Looks like resonable to me. So, testing in my site. Do you have example to catch spam with this patch enabled. (received: ??) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1032434&group_id=103