From noreply@sourceforge.net Thu Aug 1 16:30:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 01 Aug 2002 08:30:39 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-589673 ] Shadow Members on List DB file Message-ID: Bugs item #589673, was opened at 2002-08-01 11:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=589673&group_id=103 Category: security/privacy Group: 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: Stefano Santoro (vtkstef) Assigned to: Nobody/Anonymous (nobody) Summary: Shadow Members on List DB file Initial Comment: I cannot list shadow members that exist on the DB file, and for this reason I don't know how to remove them I got this from the bounce log Aug 01 05:41:01 2002 (6459) ICB: ar1728@trade-net.orgdns.org - first Aug 01 07:11:02 2002 (6694) ICB: jl1824@trade-net.bsd.st - first Aug 01 08:51:00 2002 (7070) ICB: promocao@segmentodigital.com.br - first Aug 01 09:07:02 2002 (7127) ICB: dw1834@trade.getmyip.com - first Aug 01 11:11:01 2002 (7862) Announce: CathQuigley@hotmail.com - first Aug 01 11:12:02 2002 (7867) announce: address not@ciohub.cxo.com not a member. I looked for ar1728@trade-net.orgdns.org using find_member and list_members and I could not find it. I ran the list DB file through the unix strings command, and I could see the addresses. I tried looking for it using Mailman.MailList class using both GetDelivery[Digest]Members and Get[Digest]Members methods, and again I could not find them. Please tell me how I can remove them! Stefano ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=589673&group_id=103 From noreply@sourceforge.net Thu Aug 1 16:32:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 01 Aug 2002 08:32:08 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-589673 ] Shadow Members on List DB file Message-ID: Bugs item #589673, was opened at 2002-08-01 11:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=589673&group_id=103 Category: security/privacy Group: 2.0.x Status: Open Resolution: None >Priority: 8 Submitted By: Stefano Santoro (vtkstef) Assigned to: Nobody/Anonymous (nobody) Summary: Shadow Members on List DB file Initial Comment: I cannot list shadow members that exist on the DB file, and for this reason I don't know how to remove them I got this from the bounce log Aug 01 05:41:01 2002 (6459) ICB: ar1728@trade-net.orgdns.org - first Aug 01 07:11:02 2002 (6694) ICB: jl1824@trade-net.bsd.st - first Aug 01 08:51:00 2002 (7070) ICB: promocao@segmentodigital.com.br - first Aug 01 09:07:02 2002 (7127) ICB: dw1834@trade.getmyip.com - first Aug 01 11:11:01 2002 (7862) Announce: CathQuigley@hotmail.com - first Aug 01 11:12:02 2002 (7867) announce: address not@ciohub.cxo.com not a member. I looked for ar1728@trade-net.orgdns.org using find_member and list_members and I could not find it. I ran the list DB file through the unix strings command, and I could see the addresses. I tried looking for it using Mailman.MailList class using both GetDelivery[Digest]Members and Get[Digest]Members methods, and again I could not find them. Please tell me how I can remove them! Stefano ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=589673&group_id=103 From noreply@sourceforge.net Thu Aug 1 17:33:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 01 Aug 2002 09:33:50 -0700 Subject: [Mailman-Developers] [ mailman-Patches-444879 ] Archive indexer control to improve index Message-ID: Patches item #444879, was opened at 2001-07-26 18:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=444879&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Barrett (ppsys) Assigned to: Nobody/Anonymous (nobody) Summary: Archive indexer control to improve index Initial Comment: This patch is applicable to Mailman 2.0.6 release and supercedes ealier patches 401669 and 402422. This patch should improve the quality of search results returned by search engines such as htdig (http://www.htdig.org) where the seach engine's index builder responds to strings embedded in the html pages that are the subject of the indexing. The changes in this patch: 1. allow strings for enabling and disabling indexing to be defined in mm_cfg.py. 2. embeds those strings in the pages generated as the html version of a list's archive. By default nothing in the html changes. To get the desired effect, you must define ARCHIVE_INDEXING_ENABLE and ARCHIVE_INDEXING_DISABLE in mm_cfg.py You probably want to run this patch as follows: cd patch -p1 < See also the associated patch for integrating the htdig search software with mailman's internal archiver ouput. ---------------------------------------------------------------------- >Comment By: Richard Barrett (ppsys) Date: 2002-08-01 16:33 Message: Logged In: YES user_id=75166 indexing-2.1b2-0.1.patch is a revised version of the patch that is compatible with MM 2.1b2 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-07-30 11:23 Message: Logged In: YES user_id=75166 indexing-2.0.13-0.1.patch is purely cosmetic to get no mumble application to MM 2.0.13 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-07-25 14:11 Message: Logged In: YES user_id=75166 indexing-2.0.11-0.1.patch should apply without problems to MM 2.0.12 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-05-23 09:50 Message: Logged In: YES user_id=75166 indexing-2.0.11-0.1.patch is a revised version of the patch that is compatible with MM 2.0.11 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-04-19 10:53 Message: Logged In: YES user_id=75166 indexing-2.0.9-0.1.patch should apply without problems to MM 2.0.10 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-04-08 17:43 Message: Logged In: YES user_id=75166 indexing-2.0.9-0.1.patch is a revised version of the patch that is compatible with MM 2.0.9 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-03-06 16:14 Message: Logged In: YES user_id=75166 indexing-2.1cvs-20020306.patch is a revised version of the patch that is compatible with the code published in mailman CVS on sourceforge as 12:30 GMT 6 Mar 2002. Corrects problem noted or 5 Mar 2002 by nobody ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-03-05 21:41 Message: Logged In: NO When applying this patch I get an error with Hunk 1 and Defaults.py is not updated. This happens with the a clean download of the latest cvs installation (5 Mar 2002). Any ideas what the problem is? ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-12-17 16:53 Message: Logged In: YES user_id=75166 indexing-2.1cvs-20011217.patch is a revised version of the patch that is compatible with the code published in mailman CVS on sourceforge as 11:50 GMT 17 Dec 2001 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-12-13 16:48 Message: Logged In: YES user_id=75166 indexing-2.1a3-0.1.patch is a revised version of the patch that is compatible with the code published in mailman-2.1a3.tgz on sourceforge. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-28 11:07 Message: Logged In: YES user_id=75166 This patch should also apply without problems to MM 2.0.8 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-27 12:03 Message: Logged In: YES user_id=75166 This patch should also apply without problems to MM 2.0.7 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=444879&group_id=103 From noreply@sourceforge.net Thu Aug 1 17:35:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 01 Aug 2002 09:35:48 -0700 Subject: [Mailman-Developers] [ mailman-Patches-444884 ] Integration of Mailman & htdig for archi Message-ID: Patches item #444884, was opened at 2001-07-26 18:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=444884&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Barrett (ppsys) Assigned to: Nobody/Anonymous (nobody) Summary: Integration of Mailman & htdig for archi Initial Comment: This patch is applicable to Mailman 2.0.6 release that has had search enhancement patch 444879 patch installed - if your Defaults.py has the ARCHIVE_INDEXING_ENABLE and ARCHIVE_INDEXING_DISABLE in it then you've got that patch. It replaces earlier patches 401670 and 402423 and is mainly to correct some problems arising from fixes introduced into Mailman by bug fix releases since the 402423 patch. This patch integrates htdig with Mailman and provides: 1. per list search facility with a search form on the list's TOC page. 2. maintenance of privacy of private archives which requires the user to establish their credentials via the normal private archive access before any access via htdig is allowed. 3. a common base URL for both public and private archive access via htsearch results so that htdig indices are unaffected by changingan archive from private to public and vice versa. All access to archives via htdig is controlled by a new wrapped cgi- bin script called htdig.py. 4. a new cron activated script and extra crontab entry which runs htdig regularly to maintain the per list search indices. 5. automatic creation, deletion and maintenance of htdig configuration files and such. Beyond installing htdig and telling Mailman where it is via mm_cfg you do not have to do any other setup. Well not quite you do have to set up a single per installation symlink to allow htdig to find the automatically generated per list htdig configuration files. You probably want to run this patch as follows: cd patch -p1 < ---------------------------------------------------------------------- >Comment By: Richard Barrett (ppsys) Date: 2002-08-01 16:35 Message: Logged In: YES user_id=75166 htdig-2.1b2-0.1.patch is a revised version of the patch that is compatible with MM 2.1b2 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-07-30 11:25 Message: Logged In: YES user_id=75166 htdig-2.0.13-0.1.patch is purely cosmetic to get no mumble application to MM 2.0.13 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-07-25 15:07 Message: Logged In: YES user_id=75166 Do not use htdig-2.0.12-0.1.patch there is an error in it. Use htdig-2.0.12-0.2.patch instead ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-07-25 14:10 Message: Logged In: YES user_id=75166 htdig-2.0.12-0.1.patch is a revised version of the patch that applies without complaint to MM 2.0.12. It also add a facility for adding site wide htdig configuration attributes to all list specific htdig configuration files. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-05-23 09:59 Message: Logged In: YES user_id=75166 htdig-2.0.11-0.1.patch is a revised version of the patch that is compatible with MM 2.0.11 This version removes an incompatibility with Python 2.2 which caused warning messages to be generated when any of the family cron/nightly_htdig scripts were run. Some guidance on file access permissions for some htdig database files needed by rundig have been added to installation notes. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-04-19 10:59 Message: Logged In: YES user_id=75166 htdig-2.0.10-0.1.patch is a revised version of the patch that is compatible with MM 2.0.10 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-04-08 17:46 Message: Logged In: YES user_id=75166 htdig-2.0.9-0.1.patch is a revised version of the patch that is compatible with MM 2.0.9 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-03-06 16:22 Message: Logged In: YES user_id=75166 htdig-2.1cvs-20020306.patch is a revised version of the patch that is compatible with the code published in mailman CVS on sourceforge as 12:30 GMT 6 Mar 2002 Known deficiency is that the non-English versions of files under $build/templates still contain text in English and need translations I cannot do. Also the necessary pygettext activity and subsequent translations in files under $build/messages remain to be done. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-12-17 16:56 Message: Logged In: YES user_id=75166 htdig-2.1cvs-20011217.patch is a revised version of the patch that is compatible with the code published in mailman CVS on sourceforge as 11:50 GMT 17 Dec 2001 The only known deficiency is that the non-English versions of files under $build/templates still contain text in English and need translations I cannot do. Also the necessary pygettext activity and subsequent translations in files under $build/messages remain to be done. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-12-13 16:58 Message: Logged In: YES user_id=75166 htdig-2.1a3-0.1.patch is a revised version of the patch that is compatible with the code published in mailman-2.1a3.tgz on sourceforge. The only known deficiency is that the non-English versions of files under $build/templates still contain text in English and need translations I cannot do. Also the necessary pygettext activity and subsequent translations in files under $build/messages remain to be done. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-28 17:33 Message: Logged In: YES user_id=75166 The htdig-2.0.8-0.1.patch version of the patch resolves a problem that can arise with htdig indexing if the web_page_url for a list uses other than the http addressing (some folks want to use https). While specified as for MM 2.0.8 the revised patch should work OK with 2.0.7, 2.0.6 and probably back as far as 2.0.3. If you do not have the requirement for using other than http addressing in you lists web_page_urls it probably isn't worth the trouble of upgrading to this patch level. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-28 11:08 Message: Logged In: YES user_id=75166 This patch should also apply without problems to MM 2.0.8 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-27 12:00 Message: Logged In: YES user_id=75166 This patch should also apply without problems to Mm 2.0.7 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-09 11:54 Message: Logged In: YES user_id=75166 The htdig-2.0.6-03.patch version of the patch makes some previously hard-coded things configurable and enhances the capability to run the htdig searches and indexing on a different machine to the one delivering Mailman and Mailman's web UI. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=444884&group_id=103 From noreply@sourceforge.net Thu Aug 1 18:59:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 01 Aug 2002 10:59:29 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-589673 ] Shadow Members on List DB file Message-ID: Bugs item #589673, was opened at 2002-08-01 15:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=589673&group_id=103 Category: security/privacy Group: 2.0.x Status: Open Resolution: None Priority: 8 Submitted By: Stefano Santoro (vtkstef) Assigned to: Nobody/Anonymous (nobody) Summary: Shadow Members on List DB file Initial Comment: I cannot list shadow members that exist on the DB file, and for this reason I don't know how to remove them I got this from the bounce log Aug 01 05:41:01 2002 (6459) ICB: ar1728@trade-net.orgdns.org - first Aug 01 07:11:02 2002 (6694) ICB: jl1824@trade-net.bsd.st - first Aug 01 08:51:00 2002 (7070) ICB: promocao@segmentodigital.com.br - first Aug 01 09:07:02 2002 (7127) ICB: dw1834@trade.getmyip.com - first Aug 01 11:11:01 2002 (7862) Announce: CathQuigley@hotmail.com - first Aug 01 11:12:02 2002 (7867) announce: address not@ciohub.cxo.com not a member. I looked for ar1728@trade-net.orgdns.org using find_member and list_members and I could not find it. I ran the list DB file through the unix strings command, and I could see the addresses. I tried looking for it using Mailman.MailList class using both GetDelivery[Digest]Members and Get[Digest]Members methods, and again I could not find them. Please tell me how I can remove them! Stefano ---------------------------------------------------------------------- Comment By: Dan Mick (dmick) Date: 2002-08-01 17:59 Message: Logged In: YES user_id=10725 Bounces don't always come back with the subscriber's subscribed address. You can use the regular-expression search in the membership-management web page to find an address that's likely to be them, or you can use MM 2.1 to implement VERP-style addressing, which can help find them. My bounces are a lot more reliable now that I've hacked MM to request VERP addressing from postfix; mis-labeled bounces are unfortunately a fact of life in today's complex and badly-administered email world. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=589673&group_id=103 From noreply@sourceforge.net Thu Aug 1 19:09:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 01 Aug 2002 11:09:45 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-589741 ] Subscibing - "We hit a bug" Message-ID: Bugs item #589741, was opened at 2002-08-01 13:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=589741&group_id=103 Category: (un)subscribing Group: None Status: Open Resolution: None Priority: 5 Submitted By: Denver (denversings) Assigned to: Nobody/Anonymous (nobody) Summary: Subscibing - "We hit a bug" Initial Comment: Bug in Mailman version 2.0.11 We're sorry, we hit a bug! Please inform the webmaster for this site of this problem. Printing of traceback and other system information has been explicitly inhibited, but the webmaster can find this information in the Mailman error logs. Can't subscribe! Also, not sending pasword reminders anymore. What's up? fansadmin@denversings.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=589741&group_id=103 From noreply@sourceforge.net Thu Aug 1 19:14:31 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 01 Aug 2002 11:14:31 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-589741 ] Subscibing - "We hit a bug" Message-ID: Bugs item #589741, was opened at 2002-08-01 13:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=589741&group_id=103 Category: (un)subscribing Group: None Status: Open Resolution: None Priority: 9 Submitted By: Denver (denversings) Assigned to: Nobody/Anonymous (nobody) >Summary: Subscibing - "We hit a bug" Initial Comment: Bug in Mailman version 2.0.11 We're sorry, we hit a bug! Please inform the webmaster for this site of this problem. Printing of traceback and other system information has been explicitly inhibited, but the webmaster can find this information in the Mailman error logs. Can't subscribe! Also, not sending pasword reminders anymore. What's up? fansadmin@denversings.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=589741&group_id=103 From noreply@sourceforge.net Thu Aug 1 19:19:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 01 Aug 2002 11:19:41 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-589741 ] Subscibing - "We hit a bug" Message-ID: Bugs item #589741, was opened at 2002-08-01 18:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=589741&group_id=103 Category: (un)subscribing Group: None Status: Open Resolution: None Priority: 9 Submitted By: Denver (denversings) Assigned to: Nobody/Anonymous (nobody) Summary: Subscibing - "We hit a bug" Initial Comment: Bug in Mailman version 2.0.11 We're sorry, we hit a bug! Please inform the webmaster for this site of this problem. Printing of traceback and other system information has been explicitly inhibited, but the webmaster can find this information in the Mailman error logs. Can't subscribe! Also, not sending pasword reminders anymore. What's up? fansadmin@denversings.com ---------------------------------------------------------------------- Comment By: Dan Mick (dmick) Date: 2002-08-01 18:19 Message: Logged In: YES user_id=10725 Um....there's zero information here, so... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=589741&group_id=103 From noreply@sourceforge.net Thu Aug 1 19:12:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 01 Aug 2002 11:12:41 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-589741 ] Subscibing - "We hit a bug" Message-ID: Bugs item #589741, was opened at 2002-08-01 13:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=589741&group_id=103 Category: (un)subscribing Group: None Status: Open Resolution: None >Priority: 9 Submitted By: Denver (denversings) Assigned to: Nobody/Anonymous (nobody) >Summary: Subscibing - "We hit a bug" Initial Comment: Bug in Mailman version 2.0.11 We're sorry, we hit a bug! Please inform the webmaster for this site of this problem. Printing of traceback and other system information has been explicitly inhibited, but the webmaster can find this information in the Mailman error logs. Can't subscribe! Also, not sending pasword reminders anymore. What's up? fansadmin@denversings.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=589741&group_id=103 From noreply@sourceforge.net Thu Aug 1 20:10:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 01 Aug 2002 12:10:49 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-573071 ] nonmembers can post after upgrading Message-ID: Bugs item #573071, was opened at 2002-06-24 07:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=573071&group_id=103 Category: security/privacy Group: 2.1 beta >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Daniel Buchmann (avalon) Assigned to: Nobody/Anonymous (nobody) Summary: nonmembers can post after upgrading Initial Comment: After upgrading to current CVS (2.1b2+), nonmembers are now allowed to post to a list that used to be members-only (in MM 2.0.11). The member_posting_only config variable is not propagated to the generic_nonmember_action variable when upgrading. This caused me a lot of trouble... :) The fix is probably trivial, but my lack of python experience prevents me from submitting a patch... ;) ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-01 15:10 Message: Logged In: YES user_id=12800 I've now implemented this and it seems to work "correctly" for some definition of correctly. So I'm going to go ahead and commit this algorithm. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-31 18:08 Message: Logged In: YES user_id=12800 Ugh, that last comment looks horrible. I'm attaching the plain text to this followup. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-31 18:06 Message: Logged In: YES user_id=12800 Actually, I'm sure the fix is anything /but/ trivial since the semantics and interaction of the MM2.0.x member_posting_only, posters, and moderated attributes is simply too confusing. I'm not sure I got it right the first time, and I'm not even sure that my current thinking on the subject is correct. Here is my current thinking about the steps needed to do an upgrade. I'd love to have someone else sanity check this, but I'll understand if no one does or can. We're not going to "fix" 2.1b2 lists, but this might fix things for lists that are upgraded from 2.0.x to 2.1b3. None of this is tested yet -- or even implemented -- since I need to think on it some more and see if this is correct. Have any comments? Oh yeah. I need to put a nice big warning in the UPGRADING file. # Now convert what we can... Note that the interaction between the # MM2.0.x attributes `moderated', `member_posting_only', and `posters' is # so confusing, it makes my brain really ache. Which is why they go away # in MM2.1. I think the best we can do semantically is the following: # # - If moderated == yes, then any sender who's address is not on the # posters attribute would get held for approval. if the sender was on # the posters list, then we'd defer judgement to a later step # - If member_posting_only == yes, then members could post without holds, # and if there were any addresses added to posters, they could also post # without holds. # - If member_posting_only == no, then what happens depends on the value # of the posters attribute: # o If posters was empty, then anybody can post without their # message being held for approval # o If posters was non-empty, then /only/ those addresses could post # without approval, i.e. members not on posters would have their # messages held for approval. # # How to translate this mess to MM2.1 values? I'm sure I got this wrong # before, but here's how we're going to do it, as of MM2.1b3. # # - We'll control member moderation through their Moderate flag, and # non-member moderation through the generic_nonmember_action, # hold_these_nonmembers, and accept_these_nonmembers. # - If moderated == yes then we need to troll through the addresses on # posters, and any non-members would get added to # accept_these_nonmembers. /Then/ we need to troll through the # membership and any member not on posters would get their Moderate flag # set. Then generic_nonmember_action gets set to 1 (hold) so nonmembers # get moderated, and default_member_moderation will be set to 1 (hold) # so new members will also get held for moderation. We'll stop here. # - We only get to here if moderated == no. # - If member_posting_only == yes, then we'll also set # generic_nonmember_action to 1 and we'll turn off the Moderate flag for # members. Then we troll through the posters attribute and add all # those addresses to accept_these_nonmembers. We'll stop here. # - We only get to here if member_posting_only == no # - If posters is empty, then anybody could post without being held for # approval, so we'll set generic_nonmember_action to 0 (accept), and # we'll turn off the Moderate flag for all members. We'll also turn off # default_member_moderation so new members can post without approval. # We'll stop here. # - We only get here if posters is non-empty. # - This means that /only/ the addresses on posters got to post without # being held for approval. So first, we troll through posters and add # all non-members to accept_these_nonmembers. Then we troll through the # membership and if their address is on posters, we'll clear their # Moderate flag, otherwise we'll set it. We'll turn on # default_member_moderation so new members get moderated. We'll set # generic_nonmember_action to 1 (hold) so all other non-members will get # moderated. And I think we're finally done. # # SIGH. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=573071&group_id=103 From noreply@sourceforge.net Thu Aug 1 20:27:40 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 01 Aug 2002 12:27:40 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-589741 ] Subscibing - "We hit a bug" Message-ID: Bugs item #589741, was opened at 2002-08-01 14:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=589741&group_id=103 Category: (un)subscribing Group: None >Status: Pending Resolution: None >Priority: 5 Submitted By: Denver (denversings) Assigned to: Nobody/Anonymous (nobody) >Summary: Subscibing - "We hit a bug" Initial Comment: Bug in Mailman version 2.0.11 We're sorry, we hit a bug! Please inform the webmaster for this site of this problem. Printing of traceback and other system information has been explicitly inhibited, but the webmaster can find this information in the Mailman error logs. Can't subscribe! Also, not sending pasword reminders anymore. What's up? fansadmin@denversings.com ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-01 15:27 Message: Logged In: YES user_id=12800 Check your errors/log file for traceback information. Changing status to Pending until more information is provided. ---------------------------------------------------------------------- Comment By: Dan Mick (dmick) Date: 2002-08-01 14:19 Message: Logged In: YES user_id=10725 Um....there's zero information here, so... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=589741&group_id=103 From noreply@sourceforge.net Thu Aug 1 20:39:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 01 Aug 2002 12:39:09 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-589673 ] Shadow Members on List DB file Message-ID: Bugs item #589673, was opened at 2002-08-01 11:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=589673&group_id=103 Category: security/privacy Group: 2.0.x Status: Open Resolution: None Priority: 8 Submitted By: Stefano Santoro (vtkstef) Assigned to: Nobody/Anonymous (nobody) Summary: Shadow Members on List DB file Initial Comment: I cannot list shadow members that exist on the DB file, and for this reason I don't know how to remove them I got this from the bounce log Aug 01 05:41:01 2002 (6459) ICB: ar1728@trade-net.orgdns.org - first Aug 01 07:11:02 2002 (6694) ICB: jl1824@trade-net.bsd.st - first Aug 01 08:51:00 2002 (7070) ICB: promocao@segmentodigital.com.br - first Aug 01 09:07:02 2002 (7127) ICB: dw1834@trade.getmyip.com - first Aug 01 11:11:01 2002 (7862) Announce: CathQuigley@hotmail.com - first Aug 01 11:12:02 2002 (7867) announce: address not@ciohub.cxo.com not a member. I looked for ar1728@trade-net.orgdns.org using find_member and list_members and I could not find it. I ran the list DB file through the unix strings command, and I could see the addresses. I tried looking for it using Mailman.MailList class using both GetDelivery[Digest]Members and Get[Digest]Members methods, and again I could not find them. Please tell me how I can remove them! Stefano ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-01 15:39 Message: Logged In: YES user_id=12800 We really need to know what version of Mailman you're running. Some of the older 2.0.x series versions didn't properly maintain consistency in the various member oriented dictionaries. Your config.db file wasn't readable, so I can't tell if that was your problem or not. ---------------------------------------------------------------------- Comment By: Dan Mick (dmick) Date: 2002-08-01 13:59 Message: Logged In: YES user_id=10725 Bounces don't always come back with the subscriber's subscribed address. You can use the regular-expression search in the membership-management web page to find an address that's likely to be them, or you can use MM 2.1 to implement VERP-style addressing, which can help find them. My bounces are a lot more reliable now that I've hacked MM to request VERP addressing from postfix; mis-labeled bounces are unfortunately a fact of life in today's complex and badly-administered email world. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=589673&group_id=103 From noreply@sourceforge.net Thu Aug 1 20:48:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 01 Aug 2002 12:48:19 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-589387 ] can user@host.com = user@abc.host.com? Message-ID: Bugs item #589387, was opened at 2002-07-31 17:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=589387&group_id=103 >Category: security/privacy >Group: 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: Paul Marshall (paulmarshll) Assigned to: Nobody/Anonymous (nobody) Summary: can user@host.com = user@abc.host.com? Initial Comment: I have people who subscribe under user@host.com however, their email is identified as user@abc.host.com. When Mailman sees this it rejects the post claiming that user@abc.host.com isn't subscribed to the list. This problem is very similar to the one listed here: http://mail.python.org/pipermail/mailman-users/2002- July/021343.html I tried the solution that the person suggested, modifying SMART_ADDRESS_MATCH =3D 1 in mm_cfg.py, however this still didn't work. I tried it with it set as: SMART_ADDRESS_MATCH = 1 SMART_ADDRESS_MATCH =3D 1 SMART_ADDRESS_MATCH = 0 Although none of these worked, I am assuming it has to be set to true (1). Anyone have any ideas on why that isn't working or whatelse I may need to do? Thanks. Paul ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-01 15:47 Message: Logged In: YES user_id=12800 Well the default of SMART_ADDRESS_MATCH is 1 which should turn on smart address matching. However it's possible that what is actually showing up in the From: field (or Sender: depending on if USE_ENVELOPE_SENDER) is set may not be what you think it is. You should upload a message, with full headers intact for a message that you think is getting incorrectly blocked. Also give the values of SMART_ADDRESS_MATCH and USE_ENVELOPE_SENDER, and include the address that you think this message should have matched. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=589387&group_id=103 From noreply@sourceforge.net Thu Aug 1 20:48:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 01 Aug 2002 12:48:01 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-589673 ] Shadow Members on List DB file Message-ID: Bugs item #589673, was opened at 2002-08-01 11:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=589673&group_id=103 Category: security/privacy Group: 2.0.x Status: Open Resolution: None >Priority: 5 Submitted By: Stefano Santoro (vtkstef) Assigned to: Nobody/Anonymous (nobody) Summary: Shadow Members on List DB file Initial Comment: I cannot list shadow members that exist on the DB file, and for this reason I don't know how to remove them I got this from the bounce log Aug 01 05:41:01 2002 (6459) ICB: ar1728@trade-net.orgdns.org - first Aug 01 07:11:02 2002 (6694) ICB: jl1824@trade-net.bsd.st - first Aug 01 08:51:00 2002 (7070) ICB: promocao@segmentodigital.com.br - first Aug 01 09:07:02 2002 (7127) ICB: dw1834@trade.getmyip.com - first Aug 01 11:11:01 2002 (7862) Announce: CathQuigley@hotmail.com - first Aug 01 11:12:02 2002 (7867) announce: address not@ciohub.cxo.com not a member. I looked for ar1728@trade-net.orgdns.org using find_member and list_members and I could not find it. I ran the list DB file through the unix strings command, and I could see the addresses. I tried looking for it using Mailman.MailList class using both GetDelivery[Digest]Members and Get[Digest]Members methods, and again I could not find them. Please tell me how I can remove them! Stefano ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-01 15:39 Message: Logged In: YES user_id=12800 We really need to know what version of Mailman you're running. Some of the older 2.0.x series versions didn't properly maintain consistency in the various member oriented dictionaries. Your config.db file wasn't readable, so I can't tell if that was your problem or not. ---------------------------------------------------------------------- Comment By: Dan Mick (dmick) Date: 2002-08-01 13:59 Message: Logged In: YES user_id=10725 Bounces don't always come back with the subscriber's subscribed address. You can use the regular-expression search in the membership-management web page to find an address that's likely to be them, or you can use MM 2.1 to implement VERP-style addressing, which can help find them. My bounces are a lot more reliable now that I've hacked MM to request VERP addressing from postfix; mis-labeled bounces are unfortunately a fact of life in today's complex and badly-administered email world. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=589673&group_id=103 From noreply@sourceforge.net Thu Aug 1 20:56:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 01 Aug 2002 12:56:57 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-579908 ] Very poor configuration design Message-ID: Bugs item #579908, was opened at 2002-07-10 20:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=579908&group_id=103 Category: configuring/installing Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Bob Tanner (tanner) Assigned to: Nobody/Anonymous (nobody) Summary: Very poor configuration design Initial Comment: The way configure is setup it seems to assume that you are building mailman ON the box you will be installing it. This is a terrible design decision. Make for creating packages a total nightmare. Forcing a package builder to add entries into /etc/passwd and /etc/group, is another bad design decision. Forcing a package builder to have all the directories setup and proper permissions during build it a another bad design decision. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-01 15:56 Message: Logged In: YES user_id=12800 I'm not sure there's anything left to discuss on this bug report. If you have suggestions, constructive criticism, or (preferrably) patches, please bring them to mailman-developers@python.org ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-24 11:36 Message: Logged In: YES user_id=12800 Sorry, I don't agree. They were good design decisions made for intentional reasons. You can disagree with them or suggest better ways to accomplish other goals, of course. First, sorry, but security demands a mailman user and group be added to the system. I don't think this is much different than a lot of other server type software packages, such as mail daemons. As for the second point, in MM2.1 you will be able to override some of the decisions at configure time, but it seems to me that most autoconf based programs will have similar issues, so Mailman's not unique here. One of the biggest problems IMO is that the gid's are compiled into the C wrappers. While this is very good for a local install, it probably doesn't work well for a package install. I'd be open to suggestions (or better yet, patches) to improve the situation for package builds. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=579908&group_id=103 From noreply@sourceforge.net Thu Aug 1 20:47:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 01 Aug 2002 12:47:47 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-589387 ] can user@host.com = user@abc.host.com? Message-ID: Bugs item #589387, was opened at 2002-07-31 17:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=589387&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Marshall (paulmarshll) Assigned to: Nobody/Anonymous (nobody) Summary: can user@host.com = user@abc.host.com? Initial Comment: I have people who subscribe under user@host.com however, their email is identified as user@abc.host.com. When Mailman sees this it rejects the post claiming that user@abc.host.com isn't subscribed to the list. This problem is very similar to the one listed here: http://mail.python.org/pipermail/mailman-users/2002- July/021343.html I tried the solution that the person suggested, modifying SMART_ADDRESS_MATCH =3D 1 in mm_cfg.py, however this still didn't work. I tried it with it set as: SMART_ADDRESS_MATCH = 1 SMART_ADDRESS_MATCH =3D 1 SMART_ADDRESS_MATCH = 0 Although none of these worked, I am assuming it has to be set to true (1). Anyone have any ideas on why that isn't working or whatelse I may need to do? Thanks. Paul ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-01 15:47 Message: Logged In: YES user_id=12800 Well the default of SMART_ADDRESS_MATCH is 1 which should turn on smart address matching. However it's possible that what is actually showing up in the From: field (or Sender: depending on if USE_ENVELOPE_SENDER) is set may not be what you think it is. You should upload a message, with full headers intact for a message that you think is getting incorrectly blocked. Also give the values of SMART_ADDRESS_MATCH and USE_ENVELOPE_SENDER, and include the address that you think this message should have matched. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=589387&group_id=103 From noreply@sourceforge.net Thu Aug 1 20:48:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 01 Aug 2002 12:48:39 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-582891 ] Mailman converting = to =3D Message-ID: Bugs item #582891, was opened at 2002-07-17 11:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=582891&group_id=103 Category: (un)subscribing Group: 2.0.x >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Jake Rosenbalm (jakerose) Assigned to: Nobody/Anonymous (nobody) Summary: Mailman converting = to =3D Initial Comment: We have a page allowing a user to submit thier email to subscribe to lists. The text sent is subscribe nodigest address=jakerose@yahoo.com. However, the coomand being processed by mailman is subscribe nodigest address=3Djakerose@yahoo.com, where the = is converted to =3D. ANy ideas? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-24 11:30 Message: Logged In: YES user_id=12800 It's likely something else in your tool chain (probably your MTA) is doing the quoted-printable conversion. Mailman won't do that. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=582891&group_id=103 From noreply@sourceforge.net Thu Aug 1 21:14:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 01 Aug 2002 13:14:18 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-589673 ] Shadow Members on List DB file Message-ID: Bugs item #589673, was opened at 2002-08-01 11:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=589673&group_id=103 Category: security/privacy Group: 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: Stefano Santoro (vtkstef) Assigned to: Nobody/Anonymous (nobody) Summary: Shadow Members on List DB file Initial Comment: I cannot list shadow members that exist on the DB file, and for this reason I don't know how to remove them I got this from the bounce log Aug 01 05:41:01 2002 (6459) ICB: ar1728@trade-net.orgdns.org - first Aug 01 07:11:02 2002 (6694) ICB: jl1824@trade-net.bsd.st - first Aug 01 08:51:00 2002 (7070) ICB: promocao@segmentodigital.com.br - first Aug 01 09:07:02 2002 (7127) ICB: dw1834@trade.getmyip.com - first Aug 01 11:11:01 2002 (7862) Announce: CathQuigley@hotmail.com - first Aug 01 11:12:02 2002 (7867) announce: address not@ciohub.cxo.com not a member. I looked for ar1728@trade-net.orgdns.org using find_member and list_members and I could not find it. I ran the list DB file through the unix strings command, and I could see the addresses. I tried looking for it using Mailman.MailList class using both GetDelivery[Digest]Members and Get[Digest]Members methods, and again I could not find them. Please tell me how I can remove them! Stefano ---------------------------------------------------------------------- >Comment By: Stefano Santoro (vtkstef) Date: 2002-08-01 16:14 Message: Logged In: YES user_id=16250 I am using version 2.0.5 ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-01 15:39 Message: Logged In: YES user_id=12800 We really need to know what version of Mailman you're running. Some of the older 2.0.x series versions didn't properly maintain consistency in the various member oriented dictionaries. Your config.db file wasn't readable, so I can't tell if that was your problem or not. ---------------------------------------------------------------------- Comment By: Dan Mick (dmick) Date: 2002-08-01 13:59 Message: Logged In: YES user_id=10725 Bounces don't always come back with the subscriber's subscribed address. You can use the regular-expression search in the membership-management web page to find an address that's likely to be them, or you can use MM 2.1 to implement VERP-style addressing, which can help find them. My bounces are a lot more reliable now that I've hacked MM to request VERP addressing from postfix; mis-labeled bounces are unfortunately a fact of life in today's complex and badly-administered email world. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=589673&group_id=103 From noreply@sourceforge.net Thu Aug 1 21:20:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 01 Aug 2002 13:20:03 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-589673 ] Shadow Members on List DB file Message-ID: Bugs item #589673, was opened at 2002-08-01 11:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=589673&group_id=103 Category: security/privacy Group: 2.0.x >Status: Pending Resolution: None Priority: 5 Submitted By: Stefano Santoro (vtkstef) Assigned to: Nobody/Anonymous (nobody) Summary: Shadow Members on List DB file Initial Comment: I cannot list shadow members that exist on the DB file, and for this reason I don't know how to remove them I got this from the bounce log Aug 01 05:41:01 2002 (6459) ICB: ar1728@trade-net.orgdns.org - first Aug 01 07:11:02 2002 (6694) ICB: jl1824@trade-net.bsd.st - first Aug 01 08:51:00 2002 (7070) ICB: promocao@segmentodigital.com.br - first Aug 01 09:07:02 2002 (7127) ICB: dw1834@trade.getmyip.com - first Aug 01 11:11:01 2002 (7862) Announce: CathQuigley@hotmail.com - first Aug 01 11:12:02 2002 (7867) announce: address not@ciohub.cxo.com not a member. I looked for ar1728@trade-net.orgdns.org using find_member and list_members and I could not find it. I ran the list DB file through the unix strings command, and I could see the addresses. I tried looking for it using Mailman.MailList class using both GetDelivery[Digest]Members and Get[Digest]Members methods, and again I could not find them. Please tell me how I can remove them! Stefano ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-01 16:20 Message: Logged In: YES user_id=12800 That's fairly well out of date. I suggest upgrading to MM2.0.13 and seeing if the problem persists. Moving this to Pending to wait for an update. ---------------------------------------------------------------------- Comment By: Stefano Santoro (vtkstef) Date: 2002-08-01 16:14 Message: Logged In: YES user_id=16250 I am using version 2.0.5 ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-01 15:39 Message: Logged In: YES user_id=12800 We really need to know what version of Mailman you're running. Some of the older 2.0.x series versions didn't properly maintain consistency in the various member oriented dictionaries. Your config.db file wasn't readable, so I can't tell if that was your problem or not. ---------------------------------------------------------------------- Comment By: Dan Mick (dmick) Date: 2002-08-01 13:59 Message: Logged In: YES user_id=10725 Bounces don't always come back with the subscriber's subscribed address. You can use the regular-expression search in the membership-management web page to find an address that's likely to be them, or you can use MM 2.1 to implement VERP-style addressing, which can help find them. My bounces are a lot more reliable now that I've hacked MM to request VERP addressing from postfix; mis-labeled bounces are unfortunately a fact of life in today's complex and badly-administered email world. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=589673&group_id=103 From noreply@sourceforge.net Fri Aug 2 03:12:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 01 Aug 2002 19:12:08 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-589913 ] Rejected mail not bounced back to poster Message-ID: Bugs item #589913, was opened at 2002-08-01 19:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=589913&group_id=103 Category: bounce detection Group: 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: Dan Harkless (dan_harkless) Assigned to: Nobody/Anonymous (nobody) Summary: Rejected mail not bounced back to poster Initial Comment: Howdy. First off, forgive me if "bounce detection" isn't the right category for this -- it was the closest thing I could find. Also, since I'm not a Mailman administrator, I'm unaware whether this might be a configuration problem rather than a bug, but the list admin said it was the latter, so I'm reporting it as such. The version reported in X-Mailman-Version is "2.0.9- sf.net". The problem is that when messages are rejected, the text of the message isn't bounced back to the poster. This means that for people like me, who don't save copies of _all_ outgoing mail (I especially don't for mailing list posts, since I expect to get a copy from the list), the message has to be re-composed from memory when it's re-posted (with a fix for whatever caused it to be rejected). The text of the original email should ALWAYS be included in bounce/reject messages. This is just standard established email system behavior, going back decades. In my particular case, I got a "Your message to awaits moderator approval" message, saying that the "Message has a suspicious header", and then a "Request to mailing list rejected", explaining that the problem was the "Content-Type: multipart/mixed". I had done a MIME-based forward of a message from another list, rather than doing a plain-text forward. Neither of those messages included the text of my original mail. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=589913&group_id=103 From noreply@sourceforge.net Fri Aug 2 03:24:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 01 Aug 2002 19:24:01 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-589741 ] Subscibing - "We hit a bug" Message-ID: Bugs item #589741, was opened at 2002-08-01 13:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=589741&group_id=103 Category: (un)subscribing Group: None >Status: Open Resolution: None >Priority: 9 Submitted By: Denver (denversings) Assigned to: Nobody/Anonymous (nobody) >Summary: Subscibing - "We hit a bug" Initial Comment: Bug in Mailman version 2.0.11 We're sorry, we hit a bug! Please inform the webmaster for this site of this problem. Printing of traceback and other system information has been explicitly inhibited, but the webmaster can find this information in the Mailman error logs. Can't subscribe! Also, not sending pasword reminders anymore. What's up? fansadmin@denversings.com ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-01 14:27 Message: Logged In: YES user_id=12800 Check your errors/log file for traceback information. Changing status to Pending until more information is provided. ---------------------------------------------------------------------- Comment By: Dan Mick (dmick) Date: 2002-08-01 13:19 Message: Logged In: YES user_id=10725 Um....there's zero information here, so... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=589741&group_id=103 From wilane@cyg.sn Sat Aug 3 01:57:59 2002 From: wilane@cyg.sn (Ousmane Wilane) Date: Sat, 3 Aug 2002 00:57:59 +0000 Subject: [Mailman-Developers] Password on the wire again! Message-ID: <15691.10903.127424.582452@localhost.localdomain> Hi, Thought I had to followup on this: http://honor.icsalabs.com/pipermail/firewall-wizards/2002-August/012702.html Cheers -- Ousmane WIlane wilane@omnet.sn << People who have imaginary enemies are called 'paranoid.'People who have enemies that they think are imaginary are called 'victims.'It's often hard to tell the two apart until its too late. >> << Bill Blunden, Phrack 0x0b/0x3b/#0x03 >> From noreply@sourceforge.net Sun Aug 4 02:33:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 03 Aug 2002 18:33:13 -0700 Subject: [Mailman-Developers] [ mailman-Patches-590655 ] listinfo page shows lists not on server Message-ID: Patches item #590655, was opened at 2002-08-03 20:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=590655&group_id=103 Category: Web UI Group: Mailman 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: Joshua Eichen (jeichen) Assigned to: Nobody/Anonymous (nobody) Summary: listinfo page shows lists not on server Initial Comment: This patch allows for lists that are not on the server to be read from an xml file and displayed on the list of lists page. It supports virtual hosts and the categories patch by andy_cat You need a python xml package with a sax2 reader for this to work. There are three varibles you need to add: XML_LIBRARY: where the xml library is installed up to '_xmlplus/' OSL_FILE: where the list of off site lists are stored. USE_OFF_SITE_LISTS: set to 1 to turn on. The xml file look like this: http://testl Test description localhost http://nope.info Examplek exmaple1.com example1 Changed files: listinfo.py Defaults.py OffSiteList.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=590655&group_id=103 From noreply@sourceforge.net Sun Aug 4 15:49:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 04 Aug 2002 07:49:28 -0700 Subject: [Mailman-Developers] [ mailman-Feature Requests-232489 ] RFE: Option to drop implicit destination messages Message-ID: Feature Requests item #232489, was opened at 2001-02-15 00:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=232489&group_id=103 Category: configuring/installing Group: None Status: Open Resolution: None Priority: 4 Submitted By: Karsten Thygesen (karthy) Assigned to: Nobody/Anonymous (nobody) Summary: RFE: Option to drop implicit destination messages Initial Comment: Many lists receive huge loads of spam with iimplicit destination (BCc). I would like an option to bounce their postings with information about, that implicit destinations is not allowed and then _not_ inform the administrator of the list. As admin, it is not unusual to receive more than 30 administrative mails pr. list pr. day. When running many lists, this can be quite a burden. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-08-04 07:49 Message: Logged In: NO I second this. For a public list this option is de rigeur. I admin a couple of lists, and with only a couple of exceptions, ALL MAIL with implicit destinations were spam. It's a burden on the admin to have to discard these. To add injury to insult, mailman insists on reminding me every couple of hours to deal with the spam. I don't know why you people didn't think of this long ago. Please, please, please, implement this option, and let the list admin decide if this is the default policy for the list. I have suffered enough. I am capable of implementing the changes required and would have done so, but these are sourceforge lists beyond my control. I asked sourceforge to implement this option and they said it was up to the developers. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-08-14 05:20 Message: Logged In: NO We're getting flooded with this as well on the EROS project lists. I don't think an autorespond is a good idea, but a silent discard would be EXTREMELY useful. It's annoying enough that I've been trying to find the time to dig in to the code... ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-03-02 15:52 Message: Logged In: YES user_id=34209 Moved to feature requests. Could possibly be incorporated into the autoresponder. Note, however, that bouncing spam is usually not a good idea: the from address (both of them) are almost always fake, and sometimes end up in the mailbox(es) of innocent people. I have seen a lot of uucp nodes suffer under that kind of flooding. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=232489&group_id=103 From noreply@sourceforge.net Sun Aug 4 15:57:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 04 Aug 2002 07:57:43 -0700 Subject: [Mailman-Developers] [ mailman-Feature Requests-590778 ] configurable approval timeout Message-ID: Feature Requests item #590778, was opened at 2002-08-05 00:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=590778&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ken Yap (ken_yap) Assigned to: Nobody/Anonymous (nobody) Summary: configurable approval timeout Initial Comment: Please make the reminder timeout for postings requiring approval configurable. Not every list is equally urgent and many could wait longer for the admin to get around to dealing with the approvals and do more at once. I hate getting email every couple of hours telling me to deal with a pending item. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=590778&group_id=103 From barry@python.org Sun Aug 4 16:37:03 2002 From: barry@python.org (Barry A. Warsaw) Date: Sun, 4 Aug 2002 11:37:03 -0400 Subject: [Mailman-Developers] Password on the wire again! References: <15691.10903.127424.582452@localhost.localdomain> Message-ID: <15693.18975.483531.823842@anthem.wooz.org> >>>>> "OW" == Ousmane Wilane writes: OW> Hi, Thought I had to followup on this: OW> http://honor.icsalabs.com/pipermail/firewall-wizards/2002-August/012702.html Thanks for the pointer. I'm not on that list so I won't follow up to that thread, but feel free to forward the following response. Thanks! -Barry -------------------- snip snip -------------------- Paul Robertson's followup in http://honor.icsalabs.com/pipermail/firewall-wizards/2002-August/012703.html is (mostly) right on target. User passwords protect a primarily low-value resource and the effects of an attack on a user password are fairly easy to detect. Mailman even tells you when you subscribe to a list that the passwords will be sent in plaintext monthly reminders and that you should not choose a valuable password. Everyone reads all the fine print, right? . That being said, the next release of Mailman will allow uses to inhibit their password reminders, so that should address the concerns of Anton J Aylward. Turning off password reminders means the only way to get your password is to request it via the web or email command. The default will still be to send reminders, for exactly the trade-off in costs that Paul points out. Two additional notes: list admin passwords are never sent in the clear. In fact, Mailman doesn't even store the list admin passwords in plaintext; by default it stores list admin passwords as an md5, crypt, or sha1 hash. That's why list admins can't even request their admin passwords and the only way to reset a forgotten admin password is with the site password (also not kept in plaintext). These higher privileged password obviously protect more valuable resources, so security for them is higher. Then again, how many folks hide their Mailman admin interface behind an https url? :) Finally, in the both the current and future versions of Mailman, super paranoid list owners can inhibit password reminders list-wide. I suspect few do though, because of the pain in answering "I forgot my password" messages. This may become more popular in future versions though because I think that overwhelmingly, requests for passwords come from folks who want to unsubscribe. The next version will use mailback confirmations for unsubscription requests, so most users will likely never even need their passwords. Cheers, -Barry From marc_news@merlins.org Sun Aug 4 23:03:19 2002 From: marc_news@merlins.org (Marc MERLIN) Date: Sun, 4 Aug 2002 15:03:19 -0700 Subject: [Mailman-Developers] Password on the wire again! In-Reply-To: <15691.10903.127424.582452@localhost.localdomain> References: <15691.10903.127424.582452@localhost.localdomain> Message-ID: <20020804220319.GP19654@merlins.org> On Sat, Aug 03, 2002 at 12:57:59AM +0000, Ousmane Wilane wrote: > Hi, > Thought I had to followup on this: > http://honor.icsalabs.com/pipermail/firewall-wizards/2002-August/012702.html Ahahaha, I'm happpy I'm not the one who get the insults for sending cleartext passwords every month :-) Since I got tired to answer those after the 10th one (probably happened the first or second month, 2 years ago), I wrote this and have been posting the URL since then: http://marc.merlins.org/netrants/mailman-password.txt Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From mrbill@mrbill.net Mon Aug 5 02:54:11 2002 From: mrbill@mrbill.net (Bill Bradford) Date: Sun, 4 Aug 2002 20:54:11 -0500 Subject: [Mailman-Developers] MM2.1 final timeline? Message-ID: <20020805015411.GV23413@mrbill.net> Any idea how long until Barry decides to put a stamp on 2.1 and call it final? 8-) Bill -- bill bradford mrbill@mrbill.net austin, texas From noreply@sourceforge.net Mon Aug 5 03:26:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 04 Aug 2002 19:26:19 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-526635 ] new_list failure Message-ID: Bugs item #526635, was opened at 2002-03-06 13:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=526635&group_id=103 Category: command line scripts Group: 2.0.x Status: Closed Resolution: Out of Date Priority: 5 Submitted By: Noah Swint (nswint) Assigned to: Nobody/Anonymous (nobody) Summary: new_list failure Initial Comment: after executing the command new_list from the bin folder and entering list email address and password the script hangs after the password is entered ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-08-04 19:26 Message: Logged In: NO I have the same problem with release 2.0.13.. no stale locks are present. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-03-13 22:55 Message: Logged In: YES user_id=12800 More information is needed; I've never seen this happen. Do you perhaps have any stale locks in the lock directory? Closing this as out-of-date for Mailman 2.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=526635&group_id=103 From noreply@sourceforge.net Mon Aug 5 11:08:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 05 Aug 2002 03:08:45 -0700 Subject: [Mailman-Developers] [ mailman-Patches-444879 ] Archive indexer control to improve index Message-ID: Patches item #444879, was opened at 2001-07-26 18:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=444879&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Barrett (ppsys) Assigned to: Nobody/Anonymous (nobody) Summary: Archive indexer control to improve index Initial Comment: This patch is applicable to Mailman 2.0.6 release and supercedes ealier patches 401669 and 402422. This patch should improve the quality of search results returned by search engines such as htdig (http://www.htdig.org) where the seach engine's index builder responds to strings embedded in the html pages that are the subject of the indexing. The changes in this patch: 1. allow strings for enabling and disabling indexing to be defined in mm_cfg.py. 2. embeds those strings in the pages generated as the html version of a list's archive. By default nothing in the html changes. To get the desired effect, you must define ARCHIVE_INDEXING_ENABLE and ARCHIVE_INDEXING_DISABLE in mm_cfg.py You probably want to run this patch as follows: cd patch -p1 < See also the associated patch for integrating the htdig search software with mailman's internal archiver ouput. ---------------------------------------------------------------------- >Comment By: Richard Barrett (ppsys) Date: 2002-08-05 10:08 Message: Logged In: YES user_id=75166 indexing-2.0.13-0.2.patch just adds a GPL notice to the patch ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-08-01 16:33 Message: Logged In: YES user_id=75166 indexing-2.1b2-0.1.patch is a revised version of the patch that is compatible with MM 2.1b2 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-07-30 11:23 Message: Logged In: YES user_id=75166 indexing-2.0.13-0.1.patch is purely cosmetic to get no mumble application to MM 2.0.13 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-07-25 14:11 Message: Logged In: YES user_id=75166 indexing-2.0.11-0.1.patch should apply without problems to MM 2.0.12 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-05-23 09:50 Message: Logged In: YES user_id=75166 indexing-2.0.11-0.1.patch is a revised version of the patch that is compatible with MM 2.0.11 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-04-19 10:53 Message: Logged In: YES user_id=75166 indexing-2.0.9-0.1.patch should apply without problems to MM 2.0.10 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-04-08 17:43 Message: Logged In: YES user_id=75166 indexing-2.0.9-0.1.patch is a revised version of the patch that is compatible with MM 2.0.9 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-03-06 16:14 Message: Logged In: YES user_id=75166 indexing-2.1cvs-20020306.patch is a revised version of the patch that is compatible with the code published in mailman CVS on sourceforge as 12:30 GMT 6 Mar 2002. Corrects problem noted or 5 Mar 2002 by nobody ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-03-05 21:41 Message: Logged In: NO When applying this patch I get an error with Hunk 1 and Defaults.py is not updated. This happens with the a clean download of the latest cvs installation (5 Mar 2002). Any ideas what the problem is? ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-12-17 16:53 Message: Logged In: YES user_id=75166 indexing-2.1cvs-20011217.patch is a revised version of the patch that is compatible with the code published in mailman CVS on sourceforge as 11:50 GMT 17 Dec 2001 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-12-13 16:48 Message: Logged In: YES user_id=75166 indexing-2.1a3-0.1.patch is a revised version of the patch that is compatible with the code published in mailman-2.1a3.tgz on sourceforge. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-28 11:07 Message: Logged In: YES user_id=75166 This patch should also apply without problems to MM 2.0.8 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-27 12:03 Message: Logged In: YES user_id=75166 This patch should also apply without problems to MM 2.0.7 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=444879&group_id=103 From noreply@sourceforge.net Mon Aug 5 11:11:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 05 Aug 2002 03:11:59 -0700 Subject: [Mailman-Developers] [ mailman-Patches-444884 ] Integration of Mailman & htdig for archi Message-ID: Patches item #444884, was opened at 2001-07-26 18:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=444884&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Barrett (ppsys) Assigned to: Nobody/Anonymous (nobody) Summary: Integration of Mailman & htdig for archi Initial Comment: This patch is applicable to Mailman 2.0.6 release that has had search enhancement patch 444879 patch installed - if your Defaults.py has the ARCHIVE_INDEXING_ENABLE and ARCHIVE_INDEXING_DISABLE in it then you've got that patch. It replaces earlier patches 401670 and 402423 and is mainly to correct some problems arising from fixes introduced into Mailman by bug fix releases since the 402423 patch. This patch integrates htdig with Mailman and provides: 1. per list search facility with a search form on the list's TOC page. 2. maintenance of privacy of private archives which requires the user to establish their credentials via the normal private archive access before any access via htdig is allowed. 3. a common base URL for both public and private archive access via htsearch results so that htdig indices are unaffected by changingan archive from private to public and vice versa. All access to archives via htdig is controlled by a new wrapped cgi- bin script called htdig.py. 4. a new cron activated script and extra crontab entry which runs htdig regularly to maintain the per list search indices. 5. automatic creation, deletion and maintenance of htdig configuration files and such. Beyond installing htdig and telling Mailman where it is via mm_cfg you do not have to do any other setup. Well not quite you do have to set up a single per installation symlink to allow htdig to find the automatically generated per list htdig configuration files. You probably want to run this patch as follows: cd patch -p1 < ---------------------------------------------------------------------- >Comment By: Richard Barrett (ppsys) Date: 2002-08-05 10:11 Message: Logged In: YES user_id=75166 htdig-2.0.13-0.2.patch just adds a GPL notice to the patch ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-08-01 16:35 Message: Logged In: YES user_id=75166 htdig-2.1b2-0.1.patch is a revised version of the patch that is compatible with MM 2.1b2 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-07-30 11:25 Message: Logged In: YES user_id=75166 htdig-2.0.13-0.1.patch is purely cosmetic to get no mumble application to MM 2.0.13 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-07-25 15:07 Message: Logged In: YES user_id=75166 Do not use htdig-2.0.12-0.1.patch there is an error in it. Use htdig-2.0.12-0.2.patch instead ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-07-25 14:10 Message: Logged In: YES user_id=75166 htdig-2.0.12-0.1.patch is a revised version of the patch that applies without complaint to MM 2.0.12. It also add a facility for adding site wide htdig configuration attributes to all list specific htdig configuration files. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-05-23 09:59 Message: Logged In: YES user_id=75166 htdig-2.0.11-0.1.patch is a revised version of the patch that is compatible with MM 2.0.11 This version removes an incompatibility with Python 2.2 which caused warning messages to be generated when any of the family cron/nightly_htdig scripts were run. Some guidance on file access permissions for some htdig database files needed by rundig have been added to installation notes. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-04-19 10:59 Message: Logged In: YES user_id=75166 htdig-2.0.10-0.1.patch is a revised version of the patch that is compatible with MM 2.0.10 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-04-08 17:46 Message: Logged In: YES user_id=75166 htdig-2.0.9-0.1.patch is a revised version of the patch that is compatible with MM 2.0.9 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-03-06 16:22 Message: Logged In: YES user_id=75166 htdig-2.1cvs-20020306.patch is a revised version of the patch that is compatible with the code published in mailman CVS on sourceforge as 12:30 GMT 6 Mar 2002 Known deficiency is that the non-English versions of files under $build/templates still contain text in English and need translations I cannot do. Also the necessary pygettext activity and subsequent translations in files under $build/messages remain to be done. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-12-17 16:56 Message: Logged In: YES user_id=75166 htdig-2.1cvs-20011217.patch is a revised version of the patch that is compatible with the code published in mailman CVS on sourceforge as 11:50 GMT 17 Dec 2001 The only known deficiency is that the non-English versions of files under $build/templates still contain text in English and need translations I cannot do. Also the necessary pygettext activity and subsequent translations in files under $build/messages remain to be done. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-12-13 16:58 Message: Logged In: YES user_id=75166 htdig-2.1a3-0.1.patch is a revised version of the patch that is compatible with the code published in mailman-2.1a3.tgz on sourceforge. The only known deficiency is that the non-English versions of files under $build/templates still contain text in English and need translations I cannot do. Also the necessary pygettext activity and subsequent translations in files under $build/messages remain to be done. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-28 17:33 Message: Logged In: YES user_id=75166 The htdig-2.0.8-0.1.patch version of the patch resolves a problem that can arise with htdig indexing if the web_page_url for a list uses other than the http addressing (some folks want to use https). While specified as for MM 2.0.8 the revised patch should work OK with 2.0.7, 2.0.6 and probably back as far as 2.0.3. If you do not have the requirement for using other than http addressing in you lists web_page_urls it probably isn't worth the trouble of upgrading to this patch level. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-28 11:08 Message: Logged In: YES user_id=75166 This patch should also apply without problems to MM 2.0.8 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-27 12:00 Message: Logged In: YES user_id=75166 This patch should also apply without problems to Mm 2.0.7 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-09 11:54 Message: Logged In: YES user_id=75166 The htdig-2.0.6-03.patch version of the patch makes some previously hard-coded things configurable and enhances the capability to run the htdig searches and indexing on a different machine to the one delivering Mailman and Mailman's web UI. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=444884&group_id=103 From teo@dehesselle.dropbear.id.au Mon Aug 5 06:58:50 2002 From: teo@dehesselle.dropbear.id.au (Teo de Hesselle) Date: Mon, 5 Aug 2002 15:58:50 +1000 Subject: [Mailman-Developers] Bug in configure Message-ID: <20020805055850.GC12244@dwarf.itd.uts.edu.au> The configure script included with 2.0.12 uses the "sh" interpreter, however the script seems to rely on a bash test '==' on line 1501. I suggest that this test is modified so that it works on a standard bourne shell (which bash isnt), or that the script calls the bash interpreter directly. PS: I'm not subscribed - please CC any replies directly to me. -- Teo de Hesselle | 21st Century Aircraft: "The crew will consist PGP Key: 18C35A2E Print: | of one pilot and a dog. The pilot will nurture 443C C43F 57C4 18C3 5A2E | and feed the dog. The dog will be there to bite 5F8D 8A54 ECDF 74B6 990C | the pilot if he touches anything. --Fortune Magazine From noreply@sourceforge.net Mon Aug 5 15:42:37 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 05 Aug 2002 07:42:37 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-526635 ] new_list failure Message-ID: Bugs item #526635, was opened at 2002-03-06 16:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=526635&group_id=103 Category: command line scripts Group: 2.0.x Status: Closed Resolution: Out of Date Priority: 5 Submitted By: Noah Swint (nswint) Assigned to: Nobody/Anonymous (nobody) Summary: new_list failure Initial Comment: after executing the command new_list from the bin folder and entering list email address and password the script hangs after the password is entered ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-05 10:42 Message: Logged In: YES user_id=12800 I still need more information. When the script hangs, hit control-C to interrupt the program. This should produce a stack trace. Upload that stack trace. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-08-04 22:26 Message: Logged In: NO I have the same problem with release 2.0.13.. no stale locks are present. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-03-14 01:55 Message: Logged In: YES user_id=12800 More information is needed; I've never seen this happen. Do you perhaps have any stale locks in the lock directory? Closing this as out-of-date for Mailman 2.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=526635&group_id=103 From barry@python.org Mon Aug 5 16:35:01 2002 From: barry@python.org (Barry A. Warsaw) Date: Mon, 5 Aug 2002 11:35:01 -0400 Subject: [Mailman-Developers] Bug in configure References: <20020805055850.GC12244@dwarf.itd.uts.edu.au> Message-ID: <15694.39717.652737.899638@anthem.wooz.org> >>>>> "TdH" == Teo de Hesselle writes: TdH> The configure script included with 2.0.12 uses the "sh" TdH> interpreter, however the script seems to rely on a bash test TdH> '==' on line 1501. Fixed in 2.0.13. -Barry From dgc@uchicago.edu Mon Aug 5 17:51:56 2002 From: dgc@uchicago.edu (David Champion) Date: Mon, 5 Aug 2002 11:51:56 -0500 Subject: [Mailman-Developers] Re: Password on the wire again! In-Reply-To: <20020804220319.GP19654@merlins.org> References: <15691.10903.127424.582452@localhost.localdomain> <20020804220319.GP19654@merlins.org> Message-ID: <20020805165156.GQ25814@dust.uchicago.edu> * On 2002.08.04, in <20020804220319.GP19654@merlins.org>, * "Marc MERLIN" wrote: > > Ahahaha, I'm happpy I'm not the one who get the insults for sending > cleartext passwords every month :-) Not the only one. I'm tired of those, too, but unfortunately I agree with that passwords shouldn't be automatically mailed out, even if the signup page does say that passwords should not be secure passwords. We modified mailpasswds to send out URLs, posting addresses, and admin addresses with no passwords, and a nice banner clearly stating that passwords and unsubs should be obtained at the URL. People still can't read and process that much at a sitting, though, so it also states that no one will read replies, and the patches mailpasswds makes good on that by sending from an alias address plugges into an autoresponder that re-emphasizes the URL and mentions again our site contact address, for anyone with real problems who cares to read that far. It stuffs the autoresponder's to: address into an NBDM to prevent mail loops, and erases the NDBM each month right before mailings go out. It's cut us down from about 1200-1500 junk messages each first of the month to about 15 messages, most of which we actually have a service-oriented response to. This is a big improvement from saying "reread the message we already sent you" hundreds of times. https://listhost.uchicago.edu/mailman-files/mailman-ignore/ -- -D. Fresh fruit enriches everyone. Takes the thirst Sun Project, APC/UCCO out of everyday time. A pure whiff of oxygen, University of Chicago painting over a monochrome world in primary colors. dgc@uchicago.edu We all know that. It's why everyone loves fruit. From bob@nleaudio.com Mon Aug 5 18:54:37 2002 From: bob@nleaudio.com (Bob Puff@NLE) Date: Mon, 05 Aug 2002 13:54:37 -0400 Subject: [Mailman-Developers] Re: Password on the wire again! References: <15691.10903.127424.582452@localhost.localdomain> <20020804220319.GP19654@merlins.org> <20020805165156.GQ25814@dust.uchicago.edu> Message-ID: <3D4EBBDD.9395AFD5@nleaudio.com> ...or opt out with the simple approach, like I do.. Just disable the monthly password cron job entirely! Bob David Champion wrote: > > * On 2002.08.04, in <20020804220319.GP19654@merlins.org>, > * "Marc MERLIN" wrote: > > > > Ahahaha, I'm happpy I'm not the one who get the insults for sending > > cleartext passwords every month :-) > > Not the only one. I'm tired of those, too, but unfortunately I agree > with that passwords shouldn't be automatically mailed out, even if the > signup page does say that passwords should not be secure passwords. > > We modified mailpasswds to send out URLs, posting addresses, and admin > addresses with no passwords, and a nice banner clearly stating that > passwords and unsubs should be obtained at the URL. People still can't > read and process that much at a sitting, though, so it also states that > no one will read replies, and the patches mailpasswds makes good on > that by sending from an alias address plugges into an autoresponder > that re-emphasizes the URL and mentions again our site contact address, > for anyone with real problems who cares to read that far. It stuffs the > autoresponder's to: address into an NBDM to prevent mail loops, and > erases the NDBM each month right before mailings go out. > > It's cut us down from about 1200-1500 junk messages each first of > the month to about 15 messages, most of which we actually have a > service-oriented response to. This is a big improvement from saying > "reread the message we already sent you" hundreds of times. > > https://listhost.uchicago.edu/mailman-files/mailman-ignore/ > > -- > -D. Fresh fruit enriches everyone. Takes the thirst > Sun Project, APC/UCCO out of everyday time. A pure whiff of oxygen, > University of Chicago painting over a monochrome world in primary colors. > dgc@uchicago.edu We all know that. It's why everyone loves fruit. > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman-21/listinfo/mailman-developers From dgc@uchicago.edu Mon Aug 5 19:25:23 2002 From: dgc@uchicago.edu (David Champion) Date: Mon, 5 Aug 2002 13:25:23 -0500 Subject: [Mailman-Developers] Re: Password on the wire again! In-Reply-To: <3D4EBBDD.9395AFD5@nleaudio.com> References: <15691.10903.127424.582452@localhost.localdomain> <20020804220319.GP19654@merlins.org> <20020805165156.GQ25814@dust.uchicago.edu> <3D4EBBDD.9395AFD5@nleaudio.com> Message-ID: <20020805182523.GU25814@dust.uchicago.edu> * On 2002.08.05, in <3D4EBBDD.9395AFD5@nleaudio.com>, * "Bob Puff@NLE" wrote: > ...or opt out with the simple approach, like I do.. Just disable the monthly password cron job entirely! We did that for a while, at first, but got a number of complaints from people who liked seeing a monthly reminder of which lists they're on (but didn't particularly care about passwords). -- -D. Fresh fruit enriches everyone. Takes the thirst Sun Project, APC/UCCO out of everyday time. A pure whiff of oxygen, University of Chicago painting over a monochrome world in primary colors. dgc@uchicago.edu We all know that. It's why everyone loves fruit. From joshuae@bitmine.net Mon Aug 5 19:22:35 2002 From: joshuae@bitmine.net (Joshua Eichen) Date: Mon, 5 Aug 2002 11:22:35 -0700 Subject: [Mailman-Developers] Coding Style Question Message-ID: <20020805182235.GB9875@bitmine.net> ---------------------- multipart/signed attachment Hi, I'm writing a patch for mailman 2.1 and I was wondering if I have three lev= els=20 of class inheritance before I change the mailing list class to inherit from derivative class if I should put those classes in one file or three? Thanks, Joshua Eichen --=20 Bury my heart at Betrand Russellstraat. keyserver: seattle.keyserver.net fingerprint: 363E D1F4 8EC0 DDE3 5DC1 056F E8ED 5163 EE1B 2333 ---------------------- multipart/signed attachment A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available Url : http://mail.python.org/pipermail-21/mailman-developers/attachments/96aa622f/attachment.bin ---------------------- multipart/signed attachment-- From barry@python.org Mon Aug 5 19:56:50 2002 From: barry@python.org (Barry A. Warsaw) Date: Mon, 5 Aug 2002 14:56:50 -0400 Subject: [Mailman-Developers] Coding Style Question References: <20020805182235.GB9875@bitmine.net> Message-ID: <15694.51826.112838.936466@anthem.wooz.org> >>>>> "JE" == Joshua Eichen writes: JE> Hi, I'm writing a patch for mailman 2.1 and I was wondering if JE> I have three levels of class inheritance before I change the JE> mailing list class to inherit from derivative class if I JE> should put those classes in one file or three? Personally, I like a one-class-per-file-rule, but it depends on how big the classes are, and whether they're typically used together, or whether some aren't intended for public consuption. -Barry From noreply@sourceforge.net Mon Aug 5 20:18:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 05 Aug 2002 12:18:02 -0700 Subject: [Mailman-Developers] [ mailman-Patches-591258 ] Filter module and hooks (1 of 2) Message-ID: Patches item #591258, was opened at 2002-08-05 15:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=591258&group_id=103 Category: None Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Laurence Berland (laurenceb) Assigned to: Nobody/Anonymous (nobody) Summary: Filter module and hooks (1 of 2) Initial Comment: The Filter.py module allows one to filter messages using standard regular expression replacement. You are allowed as many or few replacements as needed, comments can be placed in the configuration, each list gets its own regular expressions, and there's a toggle to short circuit the whole process and turn it off on a per-list basis. The hooks included filter messages before they are archived. The module has been tested in this capacity and functions without any bugs. The Filter.py module is written in the standard mailman module style, and so can be cleanly placed in the pipeline if one desires, though this capacity has not been tested. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=591258&group_id=103 From noreply@sourceforge.net Mon Aug 5 20:18:31 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 05 Aug 2002 12:18:31 -0700 Subject: [Mailman-Developers] [ mailman-Patches-591259 ] Filter module and hooks (2 of 2) Message-ID: Patches item #591259, was opened at 2002-08-05 15:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=591259&group_id=103 Category: None Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Laurence Berland (laurenceb) Assigned to: Nobody/Anonymous (nobody) Summary: Filter module and hooks (2 of 2) Initial Comment: The Filter.py module allows one to filter messages using standard regular expression replacement. You are allowed as many or few replacements as needed, comments can be placed in the configuration, each list gets its own regular expressions, and there's a toggle to short circuit the whole process and turn it off on a per-list basis. The hooks included filter messages before they are archived. The module has been tested in this capacity and functions without any bugs. The Filter.py module is written in the standard mailman module style, and so can be cleanly placed in the pipeline if one desires, though this capacity has not been tested. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=591259&group_id=103 From noreply@sourceforge.net Tue Aug 6 16:53:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 06 Aug 2002 08:53:28 -0700 Subject: [Mailman-Developers] [ mailman-Patches-591258 ] Filter module and hooks Message-ID: Patches item #591258, was opened at 2002-08-05 15:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=591258&group_id=103 Category: None Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Laurence Berland (laurenceb) Assigned to: Nobody/Anonymous (nobody) >Summary: Filter module and hooks Initial Comment: The Filter.py module allows one to filter messages using standard regular expression replacement. You are allowed as many or few replacements as needed, comments can be placed in the configuration, each list gets its own regular expressions, and there's a toggle to short circuit the whole process and turn it off on a per-list basis. The hooks included filter messages before they are archived. The module has been tested in this capacity and functions without any bugs. The Filter.py module is written in the standard mailman module style, and so can be cleanly placed in the pipeline if one desires, though this capacity has not been tested. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=591258&group_id=103 From noreply@sourceforge.net Tue Aug 6 16:54:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 06 Aug 2002 08:54:33 -0700 Subject: [Mailman-Developers] [ mailman-Patches-591259 ] Filter module and hooks (2 of 2) Message-ID: Patches item #591259, was opened at 2002-08-05 15:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=591259&group_id=103 Category: None Group: Mailman 2.1 >Status: Deleted >Resolution: Duplicate Priority: 5 Submitted By: Laurence Berland (laurenceb) Assigned to: Nobody/Anonymous (nobody) Summary: Filter module and hooks (2 of 2) Initial Comment: The Filter.py module allows one to filter messages using standard regular expression replacement. You are allowed as many or few replacements as needed, comments can be placed in the configuration, each list gets its own regular expressions, and there's a toggle to short circuit the whole process and turn it off on a per-list basis. The hooks included filter messages before they are archived. The module has been tested in this capacity and functions without any bugs. The Filter.py module is written in the standard mailman module style, and so can be cleanly placed in the pipeline if one desires, though this capacity has not been tested. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=591259&group_id=103 From noreply@sourceforge.net Wed Aug 7 07:32:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 06 Aug 2002 23:32:06 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-589741 ] Subscibing - "We hit a bug" Message-ID: Bugs item #589741, was opened at 2002-08-01 18:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=589741&group_id=103 Category: (un)subscribing Group: None Status: Open Resolution: None Priority: 9 Submitted By: Denver (denversings) Assigned to: Nobody/Anonymous (nobody) Summary: Subscibing - "We hit a bug" Initial Comment: Bug in Mailman version 2.0.11 We're sorry, we hit a bug! Please inform the webmaster for this site of this problem. Printing of traceback and other system information has been explicitly inhibited, but the webmaster can find this information in the Mailman error logs. Can't subscribe! Also, not sending pasword reminders anymore. What's up? fansadmin@denversings.com ---------------------------------------------------------------------- Comment By: Wilfried Gaensheimer (wig) Date: 2002-08-07 06:32 Message: Logged In: YES user_id=53758 I found a similiar problem and traced it down to the code in ../Mailman/MailCommandHandler.py: ... # Note further that some misconfigured list managers don't include any # of these clues, so there's little we can do to break loops in that # case, except throttle the number of responses sent to any one # requester in a day. That's a job for MM2.1. #!wig:org: precedence = msg.get('precedence', '').lower() precedence = msg.get('precedence', '') #!wig:org: ack = msg.get('x-ack', '').lower() ack = msg.get('x-ack', '') beenthere = msg.get('x-beenthere', '') Apparently the message mailman received (subscriptions) did not have the precedence and x-ack header line. Removing the .lower() helps (but I have no clue about python, so i guess that was only a short term fix). Further processing of files in ~mailman/qfiles was failing. Errormessage (from ~mailman/logs/error): Traceback (innermost last): Aug 07 07:52:01 2002 qrunner(16176): File "/home/mailman/cron/qrunner", line 283, in ? Aug 07 07:52:01 2002 qrunner(16176): kids = main(lock) Aug 07 07:52:01 2002 qrunner(16176): File "/home/mailman/cron/qrunner", line 253, in main Aug 07 07:52:01 2002 qrunner(16176): keepqueued = dispose_message(mlist, msg, msgdata) Aug 07 07:52:01 2002 qrunner(16176): File "/home/mailman/cron/qrunner", line 157, in dispose_message Aug 07 07:52:01 2002 qrunner(16176): mlist.ParseMailCommands(msg) Aug 07 07:52:01 2002 qrunner(16176): File "/home/mailman/Mailman/MailCommandHandler.py", line 123, in ParseMailCommands Aug 07 07:52:01 2002 qrunner(16176): precedence = msg.get('precedence', '').lower() Aug 07 07:52:01 2002 qrunner(16176): AttributeError : 'string' object has no attribute 'lower' ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-01 19:27 Message: Logged In: YES user_id=12800 Check your errors/log file for traceback information. Changing status to Pending until more information is provided. ---------------------------------------------------------------------- Comment By: Dan Mick (dmick) Date: 2002-08-01 18:19 Message: Logged In: YES user_id=10725 Um....there's zero information here, so... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=589741&group_id=103 From noreply@sourceforge.net Wed Aug 7 07:37:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 06 Aug 2002 23:37:39 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-589741 ] Subscibing - "We hit a bug" Message-ID: Bugs item #589741, was opened at 2002-08-01 18:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=589741&group_id=103 Category: (un)subscribing Group: None Status: Open Resolution: None Priority: 9 Submitted By: Denver (denversings) Assigned to: Nobody/Anonymous (nobody) Summary: Subscibing - "We hit a bug" Initial Comment: Bug in Mailman version 2.0.11 We're sorry, we hit a bug! Please inform the webmaster for this site of this problem. Printing of traceback and other system information has been explicitly inhibited, but the webmaster can find this information in the Mailman error logs. Can't subscribe! Also, not sending pasword reminders anymore. What's up? fansadmin@denversings.com ---------------------------------------------------------------------- Comment By: Wilfried Gaensheimer (wig) Date: 2002-08-07 06:37 Message: Logged In: YES user_id=53758 Sorry, forgot to add system information: We run on Solaris8 $ uname -a SunOS micmcs1 5.8 Generic_108528-15 sun4u sparc ... $ python Python 1.5.2 (#1, May 15 2000, 22:24:11) [C] on sunos5 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam The mail system is the usual Outlook/Exchange/SMTP found at medium sized companies. ---------------------------------------------------------------------- Comment By: Wilfried Gaensheimer (wig) Date: 2002-08-07 06:32 Message: Logged In: YES user_id=53758 I found a similiar problem and traced it down to the code in ../Mailman/MailCommandHandler.py: ... # Note further that some misconfigured list managers don't include any # of these clues, so there's little we can do to break loops in that # case, except throttle the number of responses sent to any one # requester in a day. That's a job for MM2.1. #!wig:org: precedence = msg.get('precedence', '').lower() precedence = msg.get('precedence', '') #!wig:org: ack = msg.get('x-ack', '').lower() ack = msg.get('x-ack', '') beenthere = msg.get('x-beenthere', '') Apparently the message mailman received (subscriptions) did not have the precedence and x-ack header line. Removing the .lower() helps (but I have no clue about python, so i guess that was only a short term fix). Further processing of files in ~mailman/qfiles was failing. Errormessage (from ~mailman/logs/error): Traceback (innermost last): Aug 07 07:52:01 2002 qrunner(16176): File "/home/mailman/cron/qrunner", line 283, in ? Aug 07 07:52:01 2002 qrunner(16176): kids = main(lock) Aug 07 07:52:01 2002 qrunner(16176): File "/home/mailman/cron/qrunner", line 253, in main Aug 07 07:52:01 2002 qrunner(16176): keepqueued = dispose_message(mlist, msg, msgdata) Aug 07 07:52:01 2002 qrunner(16176): File "/home/mailman/cron/qrunner", line 157, in dispose_message Aug 07 07:52:01 2002 qrunner(16176): mlist.ParseMailCommands(msg) Aug 07 07:52:01 2002 qrunner(16176): File "/home/mailman/Mailman/MailCommandHandler.py", line 123, in ParseMailCommands Aug 07 07:52:01 2002 qrunner(16176): precedence = msg.get('precedence', '').lower() Aug 07 07:52:01 2002 qrunner(16176): AttributeError : 'string' object has no attribute 'lower' ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-01 19:27 Message: Logged In: YES user_id=12800 Check your errors/log file for traceback information. Changing status to Pending until more information is provided. ---------------------------------------------------------------------- Comment By: Dan Mick (dmick) Date: 2002-08-01 18:19 Message: Logged In: YES user_id=10725 Um....there's zero information here, so... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=589741&group_id=103 From noreply@sourceforge.net Wed Aug 7 13:43:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 07 Aug 2002 05:43:06 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-589741 ] Subscibing - "We hit a bug" Message-ID: Bugs item #589741, was opened at 2002-08-01 14:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=589741&group_id=103 Category: (un)subscribing Group: None >Status: Pending Resolution: None Priority: 9 Submitted By: Denver (denversings) Assigned to: Nobody/Anonymous (nobody) >Summary: Subscibing - "We hit a bug" Initial Comment: Bug in Mailman version 2.0.11 We're sorry, we hit a bug! Please inform the webmaster for this site of this problem. Printing of traceback and other system information has been explicitly inhibited, but the webmaster can find this information in the Mailman error logs. Can't subscribe! Also, not sending pasword reminders anymore. What's up? fansadmin@denversings.com ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-07 08:43 Message: Logged In: YES user_id=12800 wig, you need to upgrade to MM2.0.13 which will fix your problem. I'm not sure this is the same as denversings problem though, so I'm moving this status to Pending for lack of more information from the original poster. ---------------------------------------------------------------------- Comment By: Wilfried Gaensheimer (wig) Date: 2002-08-07 02:37 Message: Logged In: YES user_id=53758 Sorry, forgot to add system information: We run on Solaris8 $ uname -a SunOS micmcs1 5.8 Generic_108528-15 sun4u sparc ... $ python Python 1.5.2 (#1, May 15 2000, 22:24:11) [C] on sunos5 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam The mail system is the usual Outlook/Exchange/SMTP found at medium sized companies. ---------------------------------------------------------------------- Comment By: Wilfried Gaensheimer (wig) Date: 2002-08-07 02:32 Message: Logged In: YES user_id=53758 I found a similiar problem and traced it down to the code in ../Mailman/MailCommandHandler.py: ... # Note further that some misconfigured list managers don't include any # of these clues, so there's little we can do to break loops in that # case, except throttle the number of responses sent to any one # requester in a day. That's a job for MM2.1. #!wig:org: precedence = msg.get('precedence', '').lower() precedence = msg.get('precedence', '') #!wig:org: ack = msg.get('x-ack', '').lower() ack = msg.get('x-ack', '') beenthere = msg.get('x-beenthere', '') Apparently the message mailman received (subscriptions) did not have the precedence and x-ack header line. Removing the .lower() helps (but I have no clue about python, so i guess that was only a short term fix). Further processing of files in ~mailman/qfiles was failing. Errormessage (from ~mailman/logs/error): Traceback (innermost last): Aug 07 07:52:01 2002 qrunner(16176): File "/home/mailman/cron/qrunner", line 283, in ? Aug 07 07:52:01 2002 qrunner(16176): kids = main(lock) Aug 07 07:52:01 2002 qrunner(16176): File "/home/mailman/cron/qrunner", line 253, in main Aug 07 07:52:01 2002 qrunner(16176): keepqueued = dispose_message(mlist, msg, msgdata) Aug 07 07:52:01 2002 qrunner(16176): File "/home/mailman/cron/qrunner", line 157, in dispose_message Aug 07 07:52:01 2002 qrunner(16176): mlist.ParseMailCommands(msg) Aug 07 07:52:01 2002 qrunner(16176): File "/home/mailman/Mailman/MailCommandHandler.py", line 123, in ParseMailCommands Aug 07 07:52:01 2002 qrunner(16176): precedence = msg.get('precedence', '').lower() Aug 07 07:52:01 2002 qrunner(16176): AttributeError : 'string' object has no attribute 'lower' ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-01 15:27 Message: Logged In: YES user_id=12800 Check your errors/log file for traceback information. Changing status to Pending until more information is provided. ---------------------------------------------------------------------- Comment By: Dan Mick (dmick) Date: 2002-08-01 14:19 Message: Logged In: YES user_id=10725 Um....there's zero information here, so... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=589741&group_id=103 From noreply@sourceforge.net Wed Aug 7 13:45:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 07 Aug 2002 05:45:46 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-592026 ] Managing Discussion Lists Message-ID: Bugs item #592026, was opened at 2002-08-07 12:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=592026&group_id=103 Category: configuring/installing Group: None Status: Open Resolution: None Priority: 5 Submitted By: H. Peter Aitken (benchmark) Assigned to: Nobody/Anonymous (nobody) Summary: Managing Discussion Lists Initial Comment: I have a Discussion List associated with my web-site hosted by Dreamhost. Dreamhost informs me that they use Mailman software and that I should contact you with information about this "known bug." Navigating through Discussion Lists -> Membership Management to the list in question, I tried to change the value of "The public name of this list (make case changes only)" so that it would appear in UPPER CASE LETTERS. I made no other changes. Then I hit the "Submit" button. But the change is not implemented. Please will you tell me how I can resolve this issue or whether you are working on a fix. Thank you. Peter Aitken peter@benchmarkresearch.org ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=592026&group_id=103 From noreply@sourceforge.net Wed Aug 7 18:02:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 07 Aug 2002 10:02:33 -0700 Subject: [Mailman-Developers] [ mailman-Feature Requests-534234 ] Automatic RSS feed generation Message-ID: Feature Requests item #534234, was opened at 2002-03-24 05:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=534234&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Rob Lanphier (robla) Assigned to: Nobody/Anonymous (nobody) Summary: Automatic RSS feed generation Initial Comment: It would be really great to have an automatic RSS feed as a result of using Mailman archiving. More info on RSS: http://purl.org/rss/1.0/ http://directory.google.com/Top/Reference/Libraries/Library_and_Information_Science/Technical_Services/Cataloguing/Metadata/Resource_Description_Framework_-_RDF/Applications/RSS/ RSS Validator: http://aggregator.userland.com/validator ---------------------------------------------------------------------- Comment By: captain larry (captainlarry) Date: 2002-08-07 17:02 Message: Logged In: YES user_id=147905 If it's useful a friend and I have recently hacked on a Perl script which generates RSS feeds by scraping the Mailman archives. We made some (I think) significant improvements over the original which are documented in our version of the script. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-05-03 05:21 Message: Logged In: YES user_id=12800 Care to submit a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=534234&group_id=103 From noreply@sourceforge.net Wed Aug 7 19:58:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 07 Aug 2002 11:58:54 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-589913 ] Rejected mail not bounced back to poster Message-ID: Bugs item #589913, was opened at 2002-08-01 22:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=589913&group_id=103 Category: bounce detection Group: 2.0.x >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Dan Harkless (dan_harkless) Assigned to: Nobody/Anonymous (nobody) Summary: Rejected mail not bounced back to poster Initial Comment: Howdy. First off, forgive me if "bounce detection" isn't the right category for this -- it was the closest thing I could find. Also, since I'm not a Mailman administrator, I'm unaware whether this might be a configuration problem rather than a bug, but the list admin said it was the latter, so I'm reporting it as such. The version reported in X-Mailman-Version is "2.0.9- sf.net". The problem is that when messages are rejected, the text of the message isn't bounced back to the poster. This means that for people like me, who don't save copies of _all_ outgoing mail (I especially don't for mailing list posts, since I expect to get a copy from the list), the message has to be re-composed from memory when it's re-posted (with a fix for whatever caused it to be rejected). The text of the original email should ALWAYS be included in bounce/reject messages. This is just standard established email system behavior, going back decades. In my particular case, I got a "Your message to awaits moderator approval" message, saying that the "Message has a suspicious header", and then a "Request to mailing list rejected", explaining that the problem was the "Content-Type: multipart/mixed". I had done a MIME-based forward of a message from another list, rather than doing a plain-text forward. Neither of those messages included the text of my original mail. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-07 14:58 Message: Logged In: YES user_id=12800 This won't be changed for MM2.0.x but it already works this way in Mailman 2.1. The original message is contained in the rejection notice as an attachment. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=589913&group_id=103 From rodolfo@pilas.net Thu Aug 8 00:56:36 2002 From: rodolfo@pilas.net (Rodolfo Pilas) Date: 07 Aug 2002 20:56:36 -0300 Subject: [Mailman-Developers] Virus checking Message-ID: <1028764604.4449.132.camel@claudia> I have MM 2.1b+ with Postfix and an antivirus (AVP) called from procmail. With this configuration, a message to a list of local users call the antivirus for each subscriber local user. i.e. I have a list called all-users@localhost with 500 users and when I send a message to said list, the antivirus scan each one of the 500 created messages just before include it at each spool file (as a result of /etc/procmail configuration) Can you tell me if there is possible to process the antivirus scan as soon as received by MM before copy for each subscribed account?? -- --- Rodolfo Pilas Quien los puso a estos tipos donde estan, rodolfo@pilas.net Quien los deja seguir en su lugar, http://rodolfo.pilas.net Quien los baja ahora de su altar, Yahoo ID: ysidorito Quien les paga para que hagan lo que haran http://xtralinux.org -=# Apocalipsis Now % Cuarteto de Nos #=- Public GnuPG key: http://www.keyserver.net 1024D/57153363 2001-06-02 key fingerprint = DAAE 3246 3F7D A420 B7A0 48A5 D120 C773 5715 3363 From noreply@sourceforge.net Thu Aug 8 15:09:40 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 08 Aug 2002 07:09:40 -0700 Subject: [Mailman-Developers] [ mailman-Patches-401669 ] improved archive html extraction by search indexers Message-ID: Patches item #401669, was opened at 2000-09-26 09:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=401669&group_id=103 Category: Pipermail Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Richard Barrett (ppsys) Assigned to: Nobody/Anonymous (nobody) Summary: improved archive html extraction by search indexers Initial Comment: ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-08 10:09 Message: Logged In: YES user_id=12800 Closing based on superceded note. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-07-26 14:32 Message: Logged In: YES user_id=75166 Superceded by #444879 ---------------------------------------------------------------------- Comment By: Nigel Metheringham (nigel) Date: 2000-11-17 10:07 Message: Superceded by 102422 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=401669&group_id=103 From noreply@sourceforge.net Thu Aug 8 15:14:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 08 Aug 2002 07:14:23 -0700 Subject: [Mailman-Developers] [ mailman-Patches-444879 ] Archive indexer control to improve index Message-ID: Patches item #444879, was opened at 2001-07-26 14:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=444879&group_id=103 Category: None Group: None Status: Open Resolution: None >Priority: 7 Submitted By: Richard Barrett (ppsys) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: Archive indexer control to improve index Initial Comment: This patch is applicable to Mailman 2.0.6 release and supercedes ealier patches 401669 and 402422. This patch should improve the quality of search results returned by search engines such as htdig (http://www.htdig.org) where the seach engine's index builder responds to strings embedded in the html pages that are the subject of the indexing. The changes in this patch: 1. allow strings for enabling and disabling indexing to be defined in mm_cfg.py. 2. embeds those strings in the pages generated as the html version of a list's archive. By default nothing in the html changes. To get the desired effect, you must define ARCHIVE_INDEXING_ENABLE and ARCHIVE_INDEXING_DISABLE in mm_cfg.py You probably want to run this patch as follows: cd patch -p1 < See also the associated patch for integrating the htdig search software with mailman's internal archiver ouput. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-08 10:14 Message: Logged In: YES user_id=12800 Looking at the 2.1b2 patch, why does it try to create HyperArch.py.orig and Defaults.py.in.orig? Are those included in the patch by mistake? ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-08-05 06:08 Message: Logged In: YES user_id=75166 indexing-2.0.13-0.2.patch just adds a GPL notice to the patch ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-08-01 12:33 Message: Logged In: YES user_id=75166 indexing-2.1b2-0.1.patch is a revised version of the patch that is compatible with MM 2.1b2 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-07-30 07:23 Message: Logged In: YES user_id=75166 indexing-2.0.13-0.1.patch is purely cosmetic to get no mumble application to MM 2.0.13 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-07-25 10:11 Message: Logged In: YES user_id=75166 indexing-2.0.11-0.1.patch should apply without problems to MM 2.0.12 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-05-23 05:50 Message: Logged In: YES user_id=75166 indexing-2.0.11-0.1.patch is a revised version of the patch that is compatible with MM 2.0.11 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-04-19 06:53 Message: Logged In: YES user_id=75166 indexing-2.0.9-0.1.patch should apply without problems to MM 2.0.10 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-04-08 13:43 Message: Logged In: YES user_id=75166 indexing-2.0.9-0.1.patch is a revised version of the patch that is compatible with MM 2.0.9 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-03-06 11:14 Message: Logged In: YES user_id=75166 indexing-2.1cvs-20020306.patch is a revised version of the patch that is compatible with the code published in mailman CVS on sourceforge as 12:30 GMT 6 Mar 2002. Corrects problem noted or 5 Mar 2002 by nobody ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-03-05 16:41 Message: Logged In: NO When applying this patch I get an error with Hunk 1 and Defaults.py is not updated. This happens with the a clean download of the latest cvs installation (5 Mar 2002). Any ideas what the problem is? ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-12-17 11:53 Message: Logged In: YES user_id=75166 indexing-2.1cvs-20011217.patch is a revised version of the patch that is compatible with the code published in mailman CVS on sourceforge as 11:50 GMT 17 Dec 2001 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-12-13 11:48 Message: Logged In: YES user_id=75166 indexing-2.1a3-0.1.patch is a revised version of the patch that is compatible with the code published in mailman-2.1a3.tgz on sourceforge. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-28 06:07 Message: Logged In: YES user_id=75166 This patch should also apply without problems to MM 2.0.8 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-27 07:03 Message: Logged In: YES user_id=75166 This patch should also apply without problems to MM 2.0.7 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=444879&group_id=103 From noreply@sourceforge.net Thu Aug 8 15:19:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 08 Aug 2002 07:19:05 -0700 Subject: [Mailman-Developers] [ mailman-Patches-444879 ] Archive indexer control to improve index Message-ID: Patches item #444879, was opened at 2001-07-26 14:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=444879&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 7 Submitted By: Richard Barrett (ppsys) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Archive indexer control to improve index Initial Comment: This patch is applicable to Mailman 2.0.6 release and supercedes ealier patches 401669 and 402422. This patch should improve the quality of search results returned by search engines such as htdig (http://www.htdig.org) where the seach engine's index builder responds to strings embedded in the html pages that are the subject of the indexing. The changes in this patch: 1. allow strings for enabling and disabling indexing to be defined in mm_cfg.py. 2. embeds those strings in the pages generated as the html version of a list's archive. By default nothing in the html changes. To get the desired effect, you must define ARCHIVE_INDEXING_ENABLE and ARCHIVE_INDEXING_DISABLE in mm_cfg.py You probably want to run this patch as follows: cd patch -p1 < See also the associated patch for integrating the htdig search software with mailman's internal archiver ouput. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-08 10:19 Message: Logged In: YES user_id=12800 Another question: is there no standard (de-facto or otherwise) for generic markup that tells indexers not to index a particular section? IOW, for ARCHIVE_INDEXING_ENABLE and ARCHIVE_INDEXING_DISABLE, is there some generic value that would instruct most (all?) indexers to ignore that section? Or does it necessarily have to be indexer specific? I'm thinking of the situation where you might have ht://Dig installed locally, but your archives are still being spidered by external indexers. It would be good if something more generic could be added to Defaults.py.in ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-08 10:14 Message: Logged In: YES user_id=12800 Looking at the 2.1b2 patch, why does it try to create HyperArch.py.orig and Defaults.py.in.orig? Are those included in the patch by mistake? ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-08-05 06:08 Message: Logged In: YES user_id=75166 indexing-2.0.13-0.2.patch just adds a GPL notice to the patch ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-08-01 12:33 Message: Logged In: YES user_id=75166 indexing-2.1b2-0.1.patch is a revised version of the patch that is compatible with MM 2.1b2 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-07-30 07:23 Message: Logged In: YES user_id=75166 indexing-2.0.13-0.1.patch is purely cosmetic to get no mumble application to MM 2.0.13 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-07-25 10:11 Message: Logged In: YES user_id=75166 indexing-2.0.11-0.1.patch should apply without problems to MM 2.0.12 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-05-23 05:50 Message: Logged In: YES user_id=75166 indexing-2.0.11-0.1.patch is a revised version of the patch that is compatible with MM 2.0.11 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-04-19 06:53 Message: Logged In: YES user_id=75166 indexing-2.0.9-0.1.patch should apply without problems to MM 2.0.10 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-04-08 13:43 Message: Logged In: YES user_id=75166 indexing-2.0.9-0.1.patch is a revised version of the patch that is compatible with MM 2.0.9 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-03-06 11:14 Message: Logged In: YES user_id=75166 indexing-2.1cvs-20020306.patch is a revised version of the patch that is compatible with the code published in mailman CVS on sourceforge as 12:30 GMT 6 Mar 2002. Corrects problem noted or 5 Mar 2002 by nobody ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-03-05 16:41 Message: Logged In: NO When applying this patch I get an error with Hunk 1 and Defaults.py is not updated. This happens with the a clean download of the latest cvs installation (5 Mar 2002). Any ideas what the problem is? ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-12-17 11:53 Message: Logged In: YES user_id=75166 indexing-2.1cvs-20011217.patch is a revised version of the patch that is compatible with the code published in mailman CVS on sourceforge as 11:50 GMT 17 Dec 2001 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-12-13 11:48 Message: Logged In: YES user_id=75166 indexing-2.1a3-0.1.patch is a revised version of the patch that is compatible with the code published in mailman-2.1a3.tgz on sourceforge. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-28 06:07 Message: Logged In: YES user_id=75166 This patch should also apply without problems to MM 2.0.8 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-27 07:03 Message: Logged In: YES user_id=75166 This patch should also apply without problems to MM 2.0.7 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=444879&group_id=103 From noreply@sourceforge.net Thu Aug 8 17:33:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 08 Aug 2002 09:33:07 -0700 Subject: [Mailman-Developers] [ mailman-Patches-444884 ] Integration of Mailman & htdig for archi Message-ID: Patches item #444884, was opened at 2001-07-26 14:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=444884&group_id=103 Category: None Group: None Status: Open Resolution: None >Priority: 7 Submitted By: Richard Barrett (ppsys) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: Integration of Mailman & htdig for archi Initial Comment: This patch is applicable to Mailman 2.0.6 release that has had search enhancement patch 444879 patch installed - if your Defaults.py has the ARCHIVE_INDEXING_ENABLE and ARCHIVE_INDEXING_DISABLE in it then you've got that patch. It replaces earlier patches 401670 and 402423 and is mainly to correct some problems arising from fixes introduced into Mailman by bug fix releases since the 402423 patch. This patch integrates htdig with Mailman and provides: 1. per list search facility with a search form on the list's TOC page. 2. maintenance of privacy of private archives which requires the user to establish their credentials via the normal private archive access before any access via htdig is allowed. 3. a common base URL for both public and private archive access via htsearch results so that htdig indices are unaffected by changingan archive from private to public and vice versa. All access to archives via htdig is controlled by a new wrapped cgi- bin script called htdig.py. 4. a new cron activated script and extra crontab entry which runs htdig regularly to maintain the per list search indices. 5. automatic creation, deletion and maintenance of htdig configuration files and such. Beyond installing htdig and telling Mailman where it is via mm_cfg you do not have to do any other setup. Well not quite you do have to set up a single per installation symlink to allow htdig to find the automatically generated per list htdig configuration files. You probably want to run this patch as follows: cd patch -p1 < ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-08 12:33 Message: Logged In: YES user_id=12800 I've sent Richard some comments off-line about this patch. Meta comments: the 2.0.x patches can't be officially supported, but I'm going to create an unofficial patches page off the wiki for where the 2.0 patches can be migrated. I think this patch set is too big for MM2.1, but if it's cleaned up as per my private message, let's re-evaluate it for MM2.2 (or 3.0). ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-08-05 06:11 Message: Logged In: YES user_id=75166 htdig-2.0.13-0.2.patch just adds a GPL notice to the patch ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-08-01 12:35 Message: Logged In: YES user_id=75166 htdig-2.1b2-0.1.patch is a revised version of the patch that is compatible with MM 2.1b2 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-07-30 07:25 Message: Logged In: YES user_id=75166 htdig-2.0.13-0.1.patch is purely cosmetic to get no mumble application to MM 2.0.13 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-07-25 11:07 Message: Logged In: YES user_id=75166 Do not use htdig-2.0.12-0.1.patch there is an error in it. Use htdig-2.0.12-0.2.patch instead ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-07-25 10:10 Message: Logged In: YES user_id=75166 htdig-2.0.12-0.1.patch is a revised version of the patch that applies without complaint to MM 2.0.12. It also add a facility for adding site wide htdig configuration attributes to all list specific htdig configuration files. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-05-23 05:59 Message: Logged In: YES user_id=75166 htdig-2.0.11-0.1.patch is a revised version of the patch that is compatible with MM 2.0.11 This version removes an incompatibility with Python 2.2 which caused warning messages to be generated when any of the family cron/nightly_htdig scripts were run. Some guidance on file access permissions for some htdig database files needed by rundig have been added to installation notes. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-04-19 06:59 Message: Logged In: YES user_id=75166 htdig-2.0.10-0.1.patch is a revised version of the patch that is compatible with MM 2.0.10 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-04-08 13:46 Message: Logged In: YES user_id=75166 htdig-2.0.9-0.1.patch is a revised version of the patch that is compatible with MM 2.0.9 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-03-06 11:22 Message: Logged In: YES user_id=75166 htdig-2.1cvs-20020306.patch is a revised version of the patch that is compatible with the code published in mailman CVS on sourceforge as 12:30 GMT 6 Mar 2002 Known deficiency is that the non-English versions of files under $build/templates still contain text in English and need translations I cannot do. Also the necessary pygettext activity and subsequent translations in files under $build/messages remain to be done. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-12-17 11:56 Message: Logged In: YES user_id=75166 htdig-2.1cvs-20011217.patch is a revised version of the patch that is compatible with the code published in mailman CVS on sourceforge as 11:50 GMT 17 Dec 2001 The only known deficiency is that the non-English versions of files under $build/templates still contain text in English and need translations I cannot do. Also the necessary pygettext activity and subsequent translations in files under $build/messages remain to be done. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-12-13 11:58 Message: Logged In: YES user_id=75166 htdig-2.1a3-0.1.patch is a revised version of the patch that is compatible with the code published in mailman-2.1a3.tgz on sourceforge. The only known deficiency is that the non-English versions of files under $build/templates still contain text in English and need translations I cannot do. Also the necessary pygettext activity and subsequent translations in files under $build/messages remain to be done. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-28 12:33 Message: Logged In: YES user_id=75166 The htdig-2.0.8-0.1.patch version of the patch resolves a problem that can arise with htdig indexing if the web_page_url for a list uses other than the http addressing (some folks want to use https). While specified as for MM 2.0.8 the revised patch should work OK with 2.0.7, 2.0.6 and probably back as far as 2.0.3. If you do not have the requirement for using other than http addressing in you lists web_page_urls it probably isn't worth the trouble of upgrading to this patch level. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-28 06:08 Message: Logged In: YES user_id=75166 This patch should also apply without problems to MM 2.0.8 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-27 07:00 Message: Logged In: YES user_id=75166 This patch should also apply without problems to Mm 2.0.7 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-09 06:54 Message: Logged In: YES user_id=75166 The htdig-2.0.6-03.patch version of the patch makes some previously hard-coded things configurable and enhances the capability to run the htdig searches and indexing on a different machine to the one delivering Mailman and Mailman's web UI. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=444884&group_id=103 From barry@python.org Thu Aug 8 18:06:39 2002 From: barry@python.org (Barry A. Warsaw) Date: Thu, 8 Aug 2002 13:06:39 -0400 Subject: [Mailman-Developers] Unofficial patches pages Message-ID: <15698.42271.601936.718975@yyz.zope.com> I've created a couple of pages off the Mailman wiki: http://www.zope.org/Members/bwarsaw/MailmanDesignNotes/FrontPage for collecting unofficial patches. SourceForge's patch manager is fine for managing the patches (uploading, updating, describing, commenting on, etc.), but really lousy for collecting them. I need to start closing patches which clearly aren't under consideration, either because they're against MM2.0.x, or because I'm pushing them back to a future release. The wiki pages should be used to describe the patch, and may include a link to the SF patch manager, or to some other location containing the patch (you could also add the patch to a sub-wiki page). SourceForge links will be fine even if the patch itself is closed. Anybody can add patch summaries to this page, although I may go back later and edit them. Please do /not/ add patches to the wiki in-line, that'll just make for an unreadable wiki. Please /do/ include an email address that users of your patch can contact you with. I've seeded the pages with a link to Richard Barrett's ht://Dig patch, for which he's included both a MM2.0.x and an MM2.1 patch. Questions, comments? -Barry From noreply@sourceforge.net Thu Aug 8 18:19:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 08 Aug 2002 10:19:02 -0700 Subject: [Mailman-Developers] [ mailman-Patches-444879 ] Archive indexer control to improve index Message-ID: Patches item #444879, was opened at 2001-07-26 18:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=444879&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 7 Submitted By: Richard Barrett (ppsys) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Archive indexer control to improve index Initial Comment: This patch is applicable to Mailman 2.0.6 release and supercedes ealier patches 401669 and 402422. This patch should improve the quality of search results returned by search engines such as htdig (http://www.htdig.org) where the seach engine's index builder responds to strings embedded in the html pages that are the subject of the indexing. The changes in this patch: 1. allow strings for enabling and disabling indexing to be defined in mm_cfg.py. 2. embeds those strings in the pages generated as the html version of a list's archive. By default nothing in the html changes. To get the desired effect, you must define ARCHIVE_INDEXING_ENABLE and ARCHIVE_INDEXING_DISABLE in mm_cfg.py You probably want to run this patch as follows: cd patch -p1 < See also the associated patch for integrating the htdig search software with mailman's internal archiver ouput. ---------------------------------------------------------------------- >Comment By: Richard Barrett (ppsys) Date: 2002-08-08 17:19 Message: Logged In: YES user_id=75166 An error when building the indexing-2.1b2-0.1.patch meant that copies of the originals of two of the files modified by this version of the patch were added when the patch was run. indexing-2.1b2-0.1.patch removes this error. However, the original error is benign and can be corrected by deleting the extra files HyperArch.py.orig and Defaults.py.in.orig. An additional file, README.NOINDEXtags is added that discusses the issue of what tags to use for controlling various search engine indexers. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-08 14:19 Message: Logged In: YES user_id=12800 Another question: is there no standard (de-facto or otherwise) for generic markup that tells indexers not to index a particular section? IOW, for ARCHIVE_INDEXING_ENABLE and ARCHIVE_INDEXING_DISABLE, is there some generic value that would instruct most (all?) indexers to ignore that section? Or does it necessarily have to be indexer specific? I'm thinking of the situation where you might have ht://Dig installed locally, but your archives are still being spidered by external indexers. It would be good if something more generic could be added to Defaults.py.in ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-08 14:14 Message: Logged In: YES user_id=12800 Looking at the 2.1b2 patch, why does it try to create HyperArch.py.orig and Defaults.py.in.orig? Are those included in the patch by mistake? ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-08-05 10:08 Message: Logged In: YES user_id=75166 indexing-2.0.13-0.2.patch just adds a GPL notice to the patch ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-08-01 16:33 Message: Logged In: YES user_id=75166 indexing-2.1b2-0.1.patch is a revised version of the patch that is compatible with MM 2.1b2 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-07-30 11:23 Message: Logged In: YES user_id=75166 indexing-2.0.13-0.1.patch is purely cosmetic to get no mumble application to MM 2.0.13 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-07-25 14:11 Message: Logged In: YES user_id=75166 indexing-2.0.11-0.1.patch should apply without problems to MM 2.0.12 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-05-23 09:50 Message: Logged In: YES user_id=75166 indexing-2.0.11-0.1.patch is a revised version of the patch that is compatible with MM 2.0.11 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-04-19 10:53 Message: Logged In: YES user_id=75166 indexing-2.0.9-0.1.patch should apply without problems to MM 2.0.10 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-04-08 17:43 Message: Logged In: YES user_id=75166 indexing-2.0.9-0.1.patch is a revised version of the patch that is compatible with MM 2.0.9 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-03-06 16:14 Message: Logged In: YES user_id=75166 indexing-2.1cvs-20020306.patch is a revised version of the patch that is compatible with the code published in mailman CVS on sourceforge as 12:30 GMT 6 Mar 2002. Corrects problem noted or 5 Mar 2002 by nobody ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-03-05 21:41 Message: Logged In: NO When applying this patch I get an error with Hunk 1 and Defaults.py is not updated. This happens with the a clean download of the latest cvs installation (5 Mar 2002). Any ideas what the problem is? ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-12-17 16:53 Message: Logged In: YES user_id=75166 indexing-2.1cvs-20011217.patch is a revised version of the patch that is compatible with the code published in mailman CVS on sourceforge as 11:50 GMT 17 Dec 2001 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-12-13 16:48 Message: Logged In: YES user_id=75166 indexing-2.1a3-0.1.patch is a revised version of the patch that is compatible with the code published in mailman-2.1a3.tgz on sourceforge. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-28 11:07 Message: Logged In: YES user_id=75166 This patch should also apply without problems to MM 2.0.8 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-27 12:03 Message: Logged In: YES user_id=75166 This patch should also apply without problems to MM 2.0.7 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=444879&group_id=103 From noreply@sourceforge.net Thu Aug 8 18:32:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 08 Aug 2002 10:32:29 -0700 Subject: [Mailman-Developers] [ mailman-Patches-444879 ] Archive indexer control to improve index Message-ID: Patches item #444879, was opened at 2001-07-26 18:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=444879&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 7 Submitted By: Richard Barrett (ppsys) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Archive indexer control to improve index Initial Comment: This patch is applicable to Mailman 2.0.6 release and supercedes ealier patches 401669 and 402422. This patch should improve the quality of search results returned by search engines such as htdig (http://www.htdig.org) where the seach engine's index builder responds to strings embedded in the html pages that are the subject of the indexing. The changes in this patch: 1. allow strings for enabling and disabling indexing to be defined in mm_cfg.py. 2. embeds those strings in the pages generated as the html version of a list's archive. By default nothing in the html changes. To get the desired effect, you must define ARCHIVE_INDEXING_ENABLE and ARCHIVE_INDEXING_DISABLE in mm_cfg.py You probably want to run this patch as follows: cd patch -p1 < See also the associated patch for integrating the htdig search software with mailman's internal archiver ouput. ---------------------------------------------------------------------- >Comment By: Richard Barrett (ppsys) Date: 2002-08-08 17:32 Message: Logged In: YES user_id=75166 An additional file, README.NOINDEXtags is added to indexing-2.0.13-0.3.patch version that discusses the issue of what tags to use for controlling various search engine indexers. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-08-08 17:19 Message: Logged In: YES user_id=75166 An error when building the indexing-2.1b2-0.1.patch meant that copies of the originals of two of the files modified by this version of the patch were added when the patch was run. indexing-2.1b2-0.1.patch removes this error. However, the original error is benign and can be corrected by deleting the extra files HyperArch.py.orig and Defaults.py.in.orig. An additional file, README.NOINDEXtags is added that discusses the issue of what tags to use for controlling various search engine indexers. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-08 14:19 Message: Logged In: YES user_id=12800 Another question: is there no standard (de-facto or otherwise) for generic markup that tells indexers not to index a particular section? IOW, for ARCHIVE_INDEXING_ENABLE and ARCHIVE_INDEXING_DISABLE, is there some generic value that would instruct most (all?) indexers to ignore that section? Or does it necessarily have to be indexer specific? I'm thinking of the situation where you might have ht://Dig installed locally, but your archives are still being spidered by external indexers. It would be good if something more generic could be added to Defaults.py.in ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-08 14:14 Message: Logged In: YES user_id=12800 Looking at the 2.1b2 patch, why does it try to create HyperArch.py.orig and Defaults.py.in.orig? Are those included in the patch by mistake? ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-08-05 10:08 Message: Logged In: YES user_id=75166 indexing-2.0.13-0.2.patch just adds a GPL notice to the patch ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-08-01 16:33 Message: Logged In: YES user_id=75166 indexing-2.1b2-0.1.patch is a revised version of the patch that is compatible with MM 2.1b2 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-07-30 11:23 Message: Logged In: YES user_id=75166 indexing-2.0.13-0.1.patch is purely cosmetic to get no mumble application to MM 2.0.13 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-07-25 14:11 Message: Logged In: YES user_id=75166 indexing-2.0.11-0.1.patch should apply without problems to MM 2.0.12 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-05-23 09:50 Message: Logged In: YES user_id=75166 indexing-2.0.11-0.1.patch is a revised version of the patch that is compatible with MM 2.0.11 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-04-19 10:53 Message: Logged In: YES user_id=75166 indexing-2.0.9-0.1.patch should apply without problems to MM 2.0.10 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-04-08 17:43 Message: Logged In: YES user_id=75166 indexing-2.0.9-0.1.patch is a revised version of the patch that is compatible with MM 2.0.9 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-03-06 16:14 Message: Logged In: YES user_id=75166 indexing-2.1cvs-20020306.patch is a revised version of the patch that is compatible with the code published in mailman CVS on sourceforge as 12:30 GMT 6 Mar 2002. Corrects problem noted or 5 Mar 2002 by nobody ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-03-05 21:41 Message: Logged In: NO When applying this patch I get an error with Hunk 1 and Defaults.py is not updated. This happens with the a clean download of the latest cvs installation (5 Mar 2002). Any ideas what the problem is? ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-12-17 16:53 Message: Logged In: YES user_id=75166 indexing-2.1cvs-20011217.patch is a revised version of the patch that is compatible with the code published in mailman CVS on sourceforge as 11:50 GMT 17 Dec 2001 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-12-13 16:48 Message: Logged In: YES user_id=75166 indexing-2.1a3-0.1.patch is a revised version of the patch that is compatible with the code published in mailman-2.1a3.tgz on sourceforge. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-28 11:07 Message: Logged In: YES user_id=75166 This patch should also apply without problems to MM 2.0.8 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-27 12:03 Message: Logged In: YES user_id=75166 This patch should also apply without problems to MM 2.0.7 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=444879&group_id=103 From les@2pi.org Thu Aug 8 18:32:06 2002 From: les@2pi.org (Les Niles) Date: Thu, 8 Aug 2002 10:32:06 -0700 Subject: [Mailman-Developers] Reconstructing config.pck Message-ID: <200208081732.KAA10148@mutiny.2pi.org> We had a little disk glitch that trashed config.pck and config.pck.save for one of our lists [I don't want to even *hear* the word "backup"!] Roughly the last half of each file is nothing but null bytes. These obviously don't unpickle very well.... Does anyone have any experience or advice to offer about recovering some of the information? At a minimum I'd like to recover the subscriber list, and hopefully the digest/no-digest settings. I see lots of subscribers in the file; presumably there are some objects that are intact but the stock pickle.load() just gives up if it can't load everything. Any suggestions would be greatly appreciated. -les From noreply@sourceforge.net Thu Aug 8 18:46:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 08 Aug 2002 10:46:14 -0700 Subject: [Mailman-Developers] [ mailman-Patches-567488 ] possible fix for Hold.py check order Message-ID: Patches item #567488, was opened at 2002-06-11 13:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=567488&group_id=103 Category: list administration Group: Mailman 2.0.x >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Jeff Garvas (jgarvas) Assigned to: Nobody/Anonymous (nobody) Summary: possible fix for Hold.py check order Initial Comment: I don't like the way Mailman checks posts in Hold.py -- I posted to mailman-users and created a bug, but this was probably too low of a priority for anyone to notice it. Basically I want to know if a user posting to a list is a subscriber (even if the list is moderated) when the list is in "subscriber only" mode. I went into Hold.py, knowing almost nothing about Python, and basically took the if block that checks for moderated status and moved it below the if block that checks for subscriber status. I created this patch by putting my version of Hold.py in the root of the directory you get when you un-tar mailman, then I ran: diff -C 2 Mailman/Handlers/Hold.py Hold.py This might not be the proper way to make the patch file, but I've never done it before. I would like some input/feedback on if this is safe. I can't fathom this breaking anything, but others obviously know this code much better than I do -- I just learned how to compile my python script last night ;) -Jeff ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-08 13:46 Message: Logged In: YES user_id=12800 Your patch looks fine, but I'm closing it anyway. ;) It's out of date for MM2.1. Thanks though! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=567488&group_id=103 From barry@python.org Thu Aug 8 19:11:22 2002 From: barry@python.org (Barry A. Warsaw) Date: Thu, 8 Aug 2002 14:11:22 -0400 Subject: [Mailman-Developers] Reconstructing config.pck References: <200208081732.KAA10148@mutiny.2pi.org> Message-ID: <15698.46154.996710.875996@anthem.wooz.org> >>>>> "LN" == Les Niles writes: LN> We had a little disk glitch that trashed config.pck and LN> config.pck.save for one of our lists [I don't want to even LN> *hear* the word "backup"!] I'm not sure what config.pck.save is -- did you mean config.pck.last? Also, do you have a config.pck.tmp.* file laying around? Mailman tries really really hard not to leave you with no usable fall backs. LN> Roughly the last half of each file is nothing but null bytes. LN> These obviously don't unpickle very well.... Does anyone have LN> any experience or advice to offer about recovering some of the LN> information? At a minimum I'd like to recover the subscriber LN> list, and hopefully the digest/no-digest settings. I see lots LN> of subscribers in the file; presumably there are some objects LN> that are intact but the stock pickle.load() just gives up if LN> it can't load everything. Any suggestions would be greatly LN> appreciated. There's no easy way to do it, but it still might be doable. The subscribers are kept in a dictionary so you can probably extract that information if you find the place in the pickle where the dictionary is defined. Here's the sad part: by default, pickles are written in binary format so you're going to have a more fun plucking apart the pickle. Pickles are essentially little state machines, and the `language' is defined in Python's pickle.py module. UTSL is probably going to be your best option. Good luck, -Barry From donn@u.washington.edu Thu Aug 8 19:18:48 2002 From: donn@u.washington.edu (Donn Cave) Date: Thu, 8 Aug 2002 11:18:48 -0700 Subject: [Mailman-Developers] Reconstructing config.pck Message-ID: <200208081818.g78IImeD008278@mailhost2.u.washington.edu> Quoth barry@python.org (Barry A. Warsaw): ... | Here's the sad part: by default, pickles are written in binary format | so you're going to have a more fun plucking apart the pickle. Pickles | are essentially little state machines, and the `language' is defined | in Python's pickle.py module. UTSL is probably going to be your best | option. Stuff accumulates in Unpickler().stack, so assuming there's nothing of interest after the start of invalid data, one could catch the exception and examine "stack". Beats vi, maybe. Donn Cave, donn@u.washington.edu From barry@python.org Thu Aug 8 19:29:47 2002 From: barry@python.org (Barry A. Warsaw) Date: Thu, 8 Aug 2002 14:29:47 -0400 Subject: [Mailman-Developers] Reconstructing config.pck References: <200208081818.g78IImeD008278@mailhost2.u.washington.edu> Message-ID: <15698.47259.354106.969936@anthem.wooz.org> >>>>> "DC" == Donn Cave writes: DC> Stuff accumulates in Unpickler().stack, so assuming there's DC> nothing of interest after the start of invalid data, one could DC> catch the exception and examine "stack". Beats vi, maybe. Ah good point. Use the Python pickle.py module, not the cPickle.py module for easier introspection. For Mailman's uses the two should be interchangeable. -Barry From les@2pi.org Thu Aug 8 19:31:48 2002 From: les@2pi.org (Les Niles) Date: Thu, 8 Aug 2002 11:31:48 -0700 Subject: [Mailman-Developers] Reconstructing config.pck In-Reply-To: <15698.46154.996710.875996@anthem.wooz.org> (barry@python.org) References: <200208081732.KAA10148@mutiny.2pi.org> <15698.46154.996710.875996@anthem.wooz.org> Message-ID: <200208081831.LAA13065@mutiny.2pi.org> On Thu, 8 Aug 2002 14:11:22 -0400 barry@python.org (Barry A. Warsaw) wrote: >I'm not sure what config.pck.save is -- did you mean config.pck.last? >Also, do you have a config.pck.tmp.* file laying around? Mailman >tries really really hard not to leave you with no usable fall backs. Yes, I meant config.pck.last. And there aren't any config.pck.anything-elses. Just to be clear, this wasn't a Mailman problem AFAICT; the files got corrupted on the disk. On Thu, 8 Aug 2002 11:18:48 -0700 "Donn Cave" wrote: >Quoth barry@python.org (Barry A. Warsaw): >... >| Here's the sad part: by default, pickles are written in binary format >| so you're going to have a more fun plucking apart the pickle. Pickles >| are essentially little state machines, and the `language' is defined >| in Python's pickle.py module. UTSL is probably going to be your best >| option. > >Stuff accumulates in Unpickler().stack, so assuming there's nothing >of interest after the start of invalid data, one could catch the >exception and examine "stack". That would help, not having to do all the parsing by hand at least. I'll give it a shot. >Beats vi, maybe. Emacs, man. Someone's probably even written python-pickle-mode. Thanks, Barry and Donn. -les From barry@python.org Thu Aug 8 19:35:55 2002 From: barry@python.org (Barry A. Warsaw) Date: Thu, 8 Aug 2002 14:35:55 -0400 Subject: [Mailman-Developers] Reconstructing config.pck References: <200208081732.KAA10148@mutiny.2pi.org> <15698.46154.996710.875996@anthem.wooz.org> <200208081831.LAA13065@mutiny.2pi.org> Message-ID: <15698.47627.991881.763481@anthem.wooz.org> >>>>> "LN" == Les Niles writes: LN> Yes, I meant config.pck.last. And there aren't any LN> config.pck.anything-elses. Just to be clear, this wasn't a LN> Mailman problem AFAICT; the files got corrupted on the disk. Dang. Yup, nothing much Mailman can do if those file operations silently fail. :( LN> That would help, not having to do all the parsing by hand at LN> least. I'll give it a shot. Cool let us know. >> Beats vi, maybe. LN> Emacs, man. Someone's probably even written LN> python-pickle-mode. LN> Thanks, Barry and Donn. N.p. avoiding-the-editor-war-bait--ly y'rs, :) -Barry From barry@python.org Fri Aug 9 00:31:24 2002 From: barry@python.org (Barry A. Warsaw) Date: Thu, 8 Aug 2002 19:31:24 -0400 Subject: [Mailman-Developers] Maildir delivery Message-ID: <15698.65356.235691.261812@anthem.wooz.org> I spent a little bit of time today playing with a Qmail-style maildir delivery mechanism instead of the current mail program approach. I'm using a modern Postfix. The idea is that if we can avoid setting the delivery aliases to a mail program (i.e. scripts/{post,bounces,confirm,...}) and instead let the MTA do maildir delivery, we can avoid having to fork a process for each message coming into the system. Maildir is nice because we don't have to worry about locking to avoid race conditions or contention on the drop files. Another advantage is that we can essentially do away with the wrapper program, but see below for caveats. Costs/risks might include increased disk i/o because of additional file renames and unlinks, or increased cpu due to inefficiencies in the code. I believe I have the whole thing working. There's a new qrunner called MaildirRunner, which is fairly different internally than the other qrunners. But the idea is essentially the same: every time through its loop it looks at the files in qfiles/maildir/new and processes each one in turn. If it can't atomically rename the file to qfiles/maildir/cur/:1,P it assumes some other MaildirRunner has already processed the file and moves on. So I think we can still have multiple MaildirRunners and not have to worry about race conditions. A couple of caveats: - The mailprog approach actually encodes some useful information in the aliases, such as the listname and the "subqueue" the message is destined for (i.e. -bounces, -request, etc.). These aren't available when using Maildir so we need to grok that information out of some header, preferrably the envelope recipient. Postfix puts the envelope recip in Delivery-To: and other MTAs do something similar using different headers, but of course there's no standard. ;). If it gets this part wrong, it won't be able to deliver the message. Still, I think it's tractable, and verp bounce detection has some similar issues anyway. An alternative is a more elaborate and inefficient maildir layout, where each list and each subqueue has its own new, cur, and tmp subdirectories. Blech. - If there are any problems in processing the maildir file, MaildirRunner leaves it in qfiles/maildir/cur/:1,X and it will never look at it again. The nice thing is that you need only mv one file back to qfiles/maildir/new to get MaildirRunner to look at it again. I still think it's difficult-to-impossible to lose a message or deliver it twice. - Because of the way Postfix handles the permissions on the files and directories, you would have to start mailmanctl as root or as mailman. I don't know how many other people use mailmanctl's -u option and run the qrunners as their own uid. I do it all the time for debugging, but I may be unique, so this may be a non-issue except for testing. - To switch to Maildir delivery, you'd need to re-run bin/genaliases. I'm sure the list auto-detection recipies for Exim and qmail would have to change accordingly, and I don't know what special permission or filesystem layout issues might exist. Where should I go from here? I'm willing to put up a patch set on SF if folks want to play with it. I'm also willing to check it into cvs, but /only/ if it's labeled experimental for MM2.1. I think this could improve the efficiency of handling incoming message, but it's equally likely my code is being too naive. I don't want to officially support it for MM2.1, but I /would/ like to get some feedback and experience with it. Comments, thoughts? -Barry From Daniel.Buchmann@bibsys.no Fri Aug 9 00:36:52 2002 From: Daniel.Buchmann@bibsys.no (Daniel Buchmann) Date: 09 Aug 2002 01:36:52 +0200 Subject: [Mailman-Developers] Maildir delivery In-Reply-To: <15698.65356.235691.261812@anthem.wooz.org> References: <15698.65356.235691.261812@anthem.wooz.org> Message-ID: <1028849814.2374.6.camel@fornax.bibsys.no> ---------------------- multipart/signed attachment On Fri, 2002-08-09 at 01:31, Barry A. Warsaw wrote: > Where should I go from here? I'm willing to put up a patch set on SF > if folks want to play with it. I'm also willing to check it into cvs, > but /only/ if it's labeled experimental for MM2.1. I think this could > improve the efficiency of handling incoming message, but it's equally > likely my code is being too naive. I don't want to officially support > it for MM2.1, but I /would/ like to get some feedback and experience > with it. >=20 > Comments, thoughts? > -Barry Sounds nice to me, though I hope this is something you will add in MM2.2 (or 3.0 if there never is a 2.2 ;). Because 2.1 _really_ should go out the door Real Soon(tm). ;) Maybe using Maildir will make it easier to fully support virtual domains in the future? i.e. two lists having the same name but different domains? This is a feature I'm really waiting for in the next version. (And I'm sure I'm not the only one..) Just my $0.02. :) -Daniel ---------------------- multipart/signed attachment A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail-21/mailman-developers/attachments/f7edf37e/attachment.bin ---------------------- multipart/signed attachment-- From casterln@nature.Berkeley.EDU Fri Aug 9 00:57:26 2002 From: casterln@nature.Berkeley.EDU (Gary Casterline) Date: Thu, 8 Aug 2002 16:57:26 -0700 Subject: [Mailman-Developers] bounces going to wrong list's admin Message-ID: <20020808235726.GA11737@nature.Berkeley.EDU> Hi, I've seen reference to this problem on mailman users and dev and thought I'd try report it as well. When the monthly reminders go out, a lot of the messages bounce. These bounce messages should go the the list's admin address. However we're seeing way too many go to one particular list admin. (Luckily this person is very patient.:) I've appended one of the bounce messages from a bad listA address, that arrived at the listB admin's address. Our setup: Mailman version 2.0.13 Python 2.2.1 (#1, Apr 20 2002, 13:05:01) [C] on sunos5 Postfix snapshot 1.1.11-20020717 (no virtual servers) Solaris 8 Aliases are of this form for our lists, where wrapper is in our sm.bin directory as a symlink to ~mailman/mail/wrapper ## listA mailing list ## created: 08-Jun-2001 mailman listA: "|/wrapper post listA" listA-admin: "|/wrapper mailowner listA" listA-request: "|/wrapper mailcmd listA" listA-owner: listA-admin ## listB mailing list ## created: 06-Dec-2001 mailman listB: "|/wrapper post listB" listB-admin: "|/wrapper mailowner listB" listB-request: "|/wrapper mailcmd listB" listB-owner: listB-admin > From listB-admin@nature.Berkeley.EDU Thu Aug 1 05:04:04 2002 > Return-Path: > Delivered-To: actual-listBadmin@nature.berkeley.edu > Received: from nature.Berkeley.EDU (localhost [127.0.0.1]) > by nature.Berkeley.EDU (Postfix) with ESMTP id 742C4261271 > for ; Thu, 1 Aug 2002 05:04:04 -= 0700 (PDT) > Delivered-To: listB-admin@nature.berkeley.edu > Received: by nature.Berkeley.EDU (Postfix) > id 3B6BB26135E; Thu, 1 Aug 2002 05:03:29 -0700 (PDT) > Date: Thu, 1 Aug 2002 05:03:29 -0700 (PDT) > From: MAILER-DAEMON@nature.Berkeley.EDU (Mail Delivery System) > Subject: Undelivered Mail Returned to Sender > To: listB-admin@nature.Berkeley.EDU > MIME-Version: 1.0 > X-Security: MIME headers sanitized on nature.Berkeley.EDU > See http://www.impsec.org/email-tools/sanitizer-intro.html > for details. $Revision: 1.135 $Date: 2002-05-26 21:19:33-07=20 > Content-Type: multipart/report; report-type=3Ddelivery-status; > boundary=3D"16E6D261360.1028203409/nature.Berkeley.EDU" > Message-Id: <20020801120329.3B6BB26135E@nature.Berkeley.EDU> > Sender: listB-owner@nature.Berkeley.EDU > Errors-To: listB-owner@nature.Berkeley.EDU > X-BeenThere: listB@nature.Berkeley.EDU > X-Mailman-Version: 2.0.13 > Precedence: bulk > List-Unsubscribe: , > > List-Id: ArcIMS User Group > List-Post: > List-Help: > List-Subscribe: , > > List-Archive: > X-Keywords: =20 > X-UID: 533 > Status: RO > Content-Length: 2818 > Lines: 78 >=20 > This is a MIME-encapsulated message. >=20 > --16E6D261360.1028203409/nature.Berkeley.EDU > Content-Description: Notification > Content-Type: text/plain >=20 > This is the Postfix program at host nature.Berkeley.EDU. >=20 > I'm sorry to have to inform you that the message returned > below could not be delivered to one or more destinations. >=20 > For further assistance, please send mail to >=20 > If you do so, please include this problem report. You can > delete your own text from the message returned below. >=20 > The Postfix program >=20 > : bad host/domain syntax: "somewhere.net?" >=20 > --16E6D261360.1028203409/nature.Berkeley.EDU > Content-Description: Delivery error report > Content-Type: message/delivery-status >=20 > Reporting-MTA: dns; nature.Berkeley.EDU > Arrival-Date: Thu, 1 Aug 2002 05:03:29 -0700 (PDT) >=20 > Final-Recipient: rfc822; username@somewhere.net? > Action: failed > Status: 5.0.0 > Diagnostic-Code: X-Postfix; bad host/domain syntax: "somewhere.net?" >=20 > --16E6D261360.1028203409/nature.Berkeley.EDU > Content-Description: Undelivered Message > Content-Type: message/rfc822 >=20 > Received: from nature.Berkeley.EDU (localhost [127.0.0.1]) > by nature.Berkeley.EDU (Postfix) with ESMTP id 16E6D261360 > for ; Thu, 1 Aug 2002 05:03:29 -0700 (PDT) > Date: Thu, 01 Aug 2002 05:03:29 -0700 > Message-ID: <20020801120329.25397.38722.Mailman@nature.Berkeley.EDU> > Subject: nature.Berkeley.EDU mailing list memberships reminder > From: mailman-owner@nature.Berkeley.EDU > To: username@somewhere.net=15 > X-No-Archive: yes > X-Ack: no > Sender: listB-admin@nature.Berkeley.EDU > Errors-To: listB-admin@nature.Berkeley.EDU > X-BeenThere: listB@nature.Berkeley.EDU > X-Mailman-Version: 2.0.13 > Precedence: bulk >=20 > This is a reminder, sent out once a month, about your > nature.Berkeley.EDU mailing list memberships. It includes your > subscription info and how to use it to change it or unsubscribe from a > list. >=20 > You can visit the URLs to change your membership status or > configuration, including unsubscribing, setting digest-style delivery > or disabling delivery altogether (e.g., for a vacation), and so on. >=20 > In addition to the URL interfaces, you can also use email to make such > changes. For more info, send a message to the '-request' address of > the list (for example, listA-request@nature.Berkeley.EDU) containing > just the word 'help' in the message body, and an email message will be > sent to you with instructions. >=20 > If you have questions, problems, comments, etc, send them to > mailman-owner@nature.Berkeley.EDU. Thanks! >=20 > Passwords for username@somewhere.net=15: >=20 > List Password // URL > ---- -------- =20 > listA@nature.Berkeley.EDU xxxxxx =20 > http://nature.Berkeley.EDU/mailman/options/listA/username%40somewhere.net= %15 >=20 > --16E6D261360.1028203409/nature.Berkeley.EDU-- >=20 From jb@cascade-sys.com Fri Aug 9 02:11:11 2002 From: jb@cascade-sys.com (James J. Besemer) Date: Thu, 08 Aug 2002 18:11:11 -0700 Subject: [Mailman-Developers] Bugs (?) Fixed (?) Message-ID: <3D5316AF.84505728@cascade-sys.com> 1. I'm using mailman to run a few lists and I just recently noticed that Archived messages show "From:" as the listname (user name) instead of just the user name and address. (user name) is missing if the user's address doesn't include a plain name. Is there a way to change it so the address shows? This is a small, private list where people want to search by names.. 2. My computer hosts 2 domain names. I setup as list and told it to use domain_name1. But it sends out messages from domain_name2. What's the fix for this? Regards --jb -- James J. Besemer 503-280-0838 voice http://cascade-sys.com 503-280-0375 fax mailto:jb@cascade-sys.com From claw@kanga.nu Fri Aug 9 07:36:02 2002 From: claw@kanga.nu (J C Lawrence) Date: Thu, 08 Aug 2002 23:36:02 -0700 Subject: [Mailman-Developers] Maildir delivery In-Reply-To: Message from barry@python.org (Barry A. Warsaw) of "Thu, 08 Aug 2002 19:31:24 EDT." <15698.65356.235691.261812@anthem.wooz.org> References: <15698.65356.235691.261812@anthem.wooz.org> Message-ID: <16800.1028874962@kanga.nu> On Thu, 8 Aug 2002 19:31:24 -0400 Barry A Warsaw wrote: > An alternative is a more elaborate and inefficient maildir layout, > where each list and each subqueue has its own new, cur, and tmp > subdirectories. Blech. This has a significant benefit as well. Given that Maildir is NFS safe we get the possibility of: -- A single machine receives all inbound mail for all lists. -- Machine Q process mail for lists A, B, and C, -- Machine R processes mail for lists D and E. -- etc for other machines. Instant parallelism, just add list-specific qrunners. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From barry@python.org Fri Aug 9 16:06:17 2002 From: barry@python.org (Barry A. Warsaw) Date: Fri, 9 Aug 2002 11:06:17 -0400 Subject: [Mailman-Developers] Maildir delivery References: <15698.65356.235691.261812@anthem.wooz.org> <16800.1028874962@kanga.nu> Message-ID: <15699.55913.814809.979055@anthem.wooz.org> >>>>> "JCL" == J C Lawrence writes: >> An alternative is a more elaborate and inefficient maildir >> layout, where each list and each subqueue has its own new, cur, >> and tmp subdirectories. Blech. JCL> This has a significant benefit as well. Given that Maildir JCL> is NFS safe we get the possibility of: JCL> -- A single machine receives all inbound mail for all JCL> lists. JCL> -- Machine Q process mail for lists A, B, and C, JCL> -- Machine R processes mail for lists D and E. JCL> -- etc for other machines. JCL> Instant parallelism, just add list-specific qrunners. Hmm, that's interesting. So there two use-cases: - You have one machine to process all your list traffic. You'd want a single maildir so that one MaildirRunner can handle everything. - You have a few machines to process your list traffic. You'd want to be able to group some lists together so that their messages can be handled by some smaller number of MaildirRunners. Sounds like you'd want a mapping between mailing lists and maildirs. I think that'd be doable, if I can tease out a sensible set of configuration variables. -Barry From chuqui@plaidworks.com Fri Aug 9 16:30:10 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Fri, 09 Aug 2002 08:30:10 -0700 Subject: [Mailman-Developers] Maildir delivery In-Reply-To: <15699.55913.814809.979055@anthem.wooz.org> Message-ID: On 8/9/02 8:06 AM, "Barry A. Warsaw" wrote: > So there two use-cases: > > - You have one machine to process all your list traffic. You'd want a > single maildir so that one MaildirRunner can handle everything. Would this be another use of multiple maildirs? You have a list server where some lists get priority. They need to be handled first (immediately?) if they get postings. Others are lower priority, and should be handled when nothing "more important" needs to be done. By splitting into maildirs, you can assign priorities to things, and instead of FIFOing stuff, work down a priority list instead.... -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ The Cliff's Notes Cliff's Notes on Hamlet: And they all died happily ever after From barry@python.org Fri Aug 9 16:50:03 2002 From: barry@python.org (Barry A. Warsaw) Date: Fri, 9 Aug 2002 11:50:03 -0400 Subject: [Mailman-Developers] Maildir delivery References: <15699.55913.814809.979055@anthem.wooz.org> Message-ID: <15699.58539.576926.776704@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: >> So there two use-cases: - You have one machine to process all >> your list traffic. You'd want a single maildir so that one >> MaildirRunner can handle everything. CVR> Would this be another use of multiple maildirs? CVR> You have a list server where some lists get priority. They CVR> need to be handled first (immediately?) if they get CVR> postings. Others are lower priority, and should be handled CVR> when nothing "more important" needs to be done. By splitting CVR> into maildirs, you can assign priorities to things, and CVR> instead of FIFOing stuff, work down a priority list CVR> instead.... Yes, that's another use case. The current way qrunners get priority is by adjusting their snooze time (the sleep time between iterations their their processing loop). You could give a higher snooze time to lower priority MaildirRunners. Eventually (read: post 2.1) we might want to tease out a more elaborate scheduling mechanism. E.g. you'd like to be able to process low priority queues if the higher priority queues are idle. Here's a plan: I will check in the existing code and label it experimental for 2.1. It won't have an easy way to configure multiple maildirs, but I think enough of the basic code is in place that folks can play with it, and the more Pythonically oriented developers could adapt it to a multiple maildir architecture. -Barry From claw@kanga.nu Fri Aug 9 17:03:05 2002 From: claw@kanga.nu (J C Lawrence) Date: Fri, 09 Aug 2002 09:03:05 -0700 Subject: [Mailman-Developers] Maildir delivery In-Reply-To: Message from Chuq Von Rospach of "Fri, 09 Aug 2002 08:30:10 PDT." References: Message-ID: <21453.1028908985@kanga.nu> On Fri, 09 Aug 2002 08:30:10 -0700 Chuq Von Rospach wrote: > You have a list server where some lists get priority. They need to be > handled first (immediately?) if they get postings. Others are lower > priority, and should be handled when nothing "more important" needs to > be done. By splitting into maildirs, you can assign priorities to > things, and instead of FIFOing stuff, work down a priority list > instead.... Ooooo, I like. That's three uses. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From noreply@sourceforge.net Fri Aug 9 19:07:21 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 09 Aug 2002 11:07:21 -0700 Subject: [Mailman-Developers] [ mailman-Patches-401670 ] integration of htdig with per list archive search Message-ID: Patches item #401670, was opened at 2000-09-26 09:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=401670&group_id=103 Category: Web UI Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Richard Barrett (ppsys) Assigned to: Nobody/Anonymous (nobody) Summary: integration of htdig with per list archive search Initial Comment: ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-07-26 14:33 Message: Logged In: YES user_id=75166 Superceded by 444884 ---------------------------------------------------------------------- Comment By: Nigel Metheringham (nigel) Date: 2000-11-17 10:22 Message: Replaced by 102423 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2000-10-10 04:00 Message: Added line to force re-write of list archive's TOC page by cron script (cron/nightly_htdig) that re-indexes archives every time the cron script runs. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2000-09-26 11:32 Message: Fixed indentation error which will cause the htdig search form to disappear from a list's TOC page when that list's archives roll over and a new archive volume is created. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=401670&group_id=103 From barry@python.org Fri Aug 9 16:09:17 2002 From: barry@python.org (Barry A. Warsaw) Date: Fri, 9 Aug 2002 11:09:17 -0400 Subject: [Mailman-Developers] Maildir delivery References: <15698.65356.235691.261812@anthem.wooz.org> <1028849814.2374.6.camel@fornax.bibsys.no> Message-ID: <15699.56093.475654.159756@anthem.wooz.org> >>>>> "DB" == Daniel Buchmann writes: DB> Sounds nice to me, though I hope this is something you will DB> add in MM2.2 (or 3.0 if there never is a 2.2 ;). Because 2.1 DB> _really_ should go out the door Real Soon(tm). ;) I know. I /will/ release a new beta today, no matter what (famous last words ;). DB> Maybe using Maildir will make it easier to fully support DB> virtual domains in the future? i.e. two lists having the same DB> name but different domains? This is a feature I'm really DB> waiting for in the next version. (And I'm sure I'm not the DB> only one..) It might help, but it's not the only thing. At the least, the domain needs to be encoded in the filesystem location of the config.pck file so that all lists don't just live in the same lists/ directory. There may be more internal changes necessary, and of course, sticking all the data in a database wouldn't hurt. :) But yes, 2.2 or 3.0. -Barry From barry@python.org Fri Aug 9 19:41:30 2002 From: barry@python.org (Barry A. Warsaw) Date: Fri, 9 Aug 2002 14:41:30 -0400 Subject: [Mailman-Developers] bounces going to wrong list's admin References: <20020808235726.GA11737@nature.Berkeley.EDU> Message-ID: <15700.3290.388914.780312@anthem.wooz.org> >>>>> "GC" == Gary Casterline writes: GC> When the monthly reminders go out, a lot of the messages GC> bounce. These bounce messages should go the the list's GC> admin address. However we're seeing way too many go to GC> one particular list admin. (Luckily this person is very GC> patient.:) This is just a byproduct of the way password reminders are sent in MM2.0.x. They appear to come from the first public mailing list on the domain. In MM2.1 they'll come from the `site list' so individual list owners won't be bothered. -Barry From noreply@sourceforge.net Fri Aug 9 20:23:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 09 Aug 2002 12:23:49 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-592026 ] Managing Discussion Lists Message-ID: Bugs item #592026, was opened at 2002-08-07 08:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=592026&group_id=103 Category: configuring/installing Group: None Status: Open >Resolution: Works For Me Priority: 5 Submitted By: H. Peter Aitken (benchmark) Assigned to: Nobody/Anonymous (nobody) Summary: Managing Discussion Lists Initial Comment: I have a Discussion List associated with my web-site hosted by Dreamhost. Dreamhost informs me that they use Mailman software and that I should contact you with information about this "known bug." Navigating through Discussion Lists -> Membership Management to the list in question, I tried to change the value of "The public name of this list (make case changes only)" so that it would appear in UPPER CASE LETTERS. I made no other changes. Then I hit the "Submit" button. But the change is not implemented. Please will you tell me how I can resolve this issue or whether you are working on a fix. Thank you. Peter Aitken peter@benchmarkresearch.org ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-09 15:23 Message: Logged In: YES user_id=12800 I can't reproduce this in either MM2.1 or MM2.0.13. What version are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=592026&group_id=103 From noreply@sourceforge.net Fri Aug 9 20:24:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 09 Aug 2002 12:24:07 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-592026 ] real_name can't be changed Message-ID: Bugs item #592026, was opened at 2002-08-07 08:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=592026&group_id=103 Category: configuring/installing Group: None Status: Open Resolution: Works For Me Priority: 5 Submitted By: H. Peter Aitken (benchmark) Assigned to: Nobody/Anonymous (nobody) >Summary: real_name can't be changed Initial Comment: I have a Discussion List associated with my web-site hosted by Dreamhost. Dreamhost informs me that they use Mailman software and that I should contact you with information about this "known bug." Navigating through Discussion Lists -> Membership Management to the list in question, I tried to change the value of "The public name of this list (make case changes only)" so that it would appear in UPPER CASE LETTERS. I made no other changes. Then I hit the "Submit" button. But the change is not implemented. Please will you tell me how I can resolve this issue or whether you are working on a fix. Thank you. Peter Aitken peter@benchmarkresearch.org ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-09 15:23 Message: Logged In: YES user_id=12800 I can't reproduce this in either MM2.1 or MM2.0.13. What version are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=592026&group_id=103 From noreply@sourceforge.net Fri Aug 9 20:24:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 09 Aug 2002 12:24:59 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-589387 ] can user@host.com = user@abc.host.com? Message-ID: Bugs item #589387, was opened at 2002-07-31 17:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=589387&group_id=103 Category: security/privacy Group: 2.0.x >Status: Pending Resolution: None Priority: 5 Submitted By: Paul Marshall (paulmarshll) Assigned to: Nobody/Anonymous (nobody) Summary: can user@host.com = user@abc.host.com? Initial Comment: I have people who subscribe under user@host.com however, their email is identified as user@abc.host.com. When Mailman sees this it rejects the post claiming that user@abc.host.com isn't subscribed to the list. This problem is very similar to the one listed here: http://mail.python.org/pipermail/mailman-users/2002- July/021343.html I tried the solution that the person suggested, modifying SMART_ADDRESS_MATCH =3D 1 in mm_cfg.py, however this still didn't work. I tried it with it set as: SMART_ADDRESS_MATCH = 1 SMART_ADDRESS_MATCH =3D 1 SMART_ADDRESS_MATCH = 0 Although none of these worked, I am assuming it has to be set to true (1). Anyone have any ideas on why that isn't working or whatelse I may need to do? Thanks. Paul ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-09 15:24 Message: Logged In: YES user_id=12800 Changing status to Pending, waiting for more information. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-01 15:47 Message: Logged In: YES user_id=12800 Well the default of SMART_ADDRESS_MATCH is 1 which should turn on smart address matching. However it's possible that what is actually showing up in the From: field (or Sender: depending on if USE_ENVELOPE_SENDER) is set may not be what you think it is. You should upload a message, with full headers intact for a message that you think is getting incorrectly blocked. Also give the values of SMART_ADDRESS_MATCH and USE_ENVELOPE_SENDER, and include the address that you think this message should have matched. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=589387&group_id=103 From noreply@sourceforge.net Fri Aug 9 20:26:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 09 Aug 2002 12:26:06 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-571636 ] Traceback in error log - bounce handling Message-ID: Bugs item #571636, was opened at 2002-06-20 09:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=571636&group_id=103 Category: bounce detection Group: 2.1 beta >Status: Pending Resolution: None Priority: 5 Submitted By: Daniel Buchmann (avalon) Assigned to: Nobody/Anonymous (nobody) Summary: Traceback in error log - bounce handling Initial Comment: I got this traceback in my error log: Jun 20 14:58:56 2002 (1992) Traceback (most recent call last): File "/home/mailman/Mailman/Queue/Runner.py", line 105, in __oneloop self.__onefile(msg, msgdata) File "/home/mailman/Mailman/Queue/Runner.py", line 154, in __onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/home/mailman/Mailman/Queue/BounceRunner.py", line 71, in _dispose addrs = BouncerAPI.ScanMessages(mlist, msg) File "/home/mailman/Mailman/Bouncers/BouncerAPI.py", line 60, in ScanMessages addrs = sys.modules[modname].process(msg) File "/home/mailman/Mailman/Bouncers/Microsoft.py", line 35, in process body = StringIO(subpart.get_payload()) TypeError: expected read buffer, list found The following had probably happened: 1. A spam mail was sent to one of our lists. 2. The list tried to send a "waiting for moderator approval" mail to the sender of the spam mail. 3. The "waiting for moderator approval" mail bounced (because the sender address was, of course, invalid). The bounce in (3) gave me the traceback and was moved to qfiles/shunt/. PCK file is attached to this bug report. Let me know if you need the DB file too... :) ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-09 15:26 Message: Logged In: YES user_id=12800 I think we resolved this one, didn't we? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=571636&group_id=103 From noreply@sourceforge.net Fri Aug 9 20:32:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 09 Aug 2002 12:32:12 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-571004 ] member_posting_only does not work Message-ID: Bugs item #571004, was opened at 2002-06-19 03:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=571004&group_id=103 Category: security/privacy Group: 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: Josef Grosch (jgrosch) Assigned to: Nobody/Anonymous (nobody) Summary: member_posting_only does not work Initial Comment: Version 2.0.11 on FreeBSD 4.6 Mailman allows people who are not on the list are allowed to post. member_posting_only is set yes but non members are still posting. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-09 15:32 Message: Logged In: YES user_id=12800 Several reasons why this could appear so: - mail headers are being forged, so they are passing the membership tests - the addresses are on the "members accepted for posting" list (e.g. the `posters' variable) - the postings are being held but a moderator is approving them I can't reproduce this, so I'll need more information. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=571004&group_id=103 From noreply@sourceforge.net Fri Aug 9 20:38:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 09 Aug 2002 12:38:39 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-566691 ] check for subscriber fails w/ moderated Message-ID: Bugs item #566691, was opened at 2002-06-10 01:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=566691&group_id=103 Category: security/privacy Group: 2.0.x >Status: Closed Resolution: None Priority: 5 Submitted By: Jeff Garvas (jgarvas) Assigned to: Nobody/Anonymous (nobody) Summary: check for subscriber fails w/ moderated Initial Comment: When you run a list that is non-moderated, but you limit posts to the subscribers list, a post by a non-member results in this error: Reason: Post by non-member to a members-only list If you go into "Privacy Options" and change "Must posts be approved by an administrator?" and maintain "Restrict posting privilege to list members" a post by a non-subscriber results in THIS reason: Reason: Post to moderated list Unless I am missing a configuration option, I believe this is a flaw in the order in which mailman is checking posts. Even if a list is moderated, the reason this individual post was rejected should still read Reason: Post by non-member to a members-only list or, a new reason should be made like this: Reason: Post by a non-member to a members-only AND moderated list This may seem like a silly request, but if you run a members only list that happens to be moderated as well, you run into the problem of accidentally approving a post from a non-member when the content of that post was "on topic". Is there a fix for this? Would this classify as a bug? Does anyone know of any other work arounds? When you have a few thousand people on a mailing list, its not really easy to realize on your own that a specific individual isn't a subscriber to the list. Especially when you have multiple individuals help administrate the list itself. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-09 15:38 Message: Logged In: YES user_id=12800 I'm closing this bug report, because I've commented favorably on the patch you posted, even though (sadly) it won't be applied to MM2.0.x and isn't applicable to MM2.1. ---------------------------------------------------------------------- Comment By: Jeff Garvas (jgarvas) Date: 2002-06-11 00:50 Message: Logged In: YES user_id=560554 I've been experimenting with Mailman/Handlers/Hold.py (playing with python for the first time ever) and after spending some time trying to figure out how to compile it, I came up with a simple idea. I moved the code that checks if the list is moderated to immediately after the code that checks if the list is "subscriber only" and the post is coming from a subscriber or not. The result: Exactly what I want. However, I don't know if I've managed to miss something obvious by doing this. Have I possibly broken an aspect of Mailman and I'm not realizing it? With this modification to Hold.py a post from a non- subscriber to a moderated (and subscriber only) list ends up in the administrative queue with a reason of "Post by non- member to member-only list" instead of a moderated list bounce. This seems like the logical and proper way for this to operate. Can someone tell me if this appears to be a safe and proper solution? If so, I think it should be rolled into the current version. I generated a patch file with diff -C 2, attached here, but possibly not created properly. Beware when running it! :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=566691&group_id=103 From noreply@sourceforge.net Fri Aug 9 20:36:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 09 Aug 2002 12:36:03 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-568456 ] base64 messages not decoded in archives Message-ID: Bugs item #568456, was opened at 2002-06-13 06:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=568456&group_id=103 Category: Pipermail Group: 2.0.x >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Benjamin Geer (beroul) Assigned to: Nobody/Anonymous (nobody) Summary: base64 messages not decoded in archives Initial Comment: It appears that messages in base-64 encoding are not decoded in pipermail archives with Mailman 2.0.8. For example: http://lists.southspace.net/pipermail/esf-uk-coordinators/2002-June/000009.html In some cases I can tell people to switch to 8-bit or quoted-printable encoding, but some people are using web-based email services that don't give them any choice. The result is that their messages are shown as garbage in the archives. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-09 15:36 Message: Logged In: YES user_id=12800 Pipermail in MM2.0.x doesn't handle MIME very well, and this is a known limitation. It won't be fixed in MM2.0.x, but it is fixed in MM2.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=568456&group_id=103 From casterln@nature.Berkeley.EDU Fri Aug 9 21:25:12 2002 From: casterln@nature.Berkeley.EDU (Gary Casterline) Date: Fri, 9 Aug 2002 13:25:12 -0700 Subject: [Mailman-Developers] bounces going to wrong list's admin In-Reply-To: <15700.3290.388914.780312@anthem.wooz.org> References: <20020808235726.GA11737@nature.Berkeley.EDU> <15700.3290.388914.780312@anthem.wooz.org> Message-ID: <20020809202512.GA14055@nature.Berkeley.EDU> On Fri, Aug 09, 2002 at 02:41:30PM -0400, Barry A. Warsaw wrote: > > >>>>> "GC" == Gary Casterline writes: > > GC> When the monthly reminders go out, a lot of the messages > GC> bounce. These bounce messages should go the the list's > GC> admin address. However we're seeing way too many go to > GC> one particular list admin. (Luckily this person is very > GC> patient.:) > > This is just a byproduct of the way password reminders are sent in > MM2.0.x. They appear to come from the first public mailing list on > the domain. In MM2.1 they'll come from the `site list' so individual > list owners won't be bothered. > > -Barry Ahh. In the meantime, if the sorting is alpha, perhaps I should create a bogus public list -- aaaaalist -- like taxi cab listings in the yellow pages? _Gary From noreply@sourceforge.net Fri Aug 9 21:34:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 09 Aug 2002 13:34:33 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-565052 ] make install fails Message-ID: Bugs item #565052, was opened at 2002-06-05 17:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=565052&group_id=103 Category: configuring/installing Group: 2.1 beta >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Aliet Santiesteban Sifontes (aliet) Assigned to: Nobody/Anonymous (nobody) Summary: make install fails Initial Comment: Hi boy: I've been trying to build a rpm for mailman 2.1 b2 but the make install fails when you define something like this, make install prefix=/var/tmp/var/mailman var_prefix=/var/tmp/var/mailman I thought I was making something wrong so I did it with the sources rather than throught rpm, and I got the same error, this error causes that I can't not build a rpm for this version of mailman, this is the error Compiling: /var/tmp/var/mailman/Mailman/version.pr... Traceback (most recent call last); File "bin/update", line 45, in ? from Mailman import mm_cfg Import error: No module named Mailman make: *** [update] Error 1 I'm building in a Linux RedHat 7.3 ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-09 16:34 Message: Logged In: YES user_id=12800 When building from source, use configure options --prefix and --exec-prefix to designate alternative installation diectories. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=565052&group_id=103 From dgc@uchicago.edu Fri Aug 9 21:40:27 2002 From: dgc@uchicago.edu (David Champion) Date: Fri, 9 Aug 2002 15:40:27 -0500 Subject: [Mailman-Developers] bounces going to wrong list's admin In-Reply-To: <20020809202512.GA14055@nature.Berkeley.EDU> References: <20020808235726.GA11737@nature.Berkeley.EDU> <15700.3290.388914.780312@anthem.wooz.org> <20020809202512.GA14055@nature.Berkeley.EDU> Message-ID: <20020809204027.GG25814@dust.uchicago.edu> * On 2002.08.09, in <20020809202512.GA14055@nature.Berkeley.EDU>, * "Gary Casterline" wrote: > > Ahh. In the meantime, if the sorting is alpha, perhaps I > should create a bogus public list -- aaaaalist -- like > taxi cab listings in the yellow pages? See my message from Monday, Aug. 5, "Passwords on the wire again". You might find the tools at the URL shown useful, though they address more (perceived) problems than you're claiming here. :) https://listhost.uchicago.edu/mailman-files/mailman-ignore/ -- -D. Fresh fruit enriches everyone. Takes the thirst Sun Project, APC/UCCO out of everyday time. A pure whiff of oxygen, University of Chicago painting over a monochrome world in primary colors. dgc@uchicago.edu We all know that. It's why everyone loves fruit. From barry@python.org Fri Aug 9 21:45:26 2002 From: barry@python.org (Barry A. Warsaw) Date: Fri, 9 Aug 2002 16:45:26 -0400 Subject: [Mailman-Developers] bounces going to wrong list's admin References: <20020808235726.GA11737@nature.Berkeley.EDU> <15700.3290.388914.780312@anthem.wooz.org> <20020809202512.GA14055@nature.Berkeley.EDU> Message-ID: <15700.10726.842997.144600@anthem.wooz.org> >>>>> "GC" == Gary Casterline writes: GC> Ahh. In the meantime, if the sorting is alpha, perhaps I GC> should create a bogus public list -- aaaaalist -- like GC> taxi cab listings in the yellow pages? I'm not sure what "if the sorting is alpha" means, but your approach would work for MM2.0. -Barry From barry@python.org Fri Aug 9 21:50:31 2002 From: barry@python.org (Barry A. Warsaw) Date: Fri, 9 Aug 2002 16:50:31 -0400 Subject: [Mailman-Developers] bounces going to wrong list's admin References: <20020808235726.GA11737@nature.Berkeley.EDU> <15700.3290.388914.780312@anthem.wooz.org> <20020809202512.GA14055@nature.Berkeley.EDU> Message-ID: <15700.11031.941999.254373@anthem.wooz.org> Ah never mind, you meant "alphabetical". Sorting will be done by os.listdir() which on *nix systems is a thin wrapper around the readdir() system call, and for all intents and purposes is random. You'd probably need to hack cron/mailpasswds to hard code a list to use. -Barry From les@2pi.org Fri Aug 9 21:52:59 2002 From: les@2pi.org (Les Niles) Date: Fri, 9 Aug 2002 13:52:59 -0700 Subject: [Mailman-Developers] Re: Reconstructing config.pck In-Reply-To: message from Les Niles on 8 Aug 2002 10:32:06 -0700 Message-ID: <200208092052.NAA16155@mutiny.2pi.org> Good news -- the list is back up, nearly intact. Thanks for the suggestions, Barry and Donn. I hacked pickle.py to return its whole parse stack when it encountered an error, instead of just giving up. The first, good half of the config.pck turned out to have the members[] array and several other arrays including user_options[] and delivery_status[]. The main things that were lost were the digest_members[] and passwords[]. I approximated digest_members[] as the set of all email addresses in the other arrays that weren't in members[], which resulted in about the right number of total subscribers, and more importantly it included my own subscription. :) As for passwords, we have another related list that has about 70% overlap in readership, so I took passwords from that list whenever possible, and gave everyone else new random passwords. I also used the data from that other list to fill in the case-sensitive addresses for digest_members[]; I'm assuming/hoping that that's not really important, for the sake of those that aren't on the other list. Thanks again for the suggestions. And I've got to say, it was a heck of a lot easier doing this in python than it would've been in some traditional compiled language. -les On 8 Aug 2002 10:32:06 -0700 Les Niles wrote: >We had a little disk glitch that trashed config.pck and >config.pck.save for one of our lists [I don't want to even *hear* >the word "backup"!] Roughly the last half of each file is nothing >but null bytes. These obviously don't unpickle very well.... Does >anyone have any experience or advice to offer about recovering some >of the information? At a minimum I'd like to recover the >subscriber list, and hopefully the digest/no-digest settings. >I see lots of subscribers in the file; presumably there are some >objects that are intact but the stock pickle.load() just gives up >if it can't load everything. Any suggestions would be greatly >appreciated. > > -les From barry@python.org Fri Aug 9 21:53:37 2002 From: barry@python.org (Barry A. Warsaw) Date: Fri, 9 Aug 2002 16:53:37 -0400 Subject: [Mailman-Developers] bounces going to wrong list's admin References: <20020808235726.GA11737@nature.Berkeley.EDU> <15700.3290.388914.780312@anthem.wooz.org> <20020809202512.GA14055@nature.Berkeley.EDU> <20020809204027.GG25814@dust.uchicago.edu> Message-ID: <15700.11217.495319.438470@anthem.wooz.org> >>>>> "DC" == David Champion writes: DC> https://listhost.uchicago.edu/mailman-files/mailman-ignore/ Are you sure about that url? Doesn't work for me. -Barry From dgc@uchicago.edu Fri Aug 9 21:56:15 2002 From: dgc@uchicago.edu (David Champion) Date: Fri, 9 Aug 2002 15:56:15 -0500 Subject: [Mailman-Developers] Re: bounces going to wrong list's admin In-Reply-To: <15700.11217.495319.438470@anthem.wooz.org> References: <20020808235726.GA11737@nature.Berkeley.EDU> <15700.3290.388914.780312@anthem.wooz.org> <20020809202512.GA14055@nature.Berkeley.EDU> <20020809204027.GG25814@dust.uchicago.edu> <15700.11217.495319.438470@anthem.wooz.org> Message-ID: <20020809205615.GH25814@dust.uchicago.edu> * On 2002.08.09, in <15700.11217.495319.438470@anthem.wooz.org>, * "Barry A. Warsaw" wrote: > > >>>>> "DC" == David Champion writes: > > DC> https://listhost.uchicago.edu/mailman-files/mailman-ignore/ > > Are you sure about that url? Doesn't work for me. Argh! OK, now I'm sure. Thanks :) -- -D. Fresh fruit enriches everyone. Takes the thirst Sun Project, APC/UCCO out of everyday time. A pure whiff of oxygen, University of Chicago painting over a monochrome world in primary colors. dgc@uchicago.edu We all know that. It's why everyone loves fruit. From barry@python.org Fri Aug 9 21:57:11 2002 From: barry@python.org (Barry A. Warsaw) Date: Fri, 9 Aug 2002 16:57:11 -0400 Subject: [Mailman-Developers] Re: Reconstructing config.pck References: <200208092052.NAA16155@mutiny.2pi.org> Message-ID: <15700.11431.988657.292874@anthem.wooz.org> Phew! :) >>>>> "LN" == Les Niles writes: LN> Thanks again for the suggestions. And I've got to say, it was LN> a heck of a lot easier doing this in python than it would've LN> been in some traditional compiled language. Python rocks like that, eh? :) -Barry From noreply@sourceforge.net Fri Aug 9 22:03:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 09 Aug 2002 14:03:01 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-564587 ] config_list breaks at filter_mime_types Message-ID: Bugs item #564587, was opened at 2002-06-04 17:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=564587&group_id=103 Category: command line scripts Group: 2.1 beta >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Devin L. Ganger (dlganger) Assigned to: Barry A. Warsaw (bwarsaw) Summary: config_list breaks at filter_mime_types Initial Comment: When running: config_list -o cpunk.conf cpunk-secpro on my list cpunk-secpro@lists.thecabal.org, I get the following error: (bofh:mailman) /home/mailman $ config_list -o cpunk.conf cpunk-secpro Traceback (most recent call last): File "/home/mailman/bin/config_list", line 268, in ? main() File "/home/mailman/bin/config_list", line 261, in main do_output(listname, outfile) File "/home/mailman/bin/config_list", line 113, in do_output do_list_categories(mlist, k, None, outfp) File "/home/mailman/bin/config_list", line 162, in do_list_categories lines = value.replace('\r', '').split('\n') AttributeError: 'list' object has no attribute 'replace' Doing a tail of the cpunk.conf file show the following: (bofh:mailman) /home/mailman $ tail cpunk.conf # matching MIME major type, e.g. image. Blank lines are ignored. # # After stripping message parts, any multipart attachment that is empty # as a result is removed all together. If the outer part's MIME type # matches one of the strip types, or if all of the outer part's subparts # are stripped, then the whole message is discarded. Finally, each # multipart/alternative section will be replaced by just the first # alternative that is non-empty after the specified types have been # removed. filter_mime_types = ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-09 17:03 Message: Logged In: YES user_id=12800 I believe this is fixed in current cvs and will be part of 2.1b3. ---------------------------------------------------------------------- Comment By: Jay Luker (lbjay) Date: 2002-07-24 17:19 Message: Logged In: YES user_id=51347 I'm experiencing the same problem on a debian (woody) install, python -V = 2.2 I worked around it temporarily by adding a varname != filter_mime_types condition to the "if" on L268. ---------------------------------------------------------------------- Comment By: Devin L. Ganger (dlganger) Date: 2002-06-04 17:08 Message: Logged In: YES user_id=478874 This is on Solaris 7, Python 2.2: (bofh:devin) /home/devin $ python -V Python 2.2 (bofh:devin) /home/devin $ uname -a SunOS bofh.thecabal.internal 5.7 Generic_106541-14 sun4m sparc SUNW,SPARCsystem-600 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=564587&group_id=103 From noreply@sourceforge.net Fri Aug 9 22:31:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 09 Aug 2002 14:31:05 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-563328 ] confirmation strings don't work 2.1b2+ Message-ID: Bugs item #563328, was opened at 2002-06-01 12:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=563328&group_id=103 Category: bounce detection Group: 2.1 beta >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Marc Merlin (marcmerlin) Assigned to: Nobody/Anonymous (nobody) Summary: confirmation strings don't work 2.1b2+ Initial Comment: I'm using a CVS tree tha's up to date I got this mail (because my spamassassin is boucing the mails, and the list mostly gets spams). No big deal, except that the URL tells me the confirmation string is incorrect and even if I re-enter it in the "Otherwise, re-enter your confirmation string." page, it still doesn't work. What can I do to help debug this/provide more info? ----- Forwarded message from web-team-request@svlug.org ----- From: web-team-request@svlug.org To: me@domain X-List-Administrivia: yes Subject: confirm 834fdd960d02e8e77409e82c626b698f96fb434a Your membership in the mailing list web-team has been disabled due to excessive bounces. You will not get any more messages from this list until you re-enable your membership. You will receive 3 more reminders like this before your membership in the list is deleted. To re-enable your membership, you can simply respond to this message (leaving the Subject: line intact), or visit the confirmation page at http://lists.svlug.org/lists/confirm/web-team/834fdd960d02e8e77409e82c626b698f96 fb434a You can also visit your membership page at http://lists.svlug.org/lists/options/web-team/merlin%40svlug.org (...) ----- End forwarded message ----- ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-09 17:31 Message: Logged In: YES user_id=12800 I believe this is all working now in cvs (2.1b3) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=563328&group_id=103 From noreply@sourceforge.net Fri Aug 9 22:47:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 09 Aug 2002 14:47:07 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-563091 ] digest an option in confirm cgi Message-ID: Bugs item #563091, was opened at 2002-05-31 17:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=563091&group_id=103 Category: Web/CGI Group: 2.1 beta >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Christopher Donald Wiegand (cdwiegand) Assigned to: Nobody/Anonymous (nobody) Summary: digest an option in confirm cgi Initial Comment: I have a list that has the digest option turned off (via the cgi). However, when I confirm a subscription to this list via the cgi link in the email, the page gives me the option of turning digests on (even though it is not an option when first subscribing to the list). Also, I would recommend that on that same confirmation page, the subscribe button be directly below the fields, and the cancel button on the side. I almost accidentally cancelled my confirmation... ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-09 17:47 Message: Logged In: YES user_id=12800 Fixed for 2.1b3, although i'm not changing the placement of the buttons (I couldn't come up with something I liked better). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=563091&group_id=103 From noreply@sourceforge.net Fri Aug 9 22:54:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 09 Aug 2002 14:54:09 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-559417 ] "arch" utility spews output Message-ID: Bugs item #559417, was opened at 2002-05-22 19:56 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=559417&group_id=103 Category: Pipermail Group: 2.0.x >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Ian Clarke (sanity) Assigned to: Nobody/Anonymous (nobody) >Summary: "arch" utility spews output Initial Comment: When I run the "arch" utility to rebuild my archives, it prints out loads of "figuring article archives", which is somewhat confusing to the new user. Would it be possible to have a more sensible status report so that people aren't confused when they rebuild a large archive? ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-09 17:54 Message: Logged In: YES user_id=12800 I don't plan on fixing this, although I would accept a patch. I'm closing this bug report. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-05-28 00:59 Message: Logged In: YES user_id=12800 What's confusing about these messages? Is it just the sheer volume of output that bothers you? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=559417&group_id=103 From noreply@sourceforge.net Fri Aug 9 22:55:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 09 Aug 2002 14:55:36 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-556250 ] Icons not copied properly on new install Message-ID: Bugs item #556250, was opened at 2002-05-15 04:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=556250&group_id=103 Category: configuring/installing Group: 2.1 beta >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Dario Lopez-Kästen (dlkita) Assigned to: Nobody/Anonymous (nobody) Summary: Icons not copied properly on new install Initial Comment: Using 2.1b2 on a minimal Solaris 8 installation, the install script fails to properly copy the icons from the misc dir in the source to the icons dir in the mailman install location. This is reproduceable (I installed 4 times). Looking in the Makefile gave no clues, mostly due to ignorance of makeifiles on my part. Haven't seen this mentioned anywhere, so I am not sure if this is my particular setup or if it is a general problem. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-09 17:55 Message: Logged In: YES user_id=12800 I can't see anything that would be causing this and it seems to work for other people, so I'm closing this bug report. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-05-28 01:08 Message: Logged In: YES user_id=12800 I can't reproduce this on my Linux system. Could there be some assumption of GNU make in the misc/Makefile.in? But if so, wouldn't that affect other targets? Can anybody else on Solaris 8 verify this bug, please? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=556250&group_id=103 From noreply@sourceforge.net Fri Aug 9 22:57:55 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 09 Aug 2002 14:57:55 -0700 Subject: [Mailman-Developers] [ mailman-Patches-502668 ] new mlist option send_reminder_frequency Message-ID: Patches item #502668, was opened at 2002-01-12 13:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=502668&group_id=103 Category: list administration Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: new mlist option send_reminder_frequency Initial Comment: For announcement mailing lists, which get only one or two mails each year, a monthly password reminder is too much. The list administrator can toggle the send_reminder once each year, but that's error prone. The attached patch adds a list specific option send_reminder_frequency with the values monthly (default), yearly and quaterly. the mailpasswds script is changed to ask for this option. I didn't yet figure out, how to update existing lists ... ---------------------------------------------------------------------- >Comment By: Matthias Klose (doko) Date: 2002-08-09 21:57 Message: Logged In: YES user_id=60903 Updated patch for the alternative (not introducing a new option, but extending the send_reminders option (updated to current CVS). ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-05-28 06:11 Message: Logged In: YES user_id=60903 Here is the updated alternative patch not introducing a new option, but extending the send_reminders option (updated to current CVS). ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-01-16 20:08 Message: Logged In: YES user_id=60903 Here is an alternative patch not introducing a new option, but extending the send_reminders option. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=502668&group_id=103 From noreply@sourceforge.net Sat Aug 10 00:05:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 09 Aug 2002 16:05:45 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-555627 ] subject prefic encoding Message-ID: Bugs item #555627, was opened at 2002-05-13 17:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=555627&group_id=103 Category: mail delivery Group: 2.1 beta >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Norbert Bollow (bollow) Assigned to: Nobody/Anonymous (nobody) Summary: subject prefic encoding Initial Comment: In Mailman 2.1b2 on Python 2.1.3 with a mailing list that has German as its default language, the subject prefix gets encoded unneccessarily, e.g. [MNO] becomes =?iso-8859-1?q?=5BMNO=5D_?= . ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-09 19:05 Message: Logged In: YES user_id=12800 This will be fixed in MM2.1 by giving you the option to disable encoded prefixes if the prefix is all ASCII. Obviously, if there are non-ASCII characters in the prefix, it must be encoded. There's also a third option, which is to only encode the prefix if the original subject is non-ascii, and therefor encoded. In that case, because of the ambiguity of the relevant RFCs not encoding the prefix might lead to extra or missing spaces depending on the end-user's mail reader. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-07-09 22:46 Message: Logged In: NO It happens the same for mailman in spanish as default language, besides it reencode de original subject so one subject like: =?iso-8859-1?Q? prueba__no_leer:_el_parag=FCas=2C_el_cami=F3n_y_el_ni= F1o_?= becomes: =?iso-8859-1?q?=5BMON=5D_?= =?iso-8859-1?q?=3D=3Fiso-8859- 1=3FQ=3Fprueba=5F=5Fno=5Fleer=3A=5Fel=5Fpa?= =?iso-8859-1?q? rag=3DFCas=3D2C=5Fel=5Fcami=3DF3n=5Fy=5Fel=5Fni=3 DF1o=5F?= =?iso-8859-1?q?=3F=3D?= where it should be: =?iso-8859-1?q?=5BMON=5D_?= =?iso-8859-1?Q? prueba__no_leer:_el_parag=FCas=2C_el_cami=F3n_y_el_ni= F1o_?= or even: [MON] =?iso-8859-1?Q? prueba__no_leer:_el_parag=FCas=2C_el_cami=F3n_y_el_ni= F1o_?= why the incoming subject line (with the "subject :" part striped) isn't copied verbatim to the next line of the message sended? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=555627&group_id=103 From noreply@sourceforge.net Sat Aug 10 00:48:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 09 Aug 2002 16:48:47 -0700 Subject: [Mailman-Developers] [ mailman-Patches-498766 ] See through MIME for list prefix Message-ID: Patches item #498766, was opened at 2002-01-02 18:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=498766&group_id=103 Category: None Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Mikhail Zabaluev (mzabaluev) Assigned to: Nobody/Anonymous (nobody) Summary: See through MIME for list prefix Initial Comment: In mailing lists with high percentage of non-English messages, the subject is often encoded using MIME =?charset?[qb]?...?= sequences. Some user agents encode _every_ word or even the entire subject, including the list label that might have been reproduced in a reply. Therefore, it's useful to decode subject into Unicode representation, to make sure the label isn't hidden there so we can slap the label before the (encoded) original subject without being redundant. The patch achieves just that. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-09 19:48 Message: Logged In: YES user_id=12800 I think this patch is no longer necessary for MM2.1b3. CookHeaders now checks for the prefix in each decoded part of the subject header. This might miss prefixes with spaces in them where each word is encoded in a separate chunk, although I think in practice that's unlikely. I'm rejecting this patch, but if you think that what's in MM2.1b3 isn't sufficient, please do work up another patch against cvs and I'll consider it. Thanks. ---------------------------------------------------------------------- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2002-04-04 16:07 Message: Logged In: YES user_id=313104 Oh -- I was under the impression that mimelib has been merged into Python completely and is developed in its CVS trunk. Now that I look into email.Header.decode_header, things become tricky. To be 100% correct, we have to reassemble the Subject line into a Unicode string. Which may raise issues with codecs. But, since the "quick and dirty" solution has been submitted in the patch 528031, we can afford being more thorough here. The update is underway. ---------------------------------------------------------------------- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2002-04-04 15:31 Message: Logged In: YES user_id=313104 The patched file compiles dandy with Python 2.2, using its bundled email package. Note that I didn't modify imports, as it is now in CVS: import email.Utils ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-04-04 07:45 Message: Logged In: YES user_id=21627 It's deprecate in the code that is in http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mimelib/mimelib/email/Utils.py.diff?r1=1.12&r2=1.13 Not sure what to do about this, though, since email.Header is not available in Python. Since mailman requires the mimelib version anyway, it appears better to forward-port it, in the long run. ---------------------------------------------------------------------- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2002-04-03 17:17 Message: Logged In: YES user_id=313104 Since when email.Utils.decode (in the Python distribution since 2.2) is deprecated? I cannot find anything about the deprecation, and it's still in the docs. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-04-02 02:44 Message: Logged In: YES user_id=21627 This patch uses Utils.decode, which is deprecated. Care to revise this patch? Please also take into account https://sourceforge.net/tracker/index.php?func=detail&aid=528031&group_id=103&atid=300103 Which of the patch do you consider better/more correct? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=498766&group_id=103 From noreply@sourceforge.net Sat Aug 10 00:46:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 09 Aug 2002 16:46:57 -0700 Subject: [Mailman-Developers] [ mailman-Patches-528031 ] avoid double prefixes for mimed subjects Message-ID: Patches item #528031, was opened at 2002-03-10 02:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=528031&group_id=103 Category: mail delivery Group: Mailman 2.0.x >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Dmitry Kohmanyuk (dk379) Assigned to: Nobody/Anonymous (nobody) Summary: avoid double prefixes for mimed subjects Initial Comment: this patch checks subject: line for being mime-encoded with charset, and if this the case, decodes is for the purpose of prefix checking. this avoids replies with subject encoded( Re: [listname] old subject.. ) to be converted to [listname] encoded( Re: [listname] old subject...) ad infinitum. patch originally developed by vaget at vaget dot org and beautified by me. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-09 19:46 Message: Logged In: YES user_id=12800 Since this patch is against MM2.0, I'm going to reject it. Security patches only now for MM2.0.x. On a related note, CookHeaders.py in MM2.1 should have enough smarts to avoid adding the prefix to encoded headers, although it could miss prefixes which contain spaces and where each word is in a separate encoded chunk. I think in practice this is unlikely. ---------------------------------------------------------------------- Comment By: Mikhail Zabaluev (mzabaluev) Date: 2002-04-03 17:05 Message: Logged In: YES user_id=313104 This patch does the job, although EncWord functionality is somewhat moot: it assumes that any string is encoded using at most one non-ASCII charset. Which _might_ be wrong. Decoding into a Unicode string with regard to charsets would be cleaner, but OTOH it would require codec support and hence would bring additional complexity and trigger more untrampled bugs. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-04-02 02:39 Message: Logged In: YES user_id=21627 How does this relate to patch http://sourceforge.net/tracker/index.php?func=detail&aid=498766&group_id=103&atid=300103 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=528031&group_id=103 From barry@python.org Sat Aug 10 05:44:55 2002 From: barry@python.org (Barry A. Warsaw) Date: Sat, 10 Aug 2002 00:44:55 -0400 Subject: [Mailman-Developers] RELEASED Mailman 2.1 beta 3 Message-ID: <15700.39495.95222.780717@anthem.wooz.org> I've released Mailman 2.1 beta 3; see below for a list of changes since version 2.1 beta 2. There have been lots of bug fixes, two new languages (Dutch and Brazilian Portuguese), and a couple of minor new features. Remember that discussions about version 2.1 are still preferred on mailman-developers. I plan on moving the remaining Mailman discussion lists (mailman-users, mailman-announce, mailman-i18n, mailman-docs, and mailman-checkins) over to the new version later this weekend. Enjoy, -Barry -------------------- snip snip -------------------- 2.1 beta 3 (09-Aug-2002) The usual assortment of bug fixes and language updates. - New languages: Dutch, Portuguese (Brazil) - New configure script options: --with-mailhost, --with-urlhost, --without-permcheck. See ./configure --help for details. - The encoding of Subject: prefixes is controlled by a new list option encode_ascii_prefixes. This is useful for languages with character sets other than us-ascii. See the Languages admin page for details. - A new list option news_prefix_subject_too controls whether postings gated from mail to news should have the subject prefix added to their Subject: header. - The algorithm for upgrading the moderation controls for a Mailman 2.0.x list has changed. The change should be transparent, but you'll want to double check the moderation controls after upgrading from MM2.0.x. This should have no effect for upgrades from a previous MM2.1 beta. See the UPGRADING file for details. - On the Mass Subscribe admin page, a text box has been added so that the admin can add a custom message to be prepended to the welcome/invite notification. - On the admindb page, a link is included to more easily reload the page. - The Sendmail.py delivery module is sabotaged so that it can't be used naively. You need to read the comments in the file and edit the code to use this unsafe module. - When a member sends a `help' command to the request address, the url to their options page is included in the response. - Autoresponses, -request command responses, and posting hold notifications are inhibited for any message that has a Precedence: {bulk|list|junk} header. This is to avoid mail loops between email 'bots. If the original message has an X-Ack: yes header, the response is sent. Responses are also limited to a maximum number per day, as defined in the site variable MAX_AUTORESPONSES_PER_DAY. This is another guard against 'bot loops, and it defaults to 10. - When a Reply-To: header is munged to include both the original and the list address, the list address is always added last. - The cron/mailpasswds script has grown a -l/--listname option. - The cron/disabled script has grown options to send out notifications for reasons other than bounce-disabled. It has also grown a -f/--force option. See cron/disabled --help for details. - The bin/dumpdb script has grown a -n/--noprint option. - An experimental new mechanism for processing incoming messages has been added. If you can configure your MTA to do qmail-style Maildir delivery, Mailman now has a MaildirRunner qrunner. This may turn out to be much more efficient and scalable, but for MM2.1, it will not be officially supported. See Defaults.py.in and Mailman/Queue/MaildirRunner.py for details. From noreply@sourceforge.net Sat Aug 10 08:38:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 10 Aug 2002 00:38:59 -0700 Subject: [Mailman-Developers] [ mailman-Feature Requests-584468 ] listinfo: cache Message-ID: Feature Requests item #584468, was opened at 2002-07-21 14:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=584468&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peer Heinlein (pheinlein) Assigned to: Nobody/Anonymous (nobody) Summary: listinfo: cache Initial Comment: We`re running more than 700 lists on our mailinglist-server. Mailman needs between 20 and 40 seconds to generate the public listinfo page. Wouldn`t it be possible to generate a listinfo.cache including all these necessary informations to speed up the process? These listinfo.cache could be valid for some specific time, before it is removed and regenerated. Or this cache-file can be deleted if somenbody is changing his list configuration. Thanks... p.heinlein@jpberlin.de ---------------------------------------------------------------------- >Comment By: Peer Heinlein (pheinlein) Date: 2002-08-10 09:38 Message: Logged In: YES user_id=581680 Having more then 700 lists on our server we now have problems generating the listinfo/admin overview-page, because the http-timeouts are faster then mailman :-) Is there something planned to solve the problem? Peer ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=584468&group_id=103 From noreply@sourceforge.net Sat Aug 10 16:52:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 10 Aug 2002 08:52:05 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-593454 ] NewsRunner error Message-ID: Bugs item #593454, was opened at 2002-08-10 17:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=593454&group_id=103 Category: nntp/news Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Simone Piunno (pioppo) Assigned to: Nobody/Anonymous (nobody) Summary: NewsRunner error Initial Comment: Just updated to Mailman 2.1b3: Aug 10 17:18:57 2002 (10526) Uncaught runner exception: len() of unsized object Aug 10 17:18:57 2002 (10526) Traceback (most recent call last): File "/home/mailman21/Mailman/Queue/Runner.py", line 105, in _oneloop self._onefile(msg, msgdata) File "/home/mailman21/Mailman/Queue/Runner.py", line 154, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/home/mailman21/Mailman/Queue/NewsRunner.py", line 56, in _dispose prepare_message(mlist, msg, msgdata) File "/home/mailman21/Mailman/Queue/NewsRunner.py", line 132, in prepare_message count = len(email.Iterators.body_line_iterator(msg)) TypeError: len() of unsized object ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=593454&group_id=103 From noreply@sourceforge.net Sun Aug 11 16:04:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 11 Aug 2002 08:04:39 -0700 Subject: [Mailman-Developers] [ mailman-Patches-593673 ] copy of help message Message-ID: Patches item #593673, was opened at 2002-08-11 17:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=593673&group_id=103 Category: list administration Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Simone Piunno (pioppo) Assigned to: Nobody/Anonymous (nobody) Summary: copy of help message Initial Comment: in 2.1b3 when a message is held for moderation and admin_immed_notify is enabled, administrators receive a notice including a full copy of the original message. This can be annoying, especially when the message was held for being too big (and as you know this happens all the time because of Klez) This patch adds a new per-list config setting, allowing the list administrator to choose if the original message will be attached or not to the notice. Default is to attach the copy unless the message was held fort being too big. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=593673&group_id=103 From noreply@sourceforge.net Sun Aug 11 16:07:34 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 11 Aug 2002 08:07:34 -0700 Subject: [Mailman-Developers] [ mailman-Patches-593674 ] notify copy Message-ID: Patches item #593674, was opened at 2002-08-11 17:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=593674&group_id=103 Category: list administration Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Simone Piunno (pioppo) Assigned to: Nobody/Anonymous (nobody) Summary: notify copy Initial Comment: in 2.1b3 when a message is held for moderation and admin_immed_notify is enabled, administrators receive a notice including a full copy of the original message. This can be annoying, especially when the message was held for being too big (and as you know this happens all the time because of Klez) This patch adds a new per-list config setting, allowing the list administrator to choose if the original message will be attached or not to the notice. Default is to attach the copy unless the message was held fort being too big. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=593674&group_id=103 From noreply@sourceforge.net Sun Aug 11 16:10:34 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 11 Aug 2002 08:10:34 -0700 Subject: [Mailman-Developers] [ mailman-Patches-593673 ] copy of help message Message-ID: Patches item #593673, was opened at 2002-08-11 17:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=593673&group_id=103 Category: list administration Group: Mailman 2.1 >Status: Deleted Resolution: None Priority: 5 Submitted By: Simone Piunno (pioppo) Assigned to: Nobody/Anonymous (nobody) Summary: copy of help message Initial Comment: in 2.1b3 when a message is held for moderation and admin_immed_notify is enabled, administrators receive a notice including a full copy of the original message. This can be annoying, especially when the message was held for being too big (and as you know this happens all the time because of Klez) This patch adds a new per-list config setting, allowing the list administrator to choose if the original message will be attached or not to the notice. Default is to attach the copy unless the message was held fort being too big. ---------------------------------------------------------------------- >Comment By: Simone Piunno (pioppo) Date: 2002-08-11 17:10 Message: Logged In: YES user_id=227443 Oops, double submit, deleting this entry. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=593673&group_id=103 From noreply@sourceforge.net Sun Aug 11 19:46:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 11 Aug 2002 11:46:11 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-593728 ] Traceback rebuilding archive Message-ID: Bugs item #593728, was opened at 2002-08-11 20:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=593728&group_id=103 Category: Pipermail Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Stefan Divjak (stdivjak) Assigned to: Nobody/Anonymous (nobody) Summary: Traceback rebuilding archive Initial Comment: Witn Mailman 2.1b3, rebuilding a pipermail archive using $ bin/arch listname runs fine for 2 lists, but on the third one gives the following traceback: [...] Updating HTML for article 52 Updating HTML for article 53 Schreibe Archivzustand in Datei /home/mailman/archives/private/humor/pipermail.pck Traceback (most recent call last): File "bin/arch", line 160, in ? main() File "bin/arch", line 148, in main archiver.processUnixMailbox(fp, Article, start, end) File "/home/mailman/Mailman/Archiver/pipermail.py", line 545, in processUnixMailbox m = mbox.next() File "/usr/local/lib/python2.2/mailbox.py", line 34, in next return self.factory(_Subfile(self.fp, start, stop)) File "/home/mailman/Mailman/Mailbox.py", line 69, in scrubber return mailbox.scrub(msg) File "/home/mailman/Mailman/Mailbox.py", line 89, in scrub return self._scrubber(self._mlist, msg) File "/home/mailman/Mailman/Handlers/Scrubber.py", line 159, in process part.set_payload(_("""\ File "/home/mailman/Mailman/i18n.py", line 76, in _ return _translation.gettext(s) % dict UnicodeError: ASCII decoding error: ordinal not in range(128) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=593728&group_id=103 From lj@mandala-designs.com Sun Aug 11 08:08:10 2002 From: lj@mandala-designs.com (ljacobs ) Date: Sun, 11 Aug 2002 03:08:10 -0400 Subject: [Mailman-Developers] 2.1b3 make install problems Message-ID: <200208110308.AA331415852@mandala-designs.com> I have been running 2.0.8 and decided to try 2.1 on a RedHat 7.2 system with python 2.2.1. Make install quits with the following error: Traceback (most recent call last): File "bin/update", line 44, in ? import paths ImportError: No module named paths make: *** [update] Error 1 What should I try next? Thanks. ________________________________________________________________ Sent via the WebMail system at mandala-designs.com From slc@publicus.net Sat Aug 10 19:16:33 2002 From: slc@publicus.net (Steven Clift) Date: Sat, 10 Aug 2002 13:16:33 -0500 Subject: [Mailman-Developers] Features query Message-ID: <3D551231.25344.2A98CA91@localhost> I am a huge Mailman fan, listowner, non-techie ... I just checked out the member web interface for the 2.1 version and archive back a couple months for this list. Comment: Get MIME verse plain text ... none of my list users will know what MIME means. If the default for lists plain text for users, then I would reverse the question and explain what a MIME digest is, perhaps list a few e-mail programs/versions+ that support it and few big ones that don't. Questions: 1. Passwords - will it be there be one universal password for all lists a person has on a server (particularly for the autogenerated passwords)? 2. Daily list post limits - Can we technically limit the number of posts per person per day. With a two post limit, an attempt to post a third time would either moderate or bounce the post based on the list settings. 2. Archives - Are there plans for enhanced integrated archives in 2.1? If not, is there a sub-group working on this topic? I'd like to connect with anyone who has implement an elegant solution here (and figured out how to munge e-mail addresses to prevent e-mail harvesting) that allows a wrap around of a sites general look and navigation. Further, what about a "Subjects" digest option that would only e-mail out the subject lines with links to the archived posts the line below? 3. Syndication - Minnesota E-Democracy is slowly moving our remaining lists off Yahoogroups. We'd like to connect "what is happening now" on our mailing lists to our home page using RSS or something similar to place automatically updated subject line links to specific archived posts. I am aware of what http://mail-archive.com does. 3. List searching/monitoring - How about e-mail list archive searches via the web and the ability to be notified via e-mail when lists you are directly subscribe to use your keywords. Imagine 300 e-mail lists across Minnesota - the value of our very public local community discussions and statewide topical information exchange e-lists would be greatly enhanced if people had a non-list member "lurking" option. 4. Enhanced directory information/statistics - I am interested in the automatic generation of statistics that would help a user determine if a list is worth joining (i.e. is it alive, member numbers, message volume) as well as the creation of additional fields that list managers of "public" lists can opt into to using. The big idea is that groups sites using Mailman could gather and distribute their directory information (not unlike listserv or the list directories at Yahoogroups) making it easier to find e-lists of interest. (Obviously major anti-e-mail harvesting controls would have to put in place or these concepts could make it too easy to overwhelm list owners with non-member e-mail posting attempts.) 5. Member directory - You might write this off as a web forum thing, but E-Democracy could really use an option that would assign every list member on our server a public page where they could opt-in to tell other members about themselves. Something like http://www.mnforum.org/mailman/members/clift@publicus.net >From here we could also hang links to their posts across the different list public archives (has anyone seen a good MYSQL e-list archive system) as well as consider options for E-Bay like ratings from other participants on substance and style (we host political/community discussions and we need tools that enhance member- to-member self-governance and accountability). I know this is a lot and much of this might be Mailman 5.0. My honest sense is that Mailman, once it has a user-oriented web interface for list members, simple, yet powerful web archives, and a DMoz-like directory scheme for public lists, could become an open source wildfire that saves low cost/free e-mail group communication on the Net as Yahoogroups folds due to the lack profitability. My whole deal is to promote tools that allow people to organize and communicate in groups, particularly in local communities around the world. The truth is that the most important freedom on the Internet is the freedom of electronic association NOT speech. Speech is only effective or powerful when you have an audience. E-mail lists are the most powerful tool for group communication and freedom on the Internet and I see the increasingly enhanced progess of Mailman as one of the key democratization on the Internet and honestly, in the "real" world. Keep up the good work. On the side, if you don't think I am full of b.s. and are interested in connecting with other "civic-interested" techies that I have met around the world (I speak on e-democracy globally), please drop me a note: clift@publicus.net Steven Clift clift@publicus.net http://www.publicus.net From tkikuchi@is.kochi-u.ac.jp Mon Aug 12 07:31:30 2002 From: tkikuchi@is.kochi-u.ac.jp (Tokio Kikuchi) Date: Mon, 12 Aug 2002 15:31:30 +0900 Subject: [Mailman-Developers] Re: [Mailman-Announce] RELEASED Mailman 2.1 beta 3 References: <15700.39495.95222.780717@anthem.wooz.org> Message-ID: <3D575642.1060703@is.kochi-u.ac.jp> Hi, Barry and all, I was a little late in Japanese translation. Please download the tar file of japanese templates and messages from http://mm.tkikuchi.net/mailman-2.1.ja/mailman.i18n.ja.tar.gz Thank you. Barry A. Warsaw wrote: > I've released Mailman 2.1 beta 3; see below for a list of changes > since version 2.1 beta 2. There have been lots of bug fixes, two new > languages (Dutch and Brazilian Portuguese), and a couple of minor new > features. -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From mjm@michaelmeltzer.com Mon Aug 12 08:21:10 2002 From: mjm@michaelmeltzer.com (Michael Meltzer) Date: Mon, 12 Aug 2002 03:21:10 -0400 Subject: [Mailman-Developers] Scrubber.py confusion, 2.1b3 Message-ID: <01c301c241d0$d59c2ba0$0b01a8c0@mjm2> I been going over some of the Scrubber.py code two thing are standing out for me 1)A lot of work was made to make the filename unique in "save_attachment", it look like a straight bug that the url returned does not have the "extra" part returned as part of the url, looks to me like the last line should be url = baseurl + 'attachments/%s/%s' % (msgdir, filename + extra) frankly I think the forming of the name could better, like filenamebase + "-" +counter + "." + ext, but that more of a feature request 2)It looks like this code is doing directory abuse, it looks like a unlimited amount of files names fill be placed in one directory, like 2^32, this is not good for systems performance, even with the latest dirhash methods by the operating system ,this will become a linear screech very quickly for file creates and file exists. Been their and killed the patient that way. Hard to spot it until you ramp the systems up. I am playing around by adding two more time based directories to the system "attachments/YYYYMM/DD/". BTW that what made spotting bug #1 so easy :-) MJM From Denis.Beauchemin@USherbrooke.ca Mon Aug 12 16:11:54 2002 From: Denis.Beauchemin@USherbrooke.ca (Denis Beauchemin) Date: 12 Aug 2002 11:11:54 -0400 Subject: [Mailman-Developers] Re: 2.1b3 make install problems Message-ID: <1029165114.7761.74.camel@dbeauchemin.si.usherb.ca> Hello, I have the same problem (and have had with version 2.1b2 also) and the same OS as ljacobs: > I have been running 2.0.8 and decided to try 2.1 on a RedHat 7.2 > system with python 2.2.1. >=20 > Make install quits with the following error: >=20 > Traceback (most recent call last): > File "bin/update", line 44, in ? > import paths > ImportError: No module named paths > make: *** [update] Error 1 >=20 > What should I try next? Any solution? Thanks.=20 Denis --=20 Denis Beauchemin, analyste Universit=E9 de Sherbrooke, S.T.I. T: 819.821.8000x2252 F: 819.821.8045 From lrosa@mail.hypertrek.info Mon Aug 12 16:54:01 2002 From: lrosa@mail.hypertrek.info (Luigi Rosa) Date: Mon, 12 Aug 2002 17:54:01 +0200 Subject: [Mailman-Developers] Re: 2.1b3 make install problems In-Reply-To: <1029165114.7761.74.camel@dbeauchemin.si.usherb.ca> References: <1029165114.7761.74.camel@dbeauchemin.si.usherb.ca> Message-ID: <1385852812.20020812175401@mail.hypertrek.info> Hello Denis, Monday, August 12, 2002, 5:11:54 PM, you wrote: >> Traceback (most recent call last): >> File "bin/update", line 44, in ? >> import paths >> ImportError: No module named paths >> make: *** [update] Error 1 >> >> What should I try next? DB> Any solution? I may be wrong (and probably I will), but I think I got the same error when I copied the config.cache file from a previous release. Try to unpack the tarball in an empty dir and configure and make a new version. -- Best regards, Luigi mailto:lrosa@mail.hypertrek.info From Denis.Beauchemin@USherbrooke.ca Mon Aug 12 18:06:33 2002 From: Denis.Beauchemin@USherbrooke.ca (Denis Beauchemin) Date: 12 Aug 2002 13:06:33 -0400 Subject: [Mailman-Developers] Re: 2.1b3 make install problems In-Reply-To: <1385852812.20020812175401@mail.hypertrek.info> References: <1029165114.7761.74.camel@dbeauchemin.si.usherb.ca> <1385852812.20020812175401@mail.hypertrek.info> Message-ID: <1029171993.7761.82.camel@dbeauchemin.si.usherb.ca> Hi Luigi, It is what I did both times and I got the error message. Any other clues? Thanks! Denis On Mon, 2002-08-12 at 11:54, Luigi Rosa wrote: > Hello Denis, >=20 > Monday, August 12, 2002, 5:11:54 PM, you wrote: >=20 > >> Traceback (most recent call last): > >> File "bin/update", line 44, in ? > >> import paths > >> ImportError: No module named paths > >> make: *** [update] Error 1 > >>=20 > >> What should I try next? >=20 > DB> Any solution? >=20 >=20 > I may be wrong (and probably I will), but I think I got the same error wh= en I > copied the config.cache file from a previous release. >=20 > Try to unpack the tarball in an empty dir and configure and make a new > version. >=20 >=20 >=20 > --=20 > Best regards, > Luigi mailto:lrosa@mail.hypertrek.info >=20 >=20 > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman-21/listinfo/mailman-developers >=20 --=20 Denis Beauchemin, analyste Universit=E9 de Sherbrooke, S.T.I. T: 819.821.8000x2252 F: 819.821.8045 From pioppo@ferrara.linux.it Mon Aug 12 19:57:35 2002 From: pioppo@ferrara.linux.it (Simone Piunno) Date: Mon, 12 Aug 2002 20:57:35 +0200 Subject: [Mailman-Developers] Mailman/Archiver/HyperArch.py has not been marked for i18n Message-ID: <20020812185735.GI2054@ferrara.linux.it> Hi, Luigi Rosa pointed me to the fact that the archive pages are not translated. After some digging in the code, I've found that no string in Mailman/Archiver/HyperArch.py has been marked for pygettext extraction. Is there any reason for this? -- Adde parvum parvo magnus acervus erit. Simone Piunno, FerraraLUG - http://members.ferrara.linux.it/pioppo From lj@mandala-designs.com Mon Aug 12 20:26:05 2002 From: lj@mandala-designs.com (Leonard Jacobs) Date: Mon, 12 Aug 2002 15:26:05 -0400 Subject: [Mailman-Developers] continued problem with the 2.1b3 installation Message-ID: <3D57D38D.30588.17F7BFF@localhost> Folks -- I did attempt this installation in a directory where there had never been an instance of Mailman, and I also tried the installation using python 2.1.3 and python 2.2.1, with mailman 2.1b2 and 2.1b3. Nothing seems to work. I see that there have been other instances of this problem mentioned among users, but am puzzled over how to the resolve my problem since there are obviously others who have not had this problem. Any suggestions welcome. > I have been running 2.0.8 and decided to try 2.1 on a RedHat 7.2 system > with python 2.2.1. > > Make install quits with the following error: > > Traceback (most recent call last): > File "bin/update", line 44, in ? > import paths > ImportError: No module named paths > make: *** [update] Error 1 > > What should I try next? > > > > Thanks. ------------------ Leonard Jacobs www.mandala-designs.com (508) 359-5753 --- [This E-mail scanned for viruses by Declude Virus] From Denis.Beauchemin@USherbrooke.ca Mon Aug 12 21:05:56 2002 From: Denis.Beauchemin@USherbrooke.ca (Denis Beauchemin) Date: 12 Aug 2002 16:05:56 -0400 Subject: [Mailman-Developers] continued problem with the 2.1b3 installation In-Reply-To: <3D57D38D.30588.17F7BFF@localhost> References: <3D57D38D.30588.17F7BFF@localhost> Message-ID: <1029182756.7764.88.camel@dbeauchemin.si.usherb.ca> I think I found the solution: install some more Python RPM: python2-devel-2.2.1-1.i386.rpm python2-docs-2.2.1-1.i386.rpm (probably not needed but...) python2-tools-2.2.1-1.i386.rpm and the problem just goes away. Denis On Mon, 2002-08-12 at 15:26, Leonard Jacobs wrote: > Folks -- >=20 > I did attempt this installation in a directory where there had never been= an=20 > instance of Mailman, and I also tried the installation using python 2.1.3= and=20 > python 2.2.1, with mailman 2.1b2 and 2.1b3. Nothing seems to work.=20 >=20 > I see that there have been other instances of this problem mentioned amon= g=20 > users, but am puzzled over how to the resolve my problem since there are=20 > obviously others who have not had this problem. =20 >=20 > Any suggestions welcome. >=20 > > I have been running 2.0.8 and decided to try 2.1 on a RedHat 7.2 system > > with python 2.2.1. > >=20 > > Make install quits with the following error: > >=20 > > Traceback (most recent call last): > > File "bin/update", line 44, in ? > > import paths > > ImportError: No module named paths > > make: *** [update] Error 1 > >=20 > > What should I try next? > > >=20 > > > Thanks.=20 >=20 >=20 >=20 > ------------------ > =20 > Leonard Jacobs > www.mandala-designs.com > (508) 359-5753 >=20 >=20 > --- > [This E-mail scanned for viruses by Declude Virus] >=20 >=20 > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman-21/listinfo/mailman-developers >=20 --=20 Denis Beauchemin, analyste Universit=E9 de Sherbrooke, S.T.I. T: 819.821.8000x2252 F: 819.821.8045 From barry@python.org Mon Aug 12 22:10:59 2002 From: barry@python.org (Barry A. Warsaw) Date: Mon, 12 Aug 2002 17:10:59 -0400 Subject: [Mailman-Developers] continued problem with the 2.1b3 installation References: <3D57D38D.30588.17F7BFF@localhost> <1029182756.7764.88.camel@dbeauchemin.si.usherb.ca> Message-ID: <15704.9315.703229.698305@anthem.wooz.org> >>>>> "DB" == Denis Beauchemin writes: | I think I found the solution: install some more Python RPM: | python2-devel-2.2.1-1.i386.rpm | python2-docs-2.2.1-1.i386.rpm (probably not needed but...) | python2-tools-2.2.1-1.i386.rpm DB> and the problem just goes away. Dang. Of course, if this is a packaging problem, it explains why I can never reproduce this. I always use a Python built from source. I suspect that it's the python2-devel package that you need, and not the docs or tools packages. If anybody has the time to spend digging into this in more detail, I'd love to know for sure which package is necessary and why. I'm having a hard time understanding why bin/update would complain about the "import paths", although it is suspicious that bin/update is the first script the Makefile tries to run out of $prefix, and paths is the first non-standard library that bin/update tries to import. Still paths doesn't do anything /that/ wacky, and it doesn't require anything but the os and sys modules and those better be part of the base python package. Note that I've had reports that Debian seems to want the python2.2-dev package, so this could be related. In the meantime I'm expanding README.LINUX with this information: -------------------- snip snip -------------------- PYTHON PACKAGES Note that if you installed Python from your Linux distribution's package manager (e.g. .rpms for Redhat-derived systems or .deb for Debian), you must install the `development' package of Python, or you may not get everything you need. For example, using Python 2.2 on Debian, you will need to install the python2.2-dev package. On Redhat, you probably need the python2-devel package. If you install Python from source, you should be fine. -------------------- snip snip -------------------- I hope that helps. -Barry From barry@python.org Mon Aug 12 22:14:29 2002 From: barry@python.org (Barry A. Warsaw) Date: Mon, 12 Aug 2002 17:14:29 -0400 Subject: [Mailman-Developers] Mailman/Archiver/HyperArch.py has not been marked for i18n References: <20020812185735.GI2054@ferrara.linux.it> Message-ID: <15704.9525.987610.147497@anthem.wooz.org> >>>>> "SP" == Simone Piunno writes: SP> Luigi Rosa pointed me to the fact that the archive pages are SP> not translated. After some digging in the code, I've found SP> that no string in Mailman/Archiver/HyperArch.py has been SP> marked for pygettext extraction. SP> Is there any reason for this? No good one. I'm sure that file's simply been overlooked during the i18n process. A brief skim shows a few in-line strings that probably need to be wrapped, but not a whole lot. The nasty bit are the templates sitting in the file as triple quoted strings. These should probably be moved out in separate template files. Care to provide a patch? -Barry From barry@python.org Mon Aug 12 22:16:25 2002 From: barry@python.org (Barry A. Warsaw) Date: Mon, 12 Aug 2002 17:16:25 -0400 Subject: [Mailman-Developers] Re: 2.1b3 make install problems References: <1029165114.7761.74.camel@dbeauchemin.si.usherb.ca> Message-ID: <15704.9641.848450.709498@anthem.wooz.org> >>>>> "DB" == Denis Beauchemin writes: DB> I have the same problem (and have had with version 2.1b2 also) DB> and the same OS as ljacobs: Oh, one thing you could try to help narrow this down: - cd to your $prefix directory - run "python -v bin/update" This will output lots of information about what Python's trying to import. Hopefully the verbose output will give us a clue as to what's failing. If it does, please send the output to me and I'll see if it makes sense Thanks, -Barry From barry@python.org Tue Aug 13 01:00:04 2002 From: barry@python.org (Barry A. Warsaw) Date: Mon, 12 Aug 2002 20:00:04 -0400 Subject: [Mailman-Developers] Scrubber.py confusion, 2.1b3 References: <01c301c241d0$d59c2ba0$0b01a8c0@mjm2> Message-ID: <15704.19460.797697.293530@anthem.wooz.org> >>>>> "MM" == Michael Meltzer writes: MM> I been going over some of the Scrubber.py code two thing are MM> standing out for me Cool, someone's looking at it :) MM> 1)A lot of work was made to make the filename unique in MM> "save_attachment", it look like a straight bug that the url MM> returned does not have the "extra" part returned as part of MM> the url, looks to me like the last line should be MM> url = baseurl + 'attachments/%s/%s' % (msgdir, filename + MM> extra) It's certainly true that extra is never used once calculated. That can't be useful. :) MM> frankly I think the forming of the name could better, like MM> filenamebase + "-" +counter + "." + ext, but that more of a MM> feature request That was the intent, but the code's broken. MM> 2)It looks like this code is doing directory abuse, it looks MM> like a unlimited amount of files names fill be placed in one MM> directory, like 2^32, this is not good for systems MM> performance, even with the latest dirhash methods by the MM> operating system ,this will become a linear screech very MM> quickly for file creates and file exists. Been their and MM> killed the patient that way. Hard to spot it until you ramp MM> the systems up. I am playing around by adding two more time MM> based directories to the system "attachments/YYYYMM/DD/". BTW MM> that what made spotting bug #1 so easy :-) I agree that the directory calculation is broken. It actually looks like a message with two attachments will end up in two different subdirs in archives/private/listname/attachments. That wasn't the intent. The idea was that each message would have a separate subdir in attachments and all its attachments would end up there. So you'd only be in trouble on very high volume lists. 2**32 at 1000 msgs / day gives you about 11k years of running room. If you were paranoid about 2**16 directories, then you might care about adding another level of directories. I'll work on fixing the code, and see how easy it is to add or change to the date-based directory. Thanks, -Barry From mjm@michaelmeltzer.com Tue Aug 13 06:00:39 2002 From: mjm@michaelmeltzer.com (Michael Meltzer) Date: Tue, 13 Aug 2002 01:00:39 -0400 Subject: [Mailman-Developers] Scrubber.py confusion, 2.1b3 References: <01c301c241d0$d59c2ba0$0b01a8c0@mjm2> <15704.19460.797697.293530@anthem.wooz.org> Message-ID: <02d101c24286$5e40a160$0b01a8c0@mjm2> Actually I "reusing" the code from Scrubber.py in MimeDel.py to turn attachments into links :-) I hardwired it for image types but it is generic enough. Some sample output from my "staging": Name: beach.jpg Type: image/jpeg Size: 18853 bytes Desc: not_available Url: http://www.michaelmeltzer.com/pipermail/meltzer-list/attachments/200208/12/b each.jpg-0005.jpe It turned out to be a 4 line hack to filter_parts, 1 line at the top and 10 lines to reformat the payload, the reset came from save_attachment, very handle :-) I have to admit environment is nice to work in. I am not sure my code it upto patch quality :-) The next step would be a modification to the content filter page for the type it should react to. I would also subject(Scrubber.py needs this too) that the filter pages list the extensions that it is allow to write. Or the converse the extensions it should not write, http://office.microsoft.com/Assistance/2000/Out2ksecFAQ.aspx. would be my start :-), save the masses someday :-) The issue with the directory is the number of files, not a name clash, `ls -d archives/private/listname/attachments/* | wc -l` > 1000 I think system performance will be effected. Above 10,000 I know it would(it would also be a problem for the http server on access). I can understand that keeping the attachment from each email in it own directory, but this way the "files version control" :-) groups them together for access(assuming least regency theory) and make cleaning out for space/inodes simple. it was just strftime wielded on. MJM ----- Original Message ----- From: "Barry A. Warsaw" To: "Michael Meltzer" Cc: Sent: Monday, August 12, 2002 8:00 PM Subject: Re: [Mailman-Developers] Scrubber.py confusion, 2.1b3 > > >>>>> "MM" == Michael Meltzer writes: > > MM> I been going over some of the Scrubber.py code two thing are > MM> standing out for me > > Cool, someone's looking at it :) > > MM> 1)A lot of work was made to make the filename unique in > MM> "save_attachment", it look like a straight bug that the url > MM> returned does not have the "extra" part returned as part of > MM> the url, looks to me like the last line should be > > MM> url = baseurl + 'attachments/%s/%s' % (msgdir, filename + > MM> extra) > > It's certainly true that extra is never used once calculated. That > can't be useful. :) > > MM> frankly I think the forming of the name could better, like > MM> filenamebase + "-" +counter + "." + ext, but that more of a > MM> feature request > > That was the intent, but the code's broken. > > MM> 2)It looks like this code is doing directory abuse, it looks > MM> like a unlimited amount of files names fill be placed in one > MM> directory, like 2^32, this is not good for systems > MM> performance, even with the latest dirhash methods by the > MM> operating system ,this will become a linear screech very > MM> quickly for file creates and file exists. Been their and > MM> killed the patient that way. Hard to spot it until you ramp > MM> the systems up. I am playing around by adding two more time > MM> based directories to the system "attachments/YYYYMM/DD/". BTW > MM> that what made spotting bug #1 so easy :-) > > I agree that the directory calculation is broken. It actually looks > like a message with two attachments will end up in two different > subdirs in archives/private/listname/attachments. That wasn't the > intent. The idea was that each message would have a separate subdir > in attachments and all its attachments would end up there. So you'd > only be in trouble on very high volume lists. 2**32 at 1000 msgs / > day gives you about 11k years of running room. If you were paranoid > about 2**16 directories, then you might care about adding another > level of directories. > > I'll work on fixing the code, and see how easy it is to add or change > to the date-based directory. > > Thanks, > -Barry From noreply@sourceforge.net Tue Aug 13 12:37:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 13 Aug 2002 04:37:56 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-550462 ] New feature: Automoderate microsoft user Message-ID: Bugs item #550462, was opened at 2002-04-30 03:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=550462&group_id=103 Category: (un)subscribing Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Mark Whitis (whitis) Assigned to: Nobody/Anonymous (nobody) Summary: New feature: Automoderate microsoft user Initial Comment: I am not using mailman at the moment but I was looking at its feature list and planned upgrades and found this missing. And it could be added in a very general form that could support many other uses. Reason for suggesting: everytime I post a message on a Linux list, I get a bunch of virus messages from bozos who have subscribed to those lists from a windows box. And I am certainly not alone in that respect. Usually these messages do not arrive via the list but are sent to anyone who posts to the list (often by lurkers). Users of real operating systems who subscribe to lists related to those should not be inconvinienced by those who use microsoft products, there of all places. I would like to suggest that future versions of Mailman include a feature (selected by the moderator) which automatically takes certain actions based on the subscibers email client. This feature could be activated based on the message headers in the replies to subscription confirmation messages. Actions could include: - Placing the user in moderated status (prevents sending virus to the list directly but doesn't prevent the virus from getting addresses from the user). - Cancelling the subscription - Sending a warning message to the user - Requiring the user to send a control message agreeing that their virus software will be kept up to date. - hide or mung all email addresses in copies of messages delivered to this user so email worms/viruses cannot harvest them. The email client status could be updated when the user sends a new control message. Optionally, it could also detect microsoft platforms via the browser ID when people sign on via the web site. Detection could be controlled by a configuration file listing with four fields: action, mail/web, field, and regex: ACCEPT MAIL X-Mailer .*Microsoft Sucks.* REJECT MAIL X-Mailer .*Microsoft Outlook.* REJECT MAIL X-Mimeole .*Microsoft Exchange.* REJECT WEB Browser-ID .*Internet Explorer.* (note: this would be triggered by opera in identify as Internet Explorer mode, but the user can switch to identify as opera). REJECT WEB Browser-ID .*Windows 95.* REJECT WEB Browser-ID .*Windows 98.* REJECT WEB Browser-ID .*Windows NT.* REJECT WEB Browser-ID .*Windows ME.* REJECT WEB Browser-ID .*Windows 2000.* REJECT WEB Browser-ID .*Win16.* REJECT WEB Browser-ID .*Win32.* REJECT WEB Browser-ID .*MSIE.* If you place someone on moderated status based on their mail client or web browser, the reason for moderation should be noted so that they can be automatically un-moderated (if otherwise consistent with policy) when they use a real computer to access the list. This feature could also be used to protect some protection against other problems, as well. Spam, REJECT MAIL From .*hotmail.com.* REJECT MAIL Subject: .*casino.* REJECT ATTACH Content-Type: application/octet-stream REJECT ATTACH Content-Type: audio/x-wav REJECT ATTACH Content-Type: audio/x-midi REJECT BODY "insurance" MODERATE-MSG BODY "profaneword" The config file could be XMLized: Possible Extensions: action: make "actions" instead and allow a comma separated list (or even nested XML action tags) moderate-msg moderate-user unmoderate-user strip-attachments strip-attachment bounce-message append-boilerplate source: comma separated list WEB_POST, WEB_CONTROL, MAIL_POST, MAIL_CONTROL, POST_BODY, POST_ATTACHMENT_HDR, POST_ATTACHMENT_BODY. blacklist: added field. .rss.mail-abuse.org .dul-mail-abuse.org Note that for the Dial Up list, this should only be applied to the first Received line added by the mail server itself. user-status: the users existing status (normal, moderated, moderated-newbie, moderated-badsoftware, trusted, moderator, list_owner, etc.) could be considered in applying filters. XML structure could be much more complicated, as well. One could also allow a user so detected to subscribe only after they had pledged to keep their virus checker up to date by sending a special control message or visiting a special web page. This could also be used to filter certain types of spam that have consistent patterns. I have seen the same websites repeately spammed to the same list (until I blew those websites away) from different aliases. ---------------------------------------------------------------------- Comment By: Claus Färber (cfaerber) Date: 2002-08-13 13:37 Message: Logged In: YES user_id=126984 The problem with misdirected bounce messages, etc. is not caused by the the operating system or the user agent. It is caused by virus scanners, vacation programmes, and even some broken MTAs that send messages back to addresses in the header and not to the return path (envelope from). Mailman could try to trigger that bug by sending a message -- for example, the monthly reminder -- with the correct return path but with a different from address. If some software then causes a bounce to be sent to the wrong address, Mailman could act accordingly (e.g. unsubscribe the user, or activate a broken-mailer flag). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=550462&group_id=103 From pioppo@ferrara.linux.it Tue Aug 13 15:39:37 2002 From: pioppo@ferrara.linux.it (Simone Piunno) Date: Tue, 13 Aug 2002 16:39:37 +0200 Subject: [Mailman-Developers] Mailman/Archiver/HyperArch.py has not been marked for i18n In-Reply-To: <15704.9525.987610.147497@anthem.wooz.org> References: <20020812185735.GI2054@ferrara.linux.it> <15704.9525.987610.147497@anthem.wooz.org> Message-ID: <20020813143937.GB12738@ferrara.linux.it> On Mon, Aug 12, 2002 at 05:14:29PM -0400, Barry A. Warsaw wrote: > SP> that no string in Mailman/Archiver/HyperArch.py has been > SP> marked for pygettext extraction. > i18n process. A brief skim shows a few in-line strings that probably > need to be wrapped, but not a whole lot. The nasty bit are the > templates sitting in the file as triple quoted strings. These should > probably be moved out in separate template files. eh, that's the least... now I can see why nobody wanted to open this can of worms... the notion of a MailList object (along with mlist.preferred_language) is lost in the process of creating Article objects and T.processUnixMailbox() is even worse. Not to mention the problem with dates localization and mangling of "2002q3" or "2002-August" volume tags. There was a template called article.html and it was completely unused (because Utils.maketext didn't receive any lang or mlist parameter) Another problem is that I'm using the list language as the archive language, so that as soon as you upgrade from 2.1b3 to the patched release, all your non-english lists will start writing translated articles. This is potentially a mess and could force list admins of non-english lists to regenerate the whole archive (the same will happen everytime you change the mlist.preferred_language). Is this acceptable? > Care to provide a patch? I'm working on it. Expect a large patch. -- Adde parvum parvo magnus acervus erit. Simone Piunno, FerraraLUG - http://members.ferrara.linux.it/pioppo From transom@extremelogic.com Tue Aug 13 16:21:24 2002 From: transom@extremelogic.com (Todd Ransom) Date: Tue, 13 Aug 2002 11:21:24 -0400 Subject: [Mailman-Developers] mailman on windows/cygwin References: <000801c234d9$c2e26640$0b00a8c0@prometheus> <15685.56530.471795.821573@anthem.wooz.org> Message-ID: <3D5923F4.4050703@extremelogic.com> I added a new entry (5.2) in the FAQ. I don't have a place to host the doc but if you would like it in its original HTML format let me know and I'll send it to you. TR Barry A. Warsaw wrote: >>>>>>"TR" == Todd Ransom writes: >>>>> > > TR> I am putting together a document to describe the steps > TR> required to get Mailman running on Windows 2000 using cygwin, > TR> exim and IIS. Just wanted to see if you were interested in > TR> including this in the documentation or on your web site. > > Absolutely! Send me a link when the docs are ready. > > I'd also suggest adding something to the Mailman FAQ. > > -Barry From noreply@sourceforge.net Tue Aug 13 16:29:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 13 Aug 2002 08:29:29 -0700 Subject: [Mailman-Developers] [ mailman-Patches-413752 ] Coerce posts to plain text. Message-ID: Patches item #413752, was opened at 2001-04-04 13:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=413752&group_id=103 Category: mail delivery >Group: Mailman 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: Geoffrey T. Dairiki (dairiki) Assigned to: Nobody/Anonymous (nobody) Summary: Coerce posts to plain text. Initial Comment: This patch adds the ability to have all posts to a mailing list forced into a MIME text/plain format. Many mailing lists have a charter which forbids binary and HTML posts to the list. This patch allows such a charter to be enforced is a maximally transparent manner. The feature is configurable on a per-list basis. If enabled, all posts to the list are run through a filter which: Squashes multipart messages into a single flat message (it picks the most plain-text-like alternative from multipart/alternative entities.) Converts 'text/html', 'text/enriched', and 'text/richtext' entities to 'text/plain'. Deletes cruft headers from content of type 'message/rfc822'. Deletes any uuencoded files from 'text/plain' entities. Entities of any other types are assumed to be binary attachements are are deleted. This patch is on mailman-2.0.3. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-13 11:29 Message: Logged In: YES user_id=12800 Since this patch is against 2.0.x and since MM2.1 provides support for stuff like this, I'm inclined to close this patch. I'd be willing to add a link to this from the unofficial patches wiki. What do you think? ---------------------------------------------------------------------- Comment By: Seb Wills (sebwills) Date: 2002-02-23 11:20 Message: Logged In: YES user_id=467580 This patch seems to leave any preamble above the first part of a multipart message intact. Many mailers put blurb such as "This is a MIME-encoded message; you will need a MIME- aware mail client to see all of this message." here, which it makes no sense to reproduce after the mail has be coerced into plaintext. Looks like it's easy enough to change this behaviour by commenting out the line mimetools.copybinary(infp, outfp) # copy preamble from Mailman/FilteringMimeWriter.py ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-12-15 13:15 Message: Logged In: YES user_id=45814 Another bug fix. Lines which contain nothing but the word 'end' mysteriously dissapear. (Reported by David Gibbs.) The only changed file in Mailman/FilteringMimeWriter.py, I've attached the latest version of that file to this page. As usual, patches on mailman 2.0.8 are also attached. Diffs and a patched Mailman-2.0.8 tarball are at ftp://www.dairiki.org/pub/mailman/ ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-09-08 16:08 Message: Logged In: YES user_id=45814 More fixes. * Mailman/FilteringMimeWriter.py: Fixes for bugs in python 1.5.2's quopri library module. The plaintext patches are at version 0.14. Look for the patches on Mailman 2.0.6, as well as a complete tarball of patched Mailman 2.0.6 code at ftp://www.dairiki.org/pub/mailman/ Patches on 2.0.6 are also attached to this page. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-08-25 15:34 Message: Logged In: YES user_id=45814 More fixes: * Mailman/PlaintextMimeWriter.py: Change Message-ID: of filtered messages. * Mailman/pythonlib/multifile.py: Fix obscure but occasionally fatal bug. The first fix is very minor. The second fix fixes a bug which caused the plaintext filter to fail occasionally. Diffs from mailman-2.0.6 are available from this page and are also at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.6-plaintext-0.13.patch.gz Pre-patched mailman-2.0.6 source code is at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.6-plaintext-0.13.tgz ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-06-16 14:33 Message: Logged In: NO After applying this patch to 2.0.5, I found that I had to add this line manually to my existing config file $prefix/Mailman/mm_cfg.py... DEFAULT_FORCE_PLAIN_TEXT = 0 If this line is not added, any web requests and any messages posted will produce an error "AttributeError : DEFAULT_FORCE_PLAIN_TEXT". Not sure if I did something wrong or if this is normal, but I wanted to advise others just in case ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-19 19:49 Message: Logged In: YES user_id=45814 More fixes: * Mailman/FilteringMimeWriter.py: Handle 'content-type: multipart' (no subtype) gracefully. * Mailman/Handlers/PlainText.py: Catch exceptions (fatal errors) from plaintext filter. When exception is caught, an error is logged, but the message is passed on unfiltered. (A diagnostic message is added to the message headers.) This should make it so little piddly bugs in the filter will get noticed, but at the same time will not cause messages to get stuck in the queue. Patches from mailman-2.0.5 are available from this page and are also at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.5-plaintext-0.10.patch.gz Pre-patched mailman-2.0.5 source code is at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.5-plaintext-0.10.tgz ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-17 15:27 Message: Logged In: YES user_id=45814 Another minor bugfix: it turns out pythons mimetools doesn't treat the content-transfer-encoding is a case insensitive fashion --- so now we smash the case ourself. A new patch set on mailman-2.0.5 is available on this page. Pre-patched mailman source code can be found at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.5-plaintext-0.9.tgz ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-08 00:38 Message: Logged In: YES user_id=45814 Disregard last. (Apparently one can't attache files bigger than 256 kb.) Mailman-2.0.5 with plaintext patches applied can be found (for a limited time) at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.5-plaintext-0.8.tgz ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-08 00:33 Message: Logged In: YES user_id=45814 If you don't want to mess with patching the source, I've also attached (below) a tarball of the mailman-2.0.5 source with my patches already applied. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-08 00:16 Message: Logged In: YES user_id=45814 Here's a rough outline of how to proceed: 1. Start by unpacking a fresh copy of mailman-2.0.5.tgz 2. Change into the top source directory (which was created in the previous step. 3. Try applying my patches with: patch -p1 < [where.ever]/mailman-2.0.5-plaintext-0.8.patch (that's "dash pee one") That should work --- you should not get any warnings or prompts from patch. If you do, something is fishy. 4. Run ./configure and 'make install' as usual (read mailman's INSTALL for instructions on this.) Feel free to write me at . ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-05-07 23:30 Message: Logged In: NO For *some* reason when I apply the patch (the newest one) to my freshly downloaded version of Mailman 2.0.5 and compile and install mail never reaches the list. I've tried without the patch and everything works fine... perhaps I'm patching wrong? I'm just saying: patch < name_of_patch It makes me fix a few paths to some of the files, but that's it... :-/ Any help would be appriciated! ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-07 12:25 Message: Logged In: YES user_id=45814 Fixed bug (reported by Pug Bainter -- thanks!) New patches, on mailman-2.0.5 uploaded (below). The only real change is: --- 0.5/Mailman/FilteringMimeWriter.py Wed, 04 Apr 2001 10:04:36 -0700 dairiki (mailman/k/4_FilteringM 1.2 664) +++ 0.8(w)/Mailman/FilteringMimeWriter.py Mon, 07 May 2001 09:05:18 -0700 dairiki (mailman/k/4_FilteringM 1.3 664) @@ -185,8 +185,12 @@ pname, pval = string.split(param, '=', 1) return (string.lower(pname), rfc822.unquote(pval)) - return map(split_param, message.getplist()) - + def valid_param(param): + return '=' in param + + # Trailing ;'s in content-type yield empty strings from getplist(). + return map(split_param, + filter(valid_param, message.getplist())) def discards_data(fp): """Determine whether file object ignores data written to it. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-04-05 11:37 Message: Logged In: YES user_id=45814 I've just made a minor change: HTML converted to plain-text now includes a list of links at the end of the message. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=413752&group_id=103 From barry@python.org Tue Aug 13 16:38:59 2002 From: barry@python.org (Barry A. Warsaw) Date: Tue, 13 Aug 2002 11:38:59 -0400 Subject: [Mailman-Developers] Scrubber.py confusion, 2.1b3 References: <01c301c241d0$d59c2ba0$0b01a8c0@mjm2> <15704.19460.797697.293530@anthem.wooz.org> <02d101c24286$5e40a160$0b01a8c0@mjm2> Message-ID: <15705.10259.859452.175451@anthem.wooz.org> >>>>> "MM" == Michael Meltzer writes: MM> Actually I "reusing" the code from Scrubber.py in MimeDel.py MM> to turn attachments into links :-) I hardwired it for image MM> types but it is generic enough. Some sample output from my MM> "staging": MM> Name: beach.jpg Type: image/jpeg Size: 18853 bytes Desc: MM> not_available Url: MM> http://www.michaelmeltzer.com/pipermail/meltzer-list/attachments/200208/12/beach.jpg-0005.jpe Cool. I'm using a slightly different naming algorithm for the path. MM> It turned out to be a 4 line hack to filter_parts, 1 line at MM> the top and 10 lines to reformat the payload, the reset came MM> from save_attachment, very handle :-) Can you try to update it to current cvs? If it's really a 4 line hack, you've got to post it. :) I tried to write the Scrubber.py updates with you in mind, by factoring out some other functionality you might need. MM> I have to admit environment is nice to work in. :) MM> I am not sure my code it upto patch quality :-) The next step MM> would be a modification to the content filter page for the MM> type it should react to. MM> I would also subject(Scrubber.py needs this too) that the MM> filter pages list the extensions that it is allow to write. Or MM> the converse the extensions it should not write, MM> http://office.microsoft.com/Assistance/2000/Out2ksecFAQ.aspx. would MM> be my start :-), save the masses someday :-) I've been thinking about this. I vaguely remember that someone did a patch to support pass-or-block semantics to the filter, but I can't put my finger on it now. I want to link Dan Mick's name to that, but does this ring a bell with anyone? MM> The issue with the directory is the number of files, not a MM> name clash Yep, I know. MM> , `ls -d archives/private/listname/attachments/* | MM> wc -l` > 1000 I think system performance will be MM> effected. Above 10,000 I know it would(it would also be a MM> problem for the http server on access). I can understand that MM> keeping the attachment from each email in it own directory, MM> but this way the "files version control" :-) groups them MM> together for access(assuming least regency theory) and make MM> cleaning out for space/inodes simple. it was just strftime MM> wielded on. I'm not sure I followed all that, but the current Scrubber.py does add the date directory to the path, so I think we're good here. -Barry From noreply@sourceforge.net Tue Aug 13 16:43:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 13 Aug 2002 08:43:20 -0700 Subject: [Mailman-Developers] [ mailman-Patches-413752 ] Coerce posts to plain text. Message-ID: Patches item #413752, was opened at 2001-04-04 10:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=413752&group_id=103 Category: mail delivery Group: Mailman 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: Geoffrey T. Dairiki (dairiki) Assigned to: Nobody/Anonymous (nobody) Summary: Coerce posts to plain text. Initial Comment: This patch adds the ability to have all posts to a mailing list forced into a MIME text/plain format. Many mailing lists have a charter which forbids binary and HTML posts to the list. This patch allows such a charter to be enforced is a maximally transparent manner. The feature is configurable on a per-list basis. If enabled, all posts to the list are run through a filter which: Squashes multipart messages into a single flat message (it picks the most plain-text-like alternative from multipart/alternative entities.) Converts 'text/html', 'text/enriched', and 'text/richtext' entities to 'text/plain'. Deletes cruft headers from content of type 'message/rfc822'. Deletes any uuencoded files from 'text/plain' entities. Entities of any other types are assumed to be binary attachements are are deleted. This patch is on mailman-2.0.3. ---------------------------------------------------------------------- >Comment By: Geoffrey T. Dairiki (dairiki) Date: 2002-08-13 08:43 Message: Logged In: YES user_id=45814 I don't have strong feelings, but my druthers would be to wait until 2.1 is officially designated "stable". A link from the wiki would be great! (There is/was already a link from the FAQ.) ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-13 08:29 Message: Logged In: YES user_id=12800 Since this patch is against 2.0.x and since MM2.1 provides support for stuff like this, I'm inclined to close this patch. I'd be willing to add a link to this from the unofficial patches wiki. What do you think? ---------------------------------------------------------------------- Comment By: Seb Wills (sebwills) Date: 2002-02-23 08:20 Message: Logged In: YES user_id=467580 This patch seems to leave any preamble above the first part of a multipart message intact. Many mailers put blurb such as "This is a MIME-encoded message; you will need a MIME- aware mail client to see all of this message." here, which it makes no sense to reproduce after the mail has be coerced into plaintext. Looks like it's easy enough to change this behaviour by commenting out the line mimetools.copybinary(infp, outfp) # copy preamble from Mailman/FilteringMimeWriter.py ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-12-15 10:15 Message: Logged In: YES user_id=45814 Another bug fix. Lines which contain nothing but the word 'end' mysteriously dissapear. (Reported by David Gibbs.) The only changed file in Mailman/FilteringMimeWriter.py, I've attached the latest version of that file to this page. As usual, patches on mailman 2.0.8 are also attached. Diffs and a patched Mailman-2.0.8 tarball are at ftp://www.dairiki.org/pub/mailman/ ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-09-08 13:08 Message: Logged In: YES user_id=45814 More fixes. * Mailman/FilteringMimeWriter.py: Fixes for bugs in python 1.5.2's quopri library module. The plaintext patches are at version 0.14. Look for the patches on Mailman 2.0.6, as well as a complete tarball of patched Mailman 2.0.6 code at ftp://www.dairiki.org/pub/mailman/ Patches on 2.0.6 are also attached to this page. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-08-25 12:34 Message: Logged In: YES user_id=45814 More fixes: * Mailman/PlaintextMimeWriter.py: Change Message-ID: of filtered messages. * Mailman/pythonlib/multifile.py: Fix obscure but occasionally fatal bug. The first fix is very minor. The second fix fixes a bug which caused the plaintext filter to fail occasionally. Diffs from mailman-2.0.6 are available from this page and are also at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.6-plaintext-0.13.patch.gz Pre-patched mailman-2.0.6 source code is at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.6-plaintext-0.13.tgz ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-06-16 11:33 Message: Logged In: NO After applying this patch to 2.0.5, I found that I had to add this line manually to my existing config file $prefix/Mailman/mm_cfg.py... DEFAULT_FORCE_PLAIN_TEXT = 0 If this line is not added, any web requests and any messages posted will produce an error "AttributeError : DEFAULT_FORCE_PLAIN_TEXT". Not sure if I did something wrong or if this is normal, but I wanted to advise others just in case ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-19 16:49 Message: Logged In: YES user_id=45814 More fixes: * Mailman/FilteringMimeWriter.py: Handle 'content-type: multipart' (no subtype) gracefully. * Mailman/Handlers/PlainText.py: Catch exceptions (fatal errors) from plaintext filter. When exception is caught, an error is logged, but the message is passed on unfiltered. (A diagnostic message is added to the message headers.) This should make it so little piddly bugs in the filter will get noticed, but at the same time will not cause messages to get stuck in the queue. Patches from mailman-2.0.5 are available from this page and are also at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.5-plaintext-0.10.patch.gz Pre-patched mailman-2.0.5 source code is at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.5-plaintext-0.10.tgz ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-17 12:27 Message: Logged In: YES user_id=45814 Another minor bugfix: it turns out pythons mimetools doesn't treat the content-transfer-encoding is a case insensitive fashion --- so now we smash the case ourself. A new patch set on mailman-2.0.5 is available on this page. Pre-patched mailman source code can be found at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.5-plaintext-0.9.tgz ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-07 21:38 Message: Logged In: YES user_id=45814 Disregard last. (Apparently one can't attache files bigger than 256 kb.) Mailman-2.0.5 with plaintext patches applied can be found (for a limited time) at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.5-plaintext-0.8.tgz ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-07 21:33 Message: Logged In: YES user_id=45814 If you don't want to mess with patching the source, I've also attached (below) a tarball of the mailman-2.0.5 source with my patches already applied. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-07 21:16 Message: Logged In: YES user_id=45814 Here's a rough outline of how to proceed: 1. Start by unpacking a fresh copy of mailman-2.0.5.tgz 2. Change into the top source directory (which was created in the previous step. 3. Try applying my patches with: patch -p1 < [where.ever]/mailman-2.0.5-plaintext-0.8.patch (that's "dash pee one") That should work --- you should not get any warnings or prompts from patch. If you do, something is fishy. 4. Run ./configure and 'make install' as usual (read mailman's INSTALL for instructions on this.) Feel free to write me at . ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-05-07 20:30 Message: Logged In: NO For *some* reason when I apply the patch (the newest one) to my freshly downloaded version of Mailman 2.0.5 and compile and install mail never reaches the list. I've tried without the patch and everything works fine... perhaps I'm patching wrong? I'm just saying: patch < name_of_patch It makes me fix a few paths to some of the files, but that's it... :-/ Any help would be appriciated! ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-07 09:25 Message: Logged In: YES user_id=45814 Fixed bug (reported by Pug Bainter -- thanks!) New patches, on mailman-2.0.5 uploaded (below). The only real change is: --- 0.5/Mailman/FilteringMimeWriter.py Wed, 04 Apr 2001 10:04:36 -0700 dairiki (mailman/k/4_FilteringM 1.2 664) +++ 0.8(w)/Mailman/FilteringMimeWriter.py Mon, 07 May 2001 09:05:18 -0700 dairiki (mailman/k/4_FilteringM 1.3 664) @@ -185,8 +185,12 @@ pname, pval = string.split(param, '=', 1) return (string.lower(pname), rfc822.unquote(pval)) - return map(split_param, message.getplist()) - + def valid_param(param): + return '=' in param + + # Trailing ;'s in content-type yield empty strings from getplist(). + return map(split_param, + filter(valid_param, message.getplist())) def discards_data(fp): """Determine whether file object ignores data written to it. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-04-05 08:37 Message: Logged In: YES user_id=45814 I've just made a minor change: HTML converted to plain-text now includes a list of links at the end of the message. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=413752&group_id=103 From pioppo@ferrara.linux.it Tue Aug 13 17:18:59 2002 From: pioppo@ferrara.linux.it (Simone Piunno) Date: Tue, 13 Aug 2002 18:18:59 +0200 Subject: [Mailman-Developers] bin/arch: a bug or not? Message-ID: <20020813161859.GD12738@ferrara.linux.it> Hi, every time I rebuild the list archive using bin/arch, the new archive has messages enumerated starting from where the old one was left and the old article .html files are left untouched (neither deleted nor overwritten). Is this the intended behaviour? I can't find any reference in the documentation. -- Adde parvum parvo magnus acervus erit. Simone Piunno, FerraraLUG - http://members.ferrara.linux.it/pioppo From barry@python.org Tue Aug 13 17:22:07 2002 From: barry@python.org (Barry A. Warsaw) Date: Tue, 13 Aug 2002 12:22:07 -0400 Subject: [Mailman-Developers] bin/arch: a bug or not? References: <20020813161859.GD12738@ferrara.linux.it> Message-ID: <15705.12847.274114.527396@anthem.wooz.org> >>>>> "SP" == Simone Piunno writes: SP> every time I rebuild the list archive using bin/arch, the new SP> archive has messages enumerated starting from where the old SP> one was left and the old article .html files are left SP> untouched (neither deleted nor overwritten). SP> Is this the intended behaviour? IMO, no, but it's the way it's worked for ages. -Barry From pioppo@ferrara.linux.it Tue Aug 13 17:33:59 2002 From: pioppo@ferrara.linux.it (Simone Piunno) Date: Tue, 13 Aug 2002 18:33:59 +0200 Subject: [Mailman-Developers] bin/arch: a bug or not? In-Reply-To: <15705.12847.274114.527396@anthem.wooz.org> References: <20020813161859.GD12738@ferrara.linux.it> <15705.12847.274114.527396@anthem.wooz.org> Message-ID: <20020813163359.GE12738@ferrara.linux.it> On Tue, Aug 13, 2002 at 12:22:07PM -0400, Barry A. Warsaw wrote: > SP> Is this the intended behaviour? > > IMO, no, but it's the way it's worked for ages. it could be a mitigating factor for people forced to rebuild the archive, becase having the old messages in place you can still serve people coming through external search engines (at the cost of wasting disk space). I think this behaviour could be documented as a feature :) -- Adde parvum parvo magnus acervus erit. Simone Piunno, FerraraLUG - http://members.ferrara.linux.it/pioppo From dgc@uchicago.edu Tue Aug 13 17:39:58 2002 From: dgc@uchicago.edu (David Champion) Date: Tue, 13 Aug 2002 11:39:58 -0500 Subject: [Mailman-Developers] Re: bin/arch: a bug or not? In-Reply-To: <20020813163359.GE12738@ferrara.linux.it> References: <20020813161859.GD12738@ferrara.linux.it> <15705.12847.274114.527396@anthem.wooz.org> <20020813163359.GE12738@ferrara.linux.it> Message-ID: <20020813163958.GI25814@dust.uchicago.edu> * On 2002.08.13, in <20020813163359.GE12738@ferrara.linux.it>, * "Simone Piunno" wrote: > > it could be a mitigating factor for people forced to rebuild the > archive, becase having the old messages in place you can still serve > people coming through external search engines (at the cost of wasting > disk space). > I think this behaviour could be documented as a feature :) It could also be a nasty turn for people accustomed to the old behavior, and IIRC Barry's pretty averse to messing with Pipermail any further. (If I'm not mistaken -- without digging into the code -- the real-time updates to the archives depend on arch's behaving this way.) It seems that you could make a copy of arch, though, and adjust some of the paths imported from paths.py so that the rebuilt html archive directory coexists with the old one, and can be easily swapped when arch is done. -- -D. Fresh fruit enriches everyone. Takes the thirst Sun Project, APC/UCCO out of everyday time. A pure whiff of oxygen, University of Chicago painting over a monochrome world in primary colors. dgc@uchicago.edu We all know that. It's why everyone loves fruit. From barry@python.org Tue Aug 13 17:50:45 2002 From: barry@python.org (Barry A. Warsaw) Date: Tue, 13 Aug 2002 12:50:45 -0400 Subject: [Mailman-Developers] bin/arch: a bug or not? References: <20020813161859.GD12738@ferrara.linux.it> <15705.12847.274114.527396@anthem.wooz.org> <20020813163359.GE12738@ferrara.linux.it> Message-ID: <15705.14565.558419.610915@anthem.wooz.org> >>>>> "SP" == Simone Piunno writes: >> SP> Is this the intended behaviour? >> IMO, no, but it's the way it's worked for ages. SP> it could be a mitigating factor for people forced to rebuild SP> the archive, becase having the old messages in place you can SP> still serve people coming through external search engines (at SP> the cost of wasting disk space). If I want to regenerate from scratch (as I do when I'm hacking on the scrubber :), I've always just blown away archives/private//* and then re-run bin/arch. A related question is whether you'll always get the same message numbers when you regenerate from scratch. I think you would, but haven't checked. Caveat doing something like bin/cleanarch over an old archive. ;( SP> I think this behaviour could be documented as a feature :) Best would be to add a switch to bin/arch to do a regen from scratch. -Barry From barry@python.org Tue Aug 13 17:52:06 2002 From: barry@python.org (Barry A. Warsaw) Date: Tue, 13 Aug 2002 12:52:06 -0400 Subject: [Mailman-Developers] Re: bin/arch: a bug or not? References: <20020813161859.GD12738@ferrara.linux.it> <15705.12847.274114.527396@anthem.wooz.org> <20020813163359.GE12738@ferrara.linux.it> <20020813163958.GI25814@dust.uchicago.edu> Message-ID: <15705.14646.788046.391504@anthem.wooz.org> >>>>> "DC" == David Champion writes: DC> It could also be a nasty turn for people accustomed to the old DC> behavior, and IIRC Barry's pretty averse to messing with DC> Pipermail any further. (If I'm not mistaken -- without DC> digging into the code -- the real-time updates to the archives DC> depend on arch's behaving this way.) I'm sure it does. -Barry From mjm@michaelmeltzer.com Tue Aug 13 17:52:06 2002 From: mjm@michaelmeltzer.com (Michael Meltzer) Date: Tue, 13 Aug 2002 12:52:06 -0400 Subject: [Mailman-Developers] Scrubber.py confusion, 2.1b3 References: <01c301c241d0$d59c2ba0$0b01a8c0@mjm2><15704.19460.797697.293530@anthem.wooz.org><02d101c24286$5e40a160$0b01a8c0@mjm2> <15705.10259.859452.175451@anthem.wooz.org> Message-ID: <005701c242e9$c1dc03f0$34f820c0@ix1x1000> I just eyeballed it, looking good, I on the "coding chain gang" for a few hours, I make my CVS recipe tonight and give it a go. Thank You. I post the MimeDel.py hack in a bit, right now my python is a graceful as a sludge hammer :-) MJM ----- Original Message ----- From: "Barry A. Warsaw" To: "Michael Meltzer" Cc: Sent: Tuesday, August 13, 2002 11:38 AM Subject: Re: [Mailman-Developers] Scrubber.py confusion, 2.1b3 > > >>>>> "MM" == Michael Meltzer writes: > > MM> Actually I "reusing" the code from Scrubber.py in MimeDel.py > MM> to turn attachments into links :-) I hardwired it for image > MM> types but it is generic enough. Some sample output from my > MM> "staging": > > MM> Name: beach.jpg Type: image/jpeg Size: 18853 bytes Desc: > MM> not_available Url: > MM> http://www.michaelmeltzer.com/pipermail/meltzer-list/attachments/200208/12/b each.jpg-0005.jpe > > Cool. I'm using a slightly different naming algorithm for the path. > > MM> It turned out to be a 4 line hack to filter_parts, 1 line at > MM> the top and 10 lines to reformat the payload, the reset came > MM> from save_attachment, very handle :-) > > Can you try to update it to current cvs? If it's really a 4 line > hack, you've got to post it. :) I tried to write the Scrubber.py > updates with you in mind, by factoring out some other functionality > you might need. > > MM> I have to admit environment is nice to work in. > > :) > > MM> I am not sure my code it upto patch quality :-) The next step > MM> would be a modification to the content filter page for the > MM> type it should react to. > > MM> I would also subject(Scrubber.py needs this too) that the > MM> filter pages list the extensions that it is allow to write. Or > MM> the converse the extensions it should not write, > MM> http://office.microsoft.com/Assistance/2000/Out2ksecFAQ.aspx. would > MM> be my start :-), save the masses someday :-) > > I've been thinking about this. I vaguely remember that someone did a > patch to support pass-or-block semantics to the filter, but I can't > put my finger on it now. I want to link Dan Mick's name to that, but > does this ring a bell with anyone? > > MM> The issue with the directory is the number of files, not a > MM> name clash > > Yep, I know. > > MM> , `ls -d archives/private/listname/attachments/* | > MM> wc -l` > 1000 I think system performance will be > MM> effected. Above 10,000 I know it would(it would also be a > MM> problem for the http server on access). I can understand that > MM> keeping the attachment from each email in it own directory, > MM> but this way the "files version control" :-) groups them > MM> together for access(assuming least regency theory) and make > MM> cleaning out for space/inodes simple. it was just strftime > MM> wielded on. > > I'm not sure I followed all that, but the current Scrubber.py does add > the date directory to the path, so I think we're good here. > > -Barry From fil@rezo.net Tue Aug 13 18:07:47 2002 From: fil@rezo.net (Fil) Date: Tue, 13 Aug 2002 19:07:47 +0200 Subject: [Mailman-Developers] XML specs for mailing-lists? Message-ID: <20020813170747.GG32522@rezo.net> Hi there, I'm working on the spip project (http://www.uzine.net/spip) which is a Content Management System under the GPL, programmed in PHP, and in French. Yet, there might be some interest in the following question: is there some XML spec for mailing-list descriptions? The long-run idea is that a website under spip could propose to each of its registered authors to 'subscribde' to such and such list. The MLM could then periodically read, through the web, the list of subscribers to those lists, and send mails accordingly. I must know how to write the answer to the question asked by the MLM (if it ever happens). Of course if such a spec exists I want to follow it ;-) -- Fil From claw@kanga.nu Tue Aug 13 18:40:07 2002 From: claw@kanga.nu (J C Lawrence) Date: Tue, 13 Aug 2002 10:40:07 -0700 Subject: [Mailman-Developers] XML specs for mailing-lists? In-Reply-To: Message from Fil of "Tue, 13 Aug 2002 19:07:47 +0200." <20020813170747.GG32522@rezo.net> References: <20020813170747.GG32522@rezo.net> Message-ID: <16636.1029260407@kanga.nu> On Tue, 13 Aug 2002 19:07:47 +0200 fil wrote: > Yet, there might be some interest in the following question: is there > some XML spec for mailing-list descriptions? The long-run idea is that > a website under spip could propose to each of its registered authors > to 'subscribde' to such and such list. The MLM could then periodically > read, through the web, the list of subscribers to those lists, and > send mails accordingly. The easier route is to used a shared DB ala SQL or LDAP as the transport via Mailman v2.1 plugin. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From noreply@sourceforge.net Tue Aug 13 19:06:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 13 Aug 2002 11:06:42 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-594703 ] Bug canceling discarded mail Message-ID: Bugs item #594703, was opened at 2002-08-13 18:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=594703&group_id=103 Category: None Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Garey Mills (gareytm) Assigned to: Nobody/Anonymous (nobody) Summary: Bug canceling discarded mail Initial Comment: When poster tries to cancel email, and moderator has already discarded it, Mailman reports a bug. Here is the trace: Traceback: Traceback (most recent call last): File "/usr/local/mailman/scripts/driver", line 82, in run_main main() File "/usr/local/mailman/Mailman/Cgi/confirm.py", line 141, in main heldmsg_prompt(mlist, doc, cookie, *content[1:]) File "/usr/local/mailman/Mailman/Cgi/confirm.py", line 612, in heldmsg_prompt ign, sender, msgsubject, givenreason, ign, ign = mlist.GetRecord(id) File "/usr/local/mailman/Mailman/ListAdmin.py", line 163, in GetRecord type, data = self.__db[id] KeyError: 5 Python information: Variable Value sys.version 2.2.1 (#1, Jun 10 2002, 14:31:04) [GCC 2.95 19990728 (release)] sys.executable /usr/local/bin/python sys.prefix /usr/local sys.exec_prefix /usr/local sys.path /usr/local sys.platform osf1V4 Environment variables: Variable Value HTTP_COOKIE mailman+admin=2802000000693f28593d7328000000613 63333616235613030333131303932383837653463343661 653733376234623536363661363939; allusers+admin=2802000000696628593d7328000000353 73635316133633866323335346264373061613638646530 323436663963633066613131336131; asc+admin=; p-r- demo+admin=280200000069bb34593d732800000034373 33562333563323038653463356264643637623566306462 6430333634313966333561353736 SERVER_SOFTWARE Apache/1.3.26 (Unix) PYTHONPATH /usr/local/mailman SCRIPT_FILENAME /usr/local/mailman/cgi-bin/confirm SERVER_ADMIN jgarey@library.berkeley.edu SCRIPT_NAME /mailman/confirm SERVER_SIGNATURE REQUEST_METHOD GET HTTP_HOST www.lib.berkeley.edu PATH_INFO /p-r- demo/690b69a8dccbfa63a5b1a8aa592f14597f517e87 SERVER_PROTOCOL HTTP/1.0 QUERY_STRING REQUEST_URI /mailman/confirm/p-r- demo/690b69a8dccbfa63a5b1a8aa592f14597f517e87 HTTP_ACCEPT image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */* HTTP_ACCEPT_CHARSET iso-8859-1,*,utf-8 HTTP_USER_AGENT Mozilla/4.79 [en] (Windows NT 5.0; U) HTTP_CONNECTION Keep-Alive HTTP_REFERER http://us.f136.mail.yahoo.com/ym/ShowLetter? MsgId=6112_8948012_210880_1238_476_0_10784&YY= 54989&inc=25&order=down&sort=date&pos=0&view=&h ead=&box=Inbox SERVER_NAME www.lib.berkeley.edu REMOTE_ADDR 128.32.238.84 REMOTE_PORT 1342 HTTP_ACCEPT_LANGUAGE en PATH_TRANSLATED /data/_b/webdata/p-r- demo/690b69a8dccbfa63a5b1a8aa592f14597f517e87 SERVER_PORT 80 GATEWAY_INTERFACE CGI/1.1 HTTP_ACCEPT_ENCODING gzip SERVER_ADDR 169.229.32.48 DOCUMENT_ROOT /data/_b/webdata ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=594703&group_id=103 From dmick@utopia.West.Sun.COM Tue Aug 13 19:37:52 2002 From: dmick@utopia.West.Sun.COM (Dan Mick) Date: Tue, 13 Aug 2002 11:37:52 -0700 Subject: [Mailman-Developers] Scrubber.py confusion, 2.1b3 References: <01c301c241d0$d59c2ba0$0b01a8c0@mjm2> <15704.19460.797697.293530@anthem.wooz.org> <02d101c24286$5e40a160$0b01a8c0@mjm2> <15705.10259.859452.175451@anthem.wooz.org> Message-ID: <3D595200.2060608@utopia.west.sun.com> > MM> I would also subject(Scrubber.py needs this too) that the > MM> filter pages list the extensions that it is allow to write. Or > MM> the converse the extensions it should not write, > MM> http://office.microsoft.com/Assistance/2000/Out2ksecFAQ.aspx. would > MM> be my start :-), save the masses someday :-) > > I've been thinking about this. I vaguely remember that someone did a > patch to support pass-or-block semantics to the filter, but I can't > put my finger on it now. I want to link Dan Mick's name to that, but > does this ring a bell with anyone? Yeah, I added some stuff, and never bothered to send it to you. It's still working, so let me cobble up a patch and show you what I've done. Didn't do anything with Scrubber.py, of course, but...perhaps it's useful as a feature in and of itself. It is useful to me. From barry@python.org Tue Aug 13 20:32:01 2002 From: barry@python.org (Barry A. Warsaw) Date: Tue, 13 Aug 2002 15:32:01 -0400 Subject: [Mailman-Developers] Scrubber.py confusion, 2.1b3 References: <01c301c241d0$d59c2ba0$0b01a8c0@mjm2> <15704.19460.797697.293530@anthem.wooz.org> <02d101c24286$5e40a160$0b01a8c0@mjm2> <15705.10259.859452.175451@anthem.wooz.org> <3D595200.2060608@utopia.west.sun.com> Message-ID: <15705.24241.853127.98326@anthem.wooz.org> >>>>> "DM" == Dan Mick writes: DM> Yeah, I added some stuff, and never bothered to send it to DM> you. It's still working, so let me cobble up a patch and show DM> you what I've done. Cool, I would like to see it, because I'm thinking something like this might have to go into MM2.1. DM> Didn't do anything with Scrubber.py, of course, but...perhaps DM> it's useful as a feature in and of itself. It is useful to DM> me. Shouldn't be related because Scrubber's all about yanking those parts out and leaving them in the file system for later access (via the web archive, or I'm guess, though a url-summary type digest). MimeDel's all about getting rid of stuff before it hits the membership. I think we just want MimeDel to support a selection on whitelist/blacklist (i.e. pass-thru these types blocking all others, or block these types passing-thru all others). -Barry From noreply@sourceforge.net Tue Aug 13 22:09:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 13 Aug 2002 14:09:26 -0700 Subject: [Mailman-Developers] [ mailman-Patches-594771 ] i18n support for Archiver Message-ID: Patches item #594771, was opened at 2002-08-13 23:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=594771&group_id=103 Category: Pipermail Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Simone Piunno (pioppo) Assigned to: Nobody/Anonymous (nobody) Summary: i18n support for Archiver Initial Comment: I'm trying to provide changes in small chunks. This 1st patch does the following: - 7 new template files: archidxentry.html archidxhead.html archidxfoot.html archliststart.html archlistend.html archtoc.html archtocentry.html - _() marking for translatable strings - a few small bugfixes (e.g. unwanted spaces, bin/arch not calling i18n.set_language, etc.) TODO: - show translated tags for archive volumes (e.g. "2002-August", "2002q3", "Week-of-Mon-XXXX") I have 2 alternatives: renaming files and dirs where the archives are built (cleaner, but screws up everything in pre-existing archives) or build a tag-to-description translator (better, I think) - find a way to produce translated datetime strings without using locale.setlocale and time.strftime() (this is discouraged in Python manual) Here I really need some advice. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=594771&group_id=103 From noreply@sourceforge.net Wed Aug 14 00:38:17 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 13 Aug 2002 16:38:17 -0700 Subject: [Mailman-Developers] [ mailman-Patches-594771 ] i18n support for Archiver Message-ID: Patches item #594771, was opened at 2002-08-13 23:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=594771&group_id=103 Category: Pipermail Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Simone Piunno (pioppo) Assigned to: Nobody/Anonymous (nobody) Summary: i18n support for Archiver Initial Comment: I'm trying to provide changes in small chunks. This 1st patch does the following: - 7 new template files: archidxentry.html archidxhead.html archidxfoot.html archliststart.html archlistend.html archtoc.html archtocentry.html - _() marking for translatable strings - a few small bugfixes (e.g. unwanted spaces, bin/arch not calling i18n.set_language, etc.) TODO: - show translated tags for archive volumes (e.g. "2002-August", "2002q3", "Week-of-Mon-XXXX") I have 2 alternatives: renaming files and dirs where the archives are built (cleaner, but screws up everything in pre-existing archives) or build a tag-to-description translator (better, I think) - find a way to produce translated datetime strings without using locale.setlocale and time.strftime() (this is discouraged in Python manual) Here I really need some advice. ---------------------------------------------------------------------- >Comment By: Simone Piunno (pioppo) Date: 2002-08-14 01:38 Message: Logged In: YES user_id=227443 Here is the 2nd patch, providing the tag-to-description translator for volume tags. This patch is incremental and must be applied after patch #¹ Now the last thing is dates. I wouln'd want to reinvent the wheel.... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=594771&group_id=103 From fil@rezo.net Wed Aug 14 00:44:05 2002 From: fil@rezo.net (Fil) Date: Wed, 14 Aug 2002 01:44:05 +0200 Subject: [Mailman-Developers] XML specs for mailing-lists? In-Reply-To: <16636.1029260407@kanga.nu> References: <20020813170747.GG32522@rezo.net> <16636.1029260407@kanga.nu> Message-ID: <20020813234405.GG4638@rezo.net> @ J C Lawrence : > The easier route is to used a shared DB ala SQL or LDAP as the transport > via Mailman v2.1 plugin. If I understand corerctly, I think a web service is much more convenient than a shared DB, as the web site and the MLM are not necessarily located on the same server. I don't know LDAP though. -- Fil From noreply@sourceforge.net Wed Aug 14 01:26:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 13 Aug 2002 17:26:42 -0700 Subject: [Mailman-Developers] [ mailman-Patches-594831 ] Incomplete DSN bounce tracking Message-ID: Patches item #594831, was opened at 2002-08-14 02:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=594831&group_id=103 Category: bounce processing Group: Mailman 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: Jesús Cea Avión (jcea) Assigned to: Nobody/Anonymous (nobody) Summary: Incomplete DSN bounce tracking Initial Comment: Mailman 2.0.13 here. I didn´t check Mailman 2.1.*. I'm very surprised nobody found & correct the problem before. Problem: Some valid DSN bounce notifications are not correctly parsed. A DSN message with several "packets", last packet is ignored. Reproduce: not neccesary. Code inspection should show this patch as trivially correct. Patch: In file Mailman/Bouncers/DSN.py, simply add two lines: --- DSN.py Tue Aug 13 13:22:39 2002 +++ DSN2.py Wed Aug 14 01:57:09 2002 @@ -105,6 +105,10 @@ headers[string.lower(hdr)] = string.strip(val) # now go through all the blocks, finding the recip address that is being # reported. + + if len(headers) : + blocks.append(headers) + addrs = [] for headers in blocks: if string.lower(headers.get('action', '')) <> 'failed': ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=594831&group_id=103 From noreply@sourceforge.net Wed Aug 14 07:19:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 13 Aug 2002 23:19:41 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-594913 ] rfc822.parseaddress() in Util.py Invalid Message-ID: Bugs item #594913, was opened at 2002-08-14 14:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=594913&group_id=103 Category: command line scripts Group: 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: Federico Sevilla III (jijo) Assigned to: Nobody/Anonymous (nobody) Summary: rfc822.parseaddress() in Util.py Invalid Initial Comment: The reference to rfc822.parseaddress() on line 160 of Util.py in Mailman 2.0.12 is invalid. As of at least Python 2.1 and Python 2.2, the rfc822 module does not contain this function. This makes it impossible to use add_members from the command line, although web-based subscription still seems to work. The pertinent traceback: Traceback (most recent call last): File "/usr/sbin/add_members", line 221, in ? main() File "/usr/sbin/add_members", line 195, in main nres = ml.ApprovedAddMembers(nmembers, None, 0, send_welcome_msg) File "/usr/lib/mailman/Mailman/MailList.py", line 1097, in ApprovedAddMembers Utils.ValidateEmail(name) File "/usr/lib/mailman/Mailman/Utils.py", line 160, in ValidateEmail realname,str = rfc822.parseaddress(str) AttributeError: 'rfc822' module has no attribute 'parseaddress' The fix is pretty simple. Simply replace realname,str = rfc822.parseaddress(str) on line 160 of Utils.py with realname,str = rfc822.parseaddr(str) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=594913&group_id=103 From claw@kanga.nu Wed Aug 14 07:52:48 2002 From: claw@kanga.nu (J C Lawrence) Date: Tue, 13 Aug 2002 23:52:48 -0700 Subject: [Mailman-Developers] XML specs for mailing-lists? In-Reply-To: Message from Fil of "Wed, 14 Aug 2002 01:44:05 +0200." <20020813234405.GG4638@rezo.net> References: <20020813170747.GG32522@rezo.net> <16636.1029260407@kanga.nu> <20020813234405.GG4638@rezo.net> Message-ID: <24827.1029307968@kanga.nu> On Wed, 14 Aug 2002 01:44:05 +0200 fil wrote: > @ J C Lawrence : >> The easier route is to used a shared DB ala SQL or LDAP as the >> transport via Mailman v2.1 plugin. > If I understand corerctly, I think a web service is much more > convenient than a shared DB, as the web site and the MLM are not > necessarily located on the same server. So use one of the many 'net transparent transports for your DB access. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From mjm@michaelmeltzer.com Wed Aug 14 10:02:31 2002 From: mjm@michaelmeltzer.com (Michael Meltzer) Date: Wed, 14 Aug 2002 05:02:31 -0400 Subject: [Mailman-Developers] Scrubber.py confusion, 2.1b3 References: <01c301c241d0$d59c2ba0$0b01a8c0@mjm2><15704.19460.797697.293530@anthem.wooz.org><02d101c24286$5e40a160$0b01a8c0@mjm2> <15705.10259.859452.175451@anthem.wooz.org> Message-ID: <06d001c24371$52b479c0$0b01a8c0@mjm2> save_attachment is looking good, "Cool", my only gripe is the url are getting very long, 80 column wrap will be an ongoing issue and most likely unsolvable. I am not married to the path issue/usage I used. I did have a problem with after 3 years by using the fully qualified date their would be over 1000 files in one directory. I am not sure about white vs. black list. The white list is nice because I know what type will pass thought, but will have the problem of playing catch up with new type's, hassle factor for the admin's and questions from new users. The black list is nice but will I wake up one mooring and read about the "latest hole" that is being exploited, could ruin a whole day ;-) Pondering it, I suspect a white list with a good set of defaults should work. I kind of like the "get the extension form mime type" but it broke down as soon as I tried to attach a "word" document, came up a application/octet-stream with only the extension as a clue. I like the method but I do not think it will last, we will end back up at lists(or maybe a real opensource anti-virus :-) MJM PS. I am sure I will get the pointy hat award for the patch below :-) I also have it running on the test server at http://www.michaelmeltzer.com/mailman/listinfo/meltzer-list , it open(at least for a few day :-), if anyone want to past some traffic thought it and see the output..............Just do not flood it out. Index: MimeDel.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Handlers/MimeDel.py,v retrieving revision 2.1 diff -u -r2.1 MimeDel.py --- MimeDel.py 18 Apr 2002 20:46:53 -0000 2.1 +++ MimeDel.py 14 Aug 2002 08:21:58 -0000 @@ -33,7 +33,9 @@ from Mailman import Errors from Mailman.Logging.Syslog import syslog from Mailman.Version import VERSION - +from Mailman.Handlers.Scrubber import save_attachment +from time import strftime +from Mailman.i18n import _ def process(mlist, msg, msgdata): @@ -41,6 +43,7 @@ if not mlist.filter_content or not mlist.filter_mime_types: return # We also don't care about our own digests or plaintext + make_attachment(mlist, msg) ctype = msg.get_type('text/plain') mtype = msg.get_main_type('text') if msgdata.get('isdigest') or ctype == 'text/plain': @@ -54,7 +57,7 @@ if msg.is_multipart(): # Recursively filter out any subparts that match the filter list prelen = len(msg.get_payload()) - filter_parts(msg, filtertypes) + filter_parts(mlist, msg, filtertypes) # If the outer message is now an emtpy multipart (and it wasn't # before!) then, again it gets discarded. postlen = len(msg.get_payload()) @@ -96,7 +99,7 @@ -def filter_parts(msg, filtertypes): +def filter_parts(mlist, msg, filtertypes): # Look at all the message's subparts, and recursively filter if not msg.is_multipart(): return 1 @@ -104,9 +107,12 @@ prelen = len(payload) newpayload = [] for subpart in payload: - keep = filter_parts(subpart, filtertypes) + keep = filter_parts(mlist, subpart, filtertypes) if not keep: continue + if make_attachment(mlist, subpart): + newpayload.append(subpart) + continue ctype = subpart.get_type('text/plain') mtype = subpart.get_main_type('text') if ctype in filtertypes or mtype in filtertypes: @@ -164,3 +170,32 @@ subpart.set_type('text/plain') changedp = 1 return changedp + + + +def make_attachment(mlist, subpart): + #should be set from mlist, work in progress + #BTW this will act real stupid with mulipart, it need the real object not the house keeping + attach_filter = ['image/bmp', 'image/jpeg', 'image/tiff', 'image/gif', 'image/png', 'image/pjpeg', 'image/x-png', 'image/x-wmf'] + ctype = subpart.get_type('text/plain') + mtype = subpart.get_main_type('text') + if ctype in attach_filter or mtype in attach_filter: + cctype = subpart.get_type() + #size is off, just could not stand to call decode to correct, might just take off 20% and be done + size = len(subpart.get_payload()) + desc = subpart.get('content-description', (_('not available'))) + filename = subpart.get_filename(_('not available')) + url = save_attachment(mlist, subpart, strftime("attch/%Y%m/%d")) + del subpart['content-type'] + del subpart['content-transfer-encoding'] + del subpart['content-disposition'] + del subpart['content-description'] + subpart.add_header('Content-Type', 'text/plain', charset='us-ascii') + subpart.add_header('Content-Transfer-Encoding', '7bit') + subpart.set_payload(_("""\ +Name: %(filename)s Type: %(cctype)s Size: %(size)d bytes Desc: %(desc)s +Url: %(url)s +""")) + return 1 + else: + return 0 ----- Original Message ----- From: "Barry A. Warsaw" To: "Michael Meltzer" Cc: Sent: Tuesday, August 13, 2002 11:38 AM Subject: Re: [Mailman-Developers] Scrubber.py confusion, 2.1b3 > > >>>>> "MM" == Michael Meltzer writes: > > MM> Actually I "reusing" the code from Scrubber.py in MimeDel.py > MM> to turn attachments into links :-) I hardwired it for image > MM> types but it is generic enough. Some sample output from my > MM> "staging": > > MM> Name: beach.jpg Type: image/jpeg Size: 18853 bytes Desc: > MM> not_available Url: > MM> http://www.michaelmeltzer.com/pipermail/meltzer-list/attachments/200208/12/beach.jpg-0005.jpe > > Cool. I'm using a slightly different naming algorithm for the path. > > MM> It turned out to be a 4 line hack to filter_parts, 1 line at > MM> the top and 10 lines to reformat the payload, the reset came > MM> from save_attachment, very handle :-) > > Can you try to update it to current cvs? If it's really a 4 line > hack, you've got to post it. :) I tried to write the Scrubber.py > updates with you in mind, by factoring out some other functionality > you might need. > > MM> I have to admit environment is nice to work in. > > :) > > MM> I am not sure my code it upto patch quality :-) The next step > MM> would be a modification to the content filter page for the > MM> type it should react to. > > MM> I would also subject(Scrubber.py needs this too) that the > MM> filter pages list the extensions that it is allow to write. Or > MM> the converse the extensions it should not write, > MM> http://office.microsoft.com/Assistance/2000/Out2ksecFAQ.aspx. would > MM> be my start :-), save the masses someday :-) > > I've been thinking about this. I vaguely remember that someone did a > patch to support pass-or-block semantics to the filter, but I can't > put my finger on it now. I want to link Dan Mick's name to that, but > does this ring a bell with anyone? > > MM> The issue with the directory is the number of files, not a > MM> name clash > > Yep, I know. > > MM> , `ls -d archives/private/listname/attachments/* | > MM> wc -l` > 1000 I think system performance will be > MM> effected. Above 10,000 I know it would(it would also be a > MM> problem for the http server on access). I can understand that > MM> keeping the attachment from each email in it own directory, > MM> but this way the "files version control" :-) groups them > MM> together for access(assuming least regency theory) and make > MM> cleaning out for space/inodes simple. it was just strftime > MM> wielded on. > > I'm not sure I followed all that, but the current Scrubber.py does add > the date directory to the path, so I think we're good here. > > -Barry From mjm@michaelmeltzer.com Wed Aug 14 10:21:40 2002 From: mjm@michaelmeltzer.com (Michael Meltzer) Date: Wed, 14 Aug 2002 05:21:40 -0400 Subject: [Mailman-Developers] Scrubber.py confusion, 2.1b3 References: <01c301c241d0$d59c2ba0$0b01a8c0@mjm2><15704.19460.797697.293530@anthem.wooz.org><02d101c24286$5e40a160$0b01a8c0@mjm2><15705.10259.859452.175451@anthem.wooz.org> <06d001c24371$52b479c0$0b01a8c0@mjm2> Message-ID: <06dd01c24373$ff7f5470$0b01a8c0@mjm2> BTW reading over the patch, it looks like I got a tab expansion issue, sorry, 5am blues :-) new one below MJM Index: MimeDel.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Handlers/MimeDel.py,v retrieving revision 2.1 diff -u -r2.1 MimeDel.py --- MimeDel.py 18 Apr 2002 20:46:53 -0000 2.1 +++ MimeDel.py 14 Aug 2002 09:19:29 -0000 @@ -33,7 +33,9 @@ from Mailman import Errors from Mailman.Logging.Syslog import syslog from Mailman.Version import VERSION - +from Mailman.Handlers.Scrubber import save_attachment +from time import strftime +from Mailman.i18n import _ def process(mlist, msg, msgdata): @@ -41,6 +43,7 @@ if not mlist.filter_content or not mlist.filter_mime_types: return # We also don't care about our own digests or plaintext + make_attachment(mlist, msg) ctype = msg.get_type('text/plain') mtype = msg.get_main_type('text') if msgdata.get('isdigest') or ctype == 'text/plain': @@ -54,7 +57,7 @@ if msg.is_multipart(): # Recursively filter out any subparts that match the filter list prelen = len(msg.get_payload()) - filter_parts(msg, filtertypes) + filter_parts(mlist, msg, filtertypes) # If the outer message is now an emtpy multipart (and it wasn't # before!) then, again it gets discarded. postlen = len(msg.get_payload()) @@ -96,7 +99,7 @@ -def filter_parts(msg, filtertypes): +def filter_parts(mlist, msg, filtertypes): # Look at all the message's subparts, and recursively filter if not msg.is_multipart(): return 1 @@ -104,9 +107,12 @@ prelen = len(payload) newpayload = [] for subpart in payload: - keep = filter_parts(subpart, filtertypes) + keep = filter_parts(mlist, subpart, filtertypes) if not keep: continue + if make_attachment(mlist, subpart): + newpayload.append(subpart) + continue ctype = subpart.get_type('text/plain') mtype = subpart.get_main_type('text') if ctype in filtertypes or mtype in filtertypes: @@ -164,3 +170,32 @@ subpart.set_type('text/plain') changedp = 1 return changedp + + + +def make_attachment(mlist, subpart): + #should be set from mlist, work in progress + #BTW this will act real stupid with mulipart, it need the real object not the house keeping + attach_filter = ['image/bmp', 'image/jpeg', 'image/tiff', 'image/gif', 'image/png', 'image/pjpeg', 'image/x-png', 'image/x-wmf'] + ctype = subpart.get_type('text/plain') + mtype = subpart.get_main_type('text') + if ctype in attach_filter or mtype in attach_filter: + cctype = subpart.get_type() + #size is off, just could not stand to call decode to correct, might just take off 20% and be done + size = len(subpart.get_payload()) + desc = subpart.get('content-description', (_('not available'))) + filename = subpart.get_filename(_('not available')) + url = save_attachment(mlist, subpart, strftime("attch/%Y%m/%d")) + del subpart['content-type'] + del subpart['content-transfer-encoding'] + del subpart['content-disposition'] + del subpart['content-description'] + subpart.add_header('Content-Type', 'text/plain', charset='us-ascii') + subpart.add_header('Content-Transfer-Encoding', '7bit') + subpart.set_payload(_("""\ +Name: %(filename)s Type: %(cctype)s Size: %(size)d bytes Desc: %(desc)s +Url: %(url)s +""")) + return 1 + else: + return 0 ----- Original Message ----- From: "Michael Meltzer" To: "Barry A. Warsaw" Cc: Sent: Wednesday, August 14, 2002 5:02 AM Subject: Re: [Mailman-Developers] Scrubber.py confusion, 2.1b3 > save_attachment is looking good, "Cool", my only gripe is the url are getting very long, 80 column wrap will be an ongoing issue and > most likely unsolvable. I am not married to the path issue/usage I used. I did have a problem with after 3 years by using the fully > qualified date their would be over 1000 files in one directory. > > I am not sure about white vs. black list. The white list is nice because I know what type will pass thought, but will have the > problem of playing catch up with new type's, hassle factor for the admin's and questions from new users. The black list is nice but > will I wake up one mooring and read about the "latest hole" that is being exploited, could ruin a whole day ;-) Pondering it, I > suspect a white list with a good set of defaults should work. I kind of like the "get the extension form mime type" but it broke > down as soon as I tried to attach a "word" document, came up a application/octet-stream with only the extension as a clue. I like > the method but I do not think it will last, we will end back up at lists(or maybe a real opensource anti-virus :-) > > MJM > PS. I am sure I will get the pointy hat award for the patch below :-) I also have it running on the test server at > http://www.michaelmeltzer.com/mailman/listinfo/meltzer-list , it open(at least for a few day :-), if anyone want to past some > traffic thought it and see the output..............Just do not flood it out. > > > > > > Index: MimeDel.py > =================================================================== > RCS file: /cvsroot/mailman/mailman/Mailman/Handlers/MimeDel.py,v > retrieving revision 2.1 > diff -u -r2.1 MimeDel.py > --- MimeDel.py 18 Apr 2002 20:46:53 -0000 2.1 > +++ MimeDel.py 14 Aug 2002 08:21:58 -0000 > @@ -33,7 +33,9 @@ > from Mailman import Errors > from Mailman.Logging.Syslog import syslog > from Mailman.Version import VERSION > - > +from Mailman.Handlers.Scrubber import save_attachment > +from time import strftime > +from Mailman.i18n import _ > > > def process(mlist, msg, msgdata): > @@ -41,6 +43,7 @@ > if not mlist.filter_content or not mlist.filter_mime_types: > return > # We also don't care about our own digests or plaintext > + make_attachment(mlist, msg) > ctype = msg.get_type('text/plain') > mtype = msg.get_main_type('text') > if msgdata.get('isdigest') or ctype == 'text/plain': > @@ -54,7 +57,7 @@ > if msg.is_multipart(): > # Recursively filter out any subparts that match the filter list > prelen = len(msg.get_payload()) > - filter_parts(msg, filtertypes) > + filter_parts(mlist, msg, filtertypes) > # If the outer message is now an emtpy multipart (and it wasn't > # before!) then, again it gets discarded. > postlen = len(msg.get_payload()) > @@ -96,7 +99,7 @@ > > > > -def filter_parts(msg, filtertypes): > +def filter_parts(mlist, msg, filtertypes): > # Look at all the message's subparts, and recursively filter > if not msg.is_multipart(): > return 1 > @@ -104,9 +107,12 @@ > prelen = len(payload) > newpayload = [] > for subpart in payload: > - keep = filter_parts(subpart, filtertypes) > + keep = filter_parts(mlist, subpart, filtertypes) > if not keep: > continue > + if make_attachment(mlist, subpart): > + newpayload.append(subpart) > + continue > ctype = subpart.get_type('text/plain') > mtype = subpart.get_main_type('text') > if ctype in filtertypes or mtype in filtertypes: > @@ -164,3 +170,32 @@ > subpart.set_type('text/plain') > changedp = 1 > return changedp > + > + > + > +def make_attachment(mlist, subpart): > + #should be set from mlist, work in progress > + #BTW this will act real stupid with mulipart, it need the real object not the house keeping > + attach_filter = ['image/bmp', 'image/jpeg', 'image/tiff', 'image/gif', 'image/png', 'image/pjpeg', 'image/x-png', > 'image/x-wmf'] > + ctype = subpart.get_type('text/plain') > + mtype = subpart.get_main_type('text') > + if ctype in attach_filter or mtype in attach_filter: > + cctype = subpart.get_type() > + #size is off, just could not stand to call decode to correct, might just take off 20% and be done > + size = len(subpart.get_payload()) > + desc = subpart.get('content-description', (_('not available'))) > + filename = subpart.get_filename(_('not available')) > + url = save_attachment(mlist, subpart, strftime("attch/%Y%m/%d")) > + del subpart['content-type'] > + del subpart['content-transfer-encoding'] > + del subpart['content-disposition'] > + del subpart['content-description'] > + subpart.add_header('Content-Type', 'text/plain', charset='us-ascii') > + subpart.add_header('Content-Transfer-Encoding', '7bit') > + subpart.set_payload(_("""\ > +Name: %(filename)s Type: %(cctype)s Size: %(size)d bytes Desc: %(desc)s > +Url: %(url)s > +""")) > + return 1 > + else: > + return 0 > > > > > > ----- Original Message ----- > From: "Barry A. Warsaw" > To: "Michael Meltzer" > Cc: > Sent: Tuesday, August 13, 2002 11:38 AM > Subject: Re: [Mailman-Developers] Scrubber.py confusion, 2.1b3 > > > > > > >>>>> "MM" == Michael Meltzer writes: > > > > MM> Actually I "reusing" the code from Scrubber.py in MimeDel.py > > MM> to turn attachments into links :-) I hardwired it for image > > MM> types but it is generic enough. Some sample output from my > > MM> "staging": > > > > MM> Name: beach.jpg Type: image/jpeg Size: 18853 bytes Desc: > > MM> not_available Url: > > MM> http://www.michaelmeltzer.com/pipermail/meltzer-list/attachments/200208/12/beach.jpg-0005.jpe > > > > Cool. I'm using a slightly different naming algorithm for the path. > > > > MM> It turned out to be a 4 line hack to filter_parts, 1 line at > > MM> the top and 10 lines to reformat the payload, the reset came > > MM> from save_attachment, very handle :-) > > > > Can you try to update it to current cvs? If it's really a 4 line > > hack, you've got to post it. :) I tried to write the Scrubber.py > > updates with you in mind, by factoring out some other functionality > > you might need. > > > > MM> I have to admit environment is nice to work in. > > > > :) > > > > MM> I am not sure my code it upto patch quality :-) The next step > > MM> would be a modification to the content filter page for the > > MM> type it should react to. > > > > MM> I would also subject(Scrubber.py needs this too) that the > > MM> filter pages list the extensions that it is allow to write. Or > > MM> the converse the extensions it should not write, > > MM> http://office.microsoft.com/Assistance/2000/Out2ksecFAQ.aspx. would > > MM> be my start :-), save the masses someday :-) > > > > I've been thinking about this. I vaguely remember that someone did a > > patch to support pass-or-block semantics to the filter, but I can't > > put my finger on it now. I want to link Dan Mick's name to that, but > > does this ring a bell with anyone? > > > > MM> The issue with the directory is the number of files, not a > > MM> name clash > > > > Yep, I know. > > > > MM> , `ls -d archives/private/listname/attachments/* | > > MM> wc -l` > 1000 I think system performance will be > > MM> effected. Above 10,000 I know it would(it would also be a > > MM> problem for the http server on access). I can understand that > > MM> keeping the attachment from each email in it own directory, > > MM> but this way the "files version control" :-) groups them > > MM> together for access(assuming least regency theory) and make > > MM> cleaning out for space/inodes simple. it was just strftime > > MM> wielded on. > > > > I'm not sure I followed all that, but the current Scrubber.py does add > > the date directory to the path, so I think we're good here. > > > > -Barry > > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman-21/listinfo/mailman-developers From Dale@Newfield.org Wed Aug 14 14:10:09 2002 From: Dale@Newfield.org (Dale Newfield) Date: Wed, 14 Aug 2002 09:10:09 -0400 (EDT) Subject: [Mailman-Developers] Scrubber.py confusion, 2.1b3 In-Reply-To: <06dd01c24373$ff7f5470$0b01a8c0@mjm2> Message-ID: On Wed, 14 Aug 2002, Michael Meltzer wrote: > BTW reading over the patch, it looks like I got a tab expansion issue, > sorry, 5am blues :-) new one below Noticed that. Great catch--thanks for the quick fix. Let me reiterate my earlier plea (for others to hear, since you've already followed it :-) for the entire codebase: "Spaces! No tabs, please!" -Dale From Dale@Newfield.org Wed Aug 14 14:07:30 2002 From: Dale@Newfield.org (Dale Newfield) Date: Wed, 14 Aug 2002 09:07:30 -0400 (EDT) Subject: [Mailman-Developers] Scrubber.py confusion, 2.1b3 In-Reply-To: <06d001c24371$52b479c0$0b01a8c0@mjm2> Message-ID: On Wed, 14 Aug 2002, Michael Meltzer wrote: > I kind of like the "get the extension form mime type" but it broke down > as soon as I tried to attach a "word" document, came up a > application/octet-stream with only the extension as a clue. I like the > method but I do not think it will last, we will end back up at lists Just want to make sure that the reason you're thinking about this is the same reason I am: I don't want someone mailing something to a mailing list forged just right so that a file with an extension they specify lands on my web server and then gets not just served from that box, but *executed* by the web server on it's way out. The most recent content system I built does indeed use the mime-type, and builds the filename extension from it. If someone sends a file abcdefg.cgi as image/gif, I will write out Q/N000-N999/X.Y.gif (where N=(X%1000), and Q, X, Y are determined by other parts of the system). The filename they send is completely dropped, and I get to filter on mime-type, assured that since the web server decides mime-type from extension, it will decide the same mime-type I was told. Sure, someone can upload stuff that might be malicious, but since I'm assured it'll never be executed, I'm not worried. -Dale From fil@rezo.net Wed Aug 14 14:56:35 2002 From: fil@rezo.net (Fil) Date: Wed, 14 Aug 2002 15:56:35 +0200 Subject: [Mailman-Developers] XML specs for mailing-lists? In-Reply-To: <24827.1029307968@kanga.nu> References: <20020813170747.GG32522@rezo.net> <16636.1029260407@kanga.nu> <20020813234405.GG4638@rezo.net> <24827.1029307968@kanga.nu> Message-ID: <20020814135634.GD18323@rezo.net> Now I think I'll do something different: 1) my user database will know how to write the list of persons it wants to see as subscribers to some listname. This will be the result of of web query with authentication. Its answer's format will be email -- password for mailing-lists -- name (seperated by tabulations) 2) a script will call the page every 2 hours, check that it came through without problems, then do withlist listname unsubscribe everybody while () subscribe address=joe@mail.com, passwd=xxxx, name=Joe User (maybe just update the list by flagging "nomail" on/ or deleting/ absent addresses and by adding the new ones, in order to keep all the flags) -- Fil From noreply@sourceforge.net Wed Aug 14 17:46:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 14 Aug 2002 09:46:41 -0700 Subject: [Mailman-Developers] [ mailman-Patches-444879 ] Archive indexer control to improve index Message-ID: Patches item #444879, was opened at 2001-07-26 18:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=444879&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 7 Submitted By: Richard Barrett (ppsys) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Archive indexer control to improve index Initial Comment: This patch is applicable to Mailman 2.0.6 release and supercedes ealier patches 401669 and 402422. This patch should improve the quality of search results returned by search engines such as htdig (http://www.htdig.org) where the seach engine's index builder responds to strings embedded in the html pages that are the subject of the indexing. The changes in this patch: 1. allow strings for enabling and disabling indexing to be defined in mm_cfg.py. 2. embeds those strings in the pages generated as the html version of a list's archive. By default nothing in the html changes. To get the desired effect, you must define ARCHIVE_INDEXING_ENABLE and ARCHIVE_INDEXING_DISABLE in mm_cfg.py You probably want to run this patch as follows: cd patch -p1 < See also the associated patch for integrating the htdig search software with mailman's internal archiver ouput. ---------------------------------------------------------------------- >Comment By: Richard Barrett (ppsys) Date: 2002-08-14 16:46 Message: Logged In: YES user_id=75166 indexing-2.1b3-0.1.patch is a revised version of the patch that is compatible with MM 2.1b3 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-08-08 17:32 Message: Logged In: YES user_id=75166 An additional file, README.NOINDEXtags is added to indexing-2.0.13-0.3.patch version that discusses the issue of what tags to use for controlling various search engine indexers. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-08-08 17:19 Message: Logged In: YES user_id=75166 An error when building the indexing-2.1b2-0.1.patch meant that copies of the originals of two of the files modified by this version of the patch were added when the patch was run. indexing-2.1b2-0.1.patch removes this error. However, the original error is benign and can be corrected by deleting the extra files HyperArch.py.orig and Defaults.py.in.orig. An additional file, README.NOINDEXtags is added that discusses the issue of what tags to use for controlling various search engine indexers. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-08 14:19 Message: Logged In: YES user_id=12800 Another question: is there no standard (de-facto or otherwise) for generic markup that tells indexers not to index a particular section? IOW, for ARCHIVE_INDEXING_ENABLE and ARCHIVE_INDEXING_DISABLE, is there some generic value that would instruct most (all?) indexers to ignore that section? Or does it necessarily have to be indexer specific? I'm thinking of the situation where you might have ht://Dig installed locally, but your archives are still being spidered by external indexers. It would be good if something more generic could be added to Defaults.py.in ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-08 14:14 Message: Logged In: YES user_id=12800 Looking at the 2.1b2 patch, why does it try to create HyperArch.py.orig and Defaults.py.in.orig? Are those included in the patch by mistake? ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-08-05 10:08 Message: Logged In: YES user_id=75166 indexing-2.0.13-0.2.patch just adds a GPL notice to the patch ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-08-01 16:33 Message: Logged In: YES user_id=75166 indexing-2.1b2-0.1.patch is a revised version of the patch that is compatible with MM 2.1b2 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-07-30 11:23 Message: Logged In: YES user_id=75166 indexing-2.0.13-0.1.patch is purely cosmetic to get no mumble application to MM 2.0.13 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-07-25 14:11 Message: Logged In: YES user_id=75166 indexing-2.0.11-0.1.patch should apply without problems to MM 2.0.12 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-05-23 09:50 Message: Logged In: YES user_id=75166 indexing-2.0.11-0.1.patch is a revised version of the patch that is compatible with MM 2.0.11 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-04-19 10:53 Message: Logged In: YES user_id=75166 indexing-2.0.9-0.1.patch should apply without problems to MM 2.0.10 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-04-08 17:43 Message: Logged In: YES user_id=75166 indexing-2.0.9-0.1.patch is a revised version of the patch that is compatible with MM 2.0.9 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-03-06 16:14 Message: Logged In: YES user_id=75166 indexing-2.1cvs-20020306.patch is a revised version of the patch that is compatible with the code published in mailman CVS on sourceforge as 12:30 GMT 6 Mar 2002. Corrects problem noted or 5 Mar 2002 by nobody ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-03-05 21:41 Message: Logged In: NO When applying this patch I get an error with Hunk 1 and Defaults.py is not updated. This happens with the a clean download of the latest cvs installation (5 Mar 2002). Any ideas what the problem is? ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-12-17 16:53 Message: Logged In: YES user_id=75166 indexing-2.1cvs-20011217.patch is a revised version of the patch that is compatible with the code published in mailman CVS on sourceforge as 11:50 GMT 17 Dec 2001 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-12-13 16:48 Message: Logged In: YES user_id=75166 indexing-2.1a3-0.1.patch is a revised version of the patch that is compatible with the code published in mailman-2.1a3.tgz on sourceforge. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-28 11:07 Message: Logged In: YES user_id=75166 This patch should also apply without problems to MM 2.0.8 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-27 12:03 Message: Logged In: YES user_id=75166 This patch should also apply without problems to MM 2.0.7 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=444879&group_id=103 From noreply@sourceforge.net Wed Aug 14 17:51:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 14 Aug 2002 09:51:43 -0700 Subject: [Mailman-Developers] [ mailman-Patches-444884 ] Integration of Mailman & htdig for archi Message-ID: Patches item #444884, was opened at 2001-07-26 18:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=444884&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 7 Submitted By: Richard Barrett (ppsys) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Integration of Mailman & htdig for archi Initial Comment: This patch is applicable to Mailman 2.0.6 release that has had search enhancement patch 444879 patch installed - if your Defaults.py has the ARCHIVE_INDEXING_ENABLE and ARCHIVE_INDEXING_DISABLE in it then you've got that patch. It replaces earlier patches 401670 and 402423 and is mainly to correct some problems arising from fixes introduced into Mailman by bug fix releases since the 402423 patch. This patch integrates htdig with Mailman and provides: 1. per list search facility with a search form on the list's TOC page. 2. maintenance of privacy of private archives which requires the user to establish their credentials via the normal private archive access before any access via htdig is allowed. 3. a common base URL for both public and private archive access via htsearch results so that htdig indices are unaffected by changingan archive from private to public and vice versa. All access to archives via htdig is controlled by a new wrapped cgi- bin script called htdig.py. 4. a new cron activated script and extra crontab entry which runs htdig regularly to maintain the per list search indices. 5. automatic creation, deletion and maintenance of htdig configuration files and such. Beyond installing htdig and telling Mailman where it is via mm_cfg you do not have to do any other setup. Well not quite you do have to set up a single per installation symlink to allow htdig to find the automatically generated per list htdig configuration files. You probably want to run this patch as follows: cd patch -p1 < ---------------------------------------------------------------------- >Comment By: Richard Barrett (ppsys) Date: 2002-08-14 16:51 Message: Logged In: YES user_id=75166 htdig-2.1b3-0.1.patch is a revised version of the patch that is compatible with MM 2.1b3 ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-08 16:33 Message: Logged In: YES user_id=12800 I've sent Richard some comments off-line about this patch. Meta comments: the 2.0.x patches can't be officially supported, but I'm going to create an unofficial patches page off the wiki for where the 2.0 patches can be migrated. I think this patch set is too big for MM2.1, but if it's cleaned up as per my private message, let's re-evaluate it for MM2.2 (or 3.0). ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-08-05 10:11 Message: Logged In: YES user_id=75166 htdig-2.0.13-0.2.patch just adds a GPL notice to the patch ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-08-01 16:35 Message: Logged In: YES user_id=75166 htdig-2.1b2-0.1.patch is a revised version of the patch that is compatible with MM 2.1b2 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-07-30 11:25 Message: Logged In: YES user_id=75166 htdig-2.0.13-0.1.patch is purely cosmetic to get no mumble application to MM 2.0.13 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-07-25 15:07 Message: Logged In: YES user_id=75166 Do not use htdig-2.0.12-0.1.patch there is an error in it. Use htdig-2.0.12-0.2.patch instead ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-07-25 14:10 Message: Logged In: YES user_id=75166 htdig-2.0.12-0.1.patch is a revised version of the patch that applies without complaint to MM 2.0.12. It also add a facility for adding site wide htdig configuration attributes to all list specific htdig configuration files. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-05-23 09:59 Message: Logged In: YES user_id=75166 htdig-2.0.11-0.1.patch is a revised version of the patch that is compatible with MM 2.0.11 This version removes an incompatibility with Python 2.2 which caused warning messages to be generated when any of the family cron/nightly_htdig scripts were run. Some guidance on file access permissions for some htdig database files needed by rundig have been added to installation notes. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-04-19 10:59 Message: Logged In: YES user_id=75166 htdig-2.0.10-0.1.patch is a revised version of the patch that is compatible with MM 2.0.10 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-04-08 17:46 Message: Logged In: YES user_id=75166 htdig-2.0.9-0.1.patch is a revised version of the patch that is compatible with MM 2.0.9 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-03-06 16:22 Message: Logged In: YES user_id=75166 htdig-2.1cvs-20020306.patch is a revised version of the patch that is compatible with the code published in mailman CVS on sourceforge as 12:30 GMT 6 Mar 2002 Known deficiency is that the non-English versions of files under $build/templates still contain text in English and need translations I cannot do. Also the necessary pygettext activity and subsequent translations in files under $build/messages remain to be done. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-12-17 16:56 Message: Logged In: YES user_id=75166 htdig-2.1cvs-20011217.patch is a revised version of the patch that is compatible with the code published in mailman CVS on sourceforge as 11:50 GMT 17 Dec 2001 The only known deficiency is that the non-English versions of files under $build/templates still contain text in English and need translations I cannot do. Also the necessary pygettext activity and subsequent translations in files under $build/messages remain to be done. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-12-13 16:58 Message: Logged In: YES user_id=75166 htdig-2.1a3-0.1.patch is a revised version of the patch that is compatible with the code published in mailman-2.1a3.tgz on sourceforge. The only known deficiency is that the non-English versions of files under $build/templates still contain text in English and need translations I cannot do. Also the necessary pygettext activity and subsequent translations in files under $build/messages remain to be done. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-28 17:33 Message: Logged In: YES user_id=75166 The htdig-2.0.8-0.1.patch version of the patch resolves a problem that can arise with htdig indexing if the web_page_url for a list uses other than the http addressing (some folks want to use https). While specified as for MM 2.0.8 the revised patch should work OK with 2.0.7, 2.0.6 and probably back as far as 2.0.3. If you do not have the requirement for using other than http addressing in you lists web_page_urls it probably isn't worth the trouble of upgrading to this patch level. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-28 11:08 Message: Logged In: YES user_id=75166 This patch should also apply without problems to MM 2.0.8 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-27 12:00 Message: Logged In: YES user_id=75166 This patch should also apply without problems to Mm 2.0.7 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-09 11:54 Message: Logged In: YES user_id=75166 The htdig-2.0.6-03.patch version of the patch makes some previously hard-coded things configurable and enhances the capability to run the htdig searches and indexing on a different machine to the one delivering Mailman and Mailman's web UI. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=444884&group_id=103 From noreply@sourceforge.net Wed Aug 14 18:02:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 14 Aug 2002 10:02:58 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-595132 ] No mail going out Message-ID: Bugs item #595132, was opened at 2002-08-14 17:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=595132&group_id=103 Category: mail delivery Group: None Status: Open Resolution: None Priority: 5 Submitted By: Terkel Olsen (terkel) Assigned to: Nobody/Anonymous (nobody) Summary: No mail going out Initial Comment: Hi there, i have Installed Mailman manually on a NetBSD for some reason its not in pkgsrc anymore. It installs allmost fine, just had to fix a few GID's and point it to python, and then it appeared to install. I created a list fine and it sent the e-mail to the admin adress, but if i try to send anything to the list nothing gets send back. Its not even held for approval. The error log shows nothing and the maillog only shows this: Aug 14 11:06:19 www sendmail[29601]: g7E96J229601: from=terkel, size=54, class=0, nrcpts=1, msgid=<200208140906.g7E96J229601@www.bon nierforlagene.dk>, relay=terkel@localhost Aug 14 11:06:19 www sendmail[29603]: g7E96J229601: to="|/usr/home/mailman/mailman/mail/wrapper post jokes", ctladdr=Jokes@www.bonnie rforlagene.dk (1/0), delay=00:00:00, xdelay=00:00:00, mailer=prog, pri=30054, dsn=2.0.0, stat=Sent But nothing further, so i guess it goes to the wrapper program but then no further... Anyone experienced this before ? Terkel ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=595132&group_id=103 From barry@python.org Wed Aug 14 19:33:19 2002 From: barry@python.org (Barry A. Warsaw) Date: Wed, 14 Aug 2002 14:33:19 -0400 Subject: [Mailman-Developers] Re: SOURCEFORGE.NET UPDATE: August 14, 2002 References: Message-ID: <15706.41583.382852.938448@anthem.wooz.org> For those of you who didn't get SourceForge's latest email update: SF> 5. SITE STATISTICS SF> Stats: (Monday 12th, 2000) SF> Hosted Projects: 45,194 SF> Registered Users: 465,530 SF> Page Views: 3,344,708 in a single day (Monday) SF> Files transfered in a single day: 340,838 (Monday) SF> Emails sent in a single day from Mailing lists: 851,143 (Monday) --------------------------------------------------------^^^^^^^ Cool! :) -Barry From noreply@sourceforge.net Wed Aug 14 19:49:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 14 Aug 2002 11:49:18 -0700 Subject: [Mailman-Developers] [ mailman-Patches-594771 ] i18n support for Archiver Message-ID: Patches item #594771, was opened at 2002-08-13 23:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=594771&group_id=103 Category: Pipermail Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Simone Piunno (pioppo) Assigned to: Nobody/Anonymous (nobody) Summary: i18n support for Archiver Initial Comment: I'm trying to provide changes in small chunks. This 1st patch does the following: - 7 new template files: archidxentry.html archidxhead.html archidxfoot.html archliststart.html archlistend.html archtoc.html archtocentry.html - _() marking for translatable strings - a few small bugfixes (e.g. unwanted spaces, bin/arch not calling i18n.set_language, etc.) TODO: - show translated tags for archive volumes (e.g. "2002-August", "2002q3", "Week-of-Mon-XXXX") I have 2 alternatives: renaming files and dirs where the archives are built (cleaner, but screws up everything in pre-existing archives) or build a tag-to-description translator (better, I think) - find a way to produce translated datetime strings without using locale.setlocale and time.strftime() (this is discouraged in Python manual) Here I really need some advice. ---------------------------------------------------------------------- >Comment By: Simone Piunno (pioppo) Date: 2002-08-14 20:49 Message: Logged In: YES user_id=227443 And finally, this is the 3rd piece of the puzzle: dates translation. I had to reinvent the wheel, and it's an relatively expensive hack (from a computational efficiency point of view) but it works without touching pipermail.py This patch is incremental and must be applied after #2 ---------------------------------------------------------------------- Comment By: Simone Piunno (pioppo) Date: 2002-08-14 01:38 Message: Logged In: YES user_id=227443 Here is the 2nd patch, providing the tag-to-description translator for volume tags. This patch is incremental and must be applied after patch #¹ Now the last thing is dates. I wouln'd want to reinvent the wheel.... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=594771&group_id=103 From mjm@michaelmeltzer.com Wed Aug 14 19:39:45 2002 From: mjm@michaelmeltzer.com (Michael Meltzer) Date: Wed, 14 Aug 2002 14:39:45 -0400 Subject: [Mailman-Developers] Scrubber.py confusion, 2.1b3 References: Message-ID: <036b01c243c1$f5cd0b40$34f820c0@ix1x1000> You got a point, we should chmod 644 (or umask 133) on the file and prevent any leading dot files (like .httpaceess :-), even with that I was a little pissed off that php reacted to the file. This is going to be bad news, I know I can lock down the paths better but..., "get the extension form mime type" will break too. if it returns a extension that is enabled in the http server or if a list owner turns on one this becomes a security blackhole. More reason to use a white list, and one that can only be a subset from mm_conf.py whitelist. MJM ----- Original Message ----- From: "Dale Newfield" To: "Michael Meltzer" Cc: "Barry A. Warsaw" ; Sent: Wednesday, August 14, 2002 9:07 AM Subject: Re: [Mailman-Developers] Scrubber.py confusion, 2.1b3 > On Wed, 14 Aug 2002, Michael Meltzer wrote: > > I kind of like the "get the extension form mime type" but it broke down > > as soon as I tried to attach a "word" document, came up a > > application/octet-stream with only the extension as a clue. I like the > > method but I do not think it will last, we will end back up at lists > > Just want to make sure that the reason you're thinking about this is the > same reason I am: I don't want someone mailing something to a mailing > list forged just right so that a file with an extension they specify lands > on my web server and then gets not just served from that box, but > *executed* by the web server on it's way out. The most recent content > system I built does indeed use the mime-type, and builds the filename > extension from it. If someone sends a file abcdefg.cgi as image/gif, I > will write out Q/N000-N999/X.Y.gif (where N=(X%1000), and Q, X, Y are > determined by other parts of the system). The filename they send is > completely dropped, and I get to filter on mime-type, assured that since > the web server decides mime-type from extension, it will decide the same > mime-type I was told. Sure, someone can upload stuff that might be > malicious, but since I'm assured it'll never be executed, I'm not worried. > > -Dale > From marc_news@merlins.org Wed Aug 14 20:02:06 2002 From: marc_news@merlins.org (Marc MERLIN) Date: Wed, 14 Aug 2002 12:02:06 -0700 Subject: [Mailman-Developers] Re: SOURCEFORGE.NET UPDATE: August 14, 2002 In-Reply-To: <15706.41583.382852.938448@anthem.wooz.org> References: <15706.41583.382852.938448@anthem.wooz.org> Message-ID: <20020814190206.GK5238@merlins.org> On Wed, Aug 14, 2002 at 02:33:19PM -0400, Barry A. Warsaw wrote: > SF> Emails sent in a single day from Mailing lists: 851,143 (Monday) > --------------------------------------------------------^^^^^^^ Actually, I remember that we hit a million a few times :-) Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From noreply@sourceforge.net Thu Aug 15 01:57:55 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 14 Aug 2002 17:57:55 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-595333 ] REQ: admindb list of default responses Message-ID: Bugs item #595333, was opened at 2002-08-15 00:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=595333&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dylan Jay (dylan_jay) Assigned to: Nobody/Anonymous (nobody) Summary: REQ: admindb list of default responses Initial Comment: When moderating most rejected posts fit into certain catagories. It would be a big time saver to have a drop down list of default responces. Each would have a name and settings and text for the responce. A text box and a "add as new default responce" checkbox is all that is needed to add a new response (or edit one) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=595333&group_id=103 From noreply@sourceforge.net Thu Aug 15 05:37:52 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 14 Aug 2002 21:37:52 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-540978 ] eMailadress too long ? Message-ID: Bugs item #540978, was opened at 2002-04-08 05:56 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=540978&group_id=103 Category: mail delivery Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Markus Mandalka (mandalka) Assigned to: Nobody/Anonymous (nobody) Summary: eMailadress too long ? Initial Comment: I have a list antiatomforum@lists.kommunikationssystem.de and others with long names. It seems that mailman can not handle with such long names, because in the subscribe-mail (which you have to answer to be in the list) the first columns are some things from the header (unsubscribe: xxx@lists.xxx and so on). Whith names like atest@lists.kommunikationssystem.de it works. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-08-14 21:37 Message: Logged In: NO I just installed mailman and can confirm this bug as well. When the list address + hostname is too long (in my case the listname was north-texas-stovebolters- club@stovebolt.stovebolt.com -- 52 characters total) the headers overflow into the body of the message. The "break point" was at the List Subscribe line: ******************* This is header: List-Subscribe: , (total of 94 characters before the split) ******************* This is body List-Unsubscribe: , List-Archive: List-Help: Sender: north-texas-stovebolters-club- bounces@stovebolt.stovebolt.com Errors-To: north-texas-stovebolters-club- bounces@stovebolt.stovebolt.com ************************ This is the initial text of the message that was posted. I'm sure that I'll be there. :-) **************************** It looks like there's a line break or line limit that's causing the problem. Perhaps it's line 33: MAXLINELEN = 78 The first line that breaks (in my case) is a line that has 94 characters in the first part, none of which can be separated (no spaces or line breaks, just continuous text.) The very next line drops to the body. I believe giuans is correct that the problem is in the wrap section of the code, because the break occurs immediately after a comma, which, if I'm understanding the code correctly, is inserted by the program after an overlength line occurs, to split the line at 78 (or as close to that as it can get.) I think the correct fix would be to add the "h" portion subsequent to the split so that each line in the header would have the required semi-colon to indicate that it's header. If the MTA sees a line with no semicolon, it's going to think that it's body text, not header. ***************** Present code: if len(h) + 2 + len(v) > 78: v = CONTINUATION.join(v.split(', ')) msg[h] = v ****************** Possible fix if len(h) + 2 + len(v) > 78: v=CONTINUATION.join(h + v.split(',')) msg[h] = v or something like that. (I haven't worked with php, so I'm not familiar with its functions and syntax.) The idea is to split a line like this: Line exceeds 78 characters? h+v, h+ rest of v HTH. ---------------------------------------------------------------------- Comment By: Jean Millerat (drsigmund) Date: 2002-07-04 01:13 Message: Logged In: YES user_id=70686 I have reached the same bug with mailing list adresses such as <11 characters>@<30 characters> whereas <8 characters>@<30 characters> works properly. The effect of this bug is that the headers of the subcription annoucement or any further email from the list are "mangled" as was said on [mailman-developers]. As an example when one of the List-* header line is too long, it is broken in two parts (and the second part is indented). Since then, Outlook (and I suppose other email clients) think this second part of the broken header line is the beginning of the body of the message. Therefore the remaining headers are sent as part of the body of the message ! I think this bug does not only occur with too long email adresses but may occur with too long header lines whichever line it is (even with the Subject line especially when this subject line is very long because of quoted-printable characters). See [mailman-developers] for the description of maybe the same bug, in mails dealing with headers being "mangled". My current workarounds : - using short mailing list names. - and not sending quoted-printable characters within subject lines. ---------------------------------------------------------------------- Comment By: Giovanni Lopedote (giuans) Date: 2002-05-02 07:27 Message: Logged In: YES user_id=531451 I've found it. A fast fix for is to comment lines 149-150 in Mailman/Handlers:/CookHeaders.py: --- CookHeaders.py 2002-05-02 14:51:36.000000000 +0200 +++ CookHeaders.py.new 2002-05-02 16:12:09.000000000 +0200 @@ -146,8 +146,8 @@ # Wrap these lines if they are too long. 78 character width probably # shouldn't be hardcoded, but is at least text-MUA friendly. The # adding of 2 is for the colon-space separator. - if len(h) + 2 + len(v) > 78: - v = CONTINUATION.join(v.split(', ')) +# if len(h) + 2 + len(v) > 78: +# v = CONTINUATION.join(v.split(', ')) msg[h] = v # Always delete List-Archive header, but only add it back if the list is # actually archiving Tested with Mailman 2.1b1, Source Mage GNU/Linux 2.4.18, Postfix 1.1.7. I know there should be a better way, but I'm not a Python programmer at all. :) ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-04-11 15:03 Message: Logged In: YES user_id=12800 I've confirmed this bug, but don't have a fix for it right now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=540978&group_id=103 From chuqui@plaidworks.com Thu Aug 15 06:29:47 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Wed, 14 Aug 2002 22:29:47 -0700 Subject: [Mailman-Developers] Html bugs in 2.0.13 Message-ID: Barry -- Ran into some HTML bugs in 2.0.13. For instance, going to the listinfo/mailman-subscribers page and subscribing, it returns the "confirmation is required" warning. It looks good, but view source it. An unterminated " is in the body, not in the head. While it seems to format okay in browsers, it's seriously broken HTML, and it's driving mod_layout nuts, since it depends on the body tags to do header/footer insertions right. I think there's one other generated page with similar problems, too, but I'm not sure which it is yet. Chuq Mailman-Users Subscription results

Mailman-Users Subscription results

Confirmation from your email address is required, to prevent anyone from subscribing you without permission. Instructions are being sent to you at me@chuqui.com. Please note your subscription will not start until you confirm your subscription.
Mailman-Users list run by barry@wooz.org, chuqui@plaidworks.com, mailman-admin@vo.cnchost.com< br>Mailman-Users administrative interface (requires authorization)

Delivered by Mailman
version 2.0.13 (101270)		 Python Powered GNU's Not Unix

-- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ Very funny, Scotty. Now beam my clothes down here, will you? From jarrell@vt.edu Thu Aug 15 08:48:24 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Thu, 15 Aug 2002 03:48:24 -0400 Subject: [Mailman-Developers] command runner Message-ID: <5.1.0.14.2.20020815034312.04eb2800@lennier.cc.vt.edu> Sorry if this has been reported and I haven't noticed it; been way busy with a bunch of new hardware, and the frenetic rush to change the entire universe between semesters (school starts in just over a week) and so I've been skimming the list, rather than savoring each and every mouthful of pythony mailinglistingly goodness... :-) Anyway, I just threw the current snapshot up on my machine, and it's fine, except someone tried to do a confirm, and commandrunner threw an exception. It's possible the subscription happened before the upgrade, and the confirm afterwards, but I haven't dug through the logs to see. Aug 15 03:23:26 2002 (19680) Uncaught runner exception: 'NoneType' object has no attribute 'lstrip' Aug 15 03:23:26 2002 (19680) Traceback (most recent call last): File "/home/mailman/Mailman/Queue/Runner.py", line 105, in _oneloop self._onefile(msg, msgdata) File "/home/mailman/Mailman/Queue/Runner.py", line 154, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/home/mailman/Mailman/Queue/CommandRunner.py", line 198, in _dispose res.process() File "/home/mailman/Mailman/Queue/CommandRunner.py", line 93, in process stop = self.do_command(cmd, args) File "/home/mailman/Mailman/Queue/CommandRunner.py", line 119, in do_command return handler.process(self, args) File "/home/mailman/Mailman/Commands/cmd_confirm.py", line 72, in process if line.lstrip() == match: AttributeError: 'NoneType' object has no attribute 'lstrip' From noreply@sourceforge.net Thu Aug 15 12:02:53 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 15 Aug 2002 04:02:53 -0700 Subject: [Mailman-Developers] [ mailman-Patches-444884 ] Integration of Mailman & htdig for archi Message-ID: Patches item #444884, was opened at 2001-07-26 18:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=444884&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 7 Submitted By: Richard Barrett (ppsys) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Integration of Mailman & htdig for archi Initial Comment: This patch is applicable to Mailman 2.0.6 release that has had search enhancement patch 444879 patch installed - if your Defaults.py has the ARCHIVE_INDEXING_ENABLE and ARCHIVE_INDEXING_DISABLE in it then you've got that patch. It replaces earlier patches 401670 and 402423 and is mainly to correct some problems arising from fixes introduced into Mailman by bug fix releases since the 402423 patch. This patch integrates htdig with Mailman and provides: 1. per list search facility with a search form on the list's TOC page. 2. maintenance of privacy of private archives which requires the user to establish their credentials via the normal private archive access before any access via htdig is allowed. 3. a common base URL for both public and private archive access via htsearch results so that htdig indices are unaffected by changingan archive from private to public and vice versa. All access to archives via htdig is controlled by a new wrapped cgi- bin script called htdig.py. 4. a new cron activated script and extra crontab entry which runs htdig regularly to maintain the per list search indices. 5. automatic creation, deletion and maintenance of htdig configuration files and such. Beyond installing htdig and telling Mailman where it is via mm_cfg you do not have to do any other setup. Well not quite you do have to set up a single per installation symlink to allow htdig to find the automatically generated per list htdig configuration files. You probably want to run this patch as follows: cd patch -p1 < ---------------------------------------------------------------------- >Comment By: Richard Barrett (ppsys) Date: 2002-08-15 11:02 Message: Logged In: YES user_id=75166 htdig-2.1b3-0.2.patch corrects a dumb syntax error in htdig- 2.1b3-0.1.patch which will typically show up as logged errors in the operation of the ArchRunner qrunner at line 721 of HyperArch.py ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-08-14 16:51 Message: Logged In: YES user_id=75166 htdig-2.1b3-0.1.patch is a revised version of the patch that is compatible with MM 2.1b3 ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-08 16:33 Message: Logged In: YES user_id=12800 I've sent Richard some comments off-line about this patch. Meta comments: the 2.0.x patches can't be officially supported, but I'm going to create an unofficial patches page off the wiki for where the 2.0 patches can be migrated. I think this patch set is too big for MM2.1, but if it's cleaned up as per my private message, let's re-evaluate it for MM2.2 (or 3.0). ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-08-05 10:11 Message: Logged In: YES user_id=75166 htdig-2.0.13-0.2.patch just adds a GPL notice to the patch ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-08-01 16:35 Message: Logged In: YES user_id=75166 htdig-2.1b2-0.1.patch is a revised version of the patch that is compatible with MM 2.1b2 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-07-30 11:25 Message: Logged In: YES user_id=75166 htdig-2.0.13-0.1.patch is purely cosmetic to get no mumble application to MM 2.0.13 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-07-25 15:07 Message: Logged In: YES user_id=75166 Do not use htdig-2.0.12-0.1.patch there is an error in it. Use htdig-2.0.12-0.2.patch instead ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-07-25 14:10 Message: Logged In: YES user_id=75166 htdig-2.0.12-0.1.patch is a revised version of the patch that applies without complaint to MM 2.0.12. It also add a facility for adding site wide htdig configuration attributes to all list specific htdig configuration files. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-05-23 09:59 Message: Logged In: YES user_id=75166 htdig-2.0.11-0.1.patch is a revised version of the patch that is compatible with MM 2.0.11 This version removes an incompatibility with Python 2.2 which caused warning messages to be generated when any of the family cron/nightly_htdig scripts were run. Some guidance on file access permissions for some htdig database files needed by rundig have been added to installation notes. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-04-19 10:59 Message: Logged In: YES user_id=75166 htdig-2.0.10-0.1.patch is a revised version of the patch that is compatible with MM 2.0.10 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-04-08 17:46 Message: Logged In: YES user_id=75166 htdig-2.0.9-0.1.patch is a revised version of the patch that is compatible with MM 2.0.9 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-03-06 16:22 Message: Logged In: YES user_id=75166 htdig-2.1cvs-20020306.patch is a revised version of the patch that is compatible with the code published in mailman CVS on sourceforge as 12:30 GMT 6 Mar 2002 Known deficiency is that the non-English versions of files under $build/templates still contain text in English and need translations I cannot do. Also the necessary pygettext activity and subsequent translations in files under $build/messages remain to be done. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-12-17 16:56 Message: Logged In: YES user_id=75166 htdig-2.1cvs-20011217.patch is a revised version of the patch that is compatible with the code published in mailman CVS on sourceforge as 11:50 GMT 17 Dec 2001 The only known deficiency is that the non-English versions of files under $build/templates still contain text in English and need translations I cannot do. Also the necessary pygettext activity and subsequent translations in files under $build/messages remain to be done. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-12-13 16:58 Message: Logged In: YES user_id=75166 htdig-2.1a3-0.1.patch is a revised version of the patch that is compatible with the code published in mailman-2.1a3.tgz on sourceforge. The only known deficiency is that the non-English versions of files under $build/templates still contain text in English and need translations I cannot do. Also the necessary pygettext activity and subsequent translations in files under $build/messages remain to be done. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-28 17:33 Message: Logged In: YES user_id=75166 The htdig-2.0.8-0.1.patch version of the patch resolves a problem that can arise with htdig indexing if the web_page_url for a list uses other than the http addressing (some folks want to use https). While specified as for MM 2.0.8 the revised patch should work OK with 2.0.7, 2.0.6 and probably back as far as 2.0.3. If you do not have the requirement for using other than http addressing in you lists web_page_urls it probably isn't worth the trouble of upgrading to this patch level. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-28 11:08 Message: Logged In: YES user_id=75166 This patch should also apply without problems to MM 2.0.8 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-27 12:00 Message: Logged In: YES user_id=75166 This patch should also apply without problems to Mm 2.0.7 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-09 11:54 Message: Logged In: YES user_id=75166 The htdig-2.0.6-03.patch version of the patch makes some previously hard-coded things configurable and enhances the capability to run the htdig searches and indexing on a different machine to the one delivering Mailman and Mailman's web UI. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=444884&group_id=103 From pioppo@ferrara.linux.it Thu Aug 15 13:36:31 2002 From: pioppo@ferrara.linux.it (Simone Piunno) Date: Thu, 15 Aug 2002 14:36:31 +0200 Subject: [Mailman-Developers] mixed translation in CommandRunner output Message-ID: <20020815123631.GG2002@ferrara.linux.it> Hi, When you send a message to foo-request asking for "help" and foo has a preferred language different from the site-wide what you get in response is a message with a mix of both languages, e.g. _() are in the site-wide language but the help.txt template is in the list-preferred language. Now, I'm willing to provide a patch, but I want to be sure the right language is the list-specific one, isn't it? -- Adde parvum parvo magnus acervus erit. Simone Piunno, FerraraLUG - http://members.ferrara.linux.it/pioppo From barry@python.org Thu Aug 15 14:21:49 2002 From: barry@python.org (Barry A. Warsaw) Date: Thu, 15 Aug 2002 09:21:49 -0400 Subject: [Mailman-Developers] Scrubber.py confusion, 2.1b3 References: <01c301c241d0$d59c2ba0$0b01a8c0@mjm2> <15704.19460.797697.293530@anthem.wooz.org> <02d101c24286$5e40a160$0b01a8c0@mjm2> <15705.10259.859452.175451@anthem.wooz.org> <005701c242e9$c1dc03f0$34f820c0@ix1x1000> Message-ID: <15707.43757.751982.174850@anthem.wooz.org> >>>>> "MM" == Michael Meltzer writes: MM> I just eyeballed it, looking good, I on the "coding chain MM> gang" for a few hours, I make my CVS recipe tonight and give MM> it a go. Thank You. I post the MimeDel.py hack in a bit, right MM> now my python is a graceful as a sludge hammer :-) Thanks for the patch Michael. I've looked it over but I've decided to postpone this one for now. I've modified MimeDel.py since you generated your patch. Can you try to resolve your patch against cvs and upload it to the SourceForge patch manager so we don't lose track of it? Thanks, -Barry From barry@python.org Thu Aug 15 14:25:47 2002 From: barry@python.org (Barry A. Warsaw) Date: Thu, 15 Aug 2002 09:25:47 -0400 Subject: [Mailman-Developers] Scrubber.py confusion, 2.1b3 References: <06d001c24371$52b479c0$0b01a8c0@mjm2> Message-ID: <15707.43995.212985.401589@anthem.wooz.org> >>>>> "DN" == Dale Newfield writes: DN> Just want to make sure that the reason you're thinking about DN> this is the same reason I am: I don't want someone mailing DN> something to a mailing list forged just right so that a file DN> with an extension they specify lands on my web server and then DN> gets not just served from that box, but *executed* by the web DN> server on it's way out. The most recent content system I DN> built does indeed use the mime-type, and builds the filename DN> extension from it. If someone sends a file abcdefg.cgi as DN> image/gif, I will write out Q/N000-N999/X.Y.gif (where DN> N=(X%1000), and Q, X, Y are determined by other parts of the DN> system). The filename they send is completely dropped, and I DN> get to filter on mime-type, assured that since the web server DN> decides mime-type from extension, it will decide the same DN> mime-type I was told. Sure, someone can upload stuff that DN> might be malicious, but since I'm assured it'll never be DN> executed, I'm not worried. Scrubber.py believes the Content-Type: over the file extension. Python has a module called mimetypes which translates between content type and file extension, so it uses that to calculate the extension on the file it saves in the file system. It also ignores any path information that might be in the filename parameter, so it basically just uses the filebase. It'll fall back to .bin if it can't calculate a better file extension. -Barry From vic@vgg.sci.uma.es Thu Aug 15 16:33:53 2002 From: vic@vgg.sci.uma.es (Victoriano Giralt) Date: Thu, 15 Aug 2002 17:33:53 +0200 (CEST) Subject: [Mailman-Developers] mixed translation in CommandRunner output In-Reply-To: <20020815123631.GG2002@ferrara.linux.it> References: <20020815123631.GG2002@ferrara.linux.it> Message-ID: <35125.62.36.189.84.1029425633.squirrel@vgg.sci.uma.es> > Now, I'm willing to provide a patch, but I want to be sure the > right language is the list-specific one, isn't it? I'd better try to find out if the user has a preferred language first, and, if she has not, the go for the list-specific language. -- Victoriano Giralt Systems Manager Central Computing Facility University of Malaga SPAIN From lrosa@mail.hypertrek.info Thu Aug 15 16:54:10 2002 From: lrosa@mail.hypertrek.info (Luigi Rosa) Date: Thu, 15 Aug 2002 17:54:10 +0200 Subject: [Mailman-Developers] mixed translation in CommandRunner output In-Reply-To: <35125.62.36.189.84.1029425633.squirrel@vgg.sci.uma.es> References: <20020815123631.GG2002@ferrara.linux.it> <35125.62.36.189.84.1029425633.squirrel@vgg.sci.uma.es> Message-ID: <10628970312.20020815175410@mail.hypertrek.info> Hello Victoriano, Thursday, August 15, 2002, 5:33:53 PM, you wrote: >> Now, I'm willing to provide a patch, but I want to be sure the >> right language is the list-specific one, isn't it? VG> I'd better try to find out if the user has a preferred language first, VG> and, if she has not, the go for the list-specific language. The problem is that in that specific context (the reply of an help command issued via e-mail) the reply contains mixed language: both English and List default. -- Best regards, Luigi mailto:lrosa@mail.hypertrek.info From barry@python.org Thu Aug 15 17:31:22 2002 From: barry@python.org (Barry A. Warsaw) Date: Thu, 15 Aug 2002 12:31:22 -0400 Subject: [Mailman-Developers] mixed translation in CommandRunner output References: <20020815123631.GG2002@ferrara.linux.it> Message-ID: <15707.55130.86006.28121@anthem.wooz.org> >>>>> "SP" == Simone Piunno writes: SP> When you send a message to foo-request asking for "help" and SP> foo has a preferred language different from the site-wide what SP> you get in response is a message with a mix of both languages, SP> e.g. _() are in the site-wide language but the help.txt SP> template is in the list-preferred language. Actually, I think the _() is coming in the sender's preferred language if they're a member, but the list language if they're not. You're right that the help.txt template comes in the list language. SP> Now, I'm willing to provide a patch, but I want to be sure the SP> right language is the list-specific one, isn't it? I think this is a simple fix, so I'll check it in. cmd_help.py needs to get the help.txt from the sender's language if they're a member. This information is available in the metadata. -Barry From barry@python.org Thu Aug 15 19:30:08 2002 From: barry@python.org (Barry A. Warsaw) Date: Thu, 15 Aug 2002 14:30:08 -0400 Subject: [Mailman-Developers] Mailman broken in Debian 3.0 Message-ID: <15707.62256.740221.744063@anthem.wooz.org> ---------------------- multipart/mixed attachment With Ben's permission I'm forwarding this message to these lists. We'll have to add this to the faqwiz at the least, and probably the MM2.0.x README file (although I'm hoping to avoid a 2.0.14 :). Brace yourselves, -Barry ---------------------- multipart/mixed attachment An embedded message was scrubbed... From: Ben Gertzfield Subject: Heads-up: Debian 3.0 (woody) shipped broken mailman Date: Thu, 15 Aug 2002 10:35:22 -0700 Size: 2078 Url: http://mail.python.org/pipermail-21/mailman-developers/attachments/a010a695/attachment.txt ---------------------- multipart/mixed attachment-- From noreply@sourceforge.net Thu Aug 15 20:02:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 15 Aug 2002 12:02:39 -0700 Subject: [Mailman-Developers] [ mailman-Patches-595692 ] mixed language in cmd_help.py Message-ID: Patches item #595692, was opened at 2002-08-15 21:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=595692&group_id=103 Category: internationalization Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Simone Piunno (pioppo) Assigned to: Nobody/Anonymous (nobody) Summary: mixed language in cmd_help.py Initial Comment: bugfix to the mixed language issue in cmd_help.py, as already discussed on the -developers list ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=595692&group_id=103 From fil@rezo.net Thu Aug 15 20:34:50 2002 From: fil@rezo.net (Fil) Date: Thu, 15 Aug 2002 21:34:50 +0200 Subject: [Mailman-Developers] XML specs for mailing-lists? In-Reply-To: <20020814135634.GD18323@rezo.net> References: <20020813170747.GG32522@rezo.net> <16636.1029260407@kanga.nu> <20020813234405.GG4638@rezo.net> <24827.1029307968@kanga.nu> <20020814135634.GD18323@rezo.net> Message-ID: <20020815193450.GA30899@rezo.net> Just a question: "bin/sync_members This script is useful if you have a Mailman mailing list and a sendmail :include: style list of addresses (also as is used in Majordomo)." For Mailman users who don't know sendmail nor majordomo, this is somewhat cryptic. What's this :include: format? Does it allow names, for examples, to be listed together with addresses? -- Fil From noreply@sourceforge.net Thu Aug 15 21:48:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 15 Aug 2002 13:48:25 -0700 Subject: [Mailman-Developers] [ mailman-Patches-595692 ] mixed language in cmd_help.py Message-ID: Patches item #595692, was opened at 2002-08-15 15:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=595692&group_id=103 Category: internationalization Group: Mailman 2.1 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Simone Piunno (pioppo) Assigned to: Nobody/Anonymous (nobody) Summary: mixed language in cmd_help.py Initial Comment: bugfix to the mixed language issue in cmd_help.py, as already discussed on the -developers list ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-15 16:48 Message: Logged In: YES user_id=12800 You don't actually need to do this because msgdata['lang'] holds the language context for the operation. Fix is already checked in. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=595692&group_id=103 From dan.mick@sun.com Thu Aug 15 22:26:05 2002 From: dan.mick@sun.com (Dan Mick) Date: Thu, 15 Aug 2002 14:26:05 -0700 (PDT) Subject: [Mailman-Developers] Html bugs in 2.0.13 Message-ID: <200208152126.g7FLQ8jX008081@utopia.West.Sun.COM> appears to be fixed in 2.1CVS, FWIW. > Barry -- > > Ran into some HTML bugs in 2.0.13. For instance, going to the > listinfo/mailman-subscribers page and subscribing, it returns the > "confirmation is required" warning. > > It looks good, but view source it. An unterminated " a second body tag with a bgcolor, followed by a third body tag a couple of > lines later. > > There are also two /body tags, and the is in the body, not in the > head. > > While it seems to format okay in browsers, it's seriously broken HTML, and > it's driving mod_layout nuts, since it depends on the body tags to do > header/footer insertions right. I think there's one other generated page > with similar problems, too, but I'm not sure which it is yet. > > Chuq > > > <HTML> > <HEAD> > </HEAD> > <BODY > <BODY bgcolor="#ffffff"> > <!-- $Revision: 1.3 $ --> > <html> > <body> > <title>Mailman-Users Subscription results >

Mailman-Users Subscription results

> Confirmation from your email address is required, to prevent anyone from > subscribing you without permission. Instructions are being sent to you at > me@chuqui.com. Please note your subscription will not start until you > confirm your subscription. >
Mailman-Users list run > by barry@wooz.org, href="mailto:chuqui@plaidworks.com">chuqui@plaidworks.com, href="mailto:mailman-admin@vo.cnchost.com">mailman-admin@vo.cnchost.com< > br>Mailman-Users administrative > interface (requires authorization)

> > > > > > >
Delivered by Mailman border=0>
version 2.0.13 (101270)		Python Powered border=0>GNU's Not Unix border=0>
>

> > > > > > > -- > Chuq Von Rospach, Architech > chuqui@plaidworks.com -- http://www.chuqui.com/ > > Very funny, Scotty. Now beam my clothes down here, will you? > > > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman-21/listinfo/mailman-developers From noreply@sourceforge.net Thu Aug 15 23:37:27 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 15 Aug 2002 15:37:27 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-593454 ] NewsRunner error Message-ID: Bugs item #593454, was opened at 2002-08-10 11:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=593454&group_id=103 Category: nntp/news Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Simone Piunno (pioppo) Assigned to: Nobody/Anonymous (nobody) Summary: NewsRunner error Initial Comment: Just updated to Mailman 2.1b3: Aug 10 17:18:57 2002 (10526) Uncaught runner exception: len() of unsized object Aug 10 17:18:57 2002 (10526) Traceback (most recent call last): File "/home/mailman21/Mailman/Queue/Runner.py", line 105, in _oneloop self._onefile(msg, msgdata) File "/home/mailman21/Mailman/Queue/Runner.py", line 154, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/home/mailman21/Mailman/Queue/NewsRunner.py", line 56, in _dispose prepare_message(mlist, msg, msgdata) File "/home/mailman21/Mailman/Queue/NewsRunner.py", line 132, in prepare_message count = len(email.Iterators.body_line_iterator(msg)) TypeError: len() of unsized object ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-15 18:37 Message: Logged In: YES user_id=12800 Two questions, what version of Python are you running, and can you upload the .pck file that's left in qfiles/shunt? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=593454&group_id=103 From Dale@Newfield.org Fri Aug 16 00:39:27 2002 From: Dale@Newfield.org (Dale Newfield) Date: Thu, 15 Aug 2002 19:39:27 -0400 (EDT) Subject: [Mailman-Developers] SQL MemberAdaptor implementation? In-Reply-To: <1262.1028093412@kanga.nu> Message-ID: OK--I think I've found the time to build this and contribute it to the cause! Just want to make sure that none already exists... Has anyone built such a beast? Are there *any* other known implementations to use as references besides OldStyleMemberships.py? I'm also wondering about dynamic groups... (and think that I should be able to implement this using some combination of the "virtual" list and the "extended" list.) In the system that I'll be integrating this there are several types of entities, and a dynamic number of instances of each. I'd like to be able to have each instance of each entity have it's own (probably virtual) mailing list. The first idea is to create one concrete mailman list (with settings/templates/etc.) for each type, and have each instance automagically exist with distinct membership (as pulled from the SQL DB). As a more concrete example, I might want to set up a "class" mailing list and a "project" mailing list, but I really want it to appear that there are many mailing lists all of the form "class+phys101@domain.edu", "class+ee382@domain.edu", "project+planQ@dom.ain", "project+noFNORDs@dom.ain", etc. (The plus'es are a straw-man, it could be deliniated some other way--the key is that I want them each to have a distinct email address so that people can respond to the group if desired--if this were announce-only I could simply use the virtual list and .inject() method.) Any suggestions as to how to go about this? I'm guessing I'll make an SQL DB framework that is only mostly concrete. Each list would need an extend.py that informs that framework about the schema through which to find various pieces of information in the DB. Any suggestions as to how that schema should be specified? This brings up something about which I'm not so clear--can different lists use different MemberAdaptors? Can I have a single mailman instance running some lists with OldStyle and other lists using my new fangled system? -Dale From noreply@sourceforge.net Fri Aug 16 10:27:22 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 16 Aug 2002 02:27:22 -0700 Subject: [Mailman-Developers] [ mailman-Feature Requests-595921 ] VirtualHost select interface Message-ID: Feature Requests item #595921, was opened at 2002-08-16 11:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=595921&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Darius Tribandis (sirijus) Assigned to: Nobody/Anonymous (nobody) Summary: VirtualHost select interface Initial Comment: Hi, becouse mailman supports virtualhosts it by pleasure to see and edit to which virtualhost belongs list, and chance to make it available to few virtual hosts. Sirijus ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=595921&group_id=103 From noreply@sourceforge.net Fri Aug 16 14:33:51 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 16 Aug 2002 06:33:51 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-593454 ] NewsRunner error Message-ID: Bugs item #593454, was opened at 2002-08-10 17:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=593454&group_id=103 Category: nntp/news Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Simone Piunno (pioppo) Assigned to: Nobody/Anonymous (nobody) Summary: NewsRunner error Initial Comment: Just updated to Mailman 2.1b3: Aug 10 17:18:57 2002 (10526) Uncaught runner exception: len() of unsized object Aug 10 17:18:57 2002 (10526) Traceback (most recent call last): File "/home/mailman21/Mailman/Queue/Runner.py", line 105, in _oneloop self._onefile(msg, msgdata) File "/home/mailman21/Mailman/Queue/Runner.py", line 154, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/home/mailman21/Mailman/Queue/NewsRunner.py", line 56, in _dispose prepare_message(mlist, msg, msgdata) File "/home/mailman21/Mailman/Queue/NewsRunner.py", line 132, in prepare_message count = len(email.Iterators.body_line_iterator(msg)) TypeError: len() of unsized object ---------------------------------------------------------------------- >Comment By: Simone Piunno (pioppo) Date: 2002-08-16 15:33 Message: Logged In: YES user_id=227443 I have installed both 1.5.2 and 2.2.1. Mailman has been configured --with-python=/usr/bin/python2 but a couple files are still referring to the old python, at least Mailman/Archiver/pipermail.py and Mailman/Post.py ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-16 00:37 Message: Logged In: YES user_id=12800 Two questions, what version of Python are you running, and can you upload the .pck file that's left in qfiles/shunt? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=593454&group_id=103 From noreply@sourceforge.net Fri Aug 16 15:20:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 16 Aug 2002 07:20:44 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-596055 ] wrong charset in bounce notice Message-ID: Bugs item #596055, was opened at 2002-08-16 16:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=596055&group_id=103 Category: bounce detection Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Simone Piunno (pioppo) Assigned to: Nobody/Anonymous (nobody) Summary: wrong charset in bounce notice Initial Comment: When a member is disabled because of too many bounces detected, if bounce_notify_owner_on_disable is set the list owner is notified with a message generated in Boucer.py using a template file (bounce.txt). The problem is that the generated message is MIME encoded and bounce.txt is attached with hardcoded charset=us-ascii, even if a translated template was used. Attached you can find a one-liner patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=596055&group_id=103 From noreply@sourceforge.net Fri Aug 16 15:41:31 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 16 Aug 2002 07:41:31 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-596055 ] wrong charset in bounce notice Message-ID: Bugs item #596055, was opened at 2002-08-16 10:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=596055&group_id=103 Category: bounce detection Group: 2.1 beta >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Simone Piunno (pioppo) Assigned to: Nobody/Anonymous (nobody) Summary: wrong charset in bounce notice Initial Comment: When a member is disabled because of too many bounces detected, if bounce_notify_owner_on_disable is set the list owner is notified with a message generated in Boucer.py using a template file (bounce.txt). The problem is that the generated message is MIME encoded and bounce.txt is attached with hardcoded charset=us-ascii, even if a translated template was used. Attached you can find a one-liner patch ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-16 10:41 Message: Logged In: YES user_id=12800 Applied, thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=596055&group_id=103 From noreply@sourceforge.net Fri Aug 16 16:43:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 16 Aug 2002 08:43:28 -0700 Subject: [Mailman-Developers] [ mailman-Feature Requests-595333 ] REQ: admindb list of default responses Message-ID: Feature Requests item #595333, was opened at 2002-08-14 20:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=595333&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dylan Jay (dylan_jay) Assigned to: Nobody/Anonymous (nobody) Summary: REQ: admindb list of default responses Initial Comment: When moderating most rejected posts fit into certain catagories. It would be a big time saver to have a drop down list of default responces. Each would have a name and settings and text for the responce. A text box and a "add as new default responce" checkbox is all that is needed to add a new response (or edit one) ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-16 11:43 Message: Logged In: YES user_id=12800 I agree that this would be nice. It's a feature that will have to wait until after MM2.1, so I'm moving this to the features request category. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=595333&group_id=103 From noreply@sourceforge.net Fri Aug 16 16:45:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 16 Aug 2002 08:45:05 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-595132 ] No mail going out Message-ID: Bugs item #595132, was opened at 2002-08-14 13:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=595132&group_id=103 Category: mail delivery >Group: 2.0.x >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Terkel Olsen (terkel) Assigned to: Nobody/Anonymous (nobody) Summary: No mail going out Initial Comment: Hi there, i have Installed Mailman manually on a NetBSD for some reason its not in pkgsrc anymore. It installs allmost fine, just had to fix a few GID's and point it to python, and then it appeared to install. I created a list fine and it sent the e-mail to the admin adress, but if i try to send anything to the list nothing gets send back. Its not even held for approval. The error log shows nothing and the maillog only shows this: Aug 14 11:06:19 www sendmail[29601]: g7E96J229601: from=terkel, size=54, class=0, nrcpts=1, msgid=<200208140906.g7E96J229601@www.bon nierforlagene.dk>, relay=terkel@localhost Aug 14 11:06:19 www sendmail[29603]: g7E96J229601: to="|/usr/home/mailman/mailman/mail/wrapper post jokes", ctladdr=Jokes@www.bonnie rforlagene.dk (1/0), delay=00:00:00, xdelay=00:00:00, mailer=prog, pri=30054, dsn=2.0.0, stat=Sent But nothing further, so i guess it goes to the wrapper program but then no further... Anyone experienced this before ? Terkel ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-16 11:45 Message: Logged In: YES user_id=12800 Sounds to me like you didn't install the cronjob to get qrunner going (assuming you're using MM2.0 -- you don't say in your bug report). I don't think this is a bug. Contact mailman-users@python.org for more help. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=595132&group_id=103 From noreply@sourceforge.net Fri Aug 16 16:51:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 16 Aug 2002 08:51:49 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-594913 ] rfc822.parseaddress() in Util.py Invalid Message-ID: Bugs item #594913, was opened at 2002-08-14 02:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=594913&group_id=103 Category: command line scripts Group: 2.0.x >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Federico Sevilla III (jijo) Assigned to: Nobody/Anonymous (nobody) Summary: rfc822.parseaddress() in Util.py Invalid Initial Comment: The reference to rfc822.parseaddress() on line 160 of Util.py in Mailman 2.0.12 is invalid. As of at least Python 2.1 and Python 2.2, the rfc822 module does not contain this function. This makes it impossible to use add_members from the command line, although web-based subscription still seems to work. The pertinent traceback: Traceback (most recent call last): File "/usr/sbin/add_members", line 221, in ? main() File "/usr/sbin/add_members", line 195, in main nres = ml.ApprovedAddMembers(nmembers, None, 0, send_welcome_msg) File "/usr/lib/mailman/Mailman/MailList.py", line 1097, in ApprovedAddMembers Utils.ValidateEmail(name) File "/usr/lib/mailman/Mailman/Utils.py", line 160, in ValidateEmail realname,str = rfc822.parseaddress(str) AttributeError: 'rfc822' module has no attribute 'parseaddress' The fix is pretty simple. Simply replace realname,str = rfc822.parseaddress(str) on line 160 of Utils.py with realname,str = rfc822.parseaddr(str) ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-16 11:51 Message: Logged In: YES user_id=12800 Where did you get Mailman 2.0.12 from? There is no parseaddress() call in Utils.py in the official Mailman 2.0.13 release, and there was no change to this since MM2.0.12. Are you using some non-standard patch or local hack? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=594913&group_id=103 From noreply@sourceforge.net Fri Aug 16 16:58:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 16 Aug 2002 08:58:47 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-595132 ] No mail going out Message-ID: Bugs item #595132, was opened at 2002-08-14 10:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=595132&group_id=103 Category: mail delivery Group: 2.0.x Status: Closed Resolution: Invalid Priority: 5 Submitted By: Terkel Olsen (terkel) Assigned to: Nobody/Anonymous (nobody) Summary: No mail going out Initial Comment: Hi there, i have Installed Mailman manually on a NetBSD for some reason its not in pkgsrc anymore. It installs allmost fine, just had to fix a few GID's and point it to python, and then it appeared to install. I created a list fine and it sent the e-mail to the admin adress, but if i try to send anything to the list nothing gets send back. Its not even held for approval. The error log shows nothing and the maillog only shows this: Aug 14 11:06:19 www sendmail[29601]: g7E96J229601: from=terkel, size=54, class=0, nrcpts=1, msgid=<200208140906.g7E96J229601@www.bon nierforlagene.dk>, relay=terkel@localhost Aug 14 11:06:19 www sendmail[29603]: g7E96J229601: to="|/usr/home/mailman/mailman/mail/wrapper post jokes", ctladdr=Jokes@www.bonnie rforlagene.dk (1/0), delay=00:00:00, xdelay=00:00:00, mailer=prog, pri=30054, dsn=2.0.0, stat=Sent But nothing further, so i guess it goes to the wrapper program but then no further... Anyone experienced this before ? Terkel ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-08-16 08:58 Message: Logged In: NO You are quite right about the cronjob, i have completely missed that section in the install file. Very sorry for creating a bug for this. Thanks again Terkel ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-16 08:45 Message: Logged In: YES user_id=12800 Sounds to me like you didn't install the cronjob to get qrunner going (assuming you're using MM2.0 -- you don't say in your bug report). I don't think this is a bug. Contact mailman-users@python.org for more help. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=595132&group_id=103 From noreply@sourceforge.net Fri Aug 16 16:59:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 16 Aug 2002 08:59:02 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-596055 ] wrong charset in bounce notice Message-ID: Bugs item #596055, was opened at 2002-08-16 14:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=596055&group_id=103 Category: bounce detection Group: 2.1 beta Status: Closed Resolution: Accepted Priority: 5 Submitted By: Simone Piunno (pioppo) Assigned to: Nobody/Anonymous (nobody) Summary: wrong charset in bounce notice Initial Comment: When a member is disabled because of too many bounces detected, if bounce_notify_owner_on_disable is set the list owner is notified with a message generated in Boucer.py using a template file (bounce.txt). The problem is that the generated message is MIME encoded and bounce.txt is attached with hardcoded charset=us-ascii, even if a translated template was used. Attached you can find a one-liner patch ---------------------------------------------------------------------- Comment By: Ousmane Wilane (wilane) Date: 2002-08-16 15:59 Message: Logged In: YES user_id=47556 Current cvs: make install leads to this (Python 2.2): Traceback (most recent call last): File "bin/update", line 47, in ? from Mailman import MailList File "/usr/local/mailman/Mailman/MailList.py", line 51, in ? from Mailman.Bouncer import Bouncer File "", line 193 if isinstance(msg, StringType): ^ SyntaxError: invalid syntax make: *** [update] Error 1 ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-16 14:41 Message: Logged In: YES user_id=12800 Applied, thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=596055&group_id=103 From noreply@sourceforge.net Fri Aug 16 17:05:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 16 Aug 2002 09:05:36 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-594913 ] rfc822.parseaddress() in Util.py Invalid Message-ID: Bugs item #594913, was opened at 2002-08-14 14:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=594913&group_id=103 Category: command line scripts Group: 2.0.x Status: Closed Resolution: Invalid Priority: 5 Submitted By: Federico Sevilla III (jijo) Assigned to: Nobody/Anonymous (nobody) Summary: rfc822.parseaddress() in Util.py Invalid Initial Comment: The reference to rfc822.parseaddress() on line 160 of Util.py in Mailman 2.0.12 is invalid. As of at least Python 2.1 and Python 2.2, the rfc822 module does not contain this function. This makes it impossible to use add_members from the command line, although web-based subscription still seems to work. The pertinent traceback: Traceback (most recent call last): File "/usr/sbin/add_members", line 221, in ? main() File "/usr/sbin/add_members", line 195, in main nres = ml.ApprovedAddMembers(nmembers, None, 0, send_welcome_msg) File "/usr/lib/mailman/Mailman/MailList.py", line 1097, in ApprovedAddMembers Utils.ValidateEmail(name) File "/usr/lib/mailman/Mailman/Utils.py", line 160, in ValidateEmail realname,str = rfc822.parseaddress(str) AttributeError: 'rfc822' module has no attribute 'parseaddress' The fix is pretty simple. Simply replace realname,str = rfc822.parseaddress(str) on line 160 of Utils.py with realname,str = rfc822.parseaddr(str) ---------------------------------------------------------------------- >Comment By: Federico Sevilla III (jijo) Date: 2002-08-17 00:05 Message: Logged In: YES user_id=9096 This is from the Debian package. I just downloaded the package sources for the 2.0.12-3 package, and there is nothing that changes the Utils.py file, and the Utils.py file as claimed indeed comes with rfc822.parseaddr(str) and not rfc822.parseaddress(str). Unfortunately because I already modified my installed Utils.py to fix the problem I was having, I cannot trace to see when the file was last updated (this wasn't a fresh install but was an upgrade from a previous version) to find out why it got changes. My apologies for the hassles. Thank you for pointing out that the distributed tarball comes with a Utils.py that was not broken to begin with. Cheers. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-16 23:51 Message: Logged In: YES user_id=12800 Where did you get Mailman 2.0.12 from? There is no parseaddress() call in Utils.py in the official Mailman 2.0.13 release, and there was no change to this since MM2.0.12. Are you using some non-standard patch or local hack? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=594913&group_id=103 From noreply@sourceforge.net Fri Aug 16 17:06:34 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 16 Aug 2002 09:06:34 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-594913 ] rfc822.parseaddress() in Util.py Invalid Message-ID: Bugs item #594913, was opened at 2002-08-14 14:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=594913&group_id=103 Category: command line scripts Group: 2.0.x Status: Closed Resolution: Invalid Priority: 5 Submitted By: Federico Sevilla III (jijo) Assigned to: Nobody/Anonymous (nobody) Summary: rfc822.parseaddress() in Util.py Invalid Initial Comment: The reference to rfc822.parseaddress() on line 160 of Util.py in Mailman 2.0.12 is invalid. As of at least Python 2.1 and Python 2.2, the rfc822 module does not contain this function. This makes it impossible to use add_members from the command line, although web-based subscription still seems to work. The pertinent traceback: Traceback (most recent call last): File "/usr/sbin/add_members", line 221, in ? main() File "/usr/sbin/add_members", line 195, in main nres = ml.ApprovedAddMembers(nmembers, None, 0, send_welcome_msg) File "/usr/lib/mailman/Mailman/MailList.py", line 1097, in ApprovedAddMembers Utils.ValidateEmail(name) File "/usr/lib/mailman/Mailman/Utils.py", line 160, in ValidateEmail realname,str = rfc822.parseaddress(str) AttributeError: 'rfc822' module has no attribute 'parseaddress' The fix is pretty simple. Simply replace realname,str = rfc822.parseaddress(str) on line 160 of Utils.py with realname,str = rfc822.parseaddr(str) ---------------------------------------------------------------------- >Comment By: Federico Sevilla III (jijo) Date: 2002-08-17 00:06 Message: Logged In: YES user_id=9096 This is from the Debian package. I just downloaded the package sources for the 2.0.12-3 package, and there is nothing that changes the Utils.py file, and the Utils.py file as claimed indeed comes with rfc822.parseaddr(str) and not rfc822.parseaddress(str). Unfortunately because I already modified my installed Utils.py to fix the problem I was having, I cannot trace to see when the file was last updated (this wasn't a fresh install but was an upgrade from a previous version) to find out why it got changes. My apologies for the hassles. Thank you for pointing out that the distributed tarball comes with a Utils.py that was not broken to begin with. Cheers. ---------------------------------------------------------------------- Comment By: Federico Sevilla III (jijo) Date: 2002-08-17 00:05 Message: Logged In: YES user_id=9096 This is from the Debian package. I just downloaded the package sources for the 2.0.12-3 package, and there is nothing that changes the Utils.py file, and the Utils.py file as claimed indeed comes with rfc822.parseaddr(str) and not rfc822.parseaddress(str). Unfortunately because I already modified my installed Utils.py to fix the problem I was having, I cannot trace to see when the file was last updated (this wasn't a fresh install but was an upgrade from a previous version) to find out why it got changes. My apologies for the hassles. Thank you for pointing out that the distributed tarball comes with a Utils.py that was not broken to begin with. Cheers. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-16 23:51 Message: Logged In: YES user_id=12800 Where did you get Mailman 2.0.12 from? There is no parseaddress() call in Utils.py in the official Mailman 2.0.13 release, and there was no change to this since MM2.0.12. Are you using some non-standard patch or local hack? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=594913&group_id=103 From noreply@sourceforge.net Fri Aug 16 17:12:21 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 16 Aug 2002 09:12:21 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-594913 ] rfc822.parseaddress() in Util.py Invalid Message-ID: Bugs item #594913, was opened at 2002-08-14 02:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=594913&group_id=103 Category: command line scripts Group: 2.0.x Status: Closed Resolution: Invalid Priority: 5 Submitted By: Federico Sevilla III (jijo) Assigned to: Nobody/Anonymous (nobody) Summary: rfc822.parseaddress() in Util.py Invalid Initial Comment: The reference to rfc822.parseaddress() on line 160 of Util.py in Mailman 2.0.12 is invalid. As of at least Python 2.1 and Python 2.2, the rfc822 module does not contain this function. This makes it impossible to use add_members from the command line, although web-based subscription still seems to work. The pertinent traceback: Traceback (most recent call last): File "/usr/sbin/add_members", line 221, in ? main() File "/usr/sbin/add_members", line 195, in main nres = ml.ApprovedAddMembers(nmembers, None, 0, send_welcome_msg) File "/usr/lib/mailman/Mailman/MailList.py", line 1097, in ApprovedAddMembers Utils.ValidateEmail(name) File "/usr/lib/mailman/Mailman/Utils.py", line 160, in ValidateEmail realname,str = rfc822.parseaddress(str) AttributeError: 'rfc822' module has no attribute 'parseaddress' The fix is pretty simple. Simply replace realname,str = rfc822.parseaddress(str) on line 160 of Utils.py with realname,str = rfc822.parseaddr(str) ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-16 12:12 Message: Logged In: YES user_id=12800 Ok, thanks for the update. ---------------------------------------------------------------------- Comment By: Federico Sevilla III (jijo) Date: 2002-08-16 12:06 Message: Logged In: YES user_id=9096 This is from the Debian package. I just downloaded the package sources for the 2.0.12-3 package, and there is nothing that changes the Utils.py file, and the Utils.py file as claimed indeed comes with rfc822.parseaddr(str) and not rfc822.parseaddress(str). Unfortunately because I already modified my installed Utils.py to fix the problem I was having, I cannot trace to see when the file was last updated (this wasn't a fresh install but was an upgrade from a previous version) to find out why it got changes. My apologies for the hassles. Thank you for pointing out that the distributed tarball comes with a Utils.py that was not broken to begin with. Cheers. ---------------------------------------------------------------------- Comment By: Federico Sevilla III (jijo) Date: 2002-08-16 12:05 Message: Logged In: YES user_id=9096 This is from the Debian package. I just downloaded the package sources for the 2.0.12-3 package, and there is nothing that changes the Utils.py file, and the Utils.py file as claimed indeed comes with rfc822.parseaddr(str) and not rfc822.parseaddress(str). Unfortunately because I already modified my installed Utils.py to fix the problem I was having, I cannot trace to see when the file was last updated (this wasn't a fresh install but was an upgrade from a previous version) to find out why it got changes. My apologies for the hassles. Thank you for pointing out that the distributed tarball comes with a Utils.py that was not broken to begin with. Cheers. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-16 11:51 Message: Logged In: YES user_id=12800 Where did you get Mailman 2.0.12 from? There is no parseaddress() call in Utils.py in the official Mailman 2.0.13 release, and there was no change to this since MM2.0.12. Are you using some non-standard patch or local hack? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=594913&group_id=103 From Dale@Newfield.org Fri Aug 16 17:56:13 2002 From: Dale@Newfield.org (Dale Newfield) Date: Fri, 16 Aug 2002 12:56:13 -0400 (EDT) Subject: [Mailman-Developers] Re: External subscriber lists in 2.1 In-Reply-To: <15397.32772.522564.275695@anthem.wooz.org> Message-ID: On Sun, 23 Dec 2001, Barry A. Warsaw wrote: > Note that if it was too expensive for getRegularMemberKeys() to return > an in-memory list, it could (if you use Python 2.2) return an iterator > object that implemented things in a more efficient manner, e.g. by > paging through blocks. I believe that any place where we expect a > Python sequence (list) we could probably accept an iterator. Do you know if this is in fact the case? Is this how I should implement it? (While I've hacked in python fairly regularly, I've not done serious Python development since ~1996, so some of these questions will be fairly basic "How's it work in Python2.2?" ones. Of course, this brings up the question of whether or not it's reasonable to require that--don't we currently only require 2.1.3?) Below are different ways the results of "get{Regular,Digest}MemberKeys" and "getMembers" are used in various places in the codebase. Will each of them still work if those methods return an iterator instead of a list? (For example, does len(iterator) work?) I'm guessing that a good answer might be that we want to add more general-purpose accessor methods in class MemberAdaptor (and have the rest of the codebase use those where appropriate) so that if there's a more efficient way for a specific backend to provide specific data, it is able to do so. I'll include the two methods I propose at the end of this message. in Handlers/CalcRecips.py: # Calculate the regular recipients of the message recips = [mlist.getMemberCPAddress(m) for m in mlist.getRegularMemberKeys() if mlist.getDeliveryStatus(m) == ENABLED] and: recips = mlist.getMemberCPAddresses(mlist.getRegularMemberKeys() + mlist.getDigestMemberKeys()) in Cgi/admin.py: if not mlist.nondigestable and mlist.getRegularMemberKeys(): and: if addr in mlist.getRegularMemberKeys(): and: # If there are more members than allowed by chunksize, then we split the # membership up alphabetically. Otherwise just display them all. chunksz = mlist.admin_member_chunksize all = mlist.getMembers() all.sort(lambda x, y: cmp(x.lower(), y.lower())) then: # BAW: There's got to be a more efficient way of doing this! names = [mlist.getMemberName(s) or '' for s in all] all = [a for n, a in zip(names, all) if cre.search(n) or cre.search(a)] in HTMLFormatter.py: members = self.getRegularMemberKeys() for m in members: if not self.getMemberOption(m, conceal_sub): people.append(m) num_concealed = len(members) - len(people) and: member_len = len(self.getRegularMemberKeys()) def getNumMembers(self, type, status, options, regexp=None): """Get the number of members of this mailing list matching type and status, and optionally matching the regular expression passed in. type is one of the module constants REGULAR, DIGEST, or EITHER. The tally should include just the appropriate type of members. status is a list containing some subset of the values ENABLED, UNKNOWN, BYUSER, BYADMIN, BYBOUNCE. The tally should include only members whose status is in that list. options is a dictionary containing some number of {flag:boolean} pairs. Only members with values matching that specified for each flag in the dictionary should be included in the tally. regexp is a string containing a regular expression to use as a filter. If this is not None, only members whose CPE or NAME match the regexp should be included in the tally. (I don't have in mind a more efficient way to implement this in the SQL MemberAdaptor, unless the only non-token element in the regexp is ".*", as that could be matched using sql's wild-card "%". Just because it doesn't result in a more efficient implementation in this case doesn't mean it shouldn't be part of the interface, though.) """ raise NotImplemented def getMemberIterator(self, type, status, options, style, order, regexp=None): """Get an iterator of members of this mailing list matching type and status, and optionally matching the regular expression passed in. type, status, options, and regexp are as used in getNumMembers(). style is what content the iterator should contain: KEY, LCE, CPE, or NAME (If NAME, and some users have no RealName set, those iterator entries will be None.) order specifies in which order those items should be returned by the iterator: KEY, LCE, CPE, or NAME (This part hasn't been thought through as thoroughly--are there other interesting orderings?) """ raise NotImplemented The rest of this message is for context since I'm responding to something 8 months old. On Sun, 23 Dec 2001, Barry A. Warsaw wrote: > >>>>> "JCL" == J C Lawrence writes: > JCL> In 2.1 when used with external subscriber storage (eg SQL), > JCL> will the new equivalent of qrunner request and load the > JCL> entire subscriber DB onto the heap prior to broadcast? > > That's really up to the implementation of the MemberAdaptor interface > for SQL (but fwiw, I'm not aware of such a beast). Mailman's > CalcrRecips module loops through all the member addresses in a list > comprehension, but all other information is requested a member at a > time. > > JCL> ObExcuse: Chap on -users asking about millions of > JCL> subscribers. > > Cool! :) From noreply@sourceforge.net Fri Aug 16 18:31:34 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 16 Aug 2002 10:31:34 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-594703 ] Bug canceling discarded mail Message-ID: Bugs item #594703, was opened at 2002-08-13 14:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=594703&group_id=103 Category: None Group: 2.1 beta >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Garey Mills (gareytm) Assigned to: Nobody/Anonymous (nobody) Summary: Bug canceling discarded mail Initial Comment: When poster tries to cancel email, and moderator has already discarded it, Mailman reports a bug. Here is the trace: Traceback: Traceback (most recent call last): File "/usr/local/mailman/scripts/driver", line 82, in run_main main() File "/usr/local/mailman/Mailman/Cgi/confirm.py", line 141, in main heldmsg_prompt(mlist, doc, cookie, *content[1:]) File "/usr/local/mailman/Mailman/Cgi/confirm.py", line 612, in heldmsg_prompt ign, sender, msgsubject, givenreason, ign, ign = mlist.GetRecord(id) File "/usr/local/mailman/Mailman/ListAdmin.py", line 163, in GetRecord type, data = self.__db[id] KeyError: 5 Python information: Variable Value sys.version 2.2.1 (#1, Jun 10 2002, 14:31:04) [GCC 2.95 19990728 (release)] sys.executable /usr/local/bin/python sys.prefix /usr/local sys.exec_prefix /usr/local sys.path /usr/local sys.platform osf1V4 Environment variables: Variable Value HTTP_COOKIE mailman+admin=2802000000693f28593d7328000000613 63333616235613030333131303932383837653463343661 653733376234623536363661363939; allusers+admin=2802000000696628593d7328000000353 73635316133633866323335346264373061613638646530 323436663963633066613131336131; asc+admin=; p-r- demo+admin=280200000069bb34593d732800000034373 33562333563323038653463356264643637623566306462 6430333634313966333561353736 SERVER_SOFTWARE Apache/1.3.26 (Unix) PYTHONPATH /usr/local/mailman SCRIPT_FILENAME /usr/local/mailman/cgi-bin/confirm SERVER_ADMIN jgarey@library.berkeley.edu SCRIPT_NAME /mailman/confirm SERVER_SIGNATURE REQUEST_METHOD GET HTTP_HOST www.lib.berkeley.edu PATH_INFO /p-r- demo/690b69a8dccbfa63a5b1a8aa592f14597f517e87 SERVER_PROTOCOL HTTP/1.0 QUERY_STRING REQUEST_URI /mailman/confirm/p-r- demo/690b69a8dccbfa63a5b1a8aa592f14597f517e87 HTTP_ACCEPT image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */* HTTP_ACCEPT_CHARSET iso-8859-1,*,utf-8 HTTP_USER_AGENT Mozilla/4.79 [en] (Windows NT 5.0; U) HTTP_CONNECTION Keep-Alive HTTP_REFERER http://us.f136.mail.yahoo.com/ym/ShowLetter? MsgId=6112_8948012_210880_1238_476_0_10784&YY= 54989&inc=25&order=down&sort=date&pos=0&view=&h ead=&box=Inbox SERVER_NAME www.lib.berkeley.edu REMOTE_ADDR 128.32.238.84 REMOTE_PORT 1342 HTTP_ACCEPT_LANGUAGE en PATH_TRANSLATED /data/_b/webdata/p-r- demo/690b69a8dccbfa63a5b1a8aa592f14597f517e87 SERVER_PORT 80 GATEWAY_INTERFACE CGI/1.1 HTTP_ACCEPT_ENCODING gzip SERVER_ADDR 169.229.32.48 DOCUMENT_ROOT /data/_b/webdata ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-16 13:31 Message: Logged In: YES user_id=12800 Fixed, thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=594703&group_id=103 From noreply@sourceforge.net Fri Aug 16 18:58:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 16 Aug 2002 10:58:50 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-594703 ] Bug canceling discarded mail Message-ID: Bugs item #594703, was opened at 2002-08-13 18:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=594703&group_id=103 Category: None Group: 2.1 beta Status: Closed Resolution: Fixed Priority: 5 Submitted By: Garey Mills (gareytm) Assigned to: Nobody/Anonymous (nobody) Summary: Bug canceling discarded mail Initial Comment: When poster tries to cancel email, and moderator has already discarded it, Mailman reports a bug. Here is the trace: Traceback: Traceback (most recent call last): File "/usr/local/mailman/scripts/driver", line 82, in run_main main() File "/usr/local/mailman/Mailman/Cgi/confirm.py", line 141, in main heldmsg_prompt(mlist, doc, cookie, *content[1:]) File "/usr/local/mailman/Mailman/Cgi/confirm.py", line 612, in heldmsg_prompt ign, sender, msgsubject, givenreason, ign, ign = mlist.GetRecord(id) File "/usr/local/mailman/Mailman/ListAdmin.py", line 163, in GetRecord type, data = self.__db[id] KeyError: 5 Python information: Variable Value sys.version 2.2.1 (#1, Jun 10 2002, 14:31:04) [GCC 2.95 19990728 (release)] sys.executable /usr/local/bin/python sys.prefix /usr/local sys.exec_prefix /usr/local sys.path /usr/local sys.platform osf1V4 Environment variables: Variable Value HTTP_COOKIE mailman+admin=2802000000693f28593d7328000000613 63333616235613030333131303932383837653463343661 653733376234623536363661363939; allusers+admin=2802000000696628593d7328000000353 73635316133633866323335346264373061613638646530 323436663963633066613131336131; asc+admin=; p-r- demo+admin=280200000069bb34593d732800000034373 33562333563323038653463356264643637623566306462 6430333634313966333561353736 SERVER_SOFTWARE Apache/1.3.26 (Unix) PYTHONPATH /usr/local/mailman SCRIPT_FILENAME /usr/local/mailman/cgi-bin/confirm SERVER_ADMIN jgarey@library.berkeley.edu SCRIPT_NAME /mailman/confirm SERVER_SIGNATURE REQUEST_METHOD GET HTTP_HOST www.lib.berkeley.edu PATH_INFO /p-r- demo/690b69a8dccbfa63a5b1a8aa592f14597f517e87 SERVER_PROTOCOL HTTP/1.0 QUERY_STRING REQUEST_URI /mailman/confirm/p-r- demo/690b69a8dccbfa63a5b1a8aa592f14597f517e87 HTTP_ACCEPT image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */* HTTP_ACCEPT_CHARSET iso-8859-1,*,utf-8 HTTP_USER_AGENT Mozilla/4.79 [en] (Windows NT 5.0; U) HTTP_CONNECTION Keep-Alive HTTP_REFERER http://us.f136.mail.yahoo.com/ym/ShowLetter? MsgId=6112_8948012_210880_1238_476_0_10784&YY= 54989&inc=25&order=down&sort=date&pos=0&view=&h ead=&box=Inbox SERVER_NAME www.lib.berkeley.edu REMOTE_ADDR 128.32.238.84 REMOTE_PORT 1342 HTTP_ACCEPT_LANGUAGE en PATH_TRANSLATED /data/_b/webdata/p-r- demo/690b69a8dccbfa63a5b1a8aa592f14597f517e87 SERVER_PORT 80 GATEWAY_INTERFACE CGI/1.1 HTTP_ACCEPT_ENCODING gzip SERVER_ADDR 169.229.32.48 DOCUMENT_ROOT /data/_b/webdata ---------------------------------------------------------------------- >Comment By: Garey Mills (gareytm) Date: 2002-08-16 17:58 Message: Logged In: YES user_id=555793 Barry - Is there a patch you could send me? Thanks; Garey Mills ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-16 17:31 Message: Logged In: YES user_id=12800 Fixed, thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=594703&group_id=103 From noreply@sourceforge.net Fri Aug 16 19:57:38 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 16 Aug 2002 11:57:38 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-596215 ] html bugs in 2.0.13 Message-ID: Bugs item #596215, was opened at 2002-08-16 11:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=596215&group_id=103 Category: Web/CGI Group: 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: Chuq Von Rospach (chuqui) Assigned to: Nobody/Anonymous (nobody) Summary: html bugs in 2.0.13 Initial Comment: Ran into some HTML bugs in 2.0.13. For instance, going to the listinfo/mailman-subscribers page and subscribing, it returns the "confirmation is required" warning. It looks good, but view source it. An unterminated " is in the body, not in the head. While it seems to format okay in browsers, it's seriously broken HTML, and it's driving mod_layout nuts, since it depends on the body tags to do header/footer insertions right. I think there's one other generated page with similar problems, too, but I'm not sure which it is yet. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=596215&group_id=103 From chuqui@plaidworks.com Fri Aug 16 21:10:45 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Fri, 16 Aug 2002 13:10:45 -0700 Subject: [Mailman-Developers] Anti-spam "killer app"? Message-ID: Hey, all. Take a look at this -- It's a new technique for identifying spam. The more I look into the details, the more I think we have the "anti-spam killer app", becaues it tunes itself to the individual (or site), adapts as the anti-spammers adapt, and the technique used is fairly easy to implement and damn difficult for a spammer to avoid.... Damn, I wish I'd thought of this. (I've dropped a pointer to it at http://www.chuqui.com/cgi-bin/mwf/topic_show.pl?tid=389) -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ IMHO: Jargon. Acronym for In My Humble Opinion. Used to flag as an opinion something that is clearly from context an opinion to everyone except the mentally dense. Opinions flagged by IMHO are actually rarely humble. IMHO. (source: third unabridged dictionary of chuqui-isms). From noreply@sourceforge.net Fri Aug 16 22:35:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 16 Aug 2002 14:35:09 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-593454 ] NewsRunner error Message-ID: Bugs item #593454, was opened at 2002-08-10 11:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=593454&group_id=103 Category: nntp/news Group: 2.1 beta >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Simone Piunno (pioppo) Assigned to: Nobody/Anonymous (nobody) Summary: NewsRunner error Initial Comment: Just updated to Mailman 2.1b3: Aug 10 17:18:57 2002 (10526) Uncaught runner exception: len() of unsized object Aug 10 17:18:57 2002 (10526) Traceback (most recent call last): File "/home/mailman21/Mailman/Queue/Runner.py", line 105, in _oneloop self._onefile(msg, msgdata) File "/home/mailman21/Mailman/Queue/Runner.py", line 154, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/home/mailman21/Mailman/Queue/NewsRunner.py", line 56, in _dispose prepare_message(mlist, msg, msgdata) File "/home/mailman21/Mailman/Queue/NewsRunner.py", line 132, in prepare_message count = len(email.Iterators.body_line_iterator(msg)) TypeError: len() of unsized object ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-16 17:35 Message: Logged In: YES user_id=12800 Fixed now, thanks! ---------------------------------------------------------------------- Comment By: Simone Piunno (pioppo) Date: 2002-08-16 09:33 Message: Logged In: YES user_id=227443 I have installed both 1.5.2 and 2.2.1. Mailman has been configured --with-python=/usr/bin/python2 but a couple files are still referring to the old python, at least Mailman/Archiver/pipermail.py and Mailman/Post.py ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-15 18:37 Message: Logged In: YES user_id=12800 Two questions, what version of Python are you running, and can you upload the .pck file that's left in qfiles/shunt? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=593454&group_id=103 From noreply@sourceforge.net Fri Aug 16 22:55:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 16 Aug 2002 14:55:50 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-593728 ] Traceback rebuilding archive Message-ID: Bugs item #593728, was opened at 2002-08-11 14:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=593728&group_id=103 Category: Pipermail Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Stefan Divjak (stdivjak) Assigned to: Nobody/Anonymous (nobody) Summary: Traceback rebuilding archive Initial Comment: Witn Mailman 2.1b3, rebuilding a pipermail archive using $ bin/arch listname runs fine for 2 lists, but on the third one gives the following traceback: [...] Updating HTML for article 52 Updating HTML for article 53 Schreibe Archivzustand in Datei /home/mailman/archives/private/humor/pipermail.pck Traceback (most recent call last): File "bin/arch", line 160, in ? main() File "bin/arch", line 148, in main archiver.processUnixMailbox(fp, Article, start, end) File "/home/mailman/Mailman/Archiver/pipermail.py", line 545, in processUnixMailbox m = mbox.next() File "/usr/local/lib/python2.2/mailbox.py", line 34, in next return self.factory(_Subfile(self.fp, start, stop)) File "/home/mailman/Mailman/Mailbox.py", line 69, in scrubber return mailbox.scrub(msg) File "/home/mailman/Mailman/Mailbox.py", line 89, in scrub return self._scrubber(self._mlist, msg) File "/home/mailman/Mailman/Handlers/Scrubber.py", line 159, in process part.set_payload(_("""\ File "/home/mailman/Mailman/i18n.py", line 76, in _ return _translation.gettext(s) % dict UnicodeError: ASCII decoding error: ordinal not in range(128) ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-16 17:55 Message: Logged In: YES user_id=12800 Can you upload the .mbox file for the list you're regenerating? If not (perhaps because it's proprietary information), can you make it available for me to look at privately? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=593728&group_id=103 From noreply@sourceforge.net Fri Aug 16 22:56:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 16 Aug 2002 14:56:26 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-592026 ] real_name can't be changed Message-ID: Bugs item #592026, was opened at 2002-08-07 08:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=592026&group_id=103 Category: configuring/installing Group: None >Status: Pending Resolution: Works For Me Priority: 5 Submitted By: H. Peter Aitken (benchmark) Assigned to: Nobody/Anonymous (nobody) Summary: real_name can't be changed Initial Comment: I have a Discussion List associated with my web-site hosted by Dreamhost. Dreamhost informs me that they use Mailman software and that I should contact you with information about this "known bug." Navigating through Discussion Lists -> Membership Management to the list in question, I tried to change the value of "The public name of this list (make case changes only)" so that it would appear in UPPER CASE LETTERS. I made no other changes. Then I hit the "Submit" button. But the change is not implemented. Please will you tell me how I can resolve this issue or whether you are working on a fix. Thank you. Peter Aitken peter@benchmarkresearch.org ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-16 17:56 Message: Logged In: YES user_id=12800 Changing status to Pending waiting for more information. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-09 15:23 Message: Logged In: YES user_id=12800 I can't reproduce this in either MM2.1 or MM2.0.13. What version are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=592026&group_id=103 From noreply@sourceforge.net Fri Aug 16 22:57:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 16 Aug 2002 14:57:01 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-571004 ] member_posting_only does not work Message-ID: Bugs item #571004, was opened at 2002-06-19 03:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=571004&group_id=103 Category: security/privacy Group: 2.0.x >Status: Pending >Resolution: Works For Me Priority: 5 Submitted By: Josef Grosch (jgrosch) Assigned to: Nobody/Anonymous (nobody) Summary: member_posting_only does not work Initial Comment: Version 2.0.11 on FreeBSD 4.6 Mailman allows people who are not on the list are allowed to post. member_posting_only is set yes but non members are still posting. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-16 17:57 Message: Logged In: YES user_id=12800 Changing status to Pending waiting on more information. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-09 15:32 Message: Logged In: YES user_id=12800 Several reasons why this could appear so: - mail headers are being forged, so they are passing the membership tests - the addresses are on the "members accepted for posting" list (e.g. the `posters' variable) - the postings are being held but a moderator is approving them I can't reproduce this, so I'll need more information. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=571004&group_id=103 From noreply@sourceforge.net Fri Aug 16 22:59:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 16 Aug 2002 14:59:18 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-566301 ] umbrella list: unsubscribe key public Message-ID: Bugs item #566301, was opened at 2002-06-08 17:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=566301&group_id=103 Category: security/privacy Group: 2.1 beta Status: Open Resolution: None >Priority: 5 Submitted By: Stefan Divjak (stdivjak) Assigned to: Nobody/Anonymous (nobody) Summary: umbrella list: unsubscribe key public Initial Comment: Mailman offers a feature to set up an "umbrella-list", which is used if a list just has other lists as members. Assume we have an umbrella-list U, which has to members, X and Y - both are also lists. Now, cleverly, the monthly password reminders are not sent to X and Y, but to "X-owner" and "Y-owner" instead, so this information should reach the owners of the subscribed lists (sending a password reminder to X would mean giving each member of the X list the power to unsubscribe X from U etc.). But: If a member of X or Y opens the member options page (http://my.server.net/mailman/options/U/X) and clicks on the "unsubscribe" button, the necessary key is mailed to X (and not to "X-owner"). This is probably not what we want. If the list archive is not private, the password is even available to everyone out there. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-16 17:59 Message: Logged In: YES user_id=12800 Umbrella lists are a hack that will eventually go away. Still, if they're there now they should at least be safer. Any chance you'd like to generate a patch for this problem? If not, I'm lowering the priority because it involves a soon-to-be deprecated feature. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=566301&group_id=103 From noreply@sourceforge.net Fri Aug 16 23:00:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 16 Aug 2002 15:00:23 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-565706 ] user wrongly detected Message-ID: Bugs item #565706, was opened at 2002-06-07 04:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=565706&group_id=103 Category: mail delivery Group: 2.0.x >Status: Pending Resolution: None Priority: 5 Submitted By: Enrico Cherubini (bestkevin) Assigned to: Nobody/Anonymous (nobody) Summary: user wrongly detected Initial Comment: Hi, I'm using mailman 2.0.6 and a user, that is in the mailing list, is not able to write in it after I closed the list to members only. He is member as I can see in the members list, here is what happen: Jun 07 09:31:06 2002 (29505) post to lugvr from ., size=1350, success the poster is identified as '.'....here are headers of an email he sent: From: .::Spark::. If you need any further information you are welcome ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-16 18:00 Message: Logged In: YES user_id=12800 No more information has been provided, and the submitter is using a fairly outdated version. I'm changing the status to Pending, awaiting an update or more information. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-07-10 14:51 Message: Logged In: NO Has the user turned off mail delivery? ---------------------------------------------------------------------- Comment By: Simone Piunno (pioppo) Date: 2002-06-07 04:43 Message: Logged In: YES user_id=227443 Ciao Enrico! did you remember me? I was pioppo on #linux-it @ IrcNET :) I think 1st of all you should upgrade to Mailman 2.0.11 and/or to a more recent Python (I guess you are using 1.5.2) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=565706&group_id=103 From jwblist@olympus.net Fri Aug 16 23:17:59 2002 From: jwblist@olympus.net (John W Baxter) Date: Fri, 16 Aug 2002 15:17:59 -0700 Subject: [Mailman-Developers] Anti-spam "killer app"? In-Reply-To: References: Message-ID: At 13:10 -0700 8/16/2002, Chuq Von Rospach wrote: >Take a look at this -- > > > >It's a new technique for identifying spam. The more I look into the details, >the more I think we have the "anti-spam killer app", becaues it tunes itself >to the individual (or site), adapts as the anti-spammers adapt, and the >technique used is fairly easy to implement and damn difficult for a spammer >to avoid.... > >Damn, I wish I'd thought of this. Me, too. ;-) I find it fascinating that the last URL reference at the bottom (yes, I read that far) is to the page at Apple's site describing the filtering in Apple's revised Mail.app in Mac OS X 10.2. I think the idea has a lot of promise. --John -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From barry@python.org Fri Aug 16 23:39:17 2002 From: barry@python.org (Barry A. Warsaw) Date: Fri, 16 Aug 2002 18:39:17 -0400 Subject: [Mailman-Developers] Anti-spam "killer app"? References: Message-ID: <15709.32533.10388.30619@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: CVR> CVR> It's a new technique for identifying spam. The more I look CVR> into the details, the more I think we have the "anti-spam CVR> killer app", becaues it tunes itself to the individual (or CVR> site), adapts as the anti-spammers adapt, and the technique CVR> used is fairly easy to implement and damn difficult for a CVR> spammer to avoid.... CVR> Damn, I wish I'd thought of this. Indeed, and from the article... > I don't know why I avoided trying the statistical approach for so > long. I think it was because I got addicted to trying to identify > spam features myself, as if I were playing some kind of competitive > game with the spammers. (Nonhackers don't often realize this, but > most hackers are very competitive.) Of course you have to realize that 83% of hackers have no idea what a statistical approach means <.532 wink>. :) On a serious note, who's gonna hack up the Python code for an MM2.1 prototype handler module? -Barry From barry@zope.com Fri Aug 16 23:55:56 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 16 Aug 2002 18:55:56 -0400 Subject: [Mailman-Developers] Comments on smart address matching? Message-ID: <15709.33532.616952.253989@anthem.wooz.org> I'm trying to decide what to do with this bug report by Chris Kolar: http://sourceforge.net/tracker/index.php?func=detail&aid=554287&group_id=103&atid=100103 SMART_ADDRESS_MATCH is gone in MM2.1 and I'm a bit loathe to add something like this back. I haven't seen nearly as many complaints about this problem as in the early days, so maybe most sysadmins are getting their act together. No doubt problems like this are still cropping up, especially for DIY'ers who run stealth mail servers, but I consider them misconfigured. Plus there's a perfectly good workaround: subscribe both addresses and nomail one of them. We know this will be easier to do post-MM2.1. So I'm inclined to close this bug as Wont Fix. Opinions? -Barry From noreply@sourceforge.net Sat Aug 17 00:36:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 16 Aug 2002 16:36:02 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-565706 ] user wrongly detected Message-ID: Bugs item #565706, was opened at 2002-06-07 01:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=565706&group_id=103 Category: mail delivery Group: 2.0.x Status: Pending Resolution: None Priority: 5 Submitted By: Enrico Cherubini (bestkevin) Assigned to: Nobody/Anonymous (nobody) Summary: user wrongly detected Initial Comment: Hi, I'm using mailman 2.0.6 and a user, that is in the mailing list, is not able to write in it after I closed the list to members only. He is member as I can see in the members list, here is what happen: Jun 07 09:31:06 2002 (29505) post to lugvr from ., size=1350, success the poster is identified as '.'....here are headers of an email he sent: From: .::Spark::. If you need any further information you are welcome ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-08-16 16:36 Message: Logged In: NO Yes I did turn off delivery. I read the mail via the web interface. we are using version 2.0.12. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-16 15:00 Message: Logged In: YES user_id=12800 No more information has been provided, and the submitter is using a fairly outdated version. I'm changing the status to Pending, awaiting an update or more information. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-07-10 11:51 Message: Logged In: NO Has the user turned off mail delivery? ---------------------------------------------------------------------- Comment By: Simone Piunno (pioppo) Date: 2002-06-07 01:43 Message: Logged In: YES user_id=227443 Ciao Enrico! did you remember me? I was pioppo on #linux-it @ IrcNET :) I think 1st of all you should upgrade to Mailman 2.0.11 and/or to a more recent Python (I guess you are using 1.5.2) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=565706&group_id=103 From noreply@sourceforge.net Sat Aug 17 01:29:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 16 Aug 2002 17:29:24 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-553385 ] Translation strings Message-ID: Bugs item #553385, was opened at 2002-05-07 14:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=553385&group_id=103 Category: Web/CGI Group: 2.1 beta >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Daniel Buchmann (avalon) Assigned to: Nobody/Anonymous (nobody) Summary: Translation strings Initial Comment: #: Mailman/Gui/ContentFilter.py:38 Minor typo; the entry reads: "Policies concerning concerning the content [...]" #: Mailman/Commands/cmd_set.py:186 msgid " %(status)s (%(how)s on %(date)s)" I'm not sure I fully understand what this is. status = delivery status? (disabled/enabled?) how = how it was disabled? date = the date it happened? How is the date written here? In english? According to the user's language setting? According to the locale? I believe this information is needed for many languages, to be able to translate this entry in the correct way... #: Mailman/Commands/cmd_set.py None of the commands should be translated, right? Should the various "set options" be translated? (e.g. 'ack', 'delivery', 'digest', etc.) If yes, then the output of the "set help" command would give the users a translated explanation to english commands. When they do "set show", the various options will also be translated, but english commands must be sent to the -request address, right? It is also currently not possible to translate the 'digest' option (there is no catalog entry for it). And why does the 'delivery' option have its own entries, when all the others have entries like this: "ack %(onoff)s" ? If no, then several cmd_set.py entries could probably be removed from the catalog, or they must be left blank so they default to their english value. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-16 20:29 Message: Logged In: YES user_id=12800 Fixed the typo in your patch, thanks. As for your questions: - we really have no architecture to do localization of dates unfortunately. The bit in cmd_set.py is trying to tell a user how and when they got disabled, e.g. something like "disabled (due to bounces on ....somedate...)". We'll have to live with US-centric formats here for now. - correct, none of the commands should be translated. Eventually we may want to localize cmd_set.py and other email commands, but that's not well supported now. - thanks for mentioning the bug in the marking of the digest options. I'll fix that too. - digest has its own entries because there are three choices. does it make a difference for how you would add translations? - i'm not sure what catalog entries should be removed. The current mapping between commands and methods is pretty static ('digest' command -> set_digest()). Thanks ---------------------------------------------------------------------- Comment By: Simone Piunno (pioppo) Date: 2002-05-10 15:54 Message: Logged In: YES user_id=227443 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=553385&group_id=103 From jarrell@vt.edu Sat Aug 17 01:30:34 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Fri, 16 Aug 2002 20:30:34 -0400 Subject: [Mailman-Developers] Anti-spam "killer app"? In-Reply-To: Message-ID: <5.1.0.14.2.20020816202126.03729b20@lennier.cc.vt.edu> At 01:10 PM 8/16/02 -0700, you wrote: >Hey, all. > >Take a look at this -- > > > >It's a new technique for identifying spam. The more I look into the details, >the more I think we have the "anti-spam killer app", becaues it tunes itself >to the individual (or site), adapts as the anti-spammers adapt, and the >technique used is fairly easy to implement and damn difficult for a spammer >to avoid.... > >Damn, I wish I'd thought of this. > >(I've dropped a pointer to it at >http://www.chuqui.com/cgi-bin/mwf/topic_show.pl?tid=389) Yea, I read that... It really started wheels turning in my head. Now, if I'd coded in lisp more recently than 20 years ago it would have been a little easier, since I hadn't taken stats any more recently either, and couldn't remember Bayesean analysis to save my soul... Of course, it still requires either you accept someone elses starting corpus, or you have to have someone still tag the spam as it arrives. But it wouldn't be *that* hard to add to mailman... Add a button to the admindb page for "this was spam". Ideally add a button into the pipermail interface (yea, I know, change pipermail; ugh feh) that the admin can use that says "This message is spam. Treat it a so". Both would make the message go away, and get added to the lists spam corpus correspondingly deleting it from the lists good corpus stats if it was in the archives (why? because if it made it that far then it was considered valid email, and we need to get its keywords *out* of that database). We'd also archive the entire note for future reference. At some point, when we had enough data to trust the corpus sample size, the list admin would be given the option of turning on the spam filter, which could just throw the same results out that the moderation checks do; discard, hold, pass, etc. Meanwhile, back at the ranch, the site owner could run a site-level filter if they liked, independant of the list-level one (hence why we save the messages. This allows the site admin to review messages tagged as spam, and agree or disagree on their inclusion, preventing the psycho-moderator syndrome), which could be used to seed new lists with a better starting corpus... From jarrell@vt.edu Sat Aug 17 01:32:43 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Fri, 16 Aug 2002 20:32:43 -0400 Subject: [Mailman-Developers] Anti-spam "killer app"? In-Reply-To: <15709.32533.10388.30619@anthem.wooz.org> References: Message-ID: <5.1.0.14.2.20020816203119.0372edf0@lennier.cc.vt.edu> At 06:39 PM 8/16/02 -0400, you wrote: >On a serious note, who's gonna hack up the Python code for an MM2.1 >prototype handler module? Please tell me that means "a module designed to fit into the 2.1 plugin architecture, that could be distributed in a post 2.1-final release" and not, cool as it is, "a module that we're going to hold up 2.1 waiting on." From noreply@sourceforge.net Sat Aug 17 01:32:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 16 Aug 2002 17:32:44 -0700 Subject: [Mailman-Developers] [ mailman-Feature Requests-550462 ] New feature: Automoderate microsoft user Message-ID: Feature Requests item #550462, was opened at 2002-04-29 21:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=550462&group_id=103 >Category: None >Group: None Status: Open >Resolution: Rejected Priority: 5 Submitted By: Mark Whitis (whitis) Assigned to: Nobody/Anonymous (nobody) Summary: New feature: Automoderate microsoft user Initial Comment: I am not using mailman at the moment but I was looking at its feature list and planned upgrades and found this missing. And it could be added in a very general form that could support many other uses. Reason for suggesting: everytime I post a message on a Linux list, I get a bunch of virus messages from bozos who have subscribed to those lists from a windows box. And I am certainly not alone in that respect. Usually these messages do not arrive via the list but are sent to anyone who posts to the list (often by lurkers). Users of real operating systems who subscribe to lists related to those should not be inconvinienced by those who use microsoft products, there of all places. I would like to suggest that future versions of Mailman include a feature (selected by the moderator) which automatically takes certain actions based on the subscibers email client. This feature could be activated based on the message headers in the replies to subscription confirmation messages. Actions could include: - Placing the user in moderated status (prevents sending virus to the list directly but doesn't prevent the virus from getting addresses from the user). - Cancelling the subscription - Sending a warning message to the user - Requiring the user to send a control message agreeing that their virus software will be kept up to date. - hide or mung all email addresses in copies of messages delivered to this user so email worms/viruses cannot harvest them. The email client status could be updated when the user sends a new control message. Optionally, it could also detect microsoft platforms via the browser ID when people sign on via the web site. Detection could be controlled by a configuration file listing with four fields: action, mail/web, field, and regex: ACCEPT MAIL X-Mailer .*Microsoft Sucks.* REJECT MAIL X-Mailer .*Microsoft Outlook.* REJECT MAIL X-Mimeole .*Microsoft Exchange.* REJECT WEB Browser-ID .*Internet Explorer.* (note: this would be triggered by opera in identify as Internet Explorer mode, but the user can switch to identify as opera). REJECT WEB Browser-ID .*Windows 95.* REJECT WEB Browser-ID .*Windows 98.* REJECT WEB Browser-ID .*Windows NT.* REJECT WEB Browser-ID .*Windows ME.* REJECT WEB Browser-ID .*Windows 2000.* REJECT WEB Browser-ID .*Win16.* REJECT WEB Browser-ID .*Win32.* REJECT WEB Browser-ID .*MSIE.* If you place someone on moderated status based on their mail client or web browser, the reason for moderation should be noted so that they can be automatically un-moderated (if otherwise consistent with policy) when they use a real computer to access the list. This feature could also be used to protect some protection against other problems, as well. Spam, REJECT MAIL From .*hotmail.com.* REJECT MAIL Subject: .*casino.* REJECT ATTACH Content-Type: application/octet-stream REJECT ATTACH Content-Type: audio/x-wav REJECT ATTACH Content-Type: audio/x-midi REJECT BODY "insurance" MODERATE-MSG BODY "profaneword" The config file could be XMLized: Possible Extensions: action: make "actions" instead and allow a comma separated list (or even nested XML action tags) moderate-msg moderate-user unmoderate-user strip-attachments strip-attachment bounce-message append-boilerplate source: comma separated list WEB_POST, WEB_CONTROL, MAIL_POST, MAIL_CONTROL, POST_BODY, POST_ATTACHMENT_HDR, POST_ATTACHMENT_BODY. blacklist: added field. .rss.mail-abuse.org .dul-mail-abuse.org Note that for the Dial Up list, this should only be applied to the first Received line added by the mail server itself. user-status: the users existing status (normal, moderated, moderated-newbie, moderated-badsoftware, trusted, moderator, list_owner, etc.) could be considered in applying filters. XML structure could be much more complicated, as well. One could also allow a user so detected to subscribe only after they had pledged to keep their virus checker up to date by sending a special control message or visiting a special web page. This could also be used to filter certain types of spam that have consistent patterns. I have seen the same websites repeately spammed to the same list (until I blew those websites away) from different aliases. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-16 20:32 Message: Logged In: YES user_id=12800 This seems like an awful lot of complexity for something that probably won't work anyway. I'm moving this to the feature request tracker, but rejecting it because it's not something I'm interesting in working on. If you are though, feel free to generate a patch for Mailman 2.1 and upload it to the patch manager. No guarantees it will go in, but at least that way, others can look at and comment on the approach. ---------------------------------------------------------------------- Comment By: Claus Färber (cfaerber) Date: 2002-08-13 07:37 Message: Logged In: YES user_id=126984 The problem with misdirected bounce messages, etc. is not caused by the the operating system or the user agent. It is caused by virus scanners, vacation programmes, and even some broken MTAs that send messages back to addresses in the header and not to the return path (envelope from). Mailman could try to trigger that bug by sending a message -- for example, the monthly reminder -- with the correct return path but with a different from address. If some software then causes a bounce to be sent to the wrong address, Mailman could act accordingly (e.g. unsubscribe the user, or activate a broken-mailer flag). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=550462&group_id=103 From noreply@sourceforge.net Sat Aug 17 01:34:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 16 Aug 2002 17:34:06 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-550314 ] Sending to multiple lists chooses one. Message-ID: Bugs item #550314, was opened at 2002-04-29 14:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=550314&group_id=103 Category: mail delivery Group: 2.0.x >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Jeff Posner (jposnersails) Assigned to: Nobody/Anonymous (nobody) Summary: Sending to multiple lists chooses one. Initial Comment: When I send a single message addressed as multiple lists on to 'TO:' line, each recipient receives exactly one copy. If a single user is a memeber of more than one list, he receives the copy to a "seemingly" random list. I am new to this version (just upgraded from 1.x) and have not seen this problem before. Thanks. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-16 20:34 Message: Logged In: YES user_id=12800 I suspect "nobody"'s analysis might be closer to the truth. Certainly we cross post all the time with MM 2.0.13 and have never seen a problem. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-02 01:52 Message: Logged In: NO If your users run Cyrus, or some similar mail system, messages with duplicate message-IDs are only stored once. This may, or may not, be relevant. ---------------------------------------------------------------------- Comment By: Dan Mick (dmick) Date: 2002-05-01 17:54 Message: Logged In: YES user_id=10725 Just tested with close-to-current 2.1CVS; it works for me. Two test lists, one post with both lists on To: line, I get two copies as expected. What version are you running? It might be worth checking the archives to see if the message got to both places; maybe one list is broken. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=550314&group_id=103 From chuqui@plaidworks.com Sat Aug 17 01:35:17 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Fri, 16 Aug 2002 17:35:17 -0700 Subject: [Mailman-Developers] Anti-spam "killer app"? In-Reply-To: <5.1.0.14.2.20020816202126.03729b20@lennier.cc.vt.edu> Message-ID: On 8/16/02 5:30 PM, "Ron Jarrell" wrote: >> (I've dropped a pointer to it at >> http://www.chuqui.com/cgi-bin/mwf/topic_show.pl?tid=389) > > > Yea, I read that... It really started wheels turning in my head. Now, if I'd > coded > in lisp more recently than 20 years ago it would have been a little easier, Cory Doctorow sent me this link: The king-hell Bayesian libraries are Andrew McCallum's Bag Of Words (BOW) stuff, which is all GPLed: http://www-2.cs.cmu.edu/~mccallum/bow/ A GPLed Bayesian library. No lisp needed. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ No! No! Dead girl, OFF the table! -- Shrek From barry@python.org Sat Aug 17 01:40:43 2002 From: barry@python.org (Barry A. Warsaw) Date: Fri, 16 Aug 2002 20:40:43 -0400 Subject: [Mailman-Developers] Anti-spam "killer app"? References: <5.1.0.14.2.20020816203119.0372edf0@lennier.cc.vt.edu> Message-ID: <15709.39819.465415.180373@anthem.wooz.org> >>>>> "RJ" == Ron Jarrell writes: RJ> At 06:39 PM 8/16/02 -0400, you wrote: >> On a serious note, who's gonna hack up the Python code for an >> MM2.1 prototype handler module? RJ> Please tell me that means "a module designed to fit into the RJ> 2.1 plugin architecture, that could be distributed in a post RJ> 2.1-final release" and not, cool as it is, "a module that RJ> we're going to hold up 2.1 waiting on." Of course! I actually think we're getting really close, and I'm psyched about all the great feedback I'm getting on beta 3. I'll probably release a beta 4 this weekend, and then I want to get serious about a release schedule. -Barry From barry@python.org Sat Aug 17 01:44:39 2002 From: barry@python.org (Barry A. Warsaw) Date: Fri, 16 Aug 2002 20:44:39 -0400 Subject: [Mailman-Developers] Anti-spam "killer app"? References: <5.1.0.14.2.20020816202126.03729b20@lennier.cc.vt.edu> Message-ID: <15709.40055.173007.971171@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: CVR> Cory Doctorow sent me this link: CVR> The king-hell Bayesian libraries are Andrew McCallum's Bag Of CVR> Words (BOW) stuff, which is all GPLed: CVR> http://www-2.cs.cmu.edu/~mccallum/bow/ CVR> A GPLed Bayesian library. No lisp needed. Neat. I'd be happy to help someone who wanted to generate a Python wrapper module around libbow. I probably won't have time. -Barry From chuqui@plaidworks.com Sat Aug 17 01:46:08 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Fri, 16 Aug 2002 17:46:08 -0700 Subject: [Mailman-Developers] Anti-spam "killer app"? In-Reply-To: Message-ID: On 8/16/02 3:17 PM, "John W Baxter" wrote: > I find it fascinating that the last URL reference at the bottom (yes, I > read that far) is to the page at Apple's site describing the filtering in > Apple's revised Mail.app in Mac OS X 10.2. Yeah. In all honesty? When I sent stuff out I hadn't read that far. As I understand it (and I could be wrong) they borrowed some stuff from the text-to-speech folks to build their text analysis in 10.0 mail.app. I hope to upgrade this weekend, and I'll let you know how I like it. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ No! No! Dead girl, OFF the table! -- Shrek From chk@pobox.com Sat Aug 17 01:46:38 2002 From: chk@pobox.com (Harald Koch) Date: Fri, 16 Aug 2002 20:46:38 -0400 Subject: [Mailman-Developers] Re: Anti-spam "killer app"? In-Reply-To: Your message of "Fri, 16 Aug 2002 13:10:45 -0700". References: Message-ID: <1615.1029545198@elisabeth.cfrq.net> > Damn, I wish I'd thought of this. A naive google search finds papers 4 years old discussing the problem, which makes me wonder why nobody has implemented this before now... -- Harald Koch "It takes a child to raze a village." -Michael T. Fry From chuqui@plaidworks.com Sat Aug 17 01:52:57 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Fri, 16 Aug 2002 17:52:57 -0700 Subject: [Mailman-Developers] Comments on smart address matching? In-Reply-To: <15709.33532.616952.253989@anthem.wooz.org> Message-ID: I wouldn't fix. Instead, I'd focus on adding address aliasing, and let people add in those as aliases. It fixes a more general issue ("I have all these addresses, and want one subscription") and they get fixed as a side effect of the more general fix. They would still have to add in their aliases. I see at as motivation to convince their admins to fix the real problem... (giggle) On 8/16/02 3:55 PM, "Barry A. Warsaw" wrote: > So I'm inclined to close this bug as Wont Fix. Opinions? -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ Someday, we'll look back on this, laugh nervously and change the subject. From noreply@sourceforge.net Sat Aug 17 01:56:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 16 Aug 2002 17:56:49 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-593454 ] NewsRunner error Message-ID: Bugs item #593454, was opened at 2002-08-10 15:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=593454&group_id=103 Category: nntp/news Group: 2.1 beta Status: Closed Resolution: Fixed Priority: 5 Submitted By: Simone Piunno (pioppo) Assigned to: Nobody/Anonymous (nobody) Summary: NewsRunner error Initial Comment: Just updated to Mailman 2.1b3: Aug 10 17:18:57 2002 (10526) Uncaught runner exception: len() of unsized object Aug 10 17:18:57 2002 (10526) Traceback (most recent call last): File "/home/mailman21/Mailman/Queue/Runner.py", line 105, in _oneloop self._onefile(msg, msgdata) File "/home/mailman21/Mailman/Queue/Runner.py", line 154, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/home/mailman21/Mailman/Queue/NewsRunner.py", line 56, in _dispose prepare_message(mlist, msg, msgdata) File "/home/mailman21/Mailman/Queue/NewsRunner.py", line 132, in prepare_message count = len(email.Iterators.body_line_iterator(msg)) TypeError: len() of unsized object ---------------------------------------------------------------------- Comment By: Ron Jarrell (jarrell) Date: 2002-08-17 00:56 Message: Logged In: YES user_id=34619 Hey, Barry, I'm getting the same thing with my installation, with straight python 2.2 everywhere (I don't *have* 1.5.2 installed anymore). ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-16 21:35 Message: Logged In: YES user_id=12800 Fixed now, thanks! ---------------------------------------------------------------------- Comment By: Simone Piunno (pioppo) Date: 2002-08-16 13:33 Message: Logged In: YES user_id=227443 I have installed both 1.5.2 and 2.2.1. Mailman has been configured --with-python=/usr/bin/python2 but a couple files are still referring to the old python, at least Mailman/Archiver/pipermail.py and Mailman/Post.py ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-15 22:37 Message: Logged In: YES user_id=12800 Two questions, what version of Python are you running, and can you upload the .pck file that's left in qfiles/shunt? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=593454&group_id=103 From noreply@sourceforge.net Sat Aug 17 01:59:52 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 16 Aug 2002 17:59:52 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-593454 ] NewsRunner error Message-ID: Bugs item #593454, was opened at 2002-08-10 15:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=593454&group_id=103 Category: nntp/news Group: 2.1 beta Status: Closed Resolution: Fixed Priority: 5 Submitted By: Simone Piunno (pioppo) Assigned to: Nobody/Anonymous (nobody) Summary: NewsRunner error Initial Comment: Just updated to Mailman 2.1b3: Aug 10 17:18:57 2002 (10526) Uncaught runner exception: len() of unsized object Aug 10 17:18:57 2002 (10526) Traceback (most recent call last): File "/home/mailman21/Mailman/Queue/Runner.py", line 105, in _oneloop self._onefile(msg, msgdata) File "/home/mailman21/Mailman/Queue/Runner.py", line 154, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/home/mailman21/Mailman/Queue/NewsRunner.py", line 56, in _dispose prepare_message(mlist, msg, msgdata) File "/home/mailman21/Mailman/Queue/NewsRunner.py", line 132, in prepare_message count = len(email.Iterators.body_line_iterator(msg)) TypeError: len() of unsized object ---------------------------------------------------------------------- Comment By: Ron Jarrell (jarrell) Date: 2002-08-17 00:59 Message: Logged In: YES user_id=34619 Rarwk. Never mind. Sourceforge for some reason did *not* show me the "Fixed now" message until *after* I re-read it after following up. ---------------------------------------------------------------------- Comment By: Ron Jarrell (jarrell) Date: 2002-08-17 00:56 Message: Logged In: YES user_id=34619 Hey, Barry, I'm getting the same thing with my installation, with straight python 2.2 everywhere (I don't *have* 1.5.2 installed anymore). ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-16 21:35 Message: Logged In: YES user_id=12800 Fixed now, thanks! ---------------------------------------------------------------------- Comment By: Simone Piunno (pioppo) Date: 2002-08-16 13:33 Message: Logged In: YES user_id=227443 I have installed both 1.5.2 and 2.2.1. Mailman has been configured --with-python=/usr/bin/python2 but a couple files are still referring to the old python, at least Mailman/Archiver/pipermail.py and Mailman/Post.py ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-15 22:37 Message: Logged In: YES user_id=12800 Two questions, what version of Python are you running, and can you upload the .pck file that's left in qfiles/shunt? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=593454&group_id=103 From chuqui@plaidworks.com Sat Aug 17 02:02:36 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Fri, 16 Aug 2002 18:02:36 -0700 Subject: [Mailman-Developers] Anti-spam "killer app"? In-Reply-To: <15709.39819.465415.180373@anthem.wooz.org> Message-ID: On 8/16/02 5:40 PM, "Barry A. Warsaw" wrote: > I actually think we're getting really close, and I'm psyched about all > the great feedback I'm getting on beta 3. I'll probably release a > beta 4 this weekend, and then I want to get serious about a > release schedule. Which is perfect timing, because I've installed jaguar on my new test server, and I'm going to spend time this weekend building out the environment, which means sometime in the next few days, I'm going to load up Mailman and see what happens... -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ No! No! Dead girl, OFF the table! -- Shrek From satyap@satya.virtualave.net Sat Aug 17 02:39:42 2002 From: satyap@satya.virtualave.net (Satya) Date: Fri, 16 Aug 2002 18:39:42 -0700 (PDT) Subject: [Mailman-Developers] Anti-spam "killer app"? In-Reply-To: Message-ID: Sounds very cool and usable. I've started hacking up a Perl (please don't deactivate me!) thingy which'll be called from procmail, and another perl thingy which'll be called from crontab ... well, never mind the details. I'm stuck on the Bayesian probability thing. What is what? Pr{X and Y} Pr{Y|X} = ------------- Pr{X} is what's at http://www.mathpages.com/home/kmath143.htm but what is X and Y, and how do I ... oh never mind, the question is too complicated. P(y/x) = probability that this is spam given that the word we're looking at is a spamword? Then what is P(xy)? Is it the probability that the word is a spamword? Then what's P(x)? And how do I accumulate the probabilities? -- Satya. Luxuriantly hand-crafted from only the finest ASCII. From barry@python.org Sat Aug 17 05:38:54 2002 From: barry@python.org (Barry A. Warsaw) Date: Sat, 17 Aug 2002 00:38:54 -0400 Subject: [Mailman-Developers] Anti-spam "killer app"? References: Message-ID: <15709.54110.673810.240332@anthem.wooz.org> >>>>> "S" == Satya writes: S> Sounds very cool and usable. I've started hacking up a Perl S> (please don't deactivate me!) thingy which'll be called from S> procmail, and another perl thingy which'll be called from S> crontab ... well, never mind the details. That's okay, I'm going to shame Tim Peters into building an ultra efficient Python version, which we'll just wrap in the MM handler API and be done with it. :) -Barry From barry@python.org Sat Aug 17 05:42:38 2002 From: barry@python.org (Barry A. Warsaw) Date: Sat, 17 Aug 2002 00:42:38 -0400 Subject: [Mailman-Developers] Anti-spam "killer app"? References: <15709.39819.465415.180373@anthem.wooz.org> Message-ID: <15709.54334.190336.362041@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: CVR> Which is perfect timing, because I've installed jaguar on my CVR> new test server, and I'm going to spend time this weekend CVR> building out the environment, which means sometime in the CVR> next few days, I'm going to load up Mailman and see what CVR> happens... Cool! Depending on how adventurous you are, you may want to check out Python 2.3's cvs. Jack Jansen's been doing a lot of work on providing Carbon support for Python, if I've been following his checkins correctly. Haven't played with it, but and of course Python 2.3's not even in alpha yet, but we use it every day and it's pretty stable (performance-wise, mostly if not feature-wise). -Barry From barry@zope.com Sat Aug 17 05:44:38 2002 From: barry@zope.com (Barry A. Warsaw) Date: Sat, 17 Aug 2002 00:44:38 -0400 Subject: [Mailman-Developers] Comments on smart address matching? References: <15709.33532.616952.253989@anthem.wooz.org> Message-ID: <15709.54454.203052.928982@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: CVR> I wouldn't fix. Instead, I'd focus on adding address CVR> aliasing, and let people add in those as aliases. It fixes a CVR> more general issue ("I have all these addresses, and want one CVR> subscription") and they get fixed as a side effect of the CVR> more general fix. Agreed. CVR> They would still have to add in their aliases. I see at as CVR> motivation to convince their admins to fix the real CVR> problem... (giggle) Agreed! -Barry From darrell@grumblesmurf.net Sat Aug 17 05:55:30 2002 From: darrell@grumblesmurf.net (Darrell Fuhriman) Date: 16 Aug 2002 21:55:30 -0700 Subject: [Mailman-Developers] Anti-spam "killer app"? In-Reply-To: References: Message-ID: Satya writes: > don't deactivate me!) thingy which'll be called from procmail, and > another perl thingy which'll be called from crontab ... well, never > mind the details. Yah, I threw it together this afternoon, too. Sorry, guys, I did it in perl, too. =A0I'm just trying to collect enough spam to seed it. I only had a couple hundred laying around. I can start doing some more serious testing. So far, it seems to do the right thing. The code's rather un-polished, but you're welcome to what I've got so far. Darrell From chuqui@plaidworks.com Sat Aug 17 06:42:20 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Fri, 16 Aug 2002 22:42:20 -0700 Subject: [Mailman-Developers] Anti-spam "killer app"? In-Reply-To: <15709.54334.190336.362041@anthem.wooz.org> Message-ID: On 8/16/02 9:42 PM, "Barry A. Warsaw" wrote: > Cool! Depending on how adventurous you are, you may want to check out > Python 2.3's cvs. Jack Jansen's been doing a lot of work on providing > Carbon support for Python, Not THAT adventurous. This is a server, so it won't be depending on GUI or Carbon anyway. (grin) -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ Yes, I am an agent of Satan, but my duties are largely ceremonial. From satyap@satya.virtualave.net Sat Aug 17 06:57:38 2002 From: satyap@satya.virtualave.net (Satya) Date: Fri, 16 Aug 2002 22:57:38 -0700 (PDT) Subject: [Mailman-Developers] Anti-spam "killer app"? In-Reply-To: Message-ID: On Aug 17, 2002 at 00:38, Barry A. Warsaw wrote: >That's okay, I'm going to shame Tim Peters into building an ultra >efficient Python version, which we'll just wrap in the MM handler API >and be done with it. :) But... but... what will *I* use? On Aug 16, 2002 at 21:55, Darrell Fuhriman wrote: >Yah, I threw it together this afternoon, too. >The code's rather un-polished, but you're welcome to what I've >got so far. Awesome, can I have it? -- Satya. "Please feel free to blither now." -- THHGTTG From noreply@sourceforge.net Sat Aug 17 07:21:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 16 Aug 2002 23:21:23 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-596361 ] rejection-notice not translated Message-ID: Bugs item #596361, was opened at 2002-08-17 06:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=596361&group_id=103 Category: Web/CGI Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: rejection-notice not translated Initial Comment: on the admindb screen, detailed description of the held messages include 'rejection-notice' field to be sent to the message sender but the default value in the text form is in english and not translated into the list-preferred language. Following short patch may work: --- admindb.py.orig Fri Aug 16 11:39:53 2002 +++ admindb.py Sat Aug 17 14:57:37 2002 @@ -595,8 +595,8 @@ t.AddRow([ Bold(_('If you reject this post,
please explain (optional):')), TextArea('comment-%d' % id, rows=4, cols=80, - text = Utils.wrap(msgdata.get('rejection-notice', - _('[No explanation given]')), + text = Utils.wrap(_(msgdata.get('rejection-notice', + _('[No explanation given]'))), column=80)) ]) row, col = t.GetCurrentRowIndex(), t.GetCurrentCellIndex() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=596361&group_id=103 From bob@nleaudio.com Sat Aug 17 16:00:15 2002 From: bob@nleaudio.com (Bob Puff@NLE) Date: Sat, 17 Aug 2002 11:00:15 -0400 Subject: [Mailman-Developers] Spammers from MM list Message-ID: <3D5E64FF.9080001@nleaudio.com> Hello, I just noticed this week I got some spam into an email address that I only posted one time on the MM-Users list. The spambots are now crawling through our archives here, which I suppose isn't surprising. What I did find a little disconcerting is that the email addresses in the archives here are in plain view, with mailto: links. Perhaps in our current efforts to reduce spam, we need not overlook our own sources. Bob From barry@python.org Sat Aug 17 16:06:36 2002 From: barry@python.org (Barry A. Warsaw) Date: Sat, 17 Aug 2002 11:06:36 -0400 Subject: [Mailman-Developers] Anti-spam "killer app"? References: <15709.54334.190336.362041@anthem.wooz.org> Message-ID: <15710.26236.813719.664217@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: >> Cool! Depending on how adventurous you are, you may want to >> check out Python 2.3's cvs. Jack Jansen's been doing a lot of >> work on providing Carbon support for Python, CVR> Not THAT adventurous. This is a server, so it won't be CVR> depending on GUI or Carbon anyway. CVR> (grin) :) Works for me. -Barry From noreply@sourceforge.net Sat Aug 17 16:11:30 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 17 Aug 2002 08:11:30 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-596456 ] TypeError: unsubscriptable object Message-ID: Bugs item #596456, was opened at 2002-08-17 17:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=596456&group_id=103 Category: None Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Simone Piunno (pioppo) Assigned to: Nobody/Anonymous (nobody) Summary: TypeError: unsubscriptable object Initial Comment: Aug 17 16:37:42 2002 (10524) Uncaught runner exception: unsubscriptable object Aug 17 16:37:42 2002 (10524) Traceback (most recent call last): File "/home/mailman21/Mailman/Queue/Runner.py", line 105, in _oneloop self._onefile(msg, msgdata) File "/home/mailman21/Mailman/Queue/Runner.py", line 154, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/home/mailman21/Mailman/Queue/CommandRunner.py", line 198, in _dispose res.process() File "/home/mailman21/Mailman/Queue/CommandRunner.py", line 93, in process stop = self.do_command(cmd, args) File "/home/mailman21/Mailman/Queue/CommandRunner.py", line 117, in do_command return self.do_command(cmd, args) File "/home/mailman21/Mailman/Queue/CommandRunner.py", line 119, in do_command return handler.process(self, args) File "/home/mailman21/Mailman/Commands/cmd_confirm.py", line 44, in process results = mlist.ProcessConfirmation(cookie, res.msg) File "/home/mailman21/Mailman/MailList.py", line 1096, in ProcessConfirmation subpart = email.Iterators.typed_subpart_iterator( TypeError: unsubscriptable object I was confirming by email to discard an held spam message. I suspect this problem is similar to #593454, related to python 2.2 compatibility ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=596456&group_id=103 From steve@spvi.com Sat Aug 17 17:58:07 2002 From: steve@spvi.com (Steve Spicklemire) Date: Sat, 17 Aug 2002 11:58:07 -0500 Subject: [Mailman-Developers] MemberAdaptor... trouble with API? In-Reply-To: Message-ID: <8107B0D3-B202-11D6-8920-0050E480B13C@spvi.com> Hi Mailman folks, I've started poking around in mailman, trying to help out some folks, and I've come across something I'm not sure how to handle. I'd like to get Mailman working with LDAP, and the first order of business is to simply allow folks to use their LDAP passwords as an option when authenticating with Mailman. Here was my first crack at it: from checkLDAP import checkLDAP import string def makefunc(oldAuth): def new_authenticateMember( member, response, oldAuth=oldAuth, debug=0 ): l_r = string.split(member, '@') if len(l_r) == 2: if l_r[1] == 'our.domain': if checkLDAP( None, member, response): return response return oldAuth( member, response) return new_authenticateMember def extend(mlist): oldfunc = mlist.authenticateMember mlist.authenticateMember = makefunc(oldfunc) I expected that all I needed to do was to replace "authenticateMember' in extend.py and I would be set. Unfortunately, my code never gets called! Snooping through the SecurityManager class, I see that instead, it uses 'getMemberPassword', and never calls 'authenticateMember' at all! The problem is that we don't have any unencrypted passwords to "get". So do I need to override "Authenticate" of SecurityManger to call authenticateMember rather then 'getMemberPassword'? This seems a little wierd. Would it be better to have SecurityManager call 'authenticateMember'? Is the cleartext password really required? If it *is* actually required, couldn't the code just call 'authenticateMember', and if successful, use 'response', rather than asking for the cleartext password from the member adaptor? thanks, -steve From noreply@sourceforge.net Sat Aug 17 19:11:17 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 17 Aug 2002 11:11:17 -0700 Subject: [Mailman-Developers] [ mailman-Patches-534577 ] Add SpamAssassin filter to mail pipeline Message-ID: Patches item #534577, was opened at 2002-03-25 01:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=534577&group_id=103 Category: list administration Group: Mailman 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: James Henstridge (jhenstridge) Assigned to: Nobody/Anonymous (nobody) Summary: Add SpamAssassin filter to mail pipeline Initial Comment: This filter adds support for discarding or holding spam sent to the mailing list. It contacts a spamd daemon (from SpamAssassin -- http://spamassassin.taint.org) to score the message. If the score is above a certain threshold (default 10), the message is discarded and an entry is written to the vette log. If the score is above another lower threshold (default 5), the message is held for moderation. The SpamAssassin.py file should be installed in Mailman/Handlers/. The LIST_PIPELINE variable in Mailman/Handlers/HandlerAPI.py should be modified to include a 'SpamAssassin' item (I put it just after the existing 'SpamDetect' item). To change the defaults, the following can be added to the mm_cfg.py file: SPAMASSASSIN_HOST = 'host:port' # how to contact SA SPAMASSASSIN_DISCARD_SCORE = 10 SPAMASSASSIN_HOLD_SCORE = 5 If you don't want to discard messages, then DISCARD_SCORE can be set to something very high (1000 should do it). It looks the MM2.1 filter APIs have changed a bit, so this filter will need some modifications to work with that version. When I get round to upgrading, I might look into updating it. ---------------------------------------------------------------------- Comment By: dann frazier (dannf) Date: 2002-08-17 12:11 Message: Logged In: YES user_id=146718 hey James, found a typo. also wanted to point out: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=139942&repeatmerged=yes --- SpamAssassin.py.orig Sat Aug 17 12:05:41 2002 +++ SpamAssassin.py Sat Aug 17 12:06:13 2002 @@ -35,7 +35,7 @@ SPAMD_HOST = mm_cfg.SPAMASSASSIN_HOST i = string.find(SPAMD_HOST, ':') if i >= 0: - SPAMD_HOST, SPAMD_PORT = SPAMD_HOST[:i], host[i+1:] + SPAMD_HOST, SPAMD_PORT = SPAMD_HOST[:i], SPAMD_HOST[i+1:] try: SPAMD_PORT = int(SPAMD_PORT) except: SPAMD_PORT = None except: ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-07-25 03:00 Message: Logged In: YES user_id=146903 remembering to check the "upload file" checkbox this time ... ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-07-25 02:59 Message: Logged In: YES user_id=146903 Yet another new version that fixes a small typo. With previous messages, you couldn't approve messages that had been identified as spam once (they would get identified again when the queue got processed, instead of passing the message through). ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-07-09 18:19 Message: Logged In: YES user_id=146903 The Mailman installation on mail.gnome.org also uses this filter. I don't think there are any stability problems with the filter. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2002-07-09 15:16 Message: Logged In: YES user_id=81797 FYI, I ran the previous version since installation and it seemed to work fine. I didn't run into any problems, with probably 500 messages handled. I've updated to the new version and it seems ok so far, but I've only sent about 10 messages through. Sean ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-07-02 22:02 Message: Logged In: YES user_id=146903 Yet another version. There were some bugs in handling of certain error conditions when talking to spamd. These would result in exceptions and the messages staying in the delivery queue :( With the new version, the message will be passed through unchecked under these conditions, and a message will be added to the error log. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2002-06-12 15:48 Message: Logged In: YES user_id=81797 FYI: I've been running the 2002-05-14 version of this patch with spamassassin 2.20 for the last day on our main mailman box and it seems to be working great. ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-05-14 00:04 Message: Logged In: YES user_id=146903 This version is essentially the same as the previous version, but adds compatibility with python > 1.5.2, which doesn't like you passing two arguments to socket.connect(). ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-04-27 00:17 Message: Logged In: YES user_id=146903 Just attached my updated version of the patch. This version requires SpamAssassin 2.20 (for the extra commands that the spamd daemon understands). It now displays a list of which rules were triggered for held messages, and can give messages from list members a bonus (defaults to 2), so that they are less likely to get held as spam. ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-03-25 18:21 Message: Logged In: YES user_id=146903 There is a fairly easy optimisation for this filter that I missed when writing it. It calls str() on the message object twice. It would be quicker to call str() on the message once. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=534577&group_id=103 From claw@kanga.nu Sat Aug 17 20:37:34 2002 From: claw@kanga.nu (J C Lawrence) Date: Sat, 17 Aug 2002 12:37:34 -0700 Subject: [Mailman-Developers] Anti-spam "killer app"? In-Reply-To: Message from Chuq Von Rospach of "Fri, 16 Aug 2002 13:10:45 PDT." References: Message-ID: <11426.1029613054@kanga.nu> On Fri, 16 Aug 2002 13:10:45 -0700 Chuq Von Rospach wrote: > ... > Damn, I wish I'd thought of this. Keep thinking about it. In essence it is a merely a finer grained scoring system. It doesn't fundamentally change the spam cold war; it moves the challenge to "writing spam messages which look even more like 'real' messages" on a statistical sampling level. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From noreply@sourceforge.net Sat Aug 17 22:13:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 17 Aug 2002 14:13:56 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-596565 ] mailman should use alphabetic U/GIDs Message-ID: Bugs item #596565, was opened at 2002-08-17 17:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=596565&group_id=103 Category: configuring/installing Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Todd Vierling (tvierling) Assigned to: Nobody/Anonymous (nobody) Summary: mailman should use alphabetic U/GIDs Initial Comment: In short: "compiling in numeric IDs is Very Evil." The long story: I'm trying to put together a packaging environment for NetBSD's "pkgsrc" to allow easy build and install of Mailman. Unfortunately, this is currently impossible thanks to the fact that alphabetic IDs are resolved to numerics at compile time. (Nearly all packages requiring cutstom IDs resolve them at runtime using get {pw,gr}nam(3)). Thanks to this behavior, it is not currently possible to: * create a prebuilt binary package of Mailman, and install it later on a system without the source tarball; * migrate an existing installation of Mailman to another system that has a uid/gid conflict without recompiling. There are other problems that compiled-in numeric IDs cause, but these two really stick out. I'm not a Pythonhead, so I don't claim to know how to fix this correctly. However, I've attached a diff for configure.in that sets the framework for the start of fixing this problem. In particular, the diff changes the MM_FIND_*_ID macros to report the ID that matched without resolving names to numbers, and allows the build to proceed if forced --with-{user,group}name options are specified and those IDs don't exist at build time. (The latter case helps autopackaging in systems like NetBSD's pkgsrc, where the IDs may be autocreated *between* the "configure" and "make install" phases.) The things that still need to be done include fixing the main scripts, and the checkperms logic, to cope with either numeric or alphabetic IDs; and possibly adding a runtime configuration of IDs (which really helps if the admin needs to reconfigure or change the mail or Web servers, while avoiding to rebuild Mailman). I openly welcome Python gurus to look into what's *really* needed to fix this.... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=596565&group_id=103 From chuqui@plaidworks.com Sat Aug 17 22:37:54 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Sat, 17 Aug 2002 14:37:54 -0700 Subject: [Mailman-Developers] Anti-spam "killer app"? In-Reply-To: <11426.1029613054@kanga.nu> Message-ID: On 8/17/02 12:37 PM, "J C Lawrence" wrote: > Keep thinking about it. In essence it is a merely a finer grained > scoring system. It doesn't fundamentally change the spam cold war; Actually, I think it does fundamentally change it. You're not just making better guesses at what spammers say. You're effectively building a digital signature of what your REAL mail looks like, and comparing messages to it. The further it deviates from your real mail, the spammier it is. The only two ways for spammers to avoid this are to move to graphics, which can still be whacked on, and to stop using open relays and other things that leave noticable signatures in the headers. It might not catch the smartest spam, but it'll sure catch everything else. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ No! No! Dead girl, OFF the table! -- Shrek From steve@spvi.com Sat Aug 17 22:46:10 2002 From: steve@spvi.com (Steve Spicklemire) Date: Sat, 17 Aug 2002 16:46:10 -0500 Subject: [Mailman-Developers] Another extend.py thing.. (was Re: MemberAdaptor... trouble with API?) In-Reply-To: <8107B0D3-B202-11D6-8920-0050E480B13C@spvi.com> Message-ID: Hi (again) mailman folk.... Another issue I've bumped into when trying to use the 'extend.py' method of modifying the behavior of a mailman (2.1b3) mailing list is pickling the modified list. It seems when a replace the authenticateMember method of the list, as described in my previous mail (and below), mailman has trouble saving any changes to the list: I get tracebacks that end up like this: File "/var/mailman/Mailman/MailList.py", line 487, in Save self.__save(dict) File "/var/mailman/Mailman/MailList.py", line 447, in __save cPickle.dump(dict, fp, 1) cPickle.PicklingError: Can't pickle : it's not found as __main__.new_authenticateMember I think the basic issue is that when I assign the modified method to an instance of a MailList, it get's stored in the instance's __dict__, which during the "Save" method, is then copied and (unsuccessfully) pickled. Do I also need to replace the "Save" method so that it avoids attempting to pickle stuff it shouldn't/can't? (as in all the methods I replaced, including itself?) thanks! -steve Does this approach still really work? Do I really need to subclass MailList On Saturday, August 17, 2002, at 11:58 AM, Steve Spicklemire wrote: > > Hi Mailman folks, > > I've started poking around in mailman, trying to help out some folks, > and I've come across something I'm not sure how to handle. I'd like to > get Mailman working with LDAP, and the first order of business is to > simply allow folks to use their LDAP passwords as an option when > authenticating with Mailman. Here was my first crack at it: > > from checkLDAP import checkLDAP > import string > > def makefunc(oldAuth): > def new_authenticateMember( member, response, oldAuth=oldAuth, > debug=0 ): > > l_r = string.split(member, '@') > > if len(l_r) == 2: > if l_r[1] == 'our.domain': > if checkLDAP( None, member, response): > return response > > return oldAuth( member, response) > > return new_authenticateMember > > def extend(mlist): > oldfunc = mlist.authenticateMember > mlist.authenticateMember = makefunc(oldfunc) > > > I expected that all I needed to do was to replace "authenticateMember' > in extend.py and I would be set. Unfortunately, my code never gets > called! Snooping through the SecurityManager class, I see that instead, > it uses 'getMemberPassword', and never calls 'authenticateMember' at > all! The problem is that we don't have any unencrypted passwords to > "get". So do I need to override "Authenticate" of SecurityManger to > call authenticateMember rather then 'getMemberPassword'? This seems a > little wierd. Would it be better to have SecurityManager call > 'authenticateMember'? Is the cleartext password really required? If it > *is* actually required, couldn't the code just call > 'authenticateMember', and if successful, use 'response', rather than > asking for the cleartext password from the member adaptor? > > thanks, > -steve From noreply@sourceforge.net Mon Aug 19 15:20:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 19 Aug 2002 07:20:41 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-571636 ] Traceback in error log - bounce handling Message-ID: Bugs item #571636, was opened at 2002-06-20 15:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=571636&group_id=103 Category: bounce detection Group: 2.1 beta >Status: Open Resolution: None Priority: 5 Submitted By: Daniel Buchmann (avalon) Assigned to: Nobody/Anonymous (nobody) Summary: Traceback in error log - bounce handling Initial Comment: I got this traceback in my error log: Jun 20 14:58:56 2002 (1992) Traceback (most recent call last): File "/home/mailman/Mailman/Queue/Runner.py", line 105, in __oneloop self.__onefile(msg, msgdata) File "/home/mailman/Mailman/Queue/Runner.py", line 154, in __onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/home/mailman/Mailman/Queue/BounceRunner.py", line 71, in _dispose addrs = BouncerAPI.ScanMessages(mlist, msg) File "/home/mailman/Mailman/Bouncers/BouncerAPI.py", line 60, in ScanMessages addrs = sys.modules[modname].process(msg) File "/home/mailman/Mailman/Bouncers/Microsoft.py", line 35, in process body = StringIO(subpart.get_payload()) TypeError: expected read buffer, list found The following had probably happened: 1. A spam mail was sent to one of our lists. 2. The list tried to send a "waiting for moderator approval" mail to the sender of the spam mail. 3. The "waiting for moderator approval" mail bounced (because the sender address was, of course, invalid). The bounce in (3) gave me the traceback and was moved to qfiles/shunt/. PCK file is attached to this bug report. Let me know if you need the DB file too... :) ---------------------------------------------------------------------- >Comment By: Daniel Buchmann (avalon) Date: 2002-08-19 16:20 Message: Logged In: YES user_id=184577 Well, at least something must have happened, because now the traceback looks different, this is the output of dumpdb on it: Traceback (most recent call last): File "/home/mailman/bin/dumpdb", line 130, in ? msg = main() File "/home/mailman/bin/dumpdb", line 124, in main pp.pprint(m) File "/usr/lib/python2.2/pprint.py", line 110, in pprint self.__stream.write(self.pformat(object) + "\n") File "/usr/lib/python2.2/pprint.py", line 114, in pformat self.__format(object, sio, 0, 0, {}, 0) File "/usr/lib/python2.2/pprint.py", line 136, in __format rep = self.__repr(object, context, level - 1) File "/usr/lib/python2.2/pprint.py", line 200, in __repr self.__depth, level) File "/usr/lib/python2.2/pprint.py", line 287, in _safe_repr rep = `object` File "/home/mailman/Mailman/Message.py", line 41, in __repr__ return self.__str__() File "/home/mailman/pythonlib/email/Message.py", line 89, in __str__ return self.as_string(unixfrom=1) File "/home/mailman/pythonlib/email/Message.py", line 99, in as_string g.flatten(self, unixfrom=unixfrom) File "/home/mailman/pythonlib/email/Generator.py", line 81, in flatten self._write(msg) File "/home/mailman/pythonlib/email/Generator.py", line 109, in _write self._dispatch(msg) File "/home/mailman/pythonlib/email/Generator.py", line 136, in _dispatch meth(msg) File "/home/mailman/pythonlib/email/Generator.py", line 219, in _handle_multipart g.flatten(part, unixfrom=0) File "/home/mailman/pythonlib/email/Generator.py", line 81, in flatten self._write(msg) File "/home/mailman/pythonlib/email/Generator.py", line 109, in _write self._dispatch(msg) File "/home/mailman/pythonlib/email/Generator.py", line 136, in _dispatch meth(msg) File "/home/mailman/pythonlib/email/Generator.py", line 278, in _handle_message g.flatten(msg.get_payload(0), unixfrom=0) File "/home/mailman/pythonlib/email/Message.py", line 167, in get_payload raise TypeError, i TypeError: 0 (Using latest CVS checked out today 19-aug-2002) ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-09 21:26 Message: Logged In: YES user_id=12800 I think we resolved this one, didn't we? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=571636&group_id=103 From noreply@sourceforge.net Mon Aug 19 18:37:31 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 19 Aug 2002 10:37:31 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-597242 ] Dead link on rfc2369 Message-ID: Bugs item #597242, was opened at 2002-08-19 17:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=597242&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: PieterB (pieterb) Assigned to: Nobody/Anonymous (nobody) Summary: Dead link on rfc2369 Initial Comment: The help message: "Should messages from this mailing list include the RFC 2369 (i.e. List-*) headers? Yes is highly recommended. (Details for include_rfc2369_headers)" from General Options contains a link to http://www.faqs.org/rfc/rfc2369.html instead of http://www.faqs.org/rfcs/rfc2369.html (mind the s) Regards, PieterB ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=597242&group_id=103 From Dale@Newfield.org Mon Aug 19 22:15:03 2002 From: Dale@Newfield.org (Dale Newfield) Date: Mon, 19 Aug 2002 17:15:03 -0400 (EDT) Subject: [Mailman-Developers] MemberAdaptor... modifications to API? In-Reply-To: <8107B0D3-B202-11D6-8920-0050E480B13C@spvi.com> Message-ID: MemberOptions. It's great that we can add more, and it's great that OldStyleMemberships is smart enough to store them in a bitfield, but it seems silly to require that all MemberAdaptors do so... ...especially when other database systems that are used to drive Mailman will want to present interfaces for users to let them set these same options (and therefore will want to know the logical names of them, besides just their position in the bitfield). I guess what I'm suggesting is that instead of using this accessor like this: mlist.getMemberOption(addr, mm_cfg.OPTINFO['plain']), it be used like this: mlist.getMemberOption(addr, 'plain'), and inside OldStyleMemberships it does the mm_cfg.OPTINFO[] lookup. That way a Membership adaptor doesn't need to know that option "8" is DisableMime (but if it wants, it can find that the value option 'plain' is found by &'ing it's internal options bitarray with the value 8). I might alternately suggest that the values be bit locations, and the values to & be figured out with (1< Bugs item #597407, was opened at 2002-08-19 21:40 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=597407&group_id=103 Category: (un)subscribing Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: PieterB (pieterb) Assigned to: Nobody/Anonymous (nobody) Summary: Confirmation usability Initial Comment: There are three usability problems with the confirmation of a subscription: a) the URL tends to be more than 80 characters. It might be a good idea too decrease the length of the confirmation-ID and/or identation and thereby increase the usability b) the URL that the user is directed to has a "Subscribe" button on the left and a "Cancel and discard" button on the right. I think the usabilty can be improved by swapping the buttons and by making the submit-button something larger (e.g. "Subscribe to mailinglist X"). See also: http://www.useit.com/alertbox/20000416.html c) if the users have already visited the page, they don't get a message saying the already confirmed their subscription. Regards, PieterB ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=597407&group_id=103 From noreply@sourceforge.net Mon Aug 19 22:43:31 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 19 Aug 2002 14:43:31 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-597242 ] Dead link on rfc2369 Message-ID: Bugs item #597242, was opened at 2002-08-19 17:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=597242&group_id=103 >Category: Web/CGI >Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: PieterB (pieterb) Assigned to: Nobody/Anonymous (nobody) Summary: Dead link on rfc2369 Initial Comment: The help message: "Should messages from this mailing list include the RFC 2369 (i.e. List-*) headers? Yes is highly recommended. (Details for include_rfc2369_headers)" from General Options contains a link to http://www.faqs.org/rfc/rfc2369.html instead of http://www.faqs.org/rfcs/rfc2369.html (mind the s) Regards, PieterB ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=597242&group_id=103 From nb@cisto.com Tue Aug 20 16:31:40 2002 From: nb@cisto.com (Norbert Bollow) Date: Tue, 20 Aug 2002 17:31:40 +0200 Subject: [Mailman-Developers] Potential customer wants to pay for Mailman improvements Message-ID: <200208201531.g7KFVeB24389@quill.local> A potential customer (a non-profit org) wants some Mailman improvements; they're willing to pay for the programming work but would appreciate a discounted rate, as the budget is tight. Specifically, the following features are desired: 1. Extending the web-based archives to a full web interface. - in other words, not just an archives but a website or page where subscribers can read and respond to messages online, as with a bulletin board. (Both the web interface and the archives be closed to members-only.) 2. Improve moderator functions, to support lists which are unmoderated but new members are initially moderated, any members can be put under moderation at any time without their knowing it, members can be unsubscribed and banned. Greetings, Norbert. -- Founder & Steering Committee member of http://gnu.org/projects/dotgnu/ Norbert Bollow, Weidlistr.18, CH-8624 Gruet (near Zurich, Switzerland) Tel +41 1 972 20 59 Fax +41 1 972 20 69 http://norbert.ch List hosting with GNU Mailman on your own domain name http://cisto.com From claw@kanga.nu Tue Aug 20 17:23:08 2002 From: claw@kanga.nu (J C Lawrence) Date: Tue, 20 Aug 2002 09:23:08 -0700 Subject: [Mailman-Developers] Potential customer wants to pay for Mailman improvements In-Reply-To: Message from Norbert Bollow of "Tue, 20 Aug 2002 17:31:40 +0200." <200208201531.g7KFVeB24389@quill.local> References: <200208201531.g7KFVeB24389@quill.local> Message-ID: <11711.1029860588@kanga.nu> On Tue, 20 Aug 2002 17:31:40 +0200 Norbert Bollow wrote: > 1. Extending the web-based archives to a full web interface. - in > other words, not just an archives but a website or page where > subscribers can read and respond to messages online, as with a > bulletin board. (Both the web interface and the archives be closed to > members-only.) 1) Take the MHonArc/PHP-base archive setup I useand extend slightly to support new messages as well as the replies it supports now and you'd pretty well have that. or: 2) Use Mailman 2.1, Zope, CMFMail, ZMailman, and a couple day's worth of work glueing them together and you'd have it all. > 2. Improve moderator functions, to support lists which are unmoderated > but new members are initially moderated, any members can be put under > moderation at any time without their knowing it, members can be > unsubscribed and banned. First blush suggests using an external membership roster via a plugin under Mailman 2.1 should get you this. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From nb@cisto.com Tue Aug 20 18:25:56 2002 From: nb@cisto.com (Norbert Bollow) Date: Tue, 20 Aug 2002 19:25:56 +0200 Subject: [Mailman-Developers] Potential customer wants to pay for Mailman improvements In-Reply-To: <11711.1029860588@kanga.nu> (message from J C Lawrence on Tue, 20 Aug 2002 09:23:08 -0700) References: <200208201531.g7KFVeB24389@quill.local> <11711.1029860588@kanga.nu> Message-ID: <200208201725.g7KHPud25340@quill.local> J C Lawrence wrote: > > 1. Extending the web-based archives to a full web interface. - in > > other words, not just an archives but a website or page where > > subscribers can read and respond to messages online, as with a > > bulletin board. (Both the web interface and the archives be closed to > > members-only.) > > 1) Take the MHonArc/PHP-base archive setup I useand extend slightly to > support new messages as well as the replies it supports now and you'd > pretty well have that. Is your code available under a free license? What would you charge for adapting it to the client's needs? > > 2. Improve moderator functions, to support lists which are unmoderated > > but new members are initially moderated, any members can be put under > > moderation at any time without their knowing it, members can be > > unsubscribed and banned. > > First blush suggests using an external membership roster via a plugin > under Mailman 2.1 should get you this. Again, I'd be interested in a specific quote (from anyone who has some time for hacking on their hands :-) (BTW is this getting off-topic for mailman-developers? Maybe it should be moved to private email? In any case, I'll share the end result with the list.) Greetings, Norbert. -- Founder & Steering Committee member of http://gnu.org/projects/dotgnu/ Norbert Bollow, Weidlistr.18, CH-8624 Gruet (near Zurich, Switzerland) Tel +41 1 972 20 59 Fax +41 1 972 20 69 http://norbert.ch List hosting with GNU Mailman on your own domain name http://cisto.com From claw@kanga.nu Tue Aug 20 18:56:04 2002 From: claw@kanga.nu (J C Lawrence) Date: Tue, 20 Aug 2002 10:56:04 -0700 Subject: [Mailman-Developers] Potential customer wants to pay for Mailman improvements In-Reply-To: Message from Norbert Bollow of "Tue, 20 Aug 2002 19:25:56 +0200." <200208201725.g7KHPud25340@quill.local> References: <200208201531.g7KFVeB24389@quill.local> <11711.1029860588@kanga.nu> <200208201725.g7KHPud25340@quill.local> Message-ID: <13036.1029866164@kanga.nu> On Tue, 20 Aug 2002 19:25:56 +0200 Norbert Bollow wrote: > J C Lawrence wrote: >> 1) Take the MHonArc/PHP-base archive setup I useand extend slightly >> to support new messages as well as the replies it supports now and >> you'd pretty well have that. > Is your code available under a free license? There's (damn near) no code there. All the bits are essentially public domain. The instructions, such as they are, may be found in the Mailman FAQ. > What would you charge for adapting it to the client's needs? Sadly, I have no time. Its one of the perils of working for tiny startups. I am however to give *some* (not much) support via email. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From barry@python.org Tue Aug 20 19:59:34 2002 From: barry@python.org (Barry A. Warsaw) Date: Tue, 20 Aug 2002 14:59:34 -0400 Subject: [Mailman-Developers] Scrubber.py confusion, 2.1b3 References: <06dd01c24373$ff7f5470$0b01a8c0@mjm2> Message-ID: <15714.37270.971979.305247@anthem.wooz.org> >>>>> "DN" == Dale Newfield writes: DN> Noticed that. Great catch--thanks for the quick fix. Let me DN> reiterate my earlier plea (for others to hear, since you've DN> already followed it :-) for the entire codebase: DN> "Spaces! No tabs, please!" +1 For (X)Emacs heads, here's the little bit of elisp I use to clean files up -- when I think about it. -Barry ;; untabify and clean up lines with just whitespace (defun baw-whitespace-normalization (start end) "Like untabify, but also cleans up lines with trailing whitespace." (interactive "r") (save-excursion (save-restriction (untabify start end) (narrow-to-region (point-min) end) (goto-char start) (while (re-search-forward "\\s +$" nil t) (let ((bol (save-excursion (beginning-of-line) (point))) (eol (save-excursion (end-of-line) (point)))) (goto-char (match-beginning 0)) (if (and (bolp) (eq (char-after) ?\ )) (forward-char 1)) (skip-chars-backward " \t" bol) (delete-region (point) eol) )) ))) From barry@zope.com Tue Aug 20 20:55:31 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 20 Aug 2002 15:55:31 -0400 Subject: [Mailman-Developers] Re: External subscriber lists in 2.1 References: <15397.32772.522564.275695@anthem.wooz.org> Message-ID: <15714.40627.779860.984053@anthem.wooz.org> On Sun, 23 Dec 2001, Barry A. Warsaw wrote: > Note that if it was too expensive for getRegularMemberKeys() to return > an in-memory list, it could (if you use Python 2.2) return an iterator > object that implemented things in a more efficient manner, e.g. by > paging through blocks. I believe that any place where we expect a > Python sequence (list) we could probably accept an iterator. DN> Do you know if this is in fact the case? Is this how I should DN> implement it? Nope, never actually tried it. Note that in Python 2.2 you might actually want to try a generator, but again, I've not tried it at all. DN> (While I've hacked in python fairly regularly, I've not done DN> serious Python development since ~1996, so some of these DN> questions will be fairly basic "How's it work in Python2.2?" DN> ones. Of course, this brings up the question of whether or DN> not it's reasonable to require that--don't we currently only DN> require 2.1.3?) Yes. Mailman 2.1 will work with Python 2.1.3 and beyond. The next version will require at least Python 2.2.1. So if you want to also support Py2.1, iterators and generators are out. DN> Below are different ways the results of DN> "get{Regular,Digest}MemberKeys" and "getMembers" are used in DN> various places in the codebase. Will each of them still work DN> if those methods return an iterator instead of a list? (For DN> example, does len(iterator) work?) len(iterator) doesn't work (unfortunately, IMO). So maybe we're screwed because we'd have to call list() on the thing to be able to give it to len(). This actually is the cause of a few recent bugs with email.Iterators.body_line_iterator(). OTOH, if the iterator object we return has an __len__() method, we should be okay. DN> I'm guessing that a good answer might be that we want to add DN> more general-purpose accessor methods in class MemberAdaptor DN> (and have the rest of the codebase use those where DN> appropriate) so that if there's a more efficient way for a DN> specific backend to provide specific data, it is able to do DN> so. I'll include the two methods I propose at the end of this DN> message. You're probably right. in Handlers/CalcRecips.py: # Calculate the regular recipients of the message recips = [mlist.getMemberCPAddress(m) for m in mlist.getRegularMemberKeys() if mlist.getDeliveryStatus(m) == ENABLED] and: recips = mlist.getMemberCPAddresses(mlist.getRegularMemberKeys() + mlist.getDigestMemberKeys()) in Cgi/admin.py: if not mlist.nondigestable and mlist.getRegularMemberKeys(): and: if addr in mlist.getRegularMemberKeys(): and: # If there are more members than allowed by chunksize, then we split the # membership up alphabetically. Otherwise just display them all. chunksz = mlist.admin_member_chunksize all = mlist.getMembers() all.sort(lambda x, y: cmp(x.lower(), y.lower())) then: # BAW: There's got to be a more efficient way of doing this! names = [mlist.getMemberName(s) or '' for s in all] all = [a for n, a in zip(names, all) if cre.search(n) or cre.search(a)] in HTMLFormatter.py: members = self.getRegularMemberKeys() for m in members: if not self.getMemberOption(m, conceal_sub): people.append(m) num_concealed = len(members) - len(people) and: member_len = len(self.getRegularMemberKeys()) | def getNumMembers(self, type, status, options, regexp=None): | """Get the number of members of this mailing list matching type and | status, and optionally matching the regular expression passed in. Would it be good enough to do something like the following: def getMatchingMembers(self, func): """Return a list of members for which function evaluates true. For each member in the database, call func(), passing in the member's subscribed address. If func() returns true, the address is included in the returned list. """ likewise, def getMatchingMembersCount(self, func): """Return a count of the members for which function evaluates true. For each member in the database, call func(), passing in the member's subscribed address. If func() returns true, that member is included in the count. """ This might be a little less efficient than your APIs because of the function call, but it's more flexible. OTOH, it might be too flexible (it'd be hard to run this in a database or translate to selects, etc.), so I'm willing to be persuaded. Also getMatchingMembers() would have to return a list for Py2.1 compatibility, but could return an iterator or generator in Py2.2+. -Barry From barry@python.org Wed Aug 21 00:36:54 2002 From: barry@python.org (Barry A. Warsaw) Date: Tue, 20 Aug 2002 19:36:54 -0400 Subject: [Mailman-Developers] Another extend.py thing.. (was Re: MemberAdaptor... trouble with API?) References: Message-ID: <15714.53910.589150.637318@yyz.zope.com> >>>>> "SS" == Steve Spicklemire writes: SS> I think the basic issue is that when I assign the modified SS> method to an instance of a MailList, it get's stored in the SS> instance's __dict__, which during the "Save" method, is then SS> copied and (unsuccessfully) pickled. Save() has a filter on names starting with underscore, and object that are methods -- type(value) is MethodType. But the way you're creating the new authenticateMethod() is you're creating a function, not a method (it's not in a class). You could try something like the following (untested) instead, or we could add another test in the attribute filter in Save() to ignore functions. Side note: all this gets much easier in Python 2.2, because I think properties make our lives much nice. class NewAuthenticator: def __init__(self, oldfunc): self._oldfunc = oldfunc def authenticateMember(member, response): l_r = member.split('@') if len(l_r) == 2: if l_r[1] == 'our.domain': if checkLDAP(None, member, response): return response return self._oldfunc(member, response) def extend(mlist): authenticator = NewAuthenticator(mlist.authenticateMember) mlist.authenticateMember = authenticator.authenticateMember HTH, -Barry From barry@python.org Wed Aug 21 00:14:10 2002 From: barry@python.org (Barry A. Warsaw) Date: Tue, 20 Aug 2002 19:14:10 -0400 Subject: [Mailman-Developers] SQL MemberAdaptor implementation? References: Message-ID: <15714.52546.412600.418957@yyz.zope.com> >>>>> "DN" == Dale Newfield writes: DN> OK--I think I've found the time to build this and contribute DN> it to the cause! Very cool! DN> Just want to make sure that none already exists... Has anyone DN> built such a beast? Not that I know of. DN> Are there *any* other known implementations to use as DN> references besides OldStyleMemberships.py? Not that I know of. DN> I'm also wondering about dynamic groups... (and think that I DN> should be able to implement this using some combination of the DN> "virtual" list and the "extended" list.) That's definitely the intent. No one's tried it, so you're bushwhacking here, but I'll try to accomodate for MM2.1 if it isn't too disruptive. DN> In the system that I'll be integrating this there are several DN> types of entities, and a dynamic number of instances of each. DN> I'd like to be able to have each instance of each entity have DN> it's own (probably virtual) mailing list. The first idea is DN> to create one concrete mailman list (with DN> settings/templates/etc.) for each type, and have each instance DN> automagically exist with distinct membership (as pulled from DN> the SQL DB). DN> As a more concrete example, I might want to set up a "class" DN> mailing list and a "project" mailing list, but I really want DN> it to appear that there are many mailing lists all of the form DN> "class+phys101@domain.edu", "class+ee382@domain.edu", DN> "project+planQ@dom.ain", "project+noFNORDs@dom.ain", etc. DN> (The plus'es are a straw-man, it could be deliniated some DN> other way--the key is that I want them each to have a distinct DN> email address so that people can respond to the group if DN> desired--if this were announce-only I could simply use the DN> virtual list and .inject() method.) Sounds good so far. DN> Any suggestions as to how to go about this? I'm guessing I'll DN> make an SQL DB framework that is only mostly concrete. Each DN> list would need an extend.py that informs that framework about DN> the schema through which to find various pieces of information DN> in the DB. Any suggestions as to how that schema should be DN> specified? I'm out of my league when it comes to SQL hacking, so I can't help much there, but there are some implicit assumptions in MemberAdaptor that you need need to keep in mind. I think most of these are described in the MemberAdaptor.py docstring (re-reading that now...). The bit about "member keys" and lce's may be inaccurate. I think in general the assumption is that an lce is the key to the member's information, and I doubt you can use something more opaque. But you could try it and we could fix breakages. DN> This brings up something about which I'm not so clear--can DN> different lists use different MemberAdaptors? Yes, definitely. The do now . If you wanted to federate the user databases for several lists, you'd have to coordinate that through the concrete adaptor, or backend. DN> Can I have a single mailman instance running some lists with DN> OldStyle and other lists using my new fangled system? I believe so. What your extend.py needs to do is set self._memberadaptor to the instance of your SQL adaptor. All relevant calls will be made through that object. The tricky part, and the part I'm less confident about, is that you need to coordinate transaction boundaries through MailList.Load() and MailList.Save(). Save() is essentially "commit", but we never Save() if there's nothing to do, or if we don't have the list lock. -Barry From noreply@sourceforge.net Wed Aug 21 00:43:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Aug 2002 16:43:46 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-598007 ] 2.1b3 encoding of Subject error Message-ID: Bugs item #598007, was opened at 2002-08-20 20:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=598007&group_id=103 Category: mail delivery Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Rodolfo Pilas (alkalino) Assigned to: Nobody/Anonymous (nobody) Summary: 2.1b3 encoding of Subject error Initial Comment: Release of 2.1b3 says: 'prefixes is controlled by a new list option encode_ascii_prefixes' but I has changed to 'Always' and the subject are now ok (in Spanish) but the option strip the white spaces, by this way: Original subject: ahora no modificás el título que me tenes podrídiño Result subject: [list] ahora nomodificáseltítuloque me tenespodrídiño ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=598007&group_id=103 From barry@python.org Wed Aug 21 00:44:12 2002 From: barry@python.org (Barry A. Warsaw) Date: Tue, 20 Aug 2002 19:44:12 -0400 Subject: [Mailman-Developers] MemberAdaptor... modifications to API? References: Message-ID: <15714.54348.730519.621979@yyz.zope.com> >>>>> "DN" == Dale Newfield writes: DN> MemberOptions. It's great that we can add more, and it's DN> great that OldStyleMemberships is smart enough to store them DN> in a bitfield, but it seems silly to require that all DN> MemberAdaptors do so... DN> ...especially when other database systems that are used to DN> drive Mailman will want to present interfaces for users to let DN> them set these same options (and therefore will want to know DN> the logical names of them, besides just their position in the DN> bitfield). DN> I guess what I'm suggesting is that instead of using this DN> accessor like this: mlist.getMemberOption(addr, DN> mm_cfg.OPTINFO['plain']), it be used like this: DN> mlist.getMemberOption(addr, 'plain'), and inside DN> OldStyleMemberships it does the mm_cfg.OPTINFO[] lookup. That DN> way a Membership adaptor doesn't need to know that option "8" DN> is DisableMime (but if it wants, it can find that the value DN> option 'plain' is found by &'ing it's internal options DN> bitarray with the value 8). The problem that I have with this approach is that it's much easier to let a typo like mm_cfg.OPTINFO['plian'] slip through than to use a symbolic constant. E.g. tools like Pychecker can verify that the constant exists, but can't really do much with the string. DN> I might alternately suggest that the values be bit locations, DN> and the values to & be figured out with (1< that at least the "option numbers" be ordinal rather than DN> powers of two. That is more much less important (more a DN> stylistic thing), though. BTW, if I'm not mistaken, here's a DN> typo in the comments in Defaults.py.in: "DEFAULT_LIST_OPTIONS" DN> should be "DEFAULT_NEW_MEMBER_OPTIONS" That's not a bad alternative, and it preserves my desire for constants, but I'm not sure it helps you much though. You still need to know what values correspond to which options. BTW, Thanks for the typo report. DN> What's the process for offering patches for things like this DN> and the other interface changes I was suggesting Friday? DN> Anyone have a chance to evaluate whether those made sense? DN> Would changes like those be too dangerous this close to DN> release? (Sorry it's taken me so long to actually get started DN> helping out! :-) Something like this is probably going to be too late for MM2.1. The best thing to do is to work out the patches and upload them to SourceForge. At least there, they won't get lost in an inbox, and we can re-examine them when MM2.1 final is released. -Barry From barry@python.org Wed Aug 21 00:29:02 2002 From: barry@python.org (Barry A. Warsaw) Date: Tue, 20 Aug 2002 19:29:02 -0400 Subject: [Mailman-Developers] MemberAdaptor... trouble with API? References: <8107B0D3-B202-11D6-8920-0050E480B13C@spvi.com> Message-ID: <15714.53438.761775.918433@yyz.zope.com> >>>>> "SS" == Steve Spicklemire writes: SS> I've started poking around in mailman, trying to help out some SS> folks, and I've come across something I'm not sure how to SS> handle. I'd like to get Mailman working with LDAP, and the SS> first order of business is to simply allow folks to use their SS> LDAP passwords as an option when authenticating with SS> Mailman. Here was my first crack at it: [...code...] SS> I expected that all I needed to do was to replace SS> "authenticateMember' in extend.py and I would be SS> set. Unfortunately, my code never gets called! Snooping SS> through the SecurityManager class, I see that instead, it uses SS> 'getMemberPassword', and never calls 'authenticateMember' at SS> all! Worse than that, a grep reveals that authenticateMember() isn't called /anywhere/. One of the reasons why SecurityManager is written the way it is, is because we want to be able to use the password as part of the input into the cookie hashcode. SS> The problem is that we don't have any unencrypted SS> passwords to "get". Do you have an encrypted password, or any other secret only associated with the member? SS> So do I need to override "Authenticate" of SS> SecurityManger to call authenticateMember rather then SS> 'getMemberPassword'? This seems a little wierd. Would it be SS> better to have SecurityManager call 'authenticateMember'? There's a lot of code sharing going on here, between the part that decodes the cookie and verifies the cookie or cleartext password input. You could try the following patch, untested, to see if this helps. I'll try it too when I get a chance. SS> Is SS> the cleartext password really required? If it *is* actually SS> required, couldn't the code just call 'authenticateMember', SS> and if successful, use 'response', rather than asking for the SS> cleartext password from the member adaptor? Hmm, possibly! MakeCookie() would have to change too, and WebAuthenticate() would have to pass it teh response, which it would use as the secret instead of what AuthContextInfo() returns. You'd still need to call AuthContextInfo() to build the key though. You bring up some good points. -Barry -------------------- snip snip -------------------- Index: SecurityManager.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/SecurityManager.py,v retrieving revision 2.18 diff -u -r2.18 SecurityManager.py --- SecurityManager.py 24 Jul 2002 14:24:45 -0000 2.18 +++ SecurityManager.py 20 Aug 2002 23:25:53 -0000 @@ -191,9 +191,7 @@ if secret and sha.new(response).hexdigest() == secret: return ac elif ac == mm_cfg.AuthUser: - # The user's passwords are kept in plain text - key, secret = self.AuthContextInfo(ac, user) - if secret and response == secret: + if self.authenticateMember(user, response): return ac else: # What is this context??? From noreply@sourceforge.net Wed Aug 21 00:55:30 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Aug 2002 16:55:30 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-598010 ] Bad Pickle? Message-ID: Bugs item #598010, was opened at 2002-08-21 01:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=598010&group_id=103 Category: None Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Peer Heinlein (pheinlein) Assigned to: Nobody/Anonymous (nobody) Summary: Bad Pickle? Initial Comment: Some days ago my server startet forgetting some imcoming mails to some special lists. SInce then I receive the followin error-notes on my Server. Could somebody explain me what`s going on very fast? Some of my important mailinglists aren`t usable any more. File "/usr/lib/mailman/bin/qrunner", line 266, in ? main() File "/usr/lib/mailman/bin/qrunner", line 226, in main qrunner.run() File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 59, in run filecnt = self._oneloop() File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 105, in _oneloop self._onefile(msg, msgdata) File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 154, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/usr/lib/mailman/Mailman/Queue/IncomingRunner.py", line 129, in _dispose status = self._dopipeline(mlist, msg, msgdata, pipeline) File "/usr/lib/mailman/Mailman/Queue/IncomingRunner.py", line 152, in _dopipeline sys.modules[modname].process(mlist, msg, msgdata) File "/usr/lib/mailman/Mailman/Handlers/Moderate.py", line 101, in process Hold.hold_for_approval(mlist, msg, msgdata, Hold.ModeratedPost) File "/usr/lib/mailman/Mailman/Handlers/Hold.py", line 219, in hold_for_approval cookie = Pending.new(Pending.HELD_MESSAGE, id) File "/usr/lib/mailman/Mailman/Pending.py", line 64, in new db = _load() File "/usr/lib/mailman/Mailman/Pending.py", line 121, in _load return cPickle.load(fp) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=598010&group_id=103 From noreply@sourceforge.net Wed Aug 21 03:47:21 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 20 Aug 2002 19:47:21 -0700 Subject: [Mailman-Developers] [ mailman-Feature Requests-598051 ] Subscribe page needs Full Name blank Message-ID: Feature Requests item #598051, was opened at 2002-08-20 19:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=598051&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Dadgar (mdadgar) Assigned to: Nobody/Anonymous (nobody) Summary: Subscribe page needs Full Name blank Initial Comment: The Subscribe webpage needs a blank for Full Name to go along with Email Address. This full name should show up along with the other info in the Admin page when you go to approve a subscribe request. This allows the list owner to screen subscribe requests to closed lists, as it's rare these days to be able to tell who the requester is from their email address. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=598051&group_id=103 From noreply@sourceforge.net Wed Aug 21 19:01:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Aug 2002 11:01:20 -0700 Subject: [Mailman-Developers] [ mailman-Patches-598381 ] list_members outputs username Message-ID: Patches item #598381, was opened at 2002-08-21 18:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=598381&group_id=103 Category: command line scripts Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: William Ahern (wahern) Assigned to: Nobody/Anonymous (nobody) Summary: list_members outputs username Initial Comment: output e-mail addresses as "Full Name" or is no username field is present Should probably be made a command-line option for backward compatibility. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=598381&group_id=103 From noreply@sourceforge.net Wed Aug 21 19:39:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Aug 2002 11:39:35 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-214101 ] footer and MIME (and Jitterbug-bug) (PR#76) Message-ID: Bugs item #214101, was opened at 2000-09-11 13:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=214101&group_id=103 Category: None Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: footer and MIME (and Jitterbug-bug) (PR#76) Initial Comment: Jitterbug-Id: 76 Submitted-By: Bernhard Reiter Date: Mon, 5 Jul 1999 03:05:04 -0500 Version: None OS: None --QTprm0S8XgL7H0Dt Content-Type: multipart/mixed; boundary=azLHFNyN32YCQGCU --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi folks, this is my fourth attempt to report this Mailman bug. Jitterbug gave me: | the system encountered a fatal error | After command:=20 | Received:=20 | The last error code was: Connection refused=20 Original Jitterbug message attached. Hope this is the correct forum. You should mention the bug-reporting address on the web. Oh, an BTW the link to mailman on http://www.python.org/mailman-bugs/ is broken. "http://" is missing... (and no feedback email address for that...) Bernhard --=20 Research Assistant, Geog Dept UM-Milwaukee, USA. (www.uwm.edu/~bernhard) Association for a Free Informational Infrastructure (ffii.org) --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=xx Content-Transfer-Encoding: quoted-printable When adding a footer to mime messages, mailman acts dumb. Consider a common PGP/MIME signature, then mailman will add the footer behind the last contents mark and a good MUA will not display the text from= there. (Tested with mutt 0.95.6i.) Possible solutions: add another MIME part with the footer or add a header w= ith the information X-Footer (seems a bit silly to me, though ;) ) Encapsulate the first mime parts as a seperate mime part message/rfc822. (Will be difficult for most MUA to decode and might not really help.) eGroups mailsystem does it totally wrong and adds the footer to the first contents. This breaks the PGP signature, of course and I would consid= er it a serious bug. Bernhard (ps.: this is my third try to report this error. Mail to the user list did'= t go=20 through without bouncing and I had serveral Jitterbug failures. Webmaster a= lso never answered.) --azLHFNyN32YCQGCU-- --QTprm0S8XgL7H0Dt Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBN4BnLxFKNN1LD7H9AQEtygP+Ow9jaSD3GyMtdMYbFbB/hV7KzRw+dEyZ 0sE6pIQUMmllpsMVWuAHcwgGmfvgKf+/WV+Rpd4P63bRWRtZrj8SYrl2iMKOW8Op 2UGqjIWAx+Rh4Io4V+EK52h7xxKS2maPDKYrePDL/ifE0cZIDQfEzMyGpwXu7pMN k04MohBKgcU= =D293 -----END PGP SIGNATURE----- --QTprm0S8XgL7H0Dt-- ==================================================================== Audit trail: Tue Jul 13 11:05:44 1999 bwarsaw moved from incoming to open ---------------------------------------------------------------------- Comment By: Len Lattanzi (zardoz) Date: 2002-08-21 11:39 Message: Logged In: YES user_id=1585 Why is this closed? It still occurs with non-DIGEST MIME messages in 2.0.13 ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2000-09-15 10:18 Message: Mailman 2.0 still has a related bug; the regular footer and header are tacked onto all digests, even though digests have the digest footer and header as attachements. This has been fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=214101&group_id=103 From noreply@sourceforge.net Thu Aug 22 04:33:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Aug 2002 20:33:42 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-214101 ] footer and MIME (and Jitterbug-bug) (PR#76) Message-ID: Bugs item #214101, was opened at 2000-09-11 16:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=214101&group_id=103 Category: None Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: footer and MIME (and Jitterbug-bug) (PR#76) Initial Comment: Jitterbug-Id: 76 Submitted-By: Bernhard Reiter Date: Mon, 5 Jul 1999 03:05:04 -0500 Version: None OS: None --QTprm0S8XgL7H0Dt Content-Type: multipart/mixed; boundary=azLHFNyN32YCQGCU --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi folks, this is my fourth attempt to report this Mailman bug. Jitterbug gave me: | the system encountered a fatal error | After command:=20 | Received:=20 | The last error code was: Connection refused=20 Original Jitterbug message attached. Hope this is the correct forum. You should mention the bug-reporting address on the web. Oh, an BTW the link to mailman on http://www.python.org/mailman-bugs/ is broken. "http://" is missing... (and no feedback email address for that...) Bernhard --=20 Research Assistant, Geog Dept UM-Milwaukee, USA. (www.uwm.edu/~bernhard) Association for a Free Informational Infrastructure (ffii.org) --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=xx Content-Transfer-Encoding: quoted-printable When adding a footer to mime messages, mailman acts dumb. Consider a common PGP/MIME signature, then mailman will add the footer behind the last contents mark and a good MUA will not display the text from= there. (Tested with mutt 0.95.6i.) Possible solutions: add another MIME part with the footer or add a header w= ith the information X-Footer (seems a bit silly to me, though ;) ) Encapsulate the first mime parts as a seperate mime part message/rfc822. (Will be difficult for most MUA to decode and might not really help.) eGroups mailsystem does it totally wrong and adds the footer to the first contents. This breaks the PGP signature, of course and I would consid= er it a serious bug. Bernhard (ps.: this is my third try to report this error. Mail to the user list did'= t go=20 through without bouncing and I had serveral Jitterbug failures. Webmaster a= lso never answered.) --azLHFNyN32YCQGCU-- --QTprm0S8XgL7H0Dt Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBN4BnLxFKNN1LD7H9AQEtygP+Ow9jaSD3GyMtdMYbFbB/hV7KzRw+dEyZ 0sE6pIQUMmllpsMVWuAHcwgGmfvgKf+/WV+Rpd4P63bRWRtZrj8SYrl2iMKOW8Op 2UGqjIWAx+Rh4Io4V+EK52h7xxKS2maPDKYrePDL/ifE0cZIDQfEzMyGpwXu7pMN k04MohBKgcU= =D293 -----END PGP SIGNATURE----- --QTprm0S8XgL7H0Dt-- ==================================================================== Audit trail: Tue Jul 13 11:05:44 1999 bwarsaw moved from incoming to open ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-21 23:33 Message: Logged In: YES user_id=12800 It's closed (now ) because MM2.0.x is in critical -- read security -- bug fix mode only. Header and footer attachment is done in a comletely MIME-safe way in Mailman 2.1, which is in beta testing and will be released RSN. ---------------------------------------------------------------------- Comment By: Len Lattanzi (zardoz) Date: 2002-08-21 14:39 Message: Logged In: YES user_id=1585 Why is this closed? It still occurs with non-DIGEST MIME messages in 2.0.13 ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2000-09-15 13:18 Message: Mailman 2.0 still has a related bug; the regular footer and header are tacked onto all digests, even though digests have the digest footer and header as attachements. This has been fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=214101&group_id=103 From noreply@sourceforge.net Thu Aug 22 04:49:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Aug 2002 20:49:24 -0700 Subject: [Mailman-Developers] [ mailman-Patches-598381 ] list_members outputs username Message-ID: Patches item #598381, was opened at 2002-08-21 14:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=598381&group_id=103 Category: command line scripts Group: Mailman 2.1 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: William Ahern (wahern) Assigned to: Nobody/Anonymous (nobody) Summary: list_members outputs username Initial Comment: output e-mail addresses as "Full Name" or is no username field is present Should probably be made a command-line option for backward compatibility. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-21 23:49 Message: Logged In: YES user_id=12800 Done, thanks. I implemented it slightly differently since email.Utils.formataddr() combines the two in an RFC 2822 compliant way, and it seems best to use this for consistency. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=598381&group_id=103 From noreply@sourceforge.net Thu Aug 22 06:38:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Aug 2002 22:38:20 -0700 Subject: [Mailman-Developers] [ mailman-Feature Requests-598051 ] Subscribe page needs Full Name blank Message-ID: Feature Requests item #598051, was opened at 2002-08-20 22:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=598051&group_id=103 Category: None Group: None >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Mark Dadgar (mdadgar) Assigned to: Nobody/Anonymous (nobody) Summary: Subscribe page needs Full Name blank Initial Comment: The Subscribe webpage needs a blank for Full Name to go along with Email Address. This full name should show up along with the other info in the Admin page when you go to approve a subscribe request. This allows the list owner to screen subscribe requests to closed lists, as it's rare these days to be able to tell who the requester is from their email address. Thanks. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-22 01:38 Message: Logged In: YES user_id=12800 Have you seen recent Mailman 2.1 betas? All this is in there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=598051&group_id=103 From noreply@sourceforge.net Thu Aug 22 06:42:37 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 21 Aug 2002 22:42:37 -0700 Subject: [Mailman-Developers] [ mailman-Feature Requests-598051 ] Subscribe page needs Full Name blank Message-ID: Feature Requests item #598051, was opened at 2002-08-20 19:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=598051&group_id=103 Category: None Group: None Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Mark Dadgar (mdadgar) Assigned to: Nobody/Anonymous (nobody) Summary: Subscribe page needs Full Name blank Initial Comment: The Subscribe webpage needs a blank for Full Name to go along with Email Address. This full name should show up along with the other info in the Admin page when you go to approve a subscribe request. This allows the list owner to screen subscribe requests to closed lists, as it's rare these days to be able to tell who the requester is from their email address. Thanks. ---------------------------------------------------------------------- >Comment By: Mark Dadgar (mdadgar) Date: 2002-08-21 22:42 Message: Logged In: YES user_id=598228 Didn't realize it was in the 2.1 feature set. Excellent. Thanks for the heads-up. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-21 22:38 Message: Logged In: YES user_id=12800 Have you seen recent Mailman 2.1 betas? All this is in there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=598051&group_id=103 From inet-list@vo.cnchost.com Sat Aug 17 23:33:44 2002 From: inet-list@vo.cnchost.com (JC Dill) Date: Sat, 17 Aug 2002 15:33:44 -0700 Subject: [Mailman-Developers] Anti-spam "killer app"? In-Reply-To: References: <11426.1029613054@kanga.nu> Message-ID: <5.0.0.25.2.20020817152554.03c04eb0@pop3.vo.cnchost.com> On 02:37 PM 8/17/02, Chuq Von Rospach wrote: >On 8/17/02 12:37 PM, "J C Lawrence" wrote: > >> Keep thinking about it. In essence it is a merely a finer grained >> scoring system. It doesn't fundamentally change the spam cold war; > >Actually, I think it does fundamentally change it. You're not just making >better guesses at what spammers say. You're effectively building a digital >signature of what your REAL mail looks like, and comparing messages to it. >The further it deviates from your real mail, the spammier it is. > >The only two ways for spammers to avoid this are to move to graphics Even then, it will still be easily sussed out. I'm on some hobby lists where people occasionally send short posts with an image attached. The small amount of text in the subject line and body, together with the headers of these desired messages, would all be very different from a similar spam message with little or no subject or body text and an attached image. I think the next big spam trick will be forged email to ObMailing lists. Why bother subscribing when you can suss out the address of a legit subscriber, forge your "from" header, and forge your mail server IP to claim to be that of that poster's normal mail server? As more and more ObMailing lists are archived on the web in a form viewable by anyone, this becomes a bigger and bigger problem. Email munging of web archives is often insufficient, email addresses are left unmunged in the body, or are often easily guessed from the remaining bits of the from header. jc From Daniel.Buchmann@bibsys.no Thu Aug 22 15:13:57 2002 From: Daniel.Buchmann@bibsys.no (Daniel Buchmann) Date: 22 Aug 2002 16:13:57 +0200 Subject: [Mailman-Developers] Anti-spam "killer app"? In-Reply-To: References: Message-ID: <1030025638.2258.44.camel@fornax.bibsys.no> ---------------------- multipart/signed attachment While reading the article by Paul Graham, something came to my mind; what will happen if the user is not english? Let's say 99.99% of all spam is in english (which is my experience), and my mother tongue is norwegian. ;) Let's also say that I usually never receive mails written in english. The Bayesian approach would then put all english words in a bad-words list (except words found in headers), and all norwegian words in a good-words list, wouldn't it? 1. What happens the day I join an english mailing list, or receive a mail written in english? 2. What happens if I receive a mail written in norwegian but containing a few english words, i.e. quoting someone? I'd say it would discard mail #1, but let through #2... What do you think..? :) On Sat, 2002-08-17 at 23:37, Chuq Von Rospach wrote: > On 8/17/02 12:37 PM, "J C Lawrence" wrote: >=20 > > Keep thinking about it. In essence it is a merely a finer grained > > scoring system. It doesn't fundamentally change the spam cold war; >=20 > Actually, I think it does fundamentally change it. You're not just making > better guesses at what spammers say. You're effectively building a digita= l > signature of what your REAL mail looks like, and comparing messages to it= . > The further it deviates from your real mail, the spammier it is. >=20 > The only two ways for spammers to avoid this are to move to graphics, whi= ch > can still be whacked on, and to stop using open relays and other things t= hat > leave noticable signatures in the headers. >=20 > It might not catch the smartest spam, but it'll sure catch everything els= e. ---------------------- multipart/signed attachment A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail-21/mailman-developers/attachments/de436e9a/attachment.bin ---------------------- multipart/signed attachment-- From dgc@uchicago.edu Thu Aug 22 15:44:32 2002 From: dgc@uchicago.edu (David Champion) Date: Thu, 22 Aug 2002 09:44:32 -0500 Subject: [Mailman-Developers] Re: Anti-spam "killer app"? In-Reply-To: <1030025638.2258.44.camel@fornax.bibsys.no> References: <1030025638.2258.44.camel@fornax.bibsys.no> Message-ID: <20020822144432.GM2400@dust.uchicago.edu> * On 2002.08.22, in <1030025638.2258.44.camel@fornax.bibsys.no>, * "Daniel Buchmann" wrote: > > Let's say 99.99% of all spam is in english (which is my experience), and > my mother tongue is norwegian. ;) Funny: my experience is that 60% of all spam is in Chinese, Spanish, or Turkish. :) > Let's also say that I usually never receive mails written in english. > > The Bayesian approach would then put all english words in a bad-words > list (except words found in headers), and all norwegian words in a > good-words list, wouldn't it? Not quite. It would put the limited subset of English words which appear in spam into a bad-words list. This isn't nit-picking: as soon as you save one legitimate English message to your good list (copy one from Usenet if you need to), the stats are weighted. Add another legit one, and it's even smarter. If you *never* receive legitimate English mail, this is not a problem to you: all English truly is spam. But if you *sometimes* receive English mail, add them all to your good list for a short while, and you'll find that the filter figures it out. > 1. What happens the day I join an english mailing list, or receive a > mail written in english? It *might* be marked as spam; it depends significantly on the headers, and on any words shared between Norwegian and English. > 2. What happens if I receive a mail written in norwegian but containing > a few english words, i.e. quoting someone? Nothing special. The volume of good Norwegian will make any English in your message matter little. However, it's not necessarily likely that these few English words will even be in your bad-words list. > I'd say it would discard mail #1, but let through #2... > What do you think..? The moral is: don't activate a Bayesian filter and start filing all its discoveries to the bitbucket. Watch it for a while, and when you're comfortable, start saving its finds to a circular file. Check this file occasionally, and file any false positives to your good-words list. Also, meanwhile, file any missed spam to your bad-words list. Why I say these things: I've been using my home-brewed system based on this article for a few days now, and it's pretty sharp. It's missed a few, but it's learning quickly. It initially had some false positives: since I receive postmaster and abuse mail at my domain, forwarded spam got flagged. But it's since learned to ignore those, too, while flagging the actual spam messages contained in those messages when they arrive separately. And so far, it only 94 spams, 99 non-spams in the database, which together provide 21,000 text tokens I have data on. Graham's article discusses having 4000 of each, IIRC. I expect even better results as I approach that, but I'm letting it happen naturally at this point. (I'm certain that I could get the same results with fewer messages; I started out by filing in a big pile of known messages, and I've been fine-tuning since. There's lots of overlap in the statistical value provided by these messages. At some point I'll clean out my database completely and begin again, tabula rasa, to see how few messages it takes to give me satisfactory results. But I probably won't try this until I'm more or less done gnashing the software.) In a mailing list server, you'd want to set up for identified spam to be redirected for moderator approval, rather than flinging it away. Once your databases are fleshed out pretty well, you might be able to start rejecting messages above some very high rating (say, 98%) and subnmitting for approval those above something lower (say, 90%). -- -D. We establised a fine coffee. What everybody can say Sun Project, APC/UCCO TASTY! It's fresh, so-mild, with some special coffee's University of Chicago bitter and sourtaste. "LET'S HAVE SUCH A COFFEE! NOW!" dgc@uchicago.edu Please love CAFE MIAMI. Many thanks. From noreply@sourceforge.net Thu Aug 22 16:52:51 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 22 Aug 2002 08:52:51 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-598844 ] BASE64 attachments barfing Message-ID: Bugs item #598844, was opened at 2002-08-22 15:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=598844&group_id=103 Category: Pipermail Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Patrick Finnerty (finnertyp) Assigned to: Nobody/Anonymous (nobody) Summary: BASE64 attachments barfing Initial Comment: When testing MIME attachments I get the following error which occurs using arch to convert a mailbox or when posting to the archive: Pickling archive state into /usr/local/mailman/archives/private/opsarchtest/pipermail.pck Traceback (most recent call last): File "bin/arch", line 160, in ? main() File "bin/arch", line 148, in main archiver.processUnixMailbox(fp, Article, start, end) File "/usr/local/mailman/Mailman/Archiver/pipermail.py", line 545, in processUnixMailbox m = mbox.next() File "/usr/local/lib/python2.2/mailbox.py", line 34, in next return self.factory(_Subfile(self.fp, start, stop)) File "/usr/local/mailman/Mailman/Mailbox.py", line 69, in scrubber return mailbox.scrub(msg) File "/usr/local/mailman/Mailman/Mailbox.py", line 89, in scrub return self._scrubber(self._mlist, msg) File "/usr/local/mailman/Mailman/Handlers/Scrubber.py", line 114, in process url = save_attachment(mlist, part, filter_html=0) File "/usr/local/mailman/Mailman/Handlers/Scrubber.py", line 217, in save_attachment decodedpayload = msg.get_payload(decode=1) File "/usr/local/mailman/pythonlib/email/Message.py", line 177, in get_payload return Utils._bdecode(payload) File "/usr/local/mailman/pythonlib/email/Utils.py", line 71, in _bdecode value = base64.decodestring(s) File "/usr/local/lib/python2.2/base64.py", line 44, in decodestring return binascii.a2b_base64(s) binascii.Error: Incorrect padding I've narrowed this down to HTML attachments that include tables. I've attached a mbox that will give this error when used with arch. This only happens when base64 is used. I've also found that even when messages with HTML attachments are archived, clicking on the attachment doesn't display the page but the source instead. Or in some cases it can be garbage. I can supply more info on this if you wish. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=598844&group_id=103 From noreply@sourceforge.net Thu Aug 22 16:58:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 22 Aug 2002 08:58:59 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-598844 ] BASE64 attachments barfing Message-ID: Bugs item #598844, was opened at 2002-08-22 15:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=598844&group_id=103 Category: Pipermail Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Patrick Finnerty (finnertyp) Assigned to: Nobody/Anonymous (nobody) Summary: BASE64 attachments barfing Initial Comment: When testing MIME attachments I get the following error which occurs using arch to convert a mailbox or when posting to the archive: Pickling archive state into /usr/local/mailman/archives/private/opsarchtest/pipermail.pck Traceback (most recent call last): File "bin/arch", line 160, in ? main() File "bin/arch", line 148, in main archiver.processUnixMailbox(fp, Article, start, end) File "/usr/local/mailman/Mailman/Archiver/pipermail.py", line 545, in processUnixMailbox m = mbox.next() File "/usr/local/lib/python2.2/mailbox.py", line 34, in next return self.factory(_Subfile(self.fp, start, stop)) File "/usr/local/mailman/Mailman/Mailbox.py", line 69, in scrubber return mailbox.scrub(msg) File "/usr/local/mailman/Mailman/Mailbox.py", line 89, in scrub return self._scrubber(self._mlist, msg) File "/usr/local/mailman/Mailman/Handlers/Scrubber.py", line 114, in process url = save_attachment(mlist, part, filter_html=0) File "/usr/local/mailman/Mailman/Handlers/Scrubber.py", line 217, in save_attachment decodedpayload = msg.get_payload(decode=1) File "/usr/local/mailman/pythonlib/email/Message.py", line 177, in get_payload return Utils._bdecode(payload) File "/usr/local/mailman/pythonlib/email/Utils.py", line 71, in _bdecode value = base64.decodestring(s) File "/usr/local/lib/python2.2/base64.py", line 44, in decodestring return binascii.a2b_base64(s) binascii.Error: Incorrect padding I've narrowed this down to HTML attachments that include tables. I've attached a mbox that will give this error when used with arch. This only happens when base64 is used. I've also found that even when messages with HTML attachments are archived, clicking on the attachment doesn't display the page but the source instead. Or in some cases it can be garbage. I can supply more info on this if you wish. ---------------------------------------------------------------------- >Comment By: Patrick Finnerty (finnertyp) Date: 2002-08-22 15:58 Message: Logged In: YES user_id=594846 Whoops. Attached the html file which was used as attachment instead of the mbox file.... ...which I'm gonna upload now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=598844&group_id=103 From bob@nleaudio.com Thu Aug 22 17:42:26 2002 From: bob@nleaudio.com (Bob Puff@NLE) Date: Thu, 22 Aug 2002 12:42:26 -0400 Subject: [Mailman-Developers] Re: Anti-spam "killer app"? References: <1030025638.2258.44.camel@fornax.bibsys.no> <20020822144432.GM2400@dust.uchicago.edu> Message-ID: <3D651472.5B1FB99D@nleaudio.com> My biggest question to all this is: how do you add to the good list, and the bad list? It seems like you need to moderate each message, at least in the beginning. How would this be implemented for standard mail clients? Would you forward each good and bad message to special addresses? It would seem this would take more time than simply deleting the spam. Bob From dgc@uchicago.edu Thu Aug 22 17:53:03 2002 From: dgc@uchicago.edu (David Champion) Date: Thu, 22 Aug 2002 11:53:03 -0500 Subject: [Mailman-Developers] Re: Anti-spam "killer app"? In-Reply-To: <3D651472.5B1FB99D@nleaudio.com> References: <1030025638.2258.44.camel@fornax.bibsys.no> <20020822144432.GM2400@dust.uchicago.edu> <3D651472.5B1FB99D@nleaudio.com> Message-ID: <20020822165303.GU2400@dust.uchicago.edu> * On 2002.08.22, in <3D651472.5B1FB99D@nleaudio.com>, * "Bob Puff@NLE" wrote: > My biggest question to all this is: how do you add to the good list, > and the bad list? It seems like you need to moderate each message, at > least in the beginning. Yes, but I find it doesn't take any longer than than deletion. I only need to react when the filter misidentifies something. I can easily bind a macro keystroke to some sequence of feeding it into my database and deleting it from my mailbox. It's not really any different from any other spam detection mechanism. Even if there's a little more startup cost, I expect that over time, maintenance cost is much lower than keeping my other spam filter rule sets up to date -- and so far, the false positive rate looks astoundingly good for remarkably little investment time in the valuation of different canonical properties of spam ("Nigerian Foreign Minister", "teen delight", "Pay your mortgage", "add.*inches"). > How would this be implemented for standard > mail clients? Would you forward each good and bad message to special > addresses? It would seem this would take more time than simply > deleting the spam. For the generic mail client, yes; that's what I was thinking of providing to my site. For specific cases, I can set up macros for UNIX mail client users, and perhaps install pretty buttons for our webmail users. But "forward to spam-submit@uchicago.edu" is pretty simple, and as the filter gets smarter, it becomes less necessary to interact with it. I've been using mine since Monday, and I'm getting no false positives anymore. Not much of a sample size, but if I can keep a rate anywhere near that, I'm not opposed to checking my separate spam folder every couple of days. I find that the biggest payoff is not in having a smart agent eliminate my spam (I don't trust computers enough to allow that by any algorithm), but in helping me to think about messages correctly. Sometimes my mind is just not quite in gear, and I need to read a bit of something before I realize that it's spam. If an agent can set a flag and thereby predispose my brain against it -- if I can automatically flag all the suspected spam and leave it to deal with in one big sweep at the end of my mail-reading session -- then I'm way ahead of where I was last week just in terms of brain efficiency. -- -D. We establised a fine coffee. What everybody can say Sun Project, APC/UCCO TASTY! It's fresh, so-mild, with some special coffee's University of Chicago bitter and sourtaste. "LET'S HAVE SUCH A COFFEE! NOW!" dgc@uchicago.edu Please love CAFE MIAMI. Many thanks. From dgc@uchicago.edu Thu Aug 22 18:03:02 2002 From: dgc@uchicago.edu (David Champion) Date: Thu, 22 Aug 2002 12:03:02 -0500 Subject: [Mailman-Developers] Re: Anti-spam "killer app"? In-Reply-To: <20020822165303.GU2400@dust.uchicago.edu> References: <1030025638.2258.44.camel@fornax.bibsys.no> <20020822144432.GM2400@dust.uchicago.edu> <3D651472.5B1FB99D@nleaudio.com> <20020822165303.GU2400@dust.uchicago.edu> Message-ID: <20020822170302.GV2400@dust.uchicago.edu> * On 2002.08.22, in <20020822165303.GU2400@dust.uchicago.edu>, * "David Champion" wrote: > > > How would this be implemented for standard > > mail clients? Would you forward each good and bad message to special > > addresses? It would seem this would take more time than simply > > deleting the spam. > > For the generic mail client, yes; that's what I was thinking of > providing to my site. For specific cases, I can set up macros for UNIX I hope to have this, provided that it can be reasonably secured against poisoning, but actually I forgot to mention what I'll favor in practice. Since we're trying to pressure our users to use IMAP, we can promote this by declaring a couple of special IMAP folders. When you receive spam that was not automatically detected and filtered, save it to your "SPAM" folder. When you receive a message that was flagged as spam, but which is not, save it to your "NOTSPAM" folder. The system will periodically add these to your personal indices, and it will make smarter decisions from then on. Cron job. One of the things I most like about this approach is that it gives the end-user a stronger sense of empowerment. Instead of "the crappy spam software they use here isn't smart enough to catch mine" and/or "they're always out of date on the rule sets, the lazy bums", it's "not happy with your results? You can change that! You can teach the system to work better for you." When I know that I can prevent bad things from happening again, I'm much happier -- or at least less dissatisfied -- than when I know I'm just stuck with it sometimes. -- -D. We establised a fine coffee. What everybody can say Sun Project, APC/UCCO TASTY! It's fresh, so-mild, with some special coffee's University of Chicago bitter and sourtaste. "LET'S HAVE SUCH A COFFEE! NOW!" dgc@uchicago.edu Please love CAFE MIAMI. Many thanks. From Dale@Newfield.org Thu Aug 22 18:11:19 2002 From: Dale@Newfield.org (Dale Newfield) Date: Thu, 22 Aug 2002 13:11:19 -0400 (EDT) Subject: [Mailman-Developers] Re: Anti-spam "killer app"? In-Reply-To: <20020822165303.GU2400@dust.uchicago.edu> Message-ID: On Thu, 22 Aug 2002, David Champion wrote: > "forward to spam-submit@uchicago.edu" is pretty simple, and as the > filter gets smarter, it becomes less necessary to interact with it. That has huge potential risks. If there's someone I don't like, I could just forward all his mail to that address (it'll learn very quickly if that person has a .sig), and he/she's screwed. Would there be an equivilant "you have to send all your good mail to this address"? The privacy risks there are tremendous, as well. --- Dale Newfield From dgc@uchicago.edu Thu Aug 22 18:32:10 2002 From: dgc@uchicago.edu (David Champion) Date: Thu, 22 Aug 2002 12:32:10 -0500 Subject: [Mailman-Developers] Re: Anti-spam "killer app"? In-Reply-To: References: <20020822165303.GU2400@dust.uchicago.edu> Message-ID: <20020822173210.GX2400@dust.uchicago.edu> * On 2002.08.22, in , * "Dale Newfield" wrote: > On Thu, 22 Aug 2002, David Champion wrote: > > "forward to spam-submit@uchicago.edu" is pretty simple, and as the > > filter gets smarter, it becomes less necessary to interact with it. > > That has huge potential risks. If there's someone I don't like, I could > just forward all his mail to that address (it'll learn very quickly if > that person has a .sig), and he/she's screwed. Yes -- I should have mention this in my first message. I'm certainly wary of that, but I also feel that sufficient safeguards are possible in principle. Verify the sender's envelope address, and require the SMTP connection to come from a limited range of addresses. It still can be abused locally, but that might be a worthwhile tradeoff, should an individual user choose to go that way. > Would there be an equivilant "you have to send all your good mail to this > address"? The privacy risks there are tremendous, as well. No. I don't want people sending the system lots of legitimate mail. I'll specifically ask that people not send legit mail except as necessary; an ever-expanding database is a big perfprmance hit. However, such text would be hashed, and the original discarded, so that privacy is protected. For people using immediate IMAP folders as sources, there are no extra privacy concerns incurred. I'm happy to continue talking about this (it's a really interesting topic, to me), but maybe it's getting a little off-topic for the mailman-developers list. Does anyone have an alternative suggestion? Does nobody mind? -- -D. We establised a fine coffee. What everybody can say Sun Project, APC/UCCO TASTY! It's fresh, so-mild, with some special coffee's University of Chicago bitter and sourtaste. "LET'S HAVE SUCH A COFFEE! NOW!" dgc@uchicago.edu Please love CAFE MIAMI. Many thanks. From mjm@michaelmeltzer.com Thu Aug 22 19:30:59 2002 From: mjm@michaelmeltzer.com (Michael Meltzer) Date: Thu, 22 Aug 2002 14:30:59 -0400 Subject: [Mailman-Developers] Re: Anti-spam "killer app"? References: <20020822165303.GU2400@dust.uchicago.edu> <20020822173210.GX2400@dust.uchicago.edu> Message-ID: <003601c24a0a$0fc592d0$34f820c0@ix1x1000> think their are simpler ways here, I would setup a new email address, then I would sent a messages to ALL news group like: to: alt.sex from new@address.com Subject: A new Method: Hi all my email is new@address.com, please do not use this address, I only want the S P A M Robots to Find it, I am trying out a new filtering system and need a large collection of S P A M, Moderators please let this though, the archives are a very "fertile ground" for this guys to harvest address. If you are wondering what I am up to www.picksomething.com/method.html THANK YOU BTW make sure the new@address.com is on the webpage. My bet in a week you will have a large sample size for the "spam" side, growing by the hour, could send it right to the file ;-)be carefull of keywords the harvesters might react to like abuse@foo.com. Thier is really only one spam table need to get started(the seed) that can be used by all. The personial side mosty likly can be seeded using the user mail mbox/archives on thier machine(or a list archive) MJM PS. I know spaming the news group is a issue here, but minor(they get flooded now), but sometime you have to play by thier rules :-) ----- Original Message ----- From: "David Champion" To: "Dale Newfield" Cc: "Bob Puff@NLE" ; Sent: Thursday, August 22, 2002 1:32 PM Subject: [Mailman-Developers] Re: Anti-spam "killer app"? > * On 2002.08.22, in , > * "Dale Newfield" wrote: > > On Thu, 22 Aug 2002, David Champion wrote: > > > "forward to spam-submit@uchicago.edu" is pretty simple, and as the > > > filter gets smarter, it becomes less necessary to interact with it. > > > > That has huge potential risks. If there's someone I don't like, I could > > just forward all his mail to that address (it'll learn very quickly if > > that person has a .sig), and he/she's screwed. > > Yes -- I should have mention this in my first message. I'm certainly > wary of that, but I also feel that sufficient safeguards are possible > in principle. Verify the sender's envelope address, and require the > SMTP connection to come from a limited range of addresses. It still can > be abused locally, but that might be a worthwhile tradeoff, should an > individual user choose to go that way. > > > > Would there be an equivilant "you have to send all your good mail to this > > address"? The privacy risks there are tremendous, as well. > > No. I don't want people sending the system lots of legitimate mail. I'll > specifically ask that people not send legit mail except as necessary; an > ever-expanding database is a big perfprmance hit. > > However, such text would be hashed, and the original discarded, so that > privacy is protected. > > For people using immediate IMAP folders as sources, there are no extra > privacy concerns incurred. > > > I'm happy to continue talking about this (it's a really interesting > topic, to me), but maybe it's getting a little off-topic for the > mailman-developers list. Does anyone have an alternative suggestion? > Does nobody mind? > > -- > -D. We establised a fine coffee. What everybody can say > Sun Project, APC/UCCO TASTY! It's fresh, so-mild, with some special coffee's > University of Chicago bitter and sourtaste. "LET'S HAVE SUCH A COFFEE! NOW!" > dgc@uchicago.edu Please love CAFE MIAMI. Many thanks. > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman-21/listinfo/mailman-developers From noreply@sourceforge.net Thu Aug 22 20:09:31 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 22 Aug 2002 12:09:31 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-598844 ] BASE64 attachments barfing Message-ID: Bugs item #598844, was opened at 2002-08-22 11:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=598844&group_id=103 Category: Pipermail Group: 2.1 beta >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Patrick Finnerty (finnertyp) Assigned to: Nobody/Anonymous (nobody) Summary: BASE64 attachments barfing Initial Comment: When testing MIME attachments I get the following error which occurs using arch to convert a mailbox or when posting to the archive: Pickling archive state into /usr/local/mailman/archives/private/opsarchtest/pipermail.pck Traceback (most recent call last): File "bin/arch", line 160, in ? main() File "bin/arch", line 148, in main archiver.processUnixMailbox(fp, Article, start, end) File "/usr/local/mailman/Mailman/Archiver/pipermail.py", line 545, in processUnixMailbox m = mbox.next() File "/usr/local/lib/python2.2/mailbox.py", line 34, in next return self.factory(_Subfile(self.fp, start, stop)) File "/usr/local/mailman/Mailman/Mailbox.py", line 69, in scrubber return mailbox.scrub(msg) File "/usr/local/mailman/Mailman/Mailbox.py", line 89, in scrub return self._scrubber(self._mlist, msg) File "/usr/local/mailman/Mailman/Handlers/Scrubber.py", line 114, in process url = save_attachment(mlist, part, filter_html=0) File "/usr/local/mailman/Mailman/Handlers/Scrubber.py", line 217, in save_attachment decodedpayload = msg.get_payload(decode=1) File "/usr/local/mailman/pythonlib/email/Message.py", line 177, in get_payload return Utils._bdecode(payload) File "/usr/local/mailman/pythonlib/email/Utils.py", line 71, in _bdecode value = base64.decodestring(s) File "/usr/local/lib/python2.2/base64.py", line 44, in decodestring return binascii.a2b_base64(s) binascii.Error: Incorrect padding I've narrowed this down to HTML attachments that include tables. I've attached a mbox that will give this error when used with arch. This only happens when base64 is used. I've also found that even when messages with HTML attachments are archived, clicking on the attachment doesn't display the page but the source instead. Or in some cases it can be garbage. I can supply more info on this if you wish. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-22 15:09 Message: Logged In: YES user_id=12800 Thanks for the report and the mbox file, this was indeed a bug, which will be fixed in beta4. As for you second question, what you're seeing could be caused by this bug, but it's more likely just the behavior specified by ARCHIVE_HTML_SANTIZER in Defaults.py/mm_cfg.py. To prohibit evil stuff like cross-site scripting, or web bugs and virus from affecting your archive readers, html is typically santized to be harmless. ---------------------------------------------------------------------- Comment By: Patrick Finnerty (finnertyp) Date: 2002-08-22 11:58 Message: Logged In: YES user_id=594846 Whoops. Attached the html file which was used as attachment instead of the mbox file.... ...which I'm gonna upload now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=598844&group_id=103 From noreply@sourceforge.net Thu Aug 22 20:17:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 22 Aug 2002 12:17:54 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-598010 ] Bad Pickle? Message-ID: Bugs item #598010, was opened at 2002-08-20 19:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=598010&group_id=103 Category: None Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Peer Heinlein (pheinlein) Assigned to: Nobody/Anonymous (nobody) Summary: Bad Pickle? Initial Comment: Some days ago my server startet forgetting some imcoming mails to some special lists. SInce then I receive the followin error-notes on my Server. Could somebody explain me what`s going on very fast? Some of my important mailinglists aren`t usable any more. File "/usr/lib/mailman/bin/qrunner", line 266, in ? main() File "/usr/lib/mailman/bin/qrunner", line 226, in main qrunner.run() File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 59, in run filecnt = self._oneloop() File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 105, in _oneloop self._onefile(msg, msgdata) File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 154, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/usr/lib/mailman/Mailman/Queue/IncomingRunner.py", line 129, in _dispose status = self._dopipeline(mlist, msg, msgdata, pipeline) File "/usr/lib/mailman/Mailman/Queue/IncomingRunner.py", line 152, in _dopipeline sys.modules[modname].process(mlist, msg, msgdata) File "/usr/lib/mailman/Mailman/Handlers/Moderate.py", line 101, in process Hold.hold_for_approval(mlist, msg, msgdata, Hold.ModeratedPost) File "/usr/lib/mailman/Mailman/Handlers/Hold.py", line 219, in hold_for_approval cookie = Pending.new(Pending.HELD_MESSAGE, id) File "/usr/lib/mailman/Mailman/Pending.py", line 64, in new db = _load() File "/usr/lib/mailman/Mailman/Pending.py", line 121, in _load return cPickle.load(fp) ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-22 15:17 Message: Logged In: YES user_id=12800 It looks like the file containing your pending actions got corrupted. Possibly you had a disk corruption, or out of space problem, or something similar. If you have a data/pending.pck.tmp file, move that to data/pending.pck. Otherwise you'll have to simply remove the data/pending.pck file, but if you do that you'll lose all your pending subscriptions and held messages. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=598010&group_id=103 From noreply@sourceforge.net Thu Aug 22 20:20:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 22 Aug 2002 12:20:56 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-598007 ] 2.1b3 encoding of Subject error Message-ID: Bugs item #598007, was opened at 2002-08-20 19:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=598007&group_id=103 Category: mail delivery Group: 2.1 beta >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Rodolfo Pilas (alkalino) Assigned to: Nobody/Anonymous (nobody) Summary: 2.1b3 encoding of Subject error Initial Comment: Release of 2.1b3 says: 'prefixes is controlled by a new list option encode_ascii_prefixes' but I has changed to 'Always' and the subject are now ok (in Spanish) but the option strip the white spaces, by this way: Original subject: ahora no modificás el título que me tenes podrídiño Result subject: [list] ahora nomodificáseltítuloque me tenespodrídiño ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-22 15:20 Message: Logged In: YES user_id=12800 You should explicitly add the space to your subject_prefix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=598007&group_id=103 From noreply@sourceforge.net Thu Aug 22 20:34:27 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 22 Aug 2002 12:34:27 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-597407 ] Confirmation usability Message-ID: Bugs item #597407, was opened at 2002-08-19 17:40 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=597407&group_id=103 Category: (un)subscribing Group: 2.1 beta >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: PieterB (pieterb) Assigned to: Nobody/Anonymous (nobody) Summary: Confirmation usability Initial Comment: There are three usability problems with the confirmation of a subscription: a) the URL tends to be more than 80 characters. It might be a good idea too decrease the length of the confirmation-ID and/or identation and thereby increase the usability b) the URL that the user is directed to has a "Subscribe" button on the left and a "Cancel and discard" button on the right. I think the usabilty can be improved by swapping the buttons and by making the submit-button something larger (e.g. "Subscribe to mailinglist X"). See also: http://www.useit.com/alertbox/20000416.html c) if the users have already visited the page, they don't get a message saying the already confirmed their subscription. Regards, PieterB ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-22 15:34 Message: Logged In: YES user_id=12800 a) For now, we'll keep the long urls. I doubt people actually type those by hand -- they usually click on them directly in their mail reader, or they cut and paste them into their browser. b) Good suggestion, I'll try to improve that page. c) Right. Once we process the confirmation, we throw away the confirmation string, so we can't link the user with their request. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=597407&group_id=103 From noreply@sourceforge.net Thu Aug 22 20:37:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 22 Aug 2002 12:37:05 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-597242 ] Dead link on rfc2369 Message-ID: Bugs item #597242, was opened at 2002-08-19 13:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=597242&group_id=103 Category: Web/CGI Group: 2.1 beta >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: PieterB (pieterb) Assigned to: Nobody/Anonymous (nobody) Summary: Dead link on rfc2369 Initial Comment: The help message: "Should messages from this mailing list include the RFC 2369 (i.e. List-*) headers? Yes is highly recommended. (Details for include_rfc2369_headers)" from General Options contains a link to http://www.faqs.org/rfc/rfc2369.html instead of http://www.faqs.org/rfcs/rfc2369.html (mind the s) Regards, PieterB ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-22 15:37 Message: Logged In: YES user_id=12800 Thanks, fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=597242&group_id=103 From satyap@satya.virtualave.net Thu Aug 22 21:33:04 2002 From: satyap@satya.virtualave.net (Satya) Date: Thu, 22 Aug 2002 13:33:04 -0700 (PDT) Subject: [Mailman-Developers] Re: Anti-spam "killer app"? In-Reply-To: <3D651472.5B1FB99D@nleaudio.com> Message-ID: On Aug 22, 2002 at 12:42, Bob Puff@NLE wrote: >My biggest question to all this is: how do you add to the good list, >and the bad list? It seems like you need to moderate each message, >at least in the beginning. How would this be implemented for >standard mail clients? Would you forward each good and bad message >to special addresses? It would seem this would take more time than I save false negatives to a folder named 'spam', and false positives (none yet, I started with a huge 'clean' sample) to a folder 'nonspam'. Every night (but I'll make it once a week now, since it's very slow) I grab the two mbox files, and shove them through scripts. Takes half an hour to run unattended. Takes milliseconds to do the save-to-folder thing. The system caught 3 this morning. -- Satya. "shutdown -halt now" - The final word in network security tools. From noreply@sourceforge.net Thu Aug 22 23:45:53 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 22 Aug 2002 15:45:53 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-596565 ] mailman should use alphabetic U/GIDs Message-ID: Bugs item #596565, was opened at 2002-08-17 17:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=596565&group_id=103 Category: configuring/installing Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Todd Vierling (tvierling) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: mailman should use alphabetic U/GIDs Initial Comment: In short: "compiling in numeric IDs is Very Evil." The long story: I'm trying to put together a packaging environment for NetBSD's "pkgsrc" to allow easy build and install of Mailman. Unfortunately, this is currently impossible thanks to the fact that alphabetic IDs are resolved to numerics at compile time. (Nearly all packages requiring cutstom IDs resolve them at runtime using get {pw,gr}nam(3)). Thanks to this behavior, it is not currently possible to: * create a prebuilt binary package of Mailman, and install it later on a system without the source tarball; * migrate an existing installation of Mailman to another system that has a uid/gid conflict without recompiling. There are other problems that compiled-in numeric IDs cause, but these two really stick out. I'm not a Pythonhead, so I don't claim to know how to fix this correctly. However, I've attached a diff for configure.in that sets the framework for the start of fixing this problem. In particular, the diff changes the MM_FIND_*_ID macros to report the ID that matched without resolving names to numbers, and allows the build to proceed if forced --with-{user,group}name options are specified and those IDs don't exist at build time. (The latter case helps autopackaging in systems like NetBSD's pkgsrc, where the IDs may be autocreated *between* the "configure" and "make install" phases.) The things that still need to be done include fixing the main scripts, and the checkperms logic, to cope with either numeric or alphabetic IDs; and possibly adding a runtime configuration of IDs (which really helps if the admin needs to reconfigure or change the mail or Web servers, while avoiding to rebuild Mailman). I openly welcome Python gurus to look into what's *really* needed to fix this.... ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-22 18:45 Message: Logged In: YES user_id=12800 I like this idea a lot, even though the patch is far too incomplete. Fortunately, you motivated me to hack the code to support symbolic names instead of numeric ids. Attached is a patch I intend to commit for MM2.1b4. Would you please try it and see if it accomplishes what you need? One minor ugliness is that it retains --with-cgi-gid and --with-mail-gid as the configure switches to set the wrapper group names. Given the communities knowledge about these switches, I'm inclined not to change or deprecate them. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=596565&group_id=103 From barry@zope.com Thu Aug 22 23:55:13 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 22 Aug 2002 18:55:13 -0400 Subject: [Mailman-Developers] Bug #596565, mailman should use alphabetic U/GIDs Message-ID: <15717.27601.412066.574315@yyz.zope.com> I think bug #596565 makes a good point. We've always known that the hardcoded numeric ids are a PITA and a major source of FAQ-ups for newbies. I've resisted (and continue to resist ;) making these totally run-time configurable for two reasons: - vague, unsubstantiated fears about security holes - avoiding like the plague any config file parsing in C Todd makes an interesting point: by using symbolic names for the groups and users, we can give a level of indirection that may make it easier for binary packages, admins moving Mailman to different systems, and other similar situations. The original patch attached to this bug was too incomplete to use, but I was running some long background tests today and had some time to hack. So I've uploaded a patch that I think does the trick. Some highlights: --with-mail-gid and --with-cgi-gid are retained, even though they should be used to specify group names instead of group ids. I don't think it's worth changing these (see my patch comments for details). --without-permcheck has been extended to mean that any verification of the mail and cgi group names is skipped. This means you can build mailman on a system without the groups installed and it'll compile just fine. It won't run of course, unless the system has those group names installed. I've completely rewritten the error messages that get printed when there are group mismatches. I really hope that now, even if it's more rare, when the mismatches happen, it'll be more obvious how to fix the problems. I've done quite a bit of testing of various combinations of switches and I think it's doing the right thing. But it's still possible I screwed up, so I'd appreciate it if someone else could apply the patch (against today's cvs) and give it a try. Does this patch help make building, distributing, and moving Mailman easier for folks? Are there any bugs where a gid is still assumed instead of a group name? Cheers, -Barry From noreply@sourceforge.net Fri Aug 23 04:31:55 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 22 Aug 2002 20:31:55 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-571636 ] Traceback in error log - bounce handling Message-ID: Bugs item #571636, was opened at 2002-06-20 09:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=571636&group_id=103 Category: bounce detection Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Daniel Buchmann (avalon) Assigned to: Nobody/Anonymous (nobody) Summary: Traceback in error log - bounce handling Initial Comment: I got this traceback in my error log: Jun 20 14:58:56 2002 (1992) Traceback (most recent call last): File "/home/mailman/Mailman/Queue/Runner.py", line 105, in __oneloop self.__onefile(msg, msgdata) File "/home/mailman/Mailman/Queue/Runner.py", line 154, in __onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/home/mailman/Mailman/Queue/BounceRunner.py", line 71, in _dispose addrs = BouncerAPI.ScanMessages(mlist, msg) File "/home/mailman/Mailman/Bouncers/BouncerAPI.py", line 60, in ScanMessages addrs = sys.modules[modname].process(msg) File "/home/mailman/Mailman/Bouncers/Microsoft.py", line 35, in process body = StringIO(subpart.get_payload()) TypeError: expected read buffer, list found The following had probably happened: 1. A spam mail was sent to one of our lists. 2. The list tried to send a "waiting for moderator approval" mail to the sender of the spam mail. 3. The "waiting for moderator approval" mail bounced (because the sender address was, of course, invalid). The bounce in (3) gave me the traceback and was moved to qfiles/shunt/. PCK file is attached to this bug report. Let me know if you need the DB file too... :) ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-22 23:31 Message: Logged In: YES user_id=12800 If this message has been in the queue since before you upgraded, it's still got a bogus representation, which won't be automatically fixed. You'd need to do some manual hacking on the object representation and then re-save it. If the message is important to you and you can't fix it, upload it or email it and I'll attempt to do so. If the message isn't important to you, just discard it. Messages sent after the upgrade should be fine. ---------------------------------------------------------------------- Comment By: Daniel Buchmann (avalon) Date: 2002-08-19 10:20 Message: Logged In: YES user_id=184577 Well, at least something must have happened, because now the traceback looks different, this is the output of dumpdb on it: Traceback (most recent call last): File "/home/mailman/bin/dumpdb", line 130, in ? msg = main() File "/home/mailman/bin/dumpdb", line 124, in main pp.pprint(m) File "/usr/lib/python2.2/pprint.py", line 110, in pprint self.__stream.write(self.pformat(object) + "\n") File "/usr/lib/python2.2/pprint.py", line 114, in pformat self.__format(object, sio, 0, 0, {}, 0) File "/usr/lib/python2.2/pprint.py", line 136, in __format rep = self.__repr(object, context, level - 1) File "/usr/lib/python2.2/pprint.py", line 200, in __repr self.__depth, level) File "/usr/lib/python2.2/pprint.py", line 287, in _safe_repr rep = `object` File "/home/mailman/Mailman/Message.py", line 41, in __repr__ return self.__str__() File "/home/mailman/pythonlib/email/Message.py", line 89, in __str__ return self.as_string(unixfrom=1) File "/home/mailman/pythonlib/email/Message.py", line 99, in as_string g.flatten(self, unixfrom=unixfrom) File "/home/mailman/pythonlib/email/Generator.py", line 81, in flatten self._write(msg) File "/home/mailman/pythonlib/email/Generator.py", line 109, in _write self._dispatch(msg) File "/home/mailman/pythonlib/email/Generator.py", line 136, in _dispatch meth(msg) File "/home/mailman/pythonlib/email/Generator.py", line 219, in _handle_multipart g.flatten(part, unixfrom=0) File "/home/mailman/pythonlib/email/Generator.py", line 81, in flatten self._write(msg) File "/home/mailman/pythonlib/email/Generator.py", line 109, in _write self._dispatch(msg) File "/home/mailman/pythonlib/email/Generator.py", line 136, in _dispatch meth(msg) File "/home/mailman/pythonlib/email/Generator.py", line 278, in _handle_message g.flatten(msg.get_payload(0), unixfrom=0) File "/home/mailman/pythonlib/email/Message.py", line 167, in get_payload raise TypeError, i TypeError: 0 (Using latest CVS checked out today 19-aug-2002) ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-09 15:26 Message: Logged In: YES user_id=12800 I think we resolved this one, didn't we? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=571636&group_id=103 From noreply@sourceforge.net Fri Aug 23 07:18:31 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 22 Aug 2002 23:18:31 -0700 Subject: [Mailman-Developers] [ mailman-Patches-534577 ] Add SpamAssassin filter to mail pipeline Message-ID: Patches item #534577, was opened at 2002-03-25 08:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=534577&group_id=103 Category: list administration Group: Mailman 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: James Henstridge (jhenstridge) Assigned to: Nobody/Anonymous (nobody) Summary: Add SpamAssassin filter to mail pipeline Initial Comment: This filter adds support for discarding or holding spam sent to the mailing list. It contacts a spamd daemon (from SpamAssassin -- http://spamassassin.taint.org) to score the message. If the score is above a certain threshold (default 10), the message is discarded and an entry is written to the vette log. If the score is above another lower threshold (default 5), the message is held for moderation. The SpamAssassin.py file should be installed in Mailman/Handlers/. The LIST_PIPELINE variable in Mailman/Handlers/HandlerAPI.py should be modified to include a 'SpamAssassin' item (I put it just after the existing 'SpamDetect' item). To change the defaults, the following can be added to the mm_cfg.py file: SPAMASSASSIN_HOST = 'host:port' # how to contact SA SPAMASSASSIN_DISCARD_SCORE = 10 SPAMASSASSIN_HOLD_SCORE = 5 If you don't want to discard messages, then DISCARD_SCORE can be set to something very high (1000 should do it). It looks the MM2.1 filter APIs have changed a bit, so this filter will need some modifications to work with that version. When I get round to upgrading, I might look into updating it. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2002-08-23 06:18 Message: Logged In: YES user_id=81797 How about changing that chunk of code to: SPAMD_HOST = 'localhost' SPAMD_PORT = None if hasattr(mm_cfg, 'SPAMASSASSIN_HOST): SPAMD_HOST = mm_cfg.SPAMASSASSIN_HOST try: SPAMD_HOST, SPAMD_PORT = string.split(SPAMD_HOST, ':', 1) SPAMD_PORT = int(SPAMD_PORT) except ValueError: SPAMD_PORT = None if not SPAMD_PORT: SPAMD_PORT = 783 This gets rid of the "bare except"s, and I think it's a little clearer than the previous code. The ValueError will be tripped if the string doesn't have a : in it, or if the int coercion fails. Though perhaps in that instance you'd want to log an error or something... Sean ---------------------------------------------------------------------- Comment By: dann frazier (dannf) Date: 2002-08-17 18:11 Message: Logged In: YES user_id=146718 hey James, found a typo. also wanted to point out: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=139942&repeatmerged=yes --- SpamAssassin.py.orig Sat Aug 17 12:05:41 2002 +++ SpamAssassin.py Sat Aug 17 12:06:13 2002 @@ -35,7 +35,7 @@ SPAMD_HOST = mm_cfg.SPAMASSASSIN_HOST i = string.find(SPAMD_HOST, ':') if i >= 0: - SPAMD_HOST, SPAMD_PORT = SPAMD_HOST[:i], host[i+1:] + SPAMD_HOST, SPAMD_PORT = SPAMD_HOST[:i], SPAMD_HOST[i+1:] try: SPAMD_PORT = int(SPAMD_PORT) except: SPAMD_PORT = None except: ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-07-25 09:00 Message: Logged In: YES user_id=146903 remembering to check the "upload file" checkbox this time ... ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-07-25 08:59 Message: Logged In: YES user_id=146903 Yet another new version that fixes a small typo. With previous messages, you couldn't approve messages that had been identified as spam once (they would get identified again when the queue got processed, instead of passing the message through). ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-07-10 00:19 Message: Logged In: YES user_id=146903 The Mailman installation on mail.gnome.org also uses this filter. I don't think there are any stability problems with the filter. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2002-07-09 21:16 Message: Logged In: YES user_id=81797 FYI, I ran the previous version since installation and it seemed to work fine. I didn't run into any problems, with probably 500 messages handled. I've updated to the new version and it seems ok so far, but I've only sent about 10 messages through. Sean ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-07-03 04:02 Message: Logged In: YES user_id=146903 Yet another version. There were some bugs in handling of certain error conditions when talking to spamd. These would result in exceptions and the messages staying in the delivery queue :( With the new version, the message will be passed through unchecked under these conditions, and a message will be added to the error log. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2002-06-12 21:48 Message: Logged In: YES user_id=81797 FYI: I've been running the 2002-05-14 version of this patch with spamassassin 2.20 for the last day on our main mailman box and it seems to be working great. ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-05-14 06:04 Message: Logged In: YES user_id=146903 This version is essentially the same as the previous version, but adds compatibility with python > 1.5.2, which doesn't like you passing two arguments to socket.connect(). ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-04-27 06:17 Message: Logged In: YES user_id=146903 Just attached my updated version of the patch. This version requires SpamAssassin 2.20 (for the extra commands that the spamd daemon understands). It now displays a list of which rules were triggered for held messages, and can give messages from list members a bonus (defaults to 2), so that they are less likely to get held as spam. ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-03-26 01:21 Message: Logged In: YES user_id=146903 There is a fairly easy optimisation for this filter that I missed when writing it. It calls str() on the message object twice. It would be quicker to call str() on the message once. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=534577&group_id=103 From noreply@sourceforge.net Fri Aug 23 07:19:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 22 Aug 2002 23:19:06 -0700 Subject: [Mailman-Developers] [ mailman-Patches-534577 ] Add SpamAssassin filter to mail pipeline Message-ID: Patches item #534577, was opened at 2002-03-25 08:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=534577&group_id=103 Category: list administration Group: Mailman 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: James Henstridge (jhenstridge) Assigned to: Nobody/Anonymous (nobody) Summary: Add SpamAssassin filter to mail pipeline Initial Comment: This filter adds support for discarding or holding spam sent to the mailing list. It contacts a spamd daemon (from SpamAssassin -- http://spamassassin.taint.org) to score the message. If the score is above a certain threshold (default 10), the message is discarded and an entry is written to the vette log. If the score is above another lower threshold (default 5), the message is held for moderation. The SpamAssassin.py file should be installed in Mailman/Handlers/. The LIST_PIPELINE variable in Mailman/Handlers/HandlerAPI.py should be modified to include a 'SpamAssassin' item (I put it just after the existing 'SpamDetect' item). To change the defaults, the following can be added to the mm_cfg.py file: SPAMASSASSIN_HOST = 'host:port' # how to contact SA SPAMASSASSIN_DISCARD_SCORE = 10 SPAMASSASSIN_HOLD_SCORE = 5 If you don't want to discard messages, then DISCARD_SCORE can be set to something very high (1000 should do it). It looks the MM2.1 filter APIs have changed a bit, so this filter will need some modifications to work with that version. When I get round to upgrading, I might look into updating it. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2002-08-23 06:19 Message: Logged In: YES user_id=81797 How about changing that chunk of code to: SPAMD_HOST = 'localhost' SPAMD_PORT = None if hasattr(mm_cfg, 'SPAMASSASSIN_HOST): SPAMD_HOST = mm_cfg.SPAMASSASSIN_HOST try: SPAMD_HOST, SPAMD_PORT = string.split(SPAMD_HOST, ':', 1) SPAMD_PORT = int(SPAMD_PORT) except ValueError: SPAMD_PORT = None if not SPAMD_PORT: SPAMD_PORT = 783 This gets rid of the "bare except"s, and I think it's a little clearer than the previous code. The ValueError will be tripped if the string doesn't have a : in it, or if the int coercion fails. Though perhaps in that instance you'd want to log an error or something... Sean ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2002-08-23 06:18 Message: Logged In: YES user_id=81797 How about changing that chunk of code to: SPAMD_HOST = 'localhost' SPAMD_PORT = None if hasattr(mm_cfg, 'SPAMASSASSIN_HOST): SPAMD_HOST = mm_cfg.SPAMASSASSIN_HOST try: SPAMD_HOST, SPAMD_PORT = string.split(SPAMD_HOST, ':', 1) SPAMD_PORT = int(SPAMD_PORT) except ValueError: SPAMD_PORT = None if not SPAMD_PORT: SPAMD_PORT = 783 This gets rid of the "bare except"s, and I think it's a little clearer than the previous code. The ValueError will be tripped if the string doesn't have a : in it, or if the int coercion fails. Though perhaps in that instance you'd want to log an error or something... Sean ---------------------------------------------------------------------- Comment By: dann frazier (dannf) Date: 2002-08-17 18:11 Message: Logged In: YES user_id=146718 hey James, found a typo. also wanted to point out: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=139942&repeatmerged=yes --- SpamAssassin.py.orig Sat Aug 17 12:05:41 2002 +++ SpamAssassin.py Sat Aug 17 12:06:13 2002 @@ -35,7 +35,7 @@ SPAMD_HOST = mm_cfg.SPAMASSASSIN_HOST i = string.find(SPAMD_HOST, ':') if i >= 0: - SPAMD_HOST, SPAMD_PORT = SPAMD_HOST[:i], host[i+1:] + SPAMD_HOST, SPAMD_PORT = SPAMD_HOST[:i], SPAMD_HOST[i+1:] try: SPAMD_PORT = int(SPAMD_PORT) except: SPAMD_PORT = None except: ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-07-25 09:00 Message: Logged In: YES user_id=146903 remembering to check the "upload file" checkbox this time ... ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-07-25 08:59 Message: Logged In: YES user_id=146903 Yet another new version that fixes a small typo. With previous messages, you couldn't approve messages that had been identified as spam once (they would get identified again when the queue got processed, instead of passing the message through). ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-07-10 00:19 Message: Logged In: YES user_id=146903 The Mailman installation on mail.gnome.org also uses this filter. I don't think there are any stability problems with the filter. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2002-07-09 21:16 Message: Logged In: YES user_id=81797 FYI, I ran the previous version since installation and it seemed to work fine. I didn't run into any problems, with probably 500 messages handled. I've updated to the new version and it seems ok so far, but I've only sent about 10 messages through. Sean ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-07-03 04:02 Message: Logged In: YES user_id=146903 Yet another version. There were some bugs in handling of certain error conditions when talking to spamd. These would result in exceptions and the messages staying in the delivery queue :( With the new version, the message will be passed through unchecked under these conditions, and a message will be added to the error log. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2002-06-12 21:48 Message: Logged In: YES user_id=81797 FYI: I've been running the 2002-05-14 version of this patch with spamassassin 2.20 for the last day on our main mailman box and it seems to be working great. ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-05-14 06:04 Message: Logged In: YES user_id=146903 This version is essentially the same as the previous version, but adds compatibility with python > 1.5.2, which doesn't like you passing two arguments to socket.connect(). ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-04-27 06:17 Message: Logged In: YES user_id=146903 Just attached my updated version of the patch. This version requires SpamAssassin 2.20 (for the extra commands that the spamd daemon understands). It now displays a list of which rules were triggered for held messages, and can give messages from list members a bonus (defaults to 2), so that they are less likely to get held as spam. ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-03-26 01:21 Message: Logged In: YES user_id=146903 There is a fairly easy optimisation for this filter that I missed when writing it. It calls str() on the message object twice. It would be quicker to call str() on the message once. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=534577&group_id=103 From noreply@sourceforge.net Fri Aug 23 07:32:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 22 Aug 2002 23:32:46 -0700 Subject: [Mailman-Developers] [ mailman-Patches-534577 ] Add SpamAssassin filter to mail pipeline Message-ID: Patches item #534577, was opened at 2002-03-25 08:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=534577&group_id=103 Category: list administration Group: Mailman 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: James Henstridge (jhenstridge) Assigned to: Nobody/Anonymous (nobody) Summary: Add SpamAssassin filter to mail pipeline Initial Comment: This filter adds support for discarding or holding spam sent to the mailing list. It contacts a spamd daemon (from SpamAssassin -- http://spamassassin.taint.org) to score the message. If the score is above a certain threshold (default 10), the message is discarded and an entry is written to the vette log. If the score is above another lower threshold (default 5), the message is held for moderation. The SpamAssassin.py file should be installed in Mailman/Handlers/. The LIST_PIPELINE variable in Mailman/Handlers/HandlerAPI.py should be modified to include a 'SpamAssassin' item (I put it just after the existing 'SpamDetect' item). To change the defaults, the following can be added to the mm_cfg.py file: SPAMASSASSIN_HOST = 'host:port' # how to contact SA SPAMASSASSIN_DISCARD_SCORE = 10 SPAMASSASSIN_HOLD_SCORE = 5 If you don't want to discard messages, then DISCARD_SCORE can be set to something very high (1000 should do it). It looks the MM2.1 filter APIs have changed a bit, so this filter will need some modifications to work with that version. When I get round to upgrading, I might look into updating it. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2002-08-23 06:32 Message: Logged In: YES user_id=81797 That last one had a missing quote. Try this patch: *** SpamAssassin.py.orig Fri Aug 23 00:28:59 2002 --- SpamAssassin.py Fri Aug 23 00:31:00 2002 *************** *** 30,45 **** from Mailman.Logging.Syslog import syslog from Hold import hold_for_approval ! SPAMD_PORT = 0 ! try: ! SPAMD_HOST = mm_cfg.SPAMASSASSIN_HOST ! i = string.find(SPAMD_HOST, ':') ! if i >= 0: ! SPAMD_HOST, SPAMD_PORT = SPAMD_HOST[:i], host[i+1:] ! try: SPAMD_PORT = int(SPAMD_PORT) ! except: SPAMD_PORT = None ! except: ! SPAMD_HOST = 'localhost' if not SPAMD_PORT: SPAMD_PORT = 783 try: DISCARD_SCORE = mm_cfg.SPAMASSASSIN_DISCARD_SCORE --- 30,44 ---- from Mailman.Logging.Syslog import syslog from Hold import hold_for_approval ! SPAMD_HOST = 'localhost' ! SPAMD_PORT = None ! if hasattr(mm_cfg, 'SPAMASSASSIN_HOST'): ! SPAMD_HOST = mm_cfg.SPAMASSASSIN_HOST ! try: ! SPAMD_HOST, SPAMD_PORT = string.split(SPAMD_HOST, ':', 1) ! SPAMD_PORT = int(SPAMD_PORT) ! except ValueError: ! SPAMD_PORT = None if not SPAMD_PORT: SPAMD_PORT = 783 try: DISCARD_SCORE = mm_cfg.SPAMASSASSIN_DISCARD_SCORE Sean ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2002-08-23 06:19 Message: Logged In: YES user_id=81797 How about changing that chunk of code to: SPAMD_HOST = 'localhost' SPAMD_PORT = None if hasattr(mm_cfg, 'SPAMASSASSIN_HOST): SPAMD_HOST = mm_cfg.SPAMASSASSIN_HOST try: SPAMD_HOST, SPAMD_PORT = string.split(SPAMD_HOST, ':', 1) SPAMD_PORT = int(SPAMD_PORT) except ValueError: SPAMD_PORT = None if not SPAMD_PORT: SPAMD_PORT = 783 This gets rid of the "bare except"s, and I think it's a little clearer than the previous code. The ValueError will be tripped if the string doesn't have a : in it, or if the int coercion fails. Though perhaps in that instance you'd want to log an error or something... Sean ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2002-08-23 06:18 Message: Logged In: YES user_id=81797 How about changing that chunk of code to: SPAMD_HOST = 'localhost' SPAMD_PORT = None if hasattr(mm_cfg, 'SPAMASSASSIN_HOST): SPAMD_HOST = mm_cfg.SPAMASSASSIN_HOST try: SPAMD_HOST, SPAMD_PORT = string.split(SPAMD_HOST, ':', 1) SPAMD_PORT = int(SPAMD_PORT) except ValueError: SPAMD_PORT = None if not SPAMD_PORT: SPAMD_PORT = 783 This gets rid of the "bare except"s, and I think it's a little clearer than the previous code. The ValueError will be tripped if the string doesn't have a : in it, or if the int coercion fails. Though perhaps in that instance you'd want to log an error or something... Sean ---------------------------------------------------------------------- Comment By: dann frazier (dannf) Date: 2002-08-17 18:11 Message: Logged In: YES user_id=146718 hey James, found a typo. also wanted to point out: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=139942&repeatmerged=yes --- SpamAssassin.py.orig Sat Aug 17 12:05:41 2002 +++ SpamAssassin.py Sat Aug 17 12:06:13 2002 @@ -35,7 +35,7 @@ SPAMD_HOST = mm_cfg.SPAMASSASSIN_HOST i = string.find(SPAMD_HOST, ':') if i >= 0: - SPAMD_HOST, SPAMD_PORT = SPAMD_HOST[:i], host[i+1:] + SPAMD_HOST, SPAMD_PORT = SPAMD_HOST[:i], SPAMD_HOST[i+1:] try: SPAMD_PORT = int(SPAMD_PORT) except: SPAMD_PORT = None except: ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-07-25 09:00 Message: Logged In: YES user_id=146903 remembering to check the "upload file" checkbox this time ... ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-07-25 08:59 Message: Logged In: YES user_id=146903 Yet another new version that fixes a small typo. With previous messages, you couldn't approve messages that had been identified as spam once (they would get identified again when the queue got processed, instead of passing the message through). ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-07-10 00:19 Message: Logged In: YES user_id=146903 The Mailman installation on mail.gnome.org also uses this filter. I don't think there are any stability problems with the filter. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2002-07-09 21:16 Message: Logged In: YES user_id=81797 FYI, I ran the previous version since installation and it seemed to work fine. I didn't run into any problems, with probably 500 messages handled. I've updated to the new version and it seems ok so far, but I've only sent about 10 messages through. Sean ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-07-03 04:02 Message: Logged In: YES user_id=146903 Yet another version. There were some bugs in handling of certain error conditions when talking to spamd. These would result in exceptions and the messages staying in the delivery queue :( With the new version, the message will be passed through unchecked under these conditions, and a message will be added to the error log. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2002-06-12 21:48 Message: Logged In: YES user_id=81797 FYI: I've been running the 2002-05-14 version of this patch with spamassassin 2.20 for the last day on our main mailman box and it seems to be working great. ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-05-14 06:04 Message: Logged In: YES user_id=146903 This version is essentially the same as the previous version, but adds compatibility with python > 1.5.2, which doesn't like you passing two arguments to socket.connect(). ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-04-27 06:17 Message: Logged In: YES user_id=146903 Just attached my updated version of the patch. This version requires SpamAssassin 2.20 (for the extra commands that the spamd daemon understands). It now displays a list of which rules were triggered for held messages, and can give messages from list members a bonus (defaults to 2), so that they are less likely to get held as spam. ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-03-26 01:21 Message: Logged In: YES user_id=146903 There is a fairly easy optimisation for this filter that I missed when writing it. It calls str() on the message object twice. It would be quicker to call str() on the message once. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=534577&group_id=103 From noreply@sourceforge.net Fri Aug 23 08:42:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Aug 2002 00:42:05 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-599112 ] UnboundLocalError: local variable 'sende Message-ID: Bugs item #599112, was opened at 2002-08-23 09:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=599112&group_id=103 Category: None Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Peer Heinlein (pheinlein) Assigned to: Nobody/Anonymous (nobody) Summary: UnboundLocalError: local variable 'sende Initial Comment: I used the last CVS from Thursday, Aug. 23, and some (all?) of my users get a bug-message when they try to confirm a heldmessage by clicking on the confirmation-link they got by mail. Peer Traceback (most recent call last): File "/usr/lib/mailman/scripts/driver", line 82, in run_main main() File "/usr/lib/mailman/Mailman/Cgi/confirm.py", line 141, in main heldmsg_prompt(mlist, doc, cookie, *content[1:]) File "/usr/lib/mailman/Mailman/Cgi/confirm.py", line 626, in heldmsg_prompt lang = mlist.getMemberLanguage(sender) UnboundLocalError: local variable 'sender' referenced before assignment ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=599112&group_id=103 From nb@cisto.com Fri Aug 23 09:31:46 2002 From: nb@cisto.com (Norbert Bollow) Date: Fri, 23 Aug 2002 10:31:46 +0200 Subject: [Mailman-Developers] Bug #596565, mailman should use alphabetic U/GIDs In-Reply-To: <15717.27601.412066.574315@yyz.zope.com> (barry@zope.com) References: <15717.27601.412066.574315@yyz.zope.com> Message-ID: <200208230831.g7N8VkX10527@quill.local> Barry A. Warsaw wrote: > Does this patch help make building, distributing, and moving Mailman > easier for folks? Yes, definately. A major server with lots of Mailman installs died on us recently due to hardware problems. I had to do an emergency move which got much more messy than expected because I hadn't realised in time that all those wrapper scrips have the numeric GID's compiled into them. (The symbolic GID's are identical on both machines, but the numeric GID's weren't.) Greetings, Norbert. -- Founder & Steering Committee member of http://gnu.org/projects/dotgnu/ Norbert Bollow, Weidlistr.18, CH-8624 Gruet (near Zurich, Switzerland) Tel +41 1 972 20 59 Fax +41 1 972 20 69 http://norbert.ch List hosting with GNU Mailman on your own domain name http://cisto.com From barry@zope.com Fri Aug 23 15:07:33 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 23 Aug 2002 10:07:33 -0400 Subject: [Mailman-Developers] Bug #596565, mailman should use alphabetic U/GIDs References: <15717.27601.412066.574315@yyz.zope.com> <200208230831.g7N8VkX10527@quill.local> Message-ID: <15718.16805.241769.646867@anthem.wooz.org> >>>>> "NB" == Norbert Bollow writes: NB> Barry A. Warsaw wrote: >> Does this patch help make building, distributing, and moving >> Mailman easier for folks? NB> Yes, definately. A major server with lots of Mailman installs NB> died on us recently due to hardware problems. I had to do an NB> emergency move which got much more messy than expected because NB> I hadn't realised in time that all those wrapper scrips have NB> the numeric GID's compiled into them. (The symbolic GID's are NB> identical on both machines, but the numeric GID's weren't.) Cool. That's what I'm hoping. Can anybody see any security problems with this approach? I'm having a hard time seeing any holes, so I think it's a win. Oh BTW, the new (experimental) maildir delivery approach would also improve the independence by eliminating the mail wrapper at least. -Barry From Victoriano.Giralt@uma.es Fri Aug 23 12:01:36 2002 From: Victoriano.Giralt@uma.es (Victoriano Giralt) Date: Fri, 23 Aug 2002 13:01:36 +0200 Subject: [Mailman-Developers] Re: Anti-spam "killer app"? References: Message-ID: <3D661610.6030801@vgg.sci.uma.es> Satya wrote: > > I save false negatives to a folder named 'spam', and false positives > (none yet, I started with a huge 'clean' sample) to a folder > 'nonspam'. Every night (but I'll make it once a week now, since it's > very slow) I grab the two mbox files, and shove them through scripts. > Takes half an hour to run unattended. Takes milliseconds to do the > save-to-folder thing. The system caught 3 this morning. Excusme if I have lost part of the thread but, what are you using for all this nice filtering? -- Victoriano Giralt Systems Manager Central Computing Facility University of Malaga SPAIN From noreply@sourceforge.net Fri Aug 23 20:55:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Aug 2002 12:55:05 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-599112 ] UnboundLocalError: local variable 'sende Message-ID: Bugs item #599112, was opened at 2002-08-23 03:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=599112&group_id=103 Category: None Group: 2.1 beta >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Peer Heinlein (pheinlein) Assigned to: Nobody/Anonymous (nobody) Summary: UnboundLocalError: local variable 'sende Initial Comment: I used the last CVS from Thursday, Aug. 23, and some (all?) of my users get a bug-message when they try to confirm a heldmessage by clicking on the confirmation-link they got by mail. Peer Traceback (most recent call last): File "/usr/lib/mailman/scripts/driver", line 82, in run_main main() File "/usr/lib/mailman/Mailman/Cgi/confirm.py", line 141, in main heldmsg_prompt(mlist, doc, cookie, *content[1:]) File "/usr/lib/mailman/Mailman/Cgi/confirm.py", line 626, in heldmsg_prompt lang = mlist.getMemberLanguage(sender) UnboundLocalError: local variable 'sender' referenced before assignment ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-23 15:55 Message: Logged In: YES user_id=12800 Fixed, thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=599112&group_id=103 From noreply@sourceforge.net Fri Aug 23 21:03:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Aug 2002 13:03:23 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-596565 ] mailman should use alphabetic U/GIDs Message-ID: Bugs item #596565, was opened at 2002-08-17 17:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=596565&group_id=103 Category: configuring/installing Group: 2.1 beta >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Todd Vierling (tvierling) Assigned to: Barry A. Warsaw (bwarsaw) Summary: mailman should use alphabetic U/GIDs Initial Comment: In short: "compiling in numeric IDs is Very Evil." The long story: I'm trying to put together a packaging environment for NetBSD's "pkgsrc" to allow easy build and install of Mailman. Unfortunately, this is currently impossible thanks to the fact that alphabetic IDs are resolved to numerics at compile time. (Nearly all packages requiring cutstom IDs resolve them at runtime using get {pw,gr}nam(3)). Thanks to this behavior, it is not currently possible to: * create a prebuilt binary package of Mailman, and install it later on a system without the source tarball; * migrate an existing installation of Mailman to another system that has a uid/gid conflict without recompiling. There are other problems that compiled-in numeric IDs cause, but these two really stick out. I'm not a Pythonhead, so I don't claim to know how to fix this correctly. However, I've attached a diff for configure.in that sets the framework for the start of fixing this problem. In particular, the diff changes the MM_FIND_*_ID macros to report the ID that matched without resolving names to numbers, and allows the build to proceed if forced --with-{user,group}name options are specified and those IDs don't exist at build time. (The latter case helps autopackaging in systems like NetBSD's pkgsrc, where the IDs may be autocreated *between* the "configure" and "make install" phases.) The things that still need to be done include fixing the main scripts, and the checkperms logic, to cope with either numeric or alphabetic IDs; and possibly adding a runtime configuration of IDs (which really helps if the admin needs to reconfigure or change the mail or Web servers, while avoiding to rebuild Mailman). I openly welcome Python gurus to look into what's *really* needed to fix this.... ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-23 16:03 Message: Logged In: YES user_id=12800 I've thought about it more and I am going to apply this patch. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-22 18:45 Message: Logged In: YES user_id=12800 I like this idea a lot, even though the patch is far too incomplete. Fortunately, you motivated me to hack the code to support symbolic names instead of numeric ids. Attached is a patch I intend to commit for MM2.1b4. Would you please try it and see if it accomplishes what you need? One minor ugliness is that it retains --with-cgi-gid and --with-mail-gid as the configure switches to set the wrapper group names. Given the communities knowledge about these switches, I'm inclined not to change or deprecate them. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=596565&group_id=103 From Dale@Newfield.org Fri Aug 23 22:03:01 2002 From: Dale@Newfield.org (Dale Newfield) Date: Fri, 23 Aug 2002 17:03:01 -0400 (EDT) Subject: [Mailman-Developers] SQL MemberAdaptor implementation? In-Reply-To: <15714.52546.412600.418957@yyz.zope.com> Message-ID: On Tue, 20 Aug 2002, Barry A. Warsaw wrote: > The bit about "member keys" and lce's may be inaccurate. I think in > general the assumption is that an lce is the key to the member's > information, and I doubt you can use something more opaque. But you > could try it and we could fix breakages. I will try to make that opacity work. A question, though, is what conceptually that key should represent. Does it represent a user, or a user's subscription (which is a one-to-many relationship)? > The tricky part, and the part I'm less confident about, is that you need > to coordinate transaction boundaries through MailList.Load() and > MailList.Save(). Save() is essentially "commit", but we never Save() if > there's nothing to do, or if we don't have the list lock. Hrm. So you're suggesting that all modifications made through the writable interface be queued up in a transaction that isn't committed until .Save()? But then this could happen: Q: What is Bob's subscription style to XYZ.? A: normal Change him to digest mode. Q: What is Bob's subscription style to XYZ.? A: normal Basically it seems that the "don't commit until .Save()" and the "all state changes happen immediately" contradict one another... -Dale From Dale@Newfield.org Fri Aug 23 22:09:56 2002 From: Dale@Newfield.org (Dale Newfield) Date: Fri, 23 Aug 2002 17:09:56 -0400 (EDT) Subject: [Mailman-Developers] MemberAdaptor... modifications to API? In-Reply-To: <15714.54348.730519.621979@yyz.zope.com> Message-ID: On Tue, 20 Aug 2002, Barry A. Warsaw wrote: > DN> I guess what I'm suggesting is that instead of using this > DN> accessor like this: mlist.getMemberOption(addr, > DN> mm_cfg.OPTINFO['plain']), it be used like this: > DN> mlist.getMemberOption(addr, 'plain'), and inside > DN> OldStyleMemberships it does the mm_cfg.OPTINFO[] lookup. That > DN> way a Membership adaptor doesn't need to know that option "8" > DN> is DisableMime (but if it wants, it can find that the value > DN> option 'plain' is found by &'ing it's internal options > DN> bitarray with the value 8). > > The problem that I have with this approach is that it's much easier to > let a typo like mm_cfg.OPTINFO['plian'] slip through than to use a > symbolic constant. E.g. tools like Pychecker can verify that the > constant exists, but can't really do much with the string. So instead of accessing it through mm_cfg.OPTINFO[], let's make a function that verifies that its one argument is in mm_cfg.OPTINFO[], if so returning it's value, if not throwing an appropriate exception. That way you'd at least get a runtime error instead of a silent failure. > DN> I might alternately suggest that the values be bit locations, > DN> and the values to & be figured out with (1< DN> that at least the "option numbers" be ordinal rather than > DN> powers of two. That is more much less important (more a > DN> stylistic thing), though. > > That's not a bad alternative, and it preserves my desire for constants, > but I'm not sure it helps you much though. You still need to know what > values correspond to which options. Right. It's not a full solution, just (IMHO) better than what we've got :-) > Something like this is probably going to be too late for MM2.1. That's what I figured. > The best thing to do is to work out the patches and upload them to > SourceForge. At least there, they won't get lost in an inbox, and we > can re-examine them when MM2.1 final is released. I'm just gonna code them up in a CVS checkout, so that (barring hairy conflicts) I'll be able to generate a patch against the baseline whenever needed. -Dale From noreply@sourceforge.net Fri Aug 23 22:13:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Aug 2002 14:13:35 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-596456 ] TypeError: unsubscriptable object Message-ID: Bugs item #596456, was opened at 2002-08-17 11:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=596456&group_id=103 Category: None Group: 2.1 beta >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Simone Piunno (pioppo) Assigned to: Nobody/Anonymous (nobody) Summary: TypeError: unsubscriptable object Initial Comment: Aug 17 16:37:42 2002 (10524) Uncaught runner exception: unsubscriptable object Aug 17 16:37:42 2002 (10524) Traceback (most recent call last): File "/home/mailman21/Mailman/Queue/Runner.py", line 105, in _oneloop self._onefile(msg, msgdata) File "/home/mailman21/Mailman/Queue/Runner.py", line 154, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/home/mailman21/Mailman/Queue/CommandRunner.py", line 198, in _dispose res.process() File "/home/mailman21/Mailman/Queue/CommandRunner.py", line 93, in process stop = self.do_command(cmd, args) File "/home/mailman21/Mailman/Queue/CommandRunner.py", line 117, in do_command return self.do_command(cmd, args) File "/home/mailman21/Mailman/Queue/CommandRunner.py", line 119, in do_command return handler.process(self, args) File "/home/mailman21/Mailman/Commands/cmd_confirm.py", line 44, in process results = mlist.ProcessConfirmation(cookie, res.msg) File "/home/mailman21/Mailman/MailList.py", line 1096, in ProcessConfirmation subpart = email.Iterators.typed_subpart_iterator( TypeError: unsubscriptable object I was confirming by email to discard an held spam message. I suspect this problem is similar to #593454, related to python 2.2 compatibility ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=596456&group_id=103 From noreply@sourceforge.net Fri Aug 23 22:16:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Aug 2002 14:16:29 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-596361 ] rejection-notice not translated Message-ID: Bugs item #596361, was opened at 2002-08-17 02:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=596361&group_id=103 Category: Web/CGI Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: rejection-notice not translated Initial Comment: on the admindb screen, detailed description of the held messages include 'rejection-notice' field to be sent to the message sender but the default value in the text form is in english and not translated into the list-preferred language. Following short patch may work: --- admindb.py.orig Fri Aug 16 11:39:53 2002 +++ admindb.py Sat Aug 17 14:57:37 2002 @@ -595,8 +595,8 @@ t.AddRow([ Bold(_('If you reject this post,
please explain (optional):')), TextArea('comment-%d' % id, rows=4, cols=80, - text = Utils.wrap(msgdata.get('rejection-notice', - _('[No explanation given]')), + text = Utils.wrap(_(msgdata.get('rejection-notice', + _('[No explanation given]'))), column=80)) ]) row, col = t.GetCurrentRowIndex(), t.GetCurrentCellIndex() ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-23 17:16 Message: Logged In: YES user_id=12800 In general it's better to attach patches instead of pasting them in. SF doesn't preserve whitespace :( Updating this one so SF will send me the whitespace preserved patch in an email notification. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=596361&group_id=103 From noreply@sourceforge.net Fri Aug 23 22:27:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Aug 2002 14:27:57 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-554287 ] smart_address_match and .us Message-ID: Bugs item #554287, was opened at 2002-05-09 17:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=554287&group_id=103 Category: mail delivery Group: 2.1 beta >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Christopher Kolar (ckolar) Assigned to: Nobody/Anonymous (nobody) Summary: smart_address_match and .us Initial Comment: I know that it is noted in Defaults.py that the smart address needs to be fixed for international TLDs, but this is also broken for .us TLDs as well. I just wanted it to be in the bug log that this needs to be fixed for all of those people. Thanks, --ck ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-23 17:27 Message: Logged In: YES user_id=12800 This seems to fall into the general "I have two email addresses I want to post from", so I think the approach for MM2.1 is going to be, subscribe them both and disable the one you don't want to receive copies at. This just can't be done reliably enough, and eventually all their posting addresses will be in one subscription record. ---------------------------------------------------------------------- Comment By: Christopher Kolar (ckolar) Date: 2002-05-13 13:06 Message: Logged In: YES user_id=40678 Regardless, it is still a problem that someone@cpc.cps.k12.il.us gets bounced when someone@cps.k12.il.us is on the subscriber list. --chris ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-05-12 02:10 Message: Logged In: YES user_id=12800 Near as I can tell, SMART_ADDRESS_MATCH isn't really used any where, except in functions that are also not used any where. Am I missing something or can all this cruft be removed now? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=554287&group_id=103 From noreply@sourceforge.net Fri Aug 23 22:29:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Aug 2002 14:29:08 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-545956 ] digest mode dont recognize latin-1 Message-ID: Bugs item #545956, was opened at 2002-04-19 01:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=545956&group_id=103 Category: None >Group: 2.0.x Status: Open Resolution: Out of Date Priority: 5 Submitted By: Veronica Loell (mindtrader) Assigned to: Nobody/Anonymous (nobody) Summary: digest mode dont recognize latin-1 Initial Comment: We just started a list where we commicate in swedish and hence use åäö from Latin-1. One of the members have choosen digest-mode and we have discovered a problem. All our mails use latin-1, and in the non-digest form and also in the archives all charachters are displayed correctly. In digest form however, the letters äåö are marked as unknown, with their hex-numbers given. I have tested this by having both digest and non-digest delivered to me, using the same mailer etc. --------- Digest --------- Date: Thu, 18 Apr 2002 07:55:22 +0200 (W. Europe Daylight Time) From: Veronica Loell To: Subject: [cvs] =?ISO-8859- 1?Q?test_med_=E5=E4=F6?= Detta =E4r bara ett test f=F6r att utreda problemet med latin-1 i digestversionen. =C5=C4=D6 =E5=E4=F6 --------- Non-digest --------- Date: Thu, 18 Apr 2002 07:55:22 +0200 (W. Europe Daylight Time) From: Veronica Loell To: ag-cling- cvs@lists.sourceforge.net Subject: [cvs] test med åäö Detta är bara ett test för att utreda problemet med latin-1 i digestversionen. ÅÄÖ åäö ---------------------------------------------------------------------- Comment By: Veronica Loell (mindtrader) Date: 2002-04-24 01:16 Message: Logged In: YES user_id=156789 It seems that this problem also is present when posts are held for approval. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-04-19 14:40 Message: Logged In: YES user_id=12800 Well, now I'm not positive. Can you send a message to mailman-developers and see what other people think? ---------------------------------------------------------------------- Comment By: Veronica Loell (mindtrader) Date: 2002-04-19 14:04 Message: Logged In: YES user_id=156789 Actually mailman does handle it perfectly, it only happens in the digest mode. And it is also not the header that is the problem it's the body of the email. But if this has been corrected I'll report it to sourceforge because they apperantly are using an old version. I do get plenty of email where the header is messed up, but the rest of the message is not. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-04-19 13:53 Message: Logged In: YES user_id=12800 Mailman 2.1 will correctly handle non-ascii characters in headers. The problem is (probably) that the addition of the prefix breaks rfc2047 encoding of the non-ascii characters in the Subject: header. ---------------------------------------------------------------------- Comment By: Veronica Loell (mindtrader) Date: 2002-04-19 01:28 Message: Logged In: YES user_id=156789 I forgot to say. This is the listmanager managed by Sourceforge. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=545956&group_id=103 From Dale@Newfield.org Fri Aug 23 22:31:46 2002 From: Dale@Newfield.org (Dale Newfield) Date: Fri, 23 Aug 2002 17:31:46 -0400 (EDT) Subject: [Mailman-Developers] Re: External subscriber lists in 2.1 In-Reply-To: <15714.40627.779860.984053@anthem.wooz.org> Message-ID: On Tue, 20 Aug 2002, Barry A. Warsaw wrote: > Yes. Mailman 2.1 will work with Python 2.1.3 and beyond. The next > version will require at least Python 2.2.1. So if you want to also > support Py2.1, iterators and generators are out. Right. That's probably a good enough reason to not even attempt getting this in to Mailman2.1 (but I would like to eventually see it in Mailman rather than a patch, as patches suffer from bit-rot quickly in systems undergoing active development). > len(iterator) doesn't work (unfortunately, IMO). So maybe we're screwed > because we'd have to call list() on the thing to be able to give it to > len(). Or have another way to not ask for the data from the MemberAdaptor, but rather ask for the number of data items. (So we never need to call len() on the results.) > OTOH, if the iterator object we return has an __len__() method, we > should be okay. That's not a bad idea, but might make cause portability problems down the road... > | def getNumMembers(self, type, status, options, regexp=None): > | """Get the number of members of this mailing list matching type and > | status, and optionally matching the regular expression passed in. > > Would it be good enough to do something like the following: > > def getMatchingMembers(self, func): > """Return a list of members for which function evaluates true. > > For each member in the database, call func(), passing in the > member's subscribed address. If func() returns true, the address > is included in the returned list. > """ I don't want to have to pull the data for every possible match into Python to decide whether it should be included--I want to be able to ask the DB to decide that for us given specific constraints. > OTOH, it might be too flexible (it'd be hard to run this in a database > or translate to selects, etc.) Exactly. > so I'm willing to be persuaded. I'd like to present to this function all the relevant information so that it can decide internally who matches and who does not. The API I designed does fit that bill, although I'm certain it's probably not ideal. Please offer suggestions if there's anything in there that you'd like to see changed. For now I'll just run with what I've got. > Also getMatchingMembers() would have to return a list for Py2.1 > compatibility, but could return an iterator or generator in Py2.2+. While I hope few mailing lists have millions of subscribers, since we'd like this tool to be able to handle that, I think I'm going to use iterators/generators (now I have to go learn about them! :-). If you think it's important to have this work w/Py2.1, I am willing to be persuaded otherwise. -Dale From noreply@sourceforge.net Fri Aug 23 22:38:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Aug 2002 14:38:11 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-540978 ] List-* header multiline split bug Message-ID: Bugs item #540978, was opened at 2002-04-08 08:56 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=540978&group_id=103 Category: mail delivery Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Markus Mandalka (mandalka) Assigned to: Nobody/Anonymous (nobody) >Summary: List-* header multiline split bug Initial Comment: I have a list antiatomforum@lists.kommunikationssystem.de and others with long names. It seems that mailman can not handle with such long names, because in the subscribe-mail (which you have to answer to be in the list) the first columns are some things from the header (unsubscribe: xxx@lists.xxx and so on). Whith names like atest@lists.kommunikationssystem.de it works. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-23 17:38 Message: Logged In: YES user_id=12800 Changing the summary ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-08-15 00:37 Message: Logged In: NO I just installed mailman and can confirm this bug as well. When the list address + hostname is too long (in my case the listname was north-texas-stovebolters- club@stovebolt.stovebolt.com -- 52 characters total) the headers overflow into the body of the message. The "break point" was at the List Subscribe line: ******************* This is header: List-Subscribe: , (total of 94 characters before the split) ******************* This is body List-Unsubscribe: , List-Archive: List-Help: Sender: north-texas-stovebolters-club- bounces@stovebolt.stovebolt.com Errors-To: north-texas-stovebolters-club- bounces@stovebolt.stovebolt.com ************************ This is the initial text of the message that was posted. I'm sure that I'll be there. :-) **************************** It looks like there's a line break or line limit that's causing the problem. Perhaps it's line 33: MAXLINELEN = 78 The first line that breaks (in my case) is a line that has 94 characters in the first part, none of which can be separated (no spaces or line breaks, just continuous text.) The very next line drops to the body. I believe giuans is correct that the problem is in the wrap section of the code, because the break occurs immediately after a comma, which, if I'm understanding the code correctly, is inserted by the program after an overlength line occurs, to split the line at 78 (or as close to that as it can get.) I think the correct fix would be to add the "h" portion subsequent to the split so that each line in the header would have the required semi-colon to indicate that it's header. If the MTA sees a line with no semicolon, it's going to think that it's body text, not header. ***************** Present code: if len(h) + 2 + len(v) > 78: v = CONTINUATION.join(v.split(', ')) msg[h] = v ****************** Possible fix if len(h) + 2 + len(v) > 78: v=CONTINUATION.join(h + v.split(',')) msg[h] = v or something like that. (I haven't worked with php, so I'm not familiar with its functions and syntax.) The idea is to split a line like this: Line exceeds 78 characters? h+v, h+ rest of v HTH. ---------------------------------------------------------------------- Comment By: Jean Millerat (drsigmund) Date: 2002-07-04 04:13 Message: Logged In: YES user_id=70686 I have reached the same bug with mailing list adresses such as <11 characters>@<30 characters> whereas <8 characters>@<30 characters> works properly. The effect of this bug is that the headers of the subcription annoucement or any further email from the list are "mangled" as was said on [mailman-developers]. As an example when one of the List-* header line is too long, it is broken in two parts (and the second part is indented). Since then, Outlook (and I suppose other email clients) think this second part of the broken header line is the beginning of the body of the message. Therefore the remaining headers are sent as part of the body of the message ! I think this bug does not only occur with too long email adresses but may occur with too long header lines whichever line it is (even with the Subject line especially when this subject line is very long because of quoted-printable characters). See [mailman-developers] for the description of maybe the same bug, in mails dealing with headers being "mangled". My current workarounds : - using short mailing list names. - and not sending quoted-printable characters within subject lines. ---------------------------------------------------------------------- Comment By: Giovanni Lopedote (giuans) Date: 2002-05-02 10:27 Message: Logged In: YES user_id=531451 I've found it. A fast fix for is to comment lines 149-150 in Mailman/Handlers:/CookHeaders.py: --- CookHeaders.py 2002-05-02 14:51:36.000000000 +0200 +++ CookHeaders.py.new 2002-05-02 16:12:09.000000000 +0200 @@ -146,8 +146,8 @@ # Wrap these lines if they are too long. 78 character width probably # shouldn't be hardcoded, but is at least text-MUA friendly. The # adding of 2 is for the colon-space separator. - if len(h) + 2 + len(v) > 78: - v = CONTINUATION.join(v.split(', ')) +# if len(h) + 2 + len(v) > 78: +# v = CONTINUATION.join(v.split(', ')) msg[h] = v # Always delete List-Archive header, but only add it back if the list is # actually archiving Tested with Mailman 2.1b1, Source Mage GNU/Linux 2.4.18, Postfix 1.1.7. I know there should be a better way, but I'm not a Python programmer at all. :) ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-04-11 18:03 Message: Logged In: YES user_id=12800 I've confirmed this bug, but don't have a fix for it right now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=540978&group_id=103 From noreply@sourceforge.net Fri Aug 23 22:55:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Aug 2002 14:55:45 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-517192 ] 2.0.8 borks on dot in local part of addr Message-ID: Bugs item #517192, was opened at 2002-02-13 16:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=517192&group_id=103 Category: mail delivery Group: 2.0.x >Status: Pending >Resolution: Works For Me Priority: 5 Submitted By: CrackMonkey (monkeymaster) Assigned to: Nobody/Anonymous (nobody) Summary: 2.0.8 borks on dot in local part of addr Initial Comment: In a mail address's local part (the part to the left of the at sign), it is perfectly valid to have periods. However, mailman stops reading the address right at the @, so that "mr.bad@pigdog.org" is shown as "mr.bad". this is disastrous for lists where only subscribers are allowed to post, since the system doesn't allow for exceptions that lack an @ and a FQDN. Either allowing exceptions to be of a more forgiving format, or fixing the broken regex that truncates the mail addresses would solve my problem. I'm getting tired of moderating a legitimate user's posts, especially since the system won't even send the warnings to the correct address. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-23 17:55 Message: Logged In: YES user_id=12800 I simply can't reproduce this problem with Python 2.2.1 and current cvs of Mailman 2.1 beta 3+ I subscribed an address like barry.warsaw@python.org (Barry Warsaw, Jr.) and then sent a message coming from that address and it went through just fine. Unless we can get more information, I'm going to have to close this report. Moving it to Pending status in lieu of follow ups. ---------------------------------------------------------------------- Comment By: CrackMonkey (monkeymaster) Date: 2002-05-07 00:43 Message: Logged In: YES user_id=76237 Oh, and for what it's worth, I applied that patch as well to my 2.1 copy, so there's no chance that's screwing this up (it's pretty definitely running 2.2.1 now, which doesn't have that 2822 problem) ---------------------------------------------------------------------- Comment By: CrackMonkey (monkeymaster) Date: 2002-05-06 23:01 Message: Logged In: YES user_id=76237 mr.bad@pigdog.org *is* a member of the list, but those headers cause mailman to tell me: List: CrackMonkey@crackmonkey.org From: mr.bad Subject: %^$!$^$%!! W32.Elkern and Kin Reason: Post by non-member to a members-only list Note the lack of an @ or FQDN in the From: Yes, I am using python 2.2.1 ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-05-06 22:59 Message: Logged In: YES user_id=12800 I don't quite understand, are you saying that even though "mr.bad@pigdog.org" is a member of the list, this message is being not matching as being posted from a member? Under Python 2.2.1? ---------------------------------------------------------------------- Comment By: CrackMonkey (monkeymaster) Date: 2002-05-06 22:37 Message: Logged In: YES user_id=76237 So when testing the 2.2.1 Python, I see the difference. However, the following headers cause it to reject "mr.bad" as a non-subscriber: Received: from mail15.speakeasy.net (mail.speakeasy.net) [216.254.0.215] by zork.zork.net with esmtp (Exim 3.35 #1 (Debian)) id 174ukJ-0000VO-00; Mon, 06 May 2002 19:30:31 -0700 Received: (qmail 3123 invoked from network); 7 May 2002 02:30:29 -0000 Received: from unknown (HELO tyrell) ([66.217.50.46]) (envelope-sender ) by mail15.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 7 May 2002 02:30:29 -0000 Received: from evan by tyrell with local (Exim 3.35 #1 (Debian)) id 174uii-0002m8-00 for ; Mon, 06 May 2002 22:28:52 -0400 To: crackmonkey@crackmonkey.org Subject: %^$!$^$%!! W32.Elkern and Kin From: Mr. Bad Organization: Pigdog Journal X-PGP-Fingerprint: 91F8 6B2D EBEA 8D7A 3F20 E5B0 6D97 B3BC F498 A1D9 X-Revolutionary-Date: Septidi, 17 Flore'al 210 9:25:94 -20833 Date: Mon, 06 May 2002 22:28:48 -0400 Message-ID: <878z6wofmn.fsf@tyrell.bad-people-of-the-future.san-francisco.ca.us> Lines: 27 User-Agent: Gnus/5.090005 (Oort Gnus v0.05) Emacs/21.1 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-05-03 00:08 Message: Logged In: YES user_id=12800 monkeymaster, please try the patch, or include a Python 2.2.1 session that shows the bug still exists. I believe this bug report should be marked closed. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-05-03 00:07 Message: Logged In: YES user_id=12800 BTW, I'm attaching the patch to Python 2.1.3's rfc822.py that I plan on checking in momentarily. This backports the Python 2.2.1 patch for the problem, and with this, my 2-line example below also succeeds for Python 2.1.3. If there's ever a Python 2.1.4, this patch will be part of it. ---------------------------------------------------------------------- Comment By: Dan Mick (dmick) Date: 2002-05-02 23:18 Message: Logged In: YES user_id=10725 I can echo that Python 2.2 doesn't have the parseaddr problem. monkeymaster, can you try Barry's two-line experiment and see if that works or fails? ---------------------------------------------------------------------- Comment By: CrackMonkey (monkeymaster) Date: 2002-04-29 18:21 Message: Logged In: YES user_id=76237 This happens even when I use python 2.2 ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-04-27 12:34 Message: Logged In: YES user_id=12800 This is really a bug with earlier versions of Python, I believe. MM2.0.x uses the standard library function rfc822.parseaddr() to break and address into its realname + email constituent parts. Here are some examples: % python Python 2.2.1 (#1, Apr 22 2002, 17:14:12) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from rfc822 import parseaddr >>> parseaddr('Mr. Bad ') ('Mr. Bad', 'mr.bad@pigdog.org') % python2.1 Python 2.1.3 (#1, Apr 22 2002, 18:17:38) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Type "copyright", "credits" or "license" for more information. >>> from rfc822 import parseaddr >>> parseaddr('Mr. Bad ') ('', 'Mr.Bad') So this is clearly broken in Python 2.1.3, and works in Python 2.2.1. I'll look at backporting the fix to Python 2.1 in case there's ever a 2.1.4. But if you're using an earlier version of Python, this will still be broken. Consider upgrading to Python 2.2.1. ---------------------------------------------------------------------- Comment By: CrackMonkey (monkeymaster) Date: 2002-04-26 15:54 Message: Logged In: YES user_id=76237 The bug turns out not to be when there is a period in the address, but in the plain text name. The mail address in question is: Mr. Bad I realized this when I saw people who had different text names from their e-mail addresses, as in: Jr. Pickle This would show up as the mythical address "jr.pickle" in mailman, and things would b0rk. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-03-14 14:18 Message: Logged In: YES user_id=12800 Either I need more information, or this problem is fixed in MM2.1. Quite often I uses test addresses like "barry.warsaw@" and I've had no problems with it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=517192&group_id=103 From noreply@sourceforge.net Fri Aug 23 22:57:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Aug 2002 14:57:03 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-449677 ] HyperArch.py assumes charsets are in \w+ Message-ID: Bugs item #449677, was opened at 2001-08-09 21:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=449677&group_id=103 Category: Pipermail >Group: 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: Ben Gertzfield (che_fox) Assigned to: Nobody/Anonymous (nobody) Summary: HyperArch.py assumes charsets are in \w+ Initial Comment: Using Mailman 2.0.6, I noticed that Japanese messages in charset iso-2022-jp are not archived correctly; their subject lines stay in MIME-encoded format, like Subject: =?ISO-2022-JP?B?WxskQiQqTD5BMBsoQi5jb21dLmNvbS8uag==?= etc. I tracked this down to the following line in HyperArch.py:158 # content-type charset rx_charset = re.compile('charset="(\w+)"') This is incorrect. According to the de-facto list of charsets at http://www.iana.org/assignments/character-sets charsets can have all sorts of characters outside of [a-zA-Z0-9_] , such as - ( ) : . etc. So, we must accept anything between the quotes with a fuzzy .+? match, instead of forcing \w+. Patch attached, against Mailman 2.0.6. ---------------------------------------------------------------------- Comment By: Ben Gertzfield (che_fox) Date: 2001-08-09 22:53 Message: Logged In: YES user_id=89313 Note: this is the solution to the problem in Bug #431511. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=449677&group_id=103 From noreply@sourceforge.net Fri Aug 23 22:57:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Aug 2002 14:57:32 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-431511 ] charset="Windows-1252" in archive Message-ID: Bugs item #431511, was opened at 2001-06-08 18:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=431511&group_id=103 Category: Pipermail >Group: 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: Ingimar Robertsson (iar) Assigned to: Nobody/Anonymous (nobody) >Summary: charset="Windows-1252" in archive Initial Comment: The archives seem to have trouble with Windows-1252 encoding. This is from the headers of such message: Content-Type: text/plain; charset="Windows-1252" Subject: [F1] =?Windows-1252?Q? RE=3A_=5BF1=5D_=5BF1=5D_Sp=E1_fyrir_Monako?= The Subject appears like this in the archives instead of being decoded. Don't know if this is a bug with the email client or Mailman but thought I'd mention it, there seems to be a lot of these things acording to a Google search for Mailman and Windows-1252. ---------------------------------------------------------------------- Comment By: Ben Gertzfield (che_fox) Date: 2001-08-09 21:31 Message: Logged In: YES user_id=89313 The bug is in HyperArch.py line 158. Check out the patch attached to bug report #449677 at http://sourceforge.net/tracker/index.php?func=detail&aid=449677&group_id=103&atid=100103 -- actually, I just realized I should upload it to the Patches section as well, and will do so now. The problem is that HyperArch.py assumes charsets are in the form \w+ (a-z A-Z 0-9 _ only). But they can and do have other characters like -, as you've seen. The patch is to replace "\w+" in HyperArch line 158 with: ".+?" This will make it match any character non-greedily up to the next ", without going past it. Hope this helps! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=431511&group_id=103 From noreply@sourceforge.net Fri Aug 23 23:24:55 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Aug 2002 15:24:55 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-443952 ] add subject to mailto link in archive Message-ID: Bugs item #443952, was opened at 2001-07-23 19:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=443952&group_id=103 Category: Pipermail >Group: 2.1 beta >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Stig Hackvan (hackvan) Assigned to: Nobody/Anonymous (nobody) Summary: add subject to mailto link in archive Initial Comment: subjects should be specified in mailto links where appropriate. example: if i'm browsing, say, the email archive for linux/tulip drivers at http://www.scyld.com/pipermail/tulip/2001- April/003370.html and i wish to reply by clicking on becker@scyld.com, then it's 99% probable that i want the subject to be specified as "Re: [tulip] Any sucess with Conexant miniPCI (presario notebooks) on Linux?" ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-23 18:24 Message: Logged In: YES user_id=12800 I've applied Nicholas Russo's patch for MM2.1b4. ---------------------------------------------------------------------- Comment By: Nicholas Russo (narusso) Date: 2002-04-19 20:46 Message: Logged In: YES user_id=118704 see patch number 546362 While looking through instantiations of article.html, I noticed some mailto urls use the character encoding for '@' and others do not. I presume this is arbitrary? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-04-19 18:51 Message: Logged In: YES user_id=12800 I'll accept a patch for this, but I have little enthusiasm to work up the patch myself. Care to submit one? ---------------------------------------------------------------------- Comment By: Nicholas Russo (narusso) Date: 2002-04-18 00:09 Message: Logged In: YES user_id=118704 Unfortunately, the resolver of a mailto URL is not expected to respect an embedded In-Reply-To header, which would preserve the threading information. Failing that, a Subject header would at least be a start. ---------------------------------------------------------------------- Comment By: Stig Hackvan (hackvan) Date: 2001-07-25 05:27 Message: Logged In: YES user_id=17610 hypermail does this, by the way... an example link is mailto:becker@scyld.com?Subject=Re:%20[tulip]%20Conexant% 20LANfinity&In-Reply-To= ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=443952&group_id=103 From noreply@sourceforge.net Fri Aug 23 23:25:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Aug 2002 15:25:08 -0700 Subject: [Mailman-Developers] [ mailman-Patches-546362 ] Includes subject in mailto links Message-ID: Patches item #546362, was opened at 2002-04-19 20:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=546362&group_id=103 Category: Pipermail >Group: Mailman 2.1 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Nicholas Russo (narusso) Assigned to: Nobody/Anonymous (nobody) Summary: Includes subject in mailto links Initial Comment: Each article in an archive lists the original sender in a mailto url at the top of the page and in the html headers. These urls could also contain the subject of the message, and the message id so the MUA may automatically set the In-Reply-To header and Subject line when resolving the url. The first diff should be used for the article.html template in each language. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-23 18:25 Message: Logged In: YES user_id=12800 This will be applied to MM2.1beta4 ---------------------------------------------------------------------- Comment By: Nicholas Russo (narusso) Date: 2002-04-20 12:09 Message: Logged In: YES user_id=118704 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=546362&group_id=103 From noreply@sourceforge.net Fri Aug 23 23:26:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Aug 2002 15:26:26 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-427421 ] Configure script problem on Mac OS X. Message-ID: Bugs item #427421, was opened at 2001-05-25 17:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=427421&group_id=103 Category: configuring/installing >Group: 2.0.x Status: Open Resolution: Works For Me Priority: 3 Submitted By: Deniau Thomas (thdeniau) Assigned to: Thomas Wouters (twouters) Summary: Configure script problem on Mac OS X. Initial Comment: I can't run configure on Mac OS X 10.0.3 (Darwin 1.3.3). When I run it as root I get : checking for --with-var-prefix... no checking for --with-username... mailman checking for mailman UID... ./configure: permission denied: conftest.py [1152] /usr/local/bin/python: can't open file 'conftest.py' cat: conftest.out: No such file or directory configure: error: ***** No "mailman" user found! ***** Your system must have a "mailman" user defined ***** (usually in your /etc/passwd file). Please see the INSTALL ***** file for details. And when I run it as a normal user :: checking for --with-var-prefix... no checking for --with-username... sh: setgroups: Operation not permitted thomas checking for thomas UID... 501 checking for --with-groupname... mailman ---------------------------------------------------------------------- Comment By: Deniau Thomas (thdeniau) Date: 2002-04-29 03:43 Message: Logged In: YES user_id=43625 Yep, with mailman 2.0.10 / Mac OS X 10.1.4 I've still this error when configuring as normal user : checking for --with-var-prefix... no checking for --with-username... sh: setgroups: Operation not permitted I've to chown and su mailman the sources dir to make it work. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-04-28 17:50 Message: Logged In: YES user_id=12800 There hasn't been any new information on this bug in a long time. Is this a problem? ---------------------------------------------------------------------- Comment By: Deniau Thomas (thdeniau) Date: 2001-06-04 18:59 Message: Logged In: YES user_id=43625 The original problem (configure on mac OS X) isn't fixed. The configure script only works if you su mailman and chown mailman the sources dir before doing configure. There is still an odd bug with conftest.py if you su root before configuring ... ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2001-06-04 14:36 Message: Logged In: YES user_id=12800 I suspect you might not be running qrunner properly from cron. Please read the README files about how to set this up. In any event, I'm closing this bug report, since the original problem (configure on MacOSX) seems to be solved. If you think you have another bug related to sending mail, please submit a new bug report. ---------------------------------------------------------------------- Comment By: Deniau Thomas (thdeniau) Date: 2001-05-30 07:57 Message: Logged In: YES user_id=43625 [thomac:~] thomas% cat > conftest.py print "hello world" [thomac:~] thomas% python conftest.py hello world this works ... OK, I've checked out the stable version ... make works perfectly, but I don't get the welcome mail when I create a new test list. i'm using Postfix as MTA and my aliases are correctly setup. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-05-30 06:58 Message: Logged In: YES user_id=34209 Oops, again. I should have been more explicit in checking out the CVS tree: if you want a stable Mailman, you should check out Mailman using cvs -d co -rRelease_2_0_1-branch mailman (after moving the old 'mailman' directory asside.) The head of the CVS tree is for Mailman 2.1, and is probably best described as "pleasantly unstable", not quite unlike Barry's poems :) The 2.0.1 release branch is currently 2.0.5 plus a few bugfixes, including the PREFIX one. I'm still stumped about the conftest.py failure, though. Can you create a file 'conftest.py' with a few lines of Python code ("print 'hello world'" will do) and try to execute it using "/usr/local/bin/python conftest.py" ? I wonder if it might be a problem with your python, in that it doesn't understand current working directories and such. (In fact.... Wasn't there a thread on python-dev not so long ago about how MacOS didn't have the concept of a current working directory ? :) ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2001-05-29 14:40 Message: Logged In: YES user_id=12800 Maybe you have an old version of mimelib? In version 0.3 the ReprMixin class was renamed to StringableMixin. ---------------------------------------------------------------------- Comment By: Deniau Thomas (thdeniau) Date: 2001-05-29 14:34 Message: Logged In: YES user_id=43625 hMmm ... i've tried with cvs. I installed mimelib and now, the compilation of common.c runs properly, but now I get the error : Traceback (most recent call last): File "bin/update", line 46, in ? from Mailman import MailList File "/usr/local/mailman/Mailman/MailList.py", line 42, in ? from Mailman.ListAdmin import ListAdmin File "/usr/local/mailman/Mailman/ListAdmin.py", line 33, in ? from Mailman import Message File "/usr/local/mailman/Mailman/Message.py", line 26, in ? from mimelib.StringableMixin import StringableMixin ImportError: No module named StringableMixin And there's still the configure problem. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-05-29 14:12 Message: Logged In: YES user_id=34209 D'oh! I just realized what the difference is... I'm using the current CVS tree, in which I fixed at least the PREFIX bug. I'm guessing you aren't. Can you try the CVS tree ? If you don't have access to cvs on your darwin box, let me know and I'll mail you a .tgz of a current snapshot. ---------------------------------------------------------------------- Comment By: Deniau Thomas (thdeniau) Date: 2001-05-29 12:37 Message: Logged In: YES user_id=43625 make -v GNU Make version 3.79, by Richard Stallman and Roland McGrath. Built for powerpc-apple-darwin1.0 Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. cc -v Reading specs from /usr/libexec/gcc/darwin/ppc/2.95.2/specs Apple Computer, Inc. version gcc-926, based on gcc version 2.95.2 19991024 (release) and for the configure problem : i'm able to sudo ... and even as root, the install fails. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-05-29 12:28 Message: Logged In: YES user_id=34209 One thing that might matter is that I had root-privs, meaning that I was allowed to do sudo. Other than that, I do the exact same thing as you, and it really works fine. The other problem is even stranger! The 'cc' line you quote has the -DPREFIX= line, which defines 'PREFIX', but then cc complains that it isn't defined ?? What version of cc and make are you using ? it worked fine with: [localhost:~/mailman-2.0] thomas% cc -v Reading specs from /usr/libexec/gcc/darwin/ppc/2.95.2/specs Apple Computer, Inc. version gcc-926, based on gcc version 2.95.2 19991024 (release) [localhost:~/mailman-2.0] thomas% make -v GNU Make version 3.79, by Richard Stallman and Roland McGrath. Built for powerpc-apple-darwin1.0 if your make doesn't report the version on -v, you're using BSD make (aka 'bsdmake' on darwin.) Try running 'gnumake' -- it wouldn't be the first weirdness being solved by using gmake instead of bsdmake :) ---------------------------------------------------------------------- Comment By: Deniau Thomas (thdeniau) Date: 2001-05-29 12:19 Message: Logged In: YES user_id=43625 HFS+ filesystem, too. I've the problem on a fresh download : the file conftest.py doesn't exist. Even I if chmod -R 777 the mailman folder, this doesn't work. The only way to configure properly is to chown the repertory to mailman and to run the configure as mailman, or to chown -R 777 continuously while configure runs. Very very odd. Maybe because HFS+ is case-insensitive ... And, even if I run configure as mailman, make install fails : cc -c -I. -DPREFIX="\/usr/local/mailman\" -DPYTHON="\/usr/local/bin/python\" -DHELPFUL -g -O2 -g -O2 -DHAVE_STRERROR=1 -DHAVE_SETREGID=1 -DHAVE_SYSLOG=1 -DSTDC_HEADERS=1 -DHAVE_SYSLOG_H=1 -DGETGROUPS_T=gid_t -DHAVE_VSNPRINTF=1 ./common.c ./common.c:26: `PREFIX' undeclared here (not in a function) ./common.c:26: `scripts' undeclared here (not in a function) ./common.c:26: parse error before `;' make[1]: *** [common.o] Error 1 ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-05-29 12:02 Message: Logged In: YES user_id=34209 It works fine on my colleague's darwin 1.3.3, on a HFS+ filesystem. I suspect that you have a 'conftest.py' leftover from a previous run, and with odd permissions. Try deleting it, and see if that helps. You do need to make a 'mailman' user and group, though, just like the README says. I didn't want to totally screw my colleague's machine (he sits within striking distance of me) so I didn't actually install, but configure and make both went fine. (Contrary to compiling Python... Cost me a good two hours to compile python on the box :) ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-05-29 09:30 Message: Logged In: YES user_id=34209 Going to check on this on my colleague's MacOS X box. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=427421&group_id=103 From noreply@sourceforge.net Fri Aug 23 23:26:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Aug 2002 15:26:54 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-419992 ] bin/arch messed up existing web archive Message-ID: Bugs item #419992, was opened at 2001-04-29 14:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=419992&group_id=103 Category: Pipermail >Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Bernhard Reiter (ber) Assigned to: Nobody/Anonymous (nobody) Summary: bin/arch messed up existing web archive Initial Comment: When running arch and webpages still exists, the web archive is messed up. This is quite confusing. A warning should be printed if arch is started on a list where there is already stuff in the web archive. Optionally it could delete the files is is regenerating first. Details: arch seems to attach each mail again to the .txt monthly archive files here and then build the web archive out of this. No wonder that the mail I deleted is still in after the process.... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=419992&group_id=103 From noreply@sourceforge.net Fri Aug 23 23:28:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Aug 2002 15:28:24 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-231776 ] Digest From address causing mail loop Message-ID: Bugs item #231776, was opened at 2001-02-09 17:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=231776&group_id=103 Category: mail delivery >Group: 2.0.x >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: D.J. Atkinson (deejster) Assigned to: Nobody/Anonymous (nobody) Summary: Digest From address causing mail loop Initial Comment: Synopsis: Request that "From" address for digest distributions be changed from -request to -owner I just had a situation where: 1) Digest went out 2) The user at remote.com was unknown (for whatever reason) 3) mdaemon@remote.com replied to the digest From address ("list-request@here.com") 4) the MM request processor said "your commands don't make sense" and sent it back to mdaemon@remote.com 5) mdaemon@remote.com [which apparently is also a command processor] said "your commands don't make sense" and sent it back to list-request@here.com 6) 4 & 5 get repeated ad-infinitum and the message grows like a snowball rolling down a mountain. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-23 18:28 Message: Logged In: YES user_id=12800 This should be fixed in MM2.1 through various techniques, including not autoresponding to Priority: {junk,list,bulk} messages, and a built-in governor maxing out the number of responses sent to any one address per day. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=231776&group_id=103 From noreply@sourceforge.net Fri Aug 23 23:30:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Aug 2002 15:30:57 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-230400 ] German Umlaute mess up subject-line and body Message-ID: Bugs item #230400, was opened at 2001-01-29 11:49 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=230400&group_id=103 Category: mail delivery >Group: 2.0.x >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Thomas Franosch (tfra) Assigned to: Nobody/Anonymous (nobody) Summary: German Umlaute mess up subject-line and body Initial Comment: These characters (ö, ä, ü and probably even others) in the subject-line lead to a multiplication of the [listname] and Re: when one replies to such a mail. This is not because of a crapy mailer. The more replies, the longer the subject-line gets (if the author doesn not delete it manually). The characters in the subject-line actually get displayed correctly. Unfortunately, the use of them in the body leads to an unreadable mess as has already been posted here earlier. Needless to say that both these phenomenons are very annoying for actually at least every German list that runs mailman! ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-23 18:30 Message: Logged In: YES user_id=12800 I believe all this stuff works much better in the latest MM2.1 betas. Please resubmit a bug report if you find problems with MM2.1 ---------------------------------------------------------------------- Comment By: Johan Holmberg (holmberg) Date: 2001-05-08 17:43 Message: Logged In: YES user_id=215003 The problems with non-ASCII characters in the Subject line can be fixed by applying my patch: ....[ #422468 ] Avoid multiple prefixes in Subject /Johan Holmberg ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=230400&group_id=103 From noreply@sourceforge.net Fri Aug 23 23:31:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Aug 2002 15:31:12 -0700 Subject: [Mailman-Developers] [ mailman-Patches-422468 ] Avoid multiple prefixes in Subject Message-ID: Patches item #422468, was opened at 2001-05-08 17:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=422468&group_id=103 Category: None >Group: Mailman 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: Johan Holmberg (holmberg) Assigned to: Nobody/Anonymous (nobody) Summary: Avoid multiple prefixes in Subject Initial Comment: Mailman often erroneously add more than one "list-prefix" to the Subject line if the Subject contains non-ASCII characters. Before adding a prefix Mailman tries to see if there already is a prefix (for example in the case of a reply to an earlier post to the same list). But Mailman is not "aware" that the prefix can be buried in the MIME-encoded part of the line. Therefore Mailman can add a 2nd prefix. The receiving mail client sees two prefixes after decoding the MIME stuff. In the next reply to the list we can get three prefixes, and so on .... And example Subject line can look like: Subject: Re: [Test] Re: [Test] Re: [Test] räkmsörgås The solution is to: - MIME-decode the subject - add list-name-prefix (if it isn't already there) - MIME-reencode the subject I have reported this solution earlier to "mailman-developers", see: http://mail.python.org/pipermail/mailman-developers/2001-April/004007.html The problems I describe here has been reported as bug #230400: [ #230400 ] German Umlaute mess up subject-line and body I attach my patch below. I have used it successfully on 2.0.1, and the file patched hasn't changed from 2.0.1 to 2.0.5. /Johan Holmberg ---------------------------------------------------------------------- Comment By: Dmitry Kohmanyuk (dk379) Date: 2002-03-10 02:30 Message: Logged In: YES user_id=15044 the patch I have mentioned is available with bug 528031. there is another patch in bug 498766 which can fix the same problem, but it seems to be for 2.1 version. ---------------------------------------------------------------------- Comment By: Dmitry Kohmanyuk (dk379) Date: 2002-03-10 02:07 Message: Logged In: YES user_id=15044 this patch does not seem to work with koi8-r encoding; I am submitting another which was done by vaget at vaget.org and then beautified by me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=422468&group_id=103 From noreply@sourceforge.net Fri Aug 23 23:33:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Aug 2002 15:33:58 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-229568 ] Pipermail won't resolve author names of aol.com addresses Message-ID: Bugs item #229568, was opened at 2001-01-20 22:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=229568&group_id=103 Category: Pipermail >Group: 2.1 beta Status: Open Resolution: Works For Me Priority: 5 Submitted By: Aharon Varady (aharon) Assigned to: Nobody/Anonymous (nobody) Summary: Pipermail won't resolve author names of aol.com addresses Initial Comment: Pipermail does not resolve the "author" of emails sent from aol.com. Instead, Pipermail gives the email address of the listserve. For example: "John" is resolved by pipermail as: listname@foo.com and not as John. This bug only occurs for users of aol.com addresses. ---------------------------------------------------------------------- Comment By: Terri Oda (spot) Date: 2002-07-02 16:00 Message: Logged In: YES user_id=110886 Whoops. Diffed the wrong thing. That's what happens when I try to patch code but haven't slept in a few days. This actually works better: 180c180 < if e is not None: --- > if e is not None and self.email == "": ---------------------------------------------------------------------- Comment By: Terri Oda (spot) Date: 2002-07-01 14:03 Message: Logged In: YES user_id=110886 The problem is that it defaults to using the reply-to address if it's set, and this isn't what we want when the reply-to is always being set by the list. Take a careful look at the rest of your archives and you'll probably note that *everyone's* email address is showing up as listname@foo.com. It's a nice anti-spam feature, perhaps, but probably not what you want. Here's a quick fix for pipermail.py: 180c180 < if e is not None: --- > if e is not None and self.email is None: This just changes it so that it defaults to the From: address (when it's set) rather than the Reply-to address. If there's some particular reason to take the Reply-To over the From, I can make something which actually checks to see if the reply-to is being set by the list, but this should solve your problem for the moment. Terri ---------------------------------------------------------------------- Comment By: Ava Jarvis (katanalynx) Date: 2002-06-10 22:14 Message: Logged In: YES user_id=561110 This bug -- for version 2.0.11 at least -- seems to occur when 'from' only contains the email address. There's some code in pipermail.py (version 2.0.11), line 177: # Figure out the e-mail address and poster's name self.author, self.email = message.getaddr('From') e = message.getheader('Reply-To') if e is not None: self.email = e self.email = strip_separators(self.email) self.author = strip_separators(self.author) if self.author == "": self.author = self.email If reply-to is set, then it is always taken as the author's email address. However, some lists set the reply-to field to be, for instance, the list address.... and you can guess what happens next when there is no name comment/author. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-06-06 12:09 Message: Logged In: NO This comment doesn't directly address the case you report, but it might be related so I thought it worthwhile to submit. I see you are using MM2.0.9. I saw a similar problem with MM2.1b1, which was fixed in MM2.1b2. The problem then was that an address with a name "comment" would be displayed in the archive as the list name, whereas an address with a name comment would be displayed (properly) with the name. Example: "John Doe" jdoe@whereever.com displayed as "John Doe" whereas jdoe@whereever.com displayed as the list name. In your comment, you use an example with a name comment of "John", but in the example you provided there is no name comment field, so perhaps my statements here do apply. ---------------------------------------------------------------------- Comment By: Aharon Varady (aharon) Date: 2002-06-05 21:37 Message: Logged In: YES user_id=139355 Well, this remains (and has always been) a problem for my lists. I have never had a user posting with an aol.com address that this hasn't been the case with. Currently my solution is to replace the wrong address shown (philly_ambient@phobos.serve.com) with a generic or balnk mark. Here is the html source of a typical email from our pipermail archive, and below it the source email with headers. ------------------------------------------------------------- [Philly_ambient] tool!

    [Philly_ambient] tool!

    Posted by . . . .. . . . on Mon Jun 3 23:17:02 2002 

    hey all
a friend can get me some free tickets to see TOOL on monday
august 12 at 
sovereign bank arena in trenton. i know mondays suck, but oh
well. is anyone 
here into going?  if so, contact me privately.  i know it's
not ambient, but 
neither is some of what we discuss here :)
let me know asap, please

gina

  • Previous message: [Philly_ambient] Noise Deafinitions and playlist
  • Next message: [Philly_ambient] Do you hear what I hear? (re: noise deaf)
  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
    • --------------------------------------------------------------------- Here is the original email with headers: --------------------------------------------------------------- >From - Tue Jun 04 01:16:56 2002 X-UIDL: m;n!!9'f!!a2E"!3;D"! X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: aharon@phobos.serve.com Received: from phobos.serve.com (localhost.localdomain [127.0.0.1]) by phobos.serve.com (Postfix) with ESMTP id 6BC4D52D2B; Mon, 3 Jun 2002 23:17:06 -0400 (EDT) Delivered-To: philly_ambient@phobos.serve.com Received: from imo-r06.mx.aol.com (imo-r06.mx.aol.com [152.163.225.102]) by phobos.serve.com (Postfix) with ESMTP id 6F82F52D1D for ; Mon, 3 Jun 2002 23:16:46 -0400 (EDT) Received: from Mistsojorn@aol.com by imo-r06.mx.aol.com (mail_out_v32.5.) id p.d4.184e63f9 (17378) for ; Mon, 3 Jun 2002 23:14:35 -0400 (EDT) From: Mistsojorn@aol.com Message-ID: To: philly_ambient@phobos.serve.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 4.0 for Mac - Post-GM sub 66 Subject: [Philly_ambient] tool! Sender: philly_ambient-admin@phobos.serve.com Errors-To: philly_ambient-admin@phobos.serve.com X-BeenThere: philly_ambient@phobos.serve.com X-Mailman-Version: 2.0.9 Precedence: bulk Reply-To: philly_ambient@phobos.serve.com List-Help: List-Post: List-Subscribe: , List-Id: a discussion list relevant to Philadelphia Ambient and Experimental Psychedelic Music Enthusiasts List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 3 Jun 2002 23:14:35 EDT Date: Mon, 3 Jun 2002 23:14:35 EDT X-UIDL: m;n!!9'f!!a2E"!3;D"! hey all a friend can get me some free tickets to see TOOL on monday august 12 at sovereign bank arena in trenton. i know mondays suck, but oh well. is anyone here into going? if so, contact me privately. i know it's not ambient, but neither is some of what we discuss here :) let me know asap, please gina _______________________________________________ Philly_ambient mailing list Philly_ambient@phobos.serve.com Subscribe, Unsubscribe, Edit Options at: http://phobos.serve.com/mailman/listinfo/philly_ambient a PAC(MaN) List http://simpletone.com -------------------------------------------------------------------- I don't know why pipermail would treat my aol subscribers different either. But it is. Aharon ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-04-28 21:11 Message: Logged In: YES user_id=12800 Bizarre. I've never seen this, and I can't see any reason why Pipermail would treat aol.com addresses any different. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=229568&group_id=103 From noreply@sourceforge.net Fri Aug 23 23:35:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Aug 2002 15:35:26 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-228680 ] Infinite loops with Auto-Reply Message-ID: Bugs item #228680, was opened at 2001-01-13 13:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=228680&group_id=103 Category: mail delivery >Group: 2.0.x >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Infinite loops with Auto-Reply Initial Comment: An infinite mail loop is created when a - member of a mailing list has an Out Of The Office or other Auto-Reply set up and - there is a misconfiguration of SMTP on the member's end (is what I'm told) and - the mailing list is moderated with a "pending moderator approval" message sent to the sender of a message Use case: person comes back from vacation and finds 3500 messages from Mailman saying "Your message is waiting for moderator approval", which were in response to her "I'm away on vacation" Auto-Reply ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-23 18:35 Message: Logged In: YES user_id=12800 I believe this problem is resolved in the latest MM2.1 betas through the use of various techniques, including not autoresponding to messages that have a Precedence: {junk,list,bulk} header, and a built-in governor for the number of autoreplies to any one address in a single day. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=228680&group_id=103 From noreply@sourceforge.net Fri Aug 23 23:36:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Aug 2002 15:36:33 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-227371 ] Bounced message not detected as bounce Message-ID: Bugs item #227371, was opened at 2001-01-02 22:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=227371&group_id=103 Category: bounce detection >Group: 2.0.x >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Bounced message not detected as bounce Initial Comment: SMTP Server ID: 220 csd.k12.nh.us FirstClass ESMTP Mail Server v5.50 ready Response from mail sent to invalid user[bouncethis@cnhec.concord.k12.nh.us] is not interpretted as a bounce and instead is sent to the list for delivery. (Good thing only subscribers can post or else a large mailstorm would have ensued). A copy of the bounce message follows: Received: .([204.238.196.5]) by dimentech.com with ESMTP id WAA08044 for ; Tue, 2 Jan 2001 22:32:36 -0500 (EST) Message-id: Date: Tue, 02 Jan 2001 22:34:11 -0500 Subject: NDN: test X-FC-Icon-ID: 2031 X-FC-MachineGenerated: true To: dwatts@dimentech.com From: "Mailer-Daemon" MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-UID: 166 Sorry. Your message could not be delivered to: bouncethis,FCServer1 (The name was not found at the remote site. Check that the name has been entered correctly.) ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-23 18:36 Message: Logged In: YES user_id=12800 I'm closing this because MM2.1 has much improved bounce processing, and because it's a royal pain to grok out the original bounce message when it was pasted in instead of attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=227371&group_id=103 From noreply@sourceforge.net Fri Aug 23 23:37:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Aug 2002 15:37:20 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-222962 ] Umlauts are behaving badly Message-ID: Bugs item #222962, was opened at 2000-11-20 06:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=222962&group_id=103 Category: Pipermail >Group: 2.0.x >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Umlauts are behaving badly Initial Comment: Umlaut characters and our nice scandinavic characters are behaving badly in the pipermail archives. As an example see the archive: http://oh3tr.ele.tut.fi/pipermail/moppe-archive/ All ä:s and ö:s are displayed like "=E4" in the message body. If there are those characters in the subject the subject line will appear as total mess. This could be corrected if those 8bit characters would be allowed to go through the archiver as they are. At the moment the text version is also messed with those =E4 characters. Tested versions: up to Pipermail 0.05 (Mailman 2.0beta5). ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-23 18:37 Message: Logged In: YES user_id=12800 I'm sure all this stuff is resolved in the latest MM2.1 betas. ---------------------------------------------------------------------- Comment By: Gisle Hannemyr (gisleh) Date: 2001-11-08 07:42 Message: Logged In: YES user_id=370926 The submitter states that "This could be corrected if those 8bit characters would be allowed to go through the archiver as they are". This is wrong. Mailers these days use quoted-printable encoding for 8-bit characters, and the archiver need to be aware om MIME headers and content encodings and decode things correctly (just like a MUA need to be). As Bernard has already stated, this is a missing feature, but an important one! ---------------------------------------------------------------------- Comment By: Bernhard Reiter (ber) Date: 2000-12-08 09:26 Message: Pipermail cannot handle mime messages and content encodings well. You could also say that it is missing the most part from being a nice mail archiving program. Mailman also needs to be internationalised. (Which is long overdue...but obviously somebody has to jump in there.) So it is not really bug, it is a missing feature. You could alternatively use a _real_ external mail archiving program. There are two I know of (both have their own problems) monarch and hypermail. Bernhard ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2000-11-23 19:43 Message: Yes, I would also like MIME-decoding of the subject-line in the header. I tested the release version now, and the same behavious is still there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=222962&group_id=103 From noreply@sourceforge.net Fri Aug 23 23:37:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Aug 2002 15:37:54 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-219808 ] Missing dependancy for 'configure'. Message-ID: Bugs item #219808, was opened at 2000-10-30 17:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=219808&group_id=103 Category: configuring/installing >Group: 2.1 beta Status: Open Resolution: None Priority: 2 Submitted By: Thomas Wouters (twouters) Assigned to: Thomas Wouters (twouters) Summary: Missing dependancy for 'configure'. Initial Comment: The Mailman makefile is missing a dependancy on 'configure', so when 'configure' is updated, it isn't re-run automatically, and you aren't warned to reconfigure. (definately low-priority bug though :) (I also ran into something weird when running 'config.status' to do the reconfiguring for me... it set 'MAILMAN_UID' in Defaults.py to 'mailman', without quotes, instead of the numeric uid. That might be caused by a mix of an old config.status and a new configure, though, as I wasn't able to reproduce it on another box.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=219808&group_id=103 From noreply@sourceforge.net Fri Aug 23 23:38:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Aug 2002 15:38:59 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-214205 ] e-mail<->usenet gateway Reply-To header (PR#303) Message-ID: Bugs item #214205, was opened at 2000-09-11 16:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=214205&group_id=103 Category: nntp/news >Group: 2.1 beta Status: Open Resolution: None Priority: 4 Submitted By: Nobody/Anonymous (nobody) Assigned to: Barry A. Warsaw (bwarsaw) Summary: e-mail<->usenet gateway Reply-To header (PR#303) Initial Comment: Jitterbug-Id: 303 Submitted-By: orion@tribble.dyndns.org Date: Mon, 24 Jul 2000 18:54:02 -0400 (EDT) Version: 2.0beta4 OS: Debian linux potato I'm running a plain e-mail<->usenet gateway. When someone replies to a usenet post through the list, his e-mail client sets an In-Reply-To: header instead of a Reply-To: header. This causes newsreaders to improperly thread messages. I inserted the following bit into Mailman/Handlers/ToUsenet.py at around line 82: # if the message is a reply to a previous post, change the header so # that newsreaders can thread it properly if msg.getheader('in-reply-to'): msg.headers.append('References: %s\n' % msg.getheader('in-reply-to')) del msg['in-reply-to'] I'm happy to say that this solved the problem. (before you laugh at me, take note that I never looked at python before.) ==================================================================== Audit trail: None ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-23 18:38 Message: Logged In: YES user_id=12800 Changing the group to 2.1 beta because I want to look at threading issues for gated messages before 2.1 final is released. ---------------------------------------------------------------------- Comment By: Giovanni Lopedote (giuans) Date: 2002-05-01 08:34 Message: Logged In: YES user_id=531451 What a coincidence! I had the same problem and I looked into the code, then modified it to work properly. The coincidence is that my patch is *identical* to yours. So, for sure it works :-) ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2000-09-27 17:00 Message: RFC 2076 says nothing about using In-Reply-To for news, so it might not be a bad idea to copy In-Reply-To to References when gating a message from mail to news. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2000-09-19 12:48 Message: This sounds like the email client in question is broken. Mine for example, correctly inserts References: headers and the news readers properly thread the messages. I'm not inclined to cater to broken email or news clients. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=214205&group_id=103 From noreply@sourceforge.net Fri Aug 23 23:40:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Aug 2002 15:40:09 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-214163 ] Netscape vCards (PR#201) Message-ID: Bugs item #214163, was opened at 2000-09-11 16:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=214163&group_id=103 Category: None >Group: 2.0.x >Status: Closed >Resolution: Out of Date Priority: 1 Submitted By: Nobody/Anonymous (nobody) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Netscape vCards (PR#201) Initial Comment: Jitterbug-Id: 201 Submitted-By: Danny.Hite@ncmail.net Date: Mon, 14 Feb 2000 11:02:48 -0500 (EST) Version: 1.1 OS: Redhat Linux 6.1 Our organization uses Netscape 4.x for email. The problem is the vCard attachments to messages that are posted to -request@...... Below is a paste of the message that I get when sending these requests. And yes, if I turn off vCards, it does not give me the error messages. Just wondering if there is a workaround to this. ---------------Begin Paste--------------- This is an automated response. There were problems with the email commands you sent to Mailman via the administrative address . To obtain instructions on valid Mailman email commands, send email to with the word "help" in the subject line or in the body of the message. If you want to reach the human being that manages this mailing list, please send your message to . The following is a detailed description of the problems. ***** who Digest Members: ?????.????@ncmail.net <<<<<<<<<>>>>>>>>>>>> Non-Digest Members: danny.hite@ncmail.net Command? This is a multi-part message in MIME format. Command? --------------673C83360F5786D2AB551932 Command? Content-Type: text/plain; charset=us-ascii Command? Content-Transfer-Encoding: 7bit Command? --------------673C83360F5786D2AB551932 >>>>> >>>>> Too many errors encountered; the rest of the message is ignored: > Content-Type: text/x-vcard; charset=us-ascii; > name="Danny.Hite.vcf" > Content-Transfer-Encoding: 7bit > Content-Description: Card for Danny Hite > Content-Disposition: attachment; > filename="Danny.Hite.vcf" > > begin:vcard > n:Hite;Danny > tel;fax: > tel;work: > x-mozilla-html:FALSE > org:NC DENR;DEH > version:2.1 > email;internet:Danny.Hite@ncmail.net > title:LAN Administrator > adr;quoted-printable:;;=0D=0A;;;; > fn:Danny Hite > end:vcard > > --------------673C83360F5786D2AB551932-- > > ---------------End Paste--------------- ==================================================================== Audit trail: None ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-23 18:40 Message: Logged In: YES user_id=12800 MM2.1's mail command processor is MIME aware now. We can now close the oldest bug in the database. Yee haw! :) ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2000-09-15 17:52 Message: MailCommandHandler should be MIME aware, and refuse to parse any part that isn't text/* type. Since vCards are text/x-vcard type, MailCommandHandler should additionally have a list of text/* subtypes that are ignored. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=214163&group_id=103 From noreply@sourceforge.net Sat Aug 24 01:17:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Aug 2002 17:17:48 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-596361 ] rejection-notice not translated Message-ID: Bugs item #596361, was opened at 2002-08-17 06:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=596361&group_id=103 Category: Web/CGI Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: rejection-notice not translated Initial Comment: on the admindb screen, detailed description of the held messages include 'rejection-notice' field to be sent to the message sender but the default value in the text form is in english and not translated into the list-preferred language. Following short patch may work: --- admindb.py.orig Fri Aug 16 11:39:53 2002 +++ admindb.py Sat Aug 17 14:57:37 2002 @@ -595,8 +595,8 @@ t.AddRow([ Bold(_('If you reject this post,
    please explain (optional):')), TextArea('comment-%d' % id, rows=4, cols=80, - text = Utils.wrap(msgdata.get('rejection-notice', - _('[No explanation given]')), + text = Utils.wrap(_(msgdata.get('rejection-notice', + _('[No explanation given]'))), column=80)) ]) row, col = t.GetCurrentRowIndex(), t.GetCurrentCellIndex() ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2002-08-24 00:17 Message: Logged In: YES user_id=67709 Sorry for the inconvenience. I uplaod a diff file. There is some clutter in creating mailman.pot, so I revised the patch. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-23 21:16 Message: Logged In: YES user_id=12800 In general it's better to attach patches instead of pasting them in. SF doesn't preserve whitespace :( Updating this one so SF will send me the whitespace preserved patch in an email notification. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=596361&group_id=103 From satyap@satya.virtualave.net Sat Aug 24 04:25:52 2002 From: satyap@satya.virtualave.net (Satya) Date: Fri, 23 Aug 2002 20:25:52 -0700 (PDT) Subject: [Mailman-Developers] Re: Anti-spam "killer app"? In-Reply-To: <3D661610.6030801@vgg.sci.uma.es> Message-ID: On Aug 23, 2002 at 13:01, Victoriano Giralt wrote: >Satya wrote: [things] >Excusme if I have lost part of the thread but, what are you using for >all this nice filtering? Okay, here's the process: Mail comes into the system, grabbed and checked by procmail. Mail delivered to various detsinations according to rules. Last set of procmail rules filter all remaining email through the SRS checker, which: a) passes it on normally if it doesn't recognize spam b) MIME-encapsulates original with a "This is spam!" message, adds X-Spam (or somesuch) header Next rule checks for X-Spam header and inserts flagged messages into special folder, which I manually empty once a day (week, whatever). False negatives (unrecognized spam) I save to another folder called 'spam'. False positives (none yet) are saved to folder 'nonspam'. This step is done manually by me while reading email. Once a night (week, whatever) I copy the spam and non-spam folder files (mbox) to SRS's directory, run the hashing and rating programs (20+ minutes), and delete the folders. (If I say 'I' in the above, it's done by me manually.) I'm sure some of those steps can be automated. -- Satya. User error: Please replace user and hit enter to continue From bob@nleaudio.com Sat Aug 24 05:12:25 2002 From: bob@nleaudio.com (Bob Puff@NLE) Date: Sat, 24 Aug 2002 00:12:25 -0400 Subject: [Mailman-Developers] Message unparsable errors Message-ID: <3D6707A9.C951B23E@nleaudio.com> In doing a routine looksee at my MM 2.1b3 install, I saw some data in my error log: Aug 13 21:01:29 2002 (9001) lost data files for filebase: 1029286885.82315+6620b 7dc5eb172c8752545915a9096a3778b0616 Aug 13 21:07:31 2002 (9001) message is unparsable: 1029287248.371788+6b3b5f5a932 4846f9ca26c0d3209f046aca69449 Aug 13 21:07:31 2002 (9001) lost data files for filebase: 1029287248.371788+6b3b 5f5a9324846f9ca26c0d3209f046aca69449 Aug 13 21:12:31 2002 (9001) message is unparsable: 1029287493.927862+c335a400f9a 1513dd5a6ca7d2c2154f72846c3fe Aug 13 21:12:31 2002 (9001) lost data files for filebase: 1029287493.927862+c335 a400f9a1513dd5a6ca7d2c2154f72846c3fe Aug 13 21:58:31 2002 (9001) message is unparsable: 1029290306.708443+f57c6fcfcbf f0bd3662c8a47e39e113f2352fa1c Aug 13 21:58:31 2002 (9001) lost data files for filebase: 1029290306.708443+f57c 6fcfcbff0bd3662c8a47e39e113f2352fa1c Aug 16 21:05:41 2002 (9001) message is unparsable: 1029546301.349363+ad52387697e 04f59e9a9647ead0822b6e27497ee Aug 16 21:05:41 2002 (9001) lost data files for filebase: 1029546301.349363+ad52 387697e04f59e9a9647ead0822b6e27497ee Aug 16 21:08:41 2002 (9001) message is unparsable: 1029546511.308229+be0a322837d cec9eda90366f706bd2e5594ed906 Aug 16 21:08:41 2002 (9001) lost data files for filebase: 1029546511.308229+be0a 322837dcec9eda90366f706bd2e5594ed906 As far as I can tell, no message was sent to MM2.1 on August 16 - at least it's not recorded in the post log. Also, in the vette log, what does this mean: Jul 24 08:59:43 2002 (9003) Precedence: bulk message ignored by: aes-la-request@ light-list.com Aug 15 08:00:04 2002 (9003) Precedence: bulk message ignored by: aes-la-request@ light-list.com Thanks! Bob From noreply@sourceforge.net Sat Aug 24 07:52:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 23 Aug 2002 23:52:50 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-599544 ] user mailman can't start mailmanctl Message-ID: Bugs item #599544, was opened at 2002-08-24 06:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=599544&group_id=103 Category: command line scripts Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: user mailman can't start mailmanctl Initial Comment: with the latest cvs as of Aug 24, mailmanctl can't be started by the mailman user. root can start. A quick patch is attatched. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=599544&group_id=103 From BarryGould@pennysaverusa.net Sat Aug 24 01:04:08 2002 From: BarryGould@pennysaverusa.net (Barry Gould) Date: Fri, 23 Aug 2002 17:04:08 -0700 Subject: [Mailman-Developers] problem with log rotation for mailman on RedHat 7.3 Message-ID: <5.1.1.6.0.20020823165535.02300d00@mail.pennysaverusa.net> something really strange is going on with log rotation for the RedHat mailman package... it keeps adding more and more .x.gz... files in the log dir. I don't think I've modified it since installing RedHat, other than upgrading the mailman rpm due to the security notice. let me know if you have any questions. Thank you, Barry [root@mail log]# rpm -q mailman mailman-2.0.11-1 [root@mail log]# ll /var/log/mailman/ total 4 -rw-rw-r-- 1 mailman mailman 0 Aug 18 04:02 error -rw-rw-r-- 1 mailman mailman 0 Aug 19 04:02 error.1.gz -rw-rw-r-- 1 mailman mailman 0 Aug 20 04:13 error.1.gz.1.gz -rw-rw-r-- 1 mailman mailman 0 Aug 21 04:02 error.1.gz.1.gz.1.gz -rw-rw-r-- 1 mailman mailman 0 Aug 22 04:02 error.1.gz.1.gz.1.gz.1.gz -rw-rw-r-- 1 mailman mailman 0 Aug 23 04:02 error.1.gz.1.gz.1.gz.1.gz.1.gz -rw-rw-r-- 1 mailman mailman 200 Aug 14 12:32 error.1.gz.1.gz.1.gz.1.gz.1.gz.1.gz [root@mail log]# cat /etc/logrotate.d/mailman /var/log/mailman/* { missingok } Barry Gould Site Administrator, Harte-Hanks Shoppers 714-577-4313 or 877-244-4421 http://www.pennysaverusa.com http://www.theflyer.com From noreply@sourceforge.net Sun Aug 25 00:50:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 24 Aug 2002 16:50:06 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-599544 ] user mailman can't start mailmanctl Message-ID: Bugs item #599544, was opened at 2002-08-24 02:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=599544&group_id=103 Category: command line scripts Group: 2.1 beta >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: user mailman can't start mailmanctl Initial Comment: with the latest cvs as of Aug 24, mailmanctl can't be started by the mailman user. root can start. A quick patch is attatched. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-24 19:50 Message: Logged In: YES user_id=12800 Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=599544&group_id=103 From barry@python.org Sun Aug 25 00:54:45 2002 From: barry@python.org (Barry A. Warsaw) Date: Sat, 24 Aug 2002 19:54:45 -0400 Subject: [Mailman-Developers] Message unparsable errors References: <3D6707A9.C951B23E@nleaudio.com> Message-ID: <15720.7365.961668.172389@anthem.wooz.org> >>>>> "B" == Bob writes: B> In doing a routine looksee at my MM 2.1b3 install, I saw some B> data in my error log: B> Aug 13 21:01:29 2002 (9001) lost data files for filebase: B> 1029286885.82315+6620b 7dc5eb172c8752545915a9096a3778b0616 Aug B> 13 21:07:31 2002 (9001) message is unparsable: B> 1029287248.371788+6b3b5f5a932 4846f9ca26c0d3209f046aca69449 Aug B> 13 21:07:31 2002 (9001) lost data files for filebase: B> 1029287248.371788+6b3b 5f5a9324846f9ca26c0d3209f046aca69449 Aug B> 13 21:12:31 2002 (9001) message is unparsable: B> 1029287493.927862+c335a400f9a 1513dd5a6ca7d2c2154f72846c3fe Aug B> 13 21:12:31 2002 (9001) lost data files for filebase: B> 1029287493.927862+c335 a400f9a1513dd5a6ca7d2c2154f72846c3fe Aug B> 13 21:58:31 2002 (9001) message is unparsable: B> 1029290306.708443+f57c6fcfcbf f0bd3662c8a47e39e113f2352fa1c Aug B> 13 21:58:31 2002 (9001) lost data files for filebase: B> 1029290306.708443+f57c 6fcfcbff0bd3662c8a47e39e113f2352fa1c Aug B> 16 21:05:41 2002 (9001) message is unparsable: B> 1029546301.349363+ad52387697e 04f59e9a9647ead0822b6e27497ee Aug B> 16 21:05:41 2002 (9001) lost data files for filebase: B> 1029546301.349363+ad52 387697e04f59e9a9647ead0822b6e27497ee Aug B> 16 21:08:41 2002 (9001) message is unparsable: B> 1029546511.308229+be0a322837d cec9eda90366f706bd2e5594ed906 Aug B> 16 21:08:41 2002 (9001) lost data files for filebase: B> 1029546511.308229+be0a 322837dcec9eda90366f706bd2e5594ed906 B> As far as I can tell, no message was sent to MM2.1 on August 16 B> - at least it's not recorded in the post log. You probably won't see entries for these except in your MTA logs. They're messages that the email package was unable to parse. Mailman will chuck these unless you set QRUNNER_SAVE_BAD_MESSAGES = 1 in your mm_cfg.py file, and then they'll get saved in qfiles/bad. Very likely, they're spam. B> Also, in the vette log, what does this mean: B> Jul 24 08:59:43 2002 (9003) Precedence: bulk message ignored B> by: aes-la-request@ light-list.com Aug 15 08:00:04 2002 (9003) B> Precedence: bulk message ignored by: aes-la-request@ B> light-list.com Normal operation. It means one of the autorepliers or the -request command handler is ignoring a message with a Precedence: bulk header. These should /only/ be sent by other automated processes, e.g. other listservers, and it makes no sense to autoreply to such a message. This is just logging that fact. -Barry From satyap@satya.virtualave.net Sun Aug 25 07:56:37 2002 From: satyap@satya.virtualave.net (Satya) Date: Sat, 24 Aug 2002 23:56:37 -0700 (PDT) Subject: [Mailman-Developers] Re: Anti-spam "killer app"? In-Reply-To: Message-ID: Here's the analysis of 4 spam messages (and one false positive, caused by forwarding the reports to myself) by the SRS. It was trained using over 100 legit emails in my Read folder, and a very small amount of real spam. It started by cathing almost no real spam, and today it has caught about 60% of the day's spam. In <5 days. ++ 2 x 0.999 19613544 [what's this?] ++ 2 x 0.999 mso-layout-grid-align ++ 2 x 0.999 x-yahoofilteredbulk [duh] ++ 1 x 0.999 0pt [i guess spam contains some hidden text] ++ 1 x 0.999 consolidation [debt consolidation] ++ 1 x 0.999 cosmic ++ 1 x 0.999 equity ++ 1 x 0.999 migada [i think that's nigerian] -- 4 x 0.001 199 -- 4 x 0.001 enclosed -- 4 x 0.001 positive -- 1 x 0.001 145 -- 1 x 0.001 lnx -- 1 x 0.001 ns -- 1 x 0.001 watch Positive records: 52 Negative records: 199 Tokens indexed: 90352 * "++" indicates tokens which suggest unsolicited bulk e-mail content. * "--" indicates tokens which suggest ordinary mail. ++ 3 x 0.999 102870244522821 ++ 3 x 0.999 cellular ++ 3 x 0.999 hi-speed ++ 1 x 0.999 -76 ++ 1 x 0.999 102870244522821-- ++ 1 x 0.999 19613544 ++ 1 x 0.999 mso-layout-grid-align ++ 1 x 0.999 opted-in [yaright] ++ 1 x 0.999 x-mailer-version -- 8 x 0.001 wm -- 2 x 0.001 misc -- 1 x 0.001 0061 -- 1 x 0.001 designs -- 1 x 0.001 hey -- 1 x 0.001 la Positive records: 52 Negative records: 199 Tokens indexed: 90352 ++ 7 x 0.999 cfm ++ 3 x 0.999 102870244522821 ++ 3 x 0.999 190 ++ 1 x 0.999 -76 ++ 1 x 0.999 0pt ++ 1 x 0.999 102870244522821-- ++ 1 x 0.999 19613544 ++ 1 x 0.999 mso-layout-grid-align ++ 1 x 0.999 msonormal ++ 1 x 0.999 scroll ++ 1 x 0.999 x-yahoofilteredbulk -- 4 x 0.001 destinations -- 2 x 0.001 exclusive -- 2 x 0.001 granted -- 2 x 0.001 luck ++ 3 x 0.999 loans ++ 1 x 0.999 -77 ++ 1 x 0.999 consolidation ++ 1 x 0.999 consultation ++ 1 x 0.999 equity ++ 1 x 0.999 gte ++ 1 x 0.999 refinancing ++ 1 x 0.999 x-yahoofilteredbulk -- 2 x 0.001 145 -- 2 x 0.001 ne -- 2 x 0.001 ns -- 1 x 0.001 fact -- 1 x 0.001 relay -- 1 x 0.001 student -- 1 x 0.001 watch ++ 15 x 0.999 12731704 ++ 4 x 0.999 enormous ++ 2 x 0.999 --------------------------------------------------- ++ 2 x 0.999 000066 ++ 2 x 0.999 produce ++ 1 x 0.999 --phqghumeaylnlfdxfircvscxggbw-- ++ 1 x 0.999 0099ff ++ 1 x 0.999 ffffcc -- 38 x 0.001 mono -- 3 x 0.001 bonus -- 2 x 0.001 listening -- 2 x 0.001 log -- 2 x 0.001 math -- 1 x 0.001 notice -- 1 x 0.001 putting -- Satya. S met ing's hap ening t my k ybo rd . . From chuqui@plaidworks.com Sun Aug 25 08:08:54 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Sun, 25 Aug 2002 00:08:54 -0700 Subject: [Mailman-Developers] Re: Anti-spam "killer app"? In-Reply-To: Message-ID: <844D5AD5-B7F9-11D6-A99B-0003934516A8@plaidworks.com> On Saturday, August 24, 2002, at 11:56 PM, Satya wrote: > ++ 2 x 0.999 19613544 > [what's this?] phone number of some sort. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ Someday, we'll look back on this, laugh nervously and change the subject. From wgong@smu.edu.sg Sun Aug 25 16:38:11 2002 From: wgong@smu.edu.sg (GONG Wei) Date: Sun, 25 Aug 2002 23:38:11 +0800 Subject: [Mailman-Developers] Disabling the use of Password totally? Message-ID: <108506BDA45F1F45AA6EDE147A27FC01013EC961@mail1.smu.edu.sg> Hi all, I recently demostrated the use of Mailman to my boss, who is quite impressed, except the fact that he really doesn't like the use of password in Mailman. I myself had been a mailman user for quite some time and I had no problem with the existence of password. But after he mentioned that I think to certain extent his reasoning is also valid. Instead of using password why not simply ask the user to confirm (by replying) if they want to, say, modify the digest option. From security point of view this really has no difference since anyway people can always hit the "send password to me" button. While browsing the list archive message I noticed that the problem discussed in thread: http://mail.python.org/pipermail-21/mailman-developers/2002-August/012757.ht ml http://mail.python.org/pipermail-21/mailman-developers/2002-August/012761.ht ml http://mail.python.org/pipermail-21/mailman-developers/2002-August/012762.ht ml http://mail.python.org/pipermail-21/mailman-developers/2002-August/012771.ht ml would not exist at all, if such "password based control" could be turnt off by the site administrator, if desirable. As usual, your comments are always more than welcome. Thank you! Regards ========== Gong Wei (+65 68220120, wgong@smu.edu.sg) Office of CIT, SMU Thawte Email Cert thumbprint: c5 84 23 68 da 18 6c 4f 57 db 42 49 55 70 74 31 4c 40 a1 52 GnuPG fingerprint: 9514 C3E9 EEF9 2117 CAA3 C438 5F27 797A D10E CB08 Visit http://www.keyserver.net/en/ for public key From noreply@sourceforge.net Mon Aug 26 05:54:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 25 Aug 2002 21:54:29 -0700 Subject: [Mailman-Developers] [ mailman-Patches-600048 ] i18n archiver update Message-ID: Patches item #600048, was opened at 2002-08-26 04:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=600048&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: i18n archiver update Initial Comment: update for patch ID 594771 - _i18n_ctime() should be outside of HyperArchive class, because it is called within Article class. HyperArch.py was updated in CVS. So, first apply patches 1and 2 from 594771, discard HyperArch.py, re-install HyperArch.py from CVS and then apply this patch. Confused? I hope Barry include this in the CVS ASAP. ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=600048&group_id=103 From noreply@sourceforge.net Mon Aug 26 05:59:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 25 Aug 2002 21:59:39 -0700 Subject: [Mailman-Developers] [ mailman-Patches-600048 ] i18n archiver update Message-ID: Patches item #600048, was opened at 2002-08-26 04:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=600048&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: i18n archiver update Initial Comment: update for patch ID 594771 - _i18n_ctime() should be outside of HyperArchive class, because it is called within Article class. HyperArch.py was updated in CVS. So, first apply patches 1and 2 from 594771, discard HyperArch.py, re-install HyperArch.py from CVS and then apply this patch. Confused? I hope Barry include this in the CVS ASAP. ;-) ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2002-08-26 04:59 Message: Logged In: YES user_id=67709 You must re-generate whole archive (or at lease recent articles) by using bin/arch, because there are new class variables. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=600048&group_id=103 From noreply@sourceforge.net Mon Aug 26 06:02:21 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 25 Aug 2002 22:02:21 -0700 Subject: [Mailman-Developers] [ mailman-Patches-594771 ] i18n support for Archiver Message-ID: Patches item #594771, was opened at 2002-08-13 21:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=594771&group_id=103 Category: Pipermail Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Simone Piunno (pioppo) Assigned to: Nobody/Anonymous (nobody) Summary: i18n support for Archiver Initial Comment: I'm trying to provide changes in small chunks. This 1st patch does the following: - 7 new template files: archidxentry.html archidxhead.html archidxfoot.html archliststart.html archlistend.html archtoc.html archtocentry.html - _() marking for translatable strings - a few small bugfixes (e.g. unwanted spaces, bin/arch not calling i18n.set_language, etc.) TODO: - show translated tags for archive volumes (e.g. "2002-August", "2002q3", "Week-of-Mon-XXXX") I have 2 alternatives: renaming files and dirs where the archives are built (cleaner, but screws up everything in pre-existing archives) or build a tag-to-description translator (better, I think) - find a way to produce translated datetime strings without using locale.setlocale and time.strftime() (this is discouraged in Python manual) Here I really need some advice. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2002-08-26 05:02 Message: Logged In: YES user_id=67709 I have submitted a slight change to this patch. It is uploaded in a separate patch ID. Thank you Simone for exellent work! ---------------------------------------------------------------------- Comment By: Simone Piunno (pioppo) Date: 2002-08-14 18:49 Message: Logged In: YES user_id=227443 And finally, this is the 3rd piece of the puzzle: dates translation. I had to reinvent the wheel, and it's an relatively expensive hack (from a computational efficiency point of view) but it works without touching pipermail.py This patch is incremental and must be applied after #2 ---------------------------------------------------------------------- Comment By: Simone Piunno (pioppo) Date: 2002-08-13 23:38 Message: Logged In: YES user_id=227443 Here is the 2nd patch, providing the tag-to-description translator for volume tags. This patch is incremental and must be applied after patch #¹ Now the last thing is dates. I wouln'd want to reinvent the wheel.... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=594771&group_id=103 From noreply@sourceforge.net Mon Aug 26 19:40:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 26 Aug 2002 11:40:05 -0700 Subject: [Mailman-Developers] [ mailman-Patches-600368 ] i18n fix for HTMLFormatter.py Message-ID: Patches item #600368, was opened at 2002-08-26 20:40 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=600368&group_id=103 Category: internationalization Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Simone Piunno (pioppo) Assigned to: Nobody/Anonymous (nobody) Summary: i18n fix for HTMLFormatter.py Initial Comment: In english the word "the" is gender-insensitive, but this is not the case in several other languages (at least italian and french). This patch tries to easy the translation process moving "the" from this string (The %(which)s is only available to the list to the %(which)s value. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=600368&group_id=103 From noreply@sourceforge.net Mon Aug 26 20:12:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 26 Aug 2002 12:12:12 -0700 Subject: [Mailman-Developers] [ mailman-Patches-594771 ] i18n support for Archiver Message-ID: Patches item #594771, was opened at 2002-08-13 23:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=594771&group_id=103 Category: Pipermail Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Simone Piunno (pioppo) Assigned to: Nobody/Anonymous (nobody) Summary: i18n support for Archiver Initial Comment: I'm trying to provide changes in small chunks. This 1st patch does the following: - 7 new template files: archidxentry.html archidxhead.html archidxfoot.html archliststart.html archlistend.html archtoc.html archtocentry.html - _() marking for translatable strings - a few small bugfixes (e.g. unwanted spaces, bin/arch not calling i18n.set_language, etc.) TODO: - show translated tags for archive volumes (e.g. "2002-August", "2002q3", "Week-of-Mon-XXXX") I have 2 alternatives: renaming files and dirs where the archives are built (cleaner, but screws up everything in pre-existing archives) or build a tag-to-description translator (better, I think) - find a way to produce translated datetime strings without using locale.setlocale and time.strftime() (this is discouraged in Python manual) Here I really need some advice. ---------------------------------------------------------------------- >Comment By: Simone Piunno (pioppo) Date: 2002-08-26 21:12 Message: Logged In: YES user_id=227443 I'm attaching the 3rd chunk modified as suggested by Tokio Kikuchi. Maybe i18n_ctime is worth moving in Mailman/i18n.py ? ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2002-08-26 07:02 Message: Logged In: YES user_id=67709 I have submitted a slight change to this patch. It is uploaded in a separate patch ID. Thank you Simone for exellent work! ---------------------------------------------------------------------- Comment By: Simone Piunno (pioppo) Date: 2002-08-14 20:49 Message: Logged In: YES user_id=227443 And finally, this is the 3rd piece of the puzzle: dates translation. I had to reinvent the wheel, and it's an relatively expensive hack (from a computational efficiency point of view) but it works without touching pipermail.py This patch is incremental and must be applied after #2 ---------------------------------------------------------------------- Comment By: Simone Piunno (pioppo) Date: 2002-08-14 01:38 Message: Logged In: YES user_id=227443 Here is the 2nd patch, providing the tag-to-description translator for volume tags. This patch is incremental and must be applied after patch #¹ Now the last thing is dates. I wouln'd want to reinvent the wheel.... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=594771&group_id=103 From Dale@Newfield.org Mon Aug 26 20:14:44 2002 From: Dale@Newfield.org (Dale Newfield) Date: Mon, 26 Aug 2002 15:14:44 -0400 (EDT) Subject: [Mailman-Developers] MemberAdaptor... modifications to API? In-Reply-To: <15714.54348.730519.621979@yyz.zope.com> Message-ID: On Tue, 20 Aug 2002, Barry A. Warsaw wrote: > >>>>> "DN" == Dale Newfield writes: > DN> I guess what I'm suggesting is that instead of using this > DN> accessor like this: mlist.getMemberOption(addr, > DN> mm_cfg.OPTINFO['plain']), it be used like this: > DN> mlist.getMemberOption(addr, 'plain') > The problem that I have with this approach is that it's much easier to > let a typo like mm_cfg.OPTINFO['plian'] slip through than to use a > symbolic constant. E.g. tools like Pychecker can verify that the > constant exists, but can't really do much with the string. Can we make the symbolic constant *be* the string? Then we can get both compile-time checking and a non-obfuscated API. Basically we'd replace: # Bitfield for user options. See DEFAULT_NEW_MEMBER_OPTIONS above to set # defaults for all new lists. Digests = 0 # handled by other mechanism, doesn't need a flag. DisableDelivery = 1 # Obsolete; use set/getDeliveryStatus() DontReceiveOwnPosts = 2 # Non-digesters only AcknowledgePosts = 4 DisableMime = 8 # Digesters only ConcealSubscription = 16 SuppressPasswordReminder = 32 ReceiveNonmatchingTopics = 64 Moderate = 128 DontReceiveDuplicates = 256 # A mapping between short option tags and their flag OPTINFO = {'hide' : ConcealSubscription, 'nomail' : DisableDelivery, 'ack' : AcknowledgePosts, 'notmetoo': DontReceiveOwnPosts, 'digest' : 0, 'plain' : DisableMime, 'nodupes' : DontReceiveDuplicates } With something like: # Strings for user options. See DEFAULT_NEW_MEMBER_OPTIONS above to set # defaults for all new lists. Digests = 'digest' DisableDelivery = 'nomail' DontReceiveOwnPosts = 'notmetoo' AcknowledgePosts = 'ack' DisableMime = 'plain' ConcealSubscription = 'hide' SuppressPasswordReminder = 'noreminder' # made up... ReceiveNonmatchingTopics = 'newtopics' # made up... Moderate = 'moderate' # made up... DontReceiveDuplicates = 'nodupes' # This could probably move inside OldStyleMemberships.py # Why are more of the above ones not in this? # A mapping between short option tags and their flag OPTINFO = {ConcealSubscription : 16, DisableDelivery : 1, AcknowledgePosts : 4, DontReceiveOwnPosts : 2, Digests : 0, DisableMime : 8, DontReceiveDuplicates : 256 } Note that DEFAULT_NEW_MEMBER_OPTIONS should probably become a list of strings, expanded to current value by |'ing together each OPTINFO[listentry] If you'd like me to try to make a clean pass of this and submit a patch, let me know. It seems that API changes should happen sooner than later so that any other implementations of this interface also get built to the same API... -Dale From Dale@Newfield.org Mon Aug 26 20:19:32 2002 From: Dale@Newfield.org (Dale Newfield) Date: Mon, 26 Aug 2002 15:19:32 -0400 (EDT) Subject: [Mailman-Developers] MemberAdaptor... modifications to API? In-Reply-To: Message-ID: On Mon, 26 Aug 2002, Dale Newfield wrote: > # This could probably move inside OldStyleMemberships.py And the string definitions should probably move inside MemberAdaptor.py... -Dale From noreply@sourceforge.net Tue Aug 27 00:53:38 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 26 Aug 2002 16:53:38 -0700 Subject: [Mailman-Developers] [ mailman-Patches-594771 ] i18n support for Archiver Message-ID: Patches item #594771, was opened at 2002-08-13 21:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=594771&group_id=103 Category: Pipermail Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Simone Piunno (pioppo) Assigned to: Nobody/Anonymous (nobody) Summary: i18n support for Archiver Initial Comment: I'm trying to provide changes in small chunks. This 1st patch does the following: - 7 new template files: archidxentry.html archidxhead.html archidxfoot.html archliststart.html archlistend.html archtoc.html archtocentry.html - _() marking for translatable strings - a few small bugfixes (e.g. unwanted spaces, bin/arch not calling i18n.set_language, etc.) TODO: - show translated tags for archive volumes (e.g. "2002-August", "2002q3", "Week-of-Mon-XXXX") I have 2 alternatives: renaming files and dirs where the archives are built (cleaner, but screws up everything in pre-existing archives) or build a tag-to-description translator (better, I think) - find a way to produce translated datetime strings without using locale.setlocale and time.strftime() (this is discouraged in Python manual) Here I really need some advice. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2002-08-26 23:53 Message: Logged In: YES user_id=67709 Thank you for updating. Another comment: I'v got error when I post a message to a list after applying this patch. It is because a new variable Article._lang was introduced and the older archive doesn't have this. I had to re-generate the whole archive. Another solution may be like..... if not self._lang: self._lang = self._mlist.preferred_language i18n.set_language(self._lang) ---------------------------------------------------------------------- Comment By: Simone Piunno (pioppo) Date: 2002-08-26 19:12 Message: Logged In: YES user_id=227443 I'm attaching the 3rd chunk modified as suggested by Tokio Kikuchi. Maybe i18n_ctime is worth moving in Mailman/i18n.py ? ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2002-08-26 05:02 Message: Logged In: YES user_id=67709 I have submitted a slight change to this patch. It is uploaded in a separate patch ID. Thank you Simone for exellent work! ---------------------------------------------------------------------- Comment By: Simone Piunno (pioppo) Date: 2002-08-14 18:49 Message: Logged In: YES user_id=227443 And finally, this is the 3rd piece of the puzzle: dates translation. I had to reinvent the wheel, and it's an relatively expensive hack (from a computational efficiency point of view) but it works without touching pipermail.py This patch is incremental and must be applied after #2 ---------------------------------------------------------------------- Comment By: Simone Piunno (pioppo) Date: 2002-08-13 23:38 Message: Logged In: YES user_id=227443 Here is the 2nd patch, providing the tag-to-description translator for volume tags. This patch is incremental and must be applied after patch #¹ Now the last thing is dates. I wouln'd want to reinvent the wheel.... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=594771&group_id=103 From noreply@sourceforge.net Tue Aug 27 00:56:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 26 Aug 2002 16:56:32 -0700 Subject: [Mailman-Developers] [ mailman-Patches-600048 ] i18n archiver update Message-ID: Patches item #600048, was opened at 2002-08-26 04:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=600048&group_id=103 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: i18n archiver update Initial Comment: update for patch ID 594771 - _i18n_ctime() should be outside of HyperArchive class, because it is called within Article class. HyperArch.py was updated in CVS. So, first apply patches 1and 2 from 594771, discard HyperArch.py, re-install HyperArch.py from CVS and then apply this patch. Confused? I hope Barry include this in the CVS ASAP. ;-) ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2002-08-26 23:56 Message: Logged In: YES user_id=67709 closing because this is included in the original patch (594771) ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2002-08-26 04:59 Message: Logged In: YES user_id=67709 You must re-generate whole archive (or at lease recent articles) by using bin/arch, because there are new class variables. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=600048&group_id=103 From barry@zope.com Tue Aug 27 02:53:44 2002 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 26 Aug 2002 21:53:44 -0400 Subject: [Mailman-Developers] (More) pristine archives Message-ID: <15722.56232.271718.506588@anthem.wooz.org> An interesting issue came up today while we were playing with a Bayesian spam classifier. Mailman's archives aren't very clean. Messages are sent to the archiver after various headering munging steps, including the adding of the List-* headers and the Subject prefix. We still want to do some munging, e.g. for anonymous lists. This tells me that we may want to move ToArchive up before CookHeaders in the global pipeline. I don't think we want to move ToDigest or ToUsenet because I think we /want/ those headers munged before the message is sent to the digests or news server. What do you think? -Barry From tkikuchi@is.kochi-u.ac.jp Tue Aug 27 03:27:15 2002 From: tkikuchi@is.kochi-u.ac.jp (Tokio Kikuchi) Date: Tue, 27 Aug 2002 11:27:15 +0900 Subject: [Mailman-Developers] (More) pristine archives References: <15722.56232.271718.506588@anthem.wooz.org> Message-ID: <3D6AE383.9000800@is.kochi-u.ac.jp> Hi, Barry A. Warsaw wrote: > An interesting issue came up today while we were playing with a > Bayesian spam classifier. Mailman's archives aren't very clean. > Messages are sent to the archiver after various headering munging > steps, including the adding of the List-* headers and the Subject > prefix. The headers are in the raw archive and not in the monthly (or quaterly, weekly) text format archive. I would rather stop publicizing the raw archive even if the other archives are public accessible. At least it should be configurable (in mm_cfg). > > We still want to do some munging, e.g. for anonymous lists. This > tells me that we may want to move ToArchive up before CookHeaders in > the global pipeline. We use a modified version of mailman 2.0.x in Japan and we like a feature of adding numbers in the subject header. The users tend to reference articles by the number not by the archive URL. So, we want the archive to be munged. BTW, I'm preparing a patch for numbering the subject prefix. > > I don't think we want to move ToDigest or ToUsenet because I think we > /want/ those headers munged before the message is sent to the digests > or news server. What do you think? > > -Barry > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman-21/listinfo/mailman-developers > > > -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/ From bob@nleaudio.com Tue Aug 27 04:58:26 2002 From: bob@nleaudio.com (Bob Puff@NLE) Date: Mon, 26 Aug 2002 23:58:26 -0400 Subject: [Mailman-Developers] Re: i18n support for Archiver In-Reply-To: References: Message-ID: <20020827035826.M37023@nleaudio.com> A note / plea for those working on Pipermail archives. It would be really nice if Mailman would store the archives in a 8.3 dos-compatible filename. This makes the storing of archives on CDROM much easier, and cross-platform friendly. This means two things: 1. The archive volume names need to be trimmed. For monthly groupings, this only involves changing the "B" to a lower-case one in the following procedure that is called to build the filename: time.strftime("%b",(1999,i,1,0,0,0,0,1,0)) More work would be needed for "Week of ...", but could be done. 2. The extension would need to be ".htm" instead of ".html" Just my thoughts. Bob From claw@kanga.nu Tue Aug 27 09:08:54 2002 From: claw@kanga.nu (J C Lawrence) Date: Tue, 27 Aug 2002 01:08:54 -0700 Subject: [Mailman-Developers] (More) pristine archives In-Reply-To: Message from barry@zope.com (Barry A. Warsaw) of "Mon, 26 Aug 2002 21:53:44 EDT." <15722.56232.271718.506588@anthem.wooz.org> References: <15722.56232.271718.506588@anthem.wooz.org> Message-ID: <26074.1030435734@kanga.nu> On Mon, 26 Aug 2002 21:53:44 -0400 Barry A Warsaw wrote: > An interesting issue came up today while we were playing with a > Bayesian spam classifier. Mailman's archives aren't very clean. > Messages are sent to the archiver after various headering munging > steps, including the adding of the List-* headers and the Subject > prefix. ... > What do you think? Specifically that I want to archive the exact message, down to the byte, that subscriber's receive. Beyond that I don't care. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From claw@kanga.nu Tue Aug 27 09:11:14 2002 From: claw@kanga.nu (J C Lawrence) Date: Tue, 27 Aug 2002 01:11:14 -0700 Subject: [Mailman-Developers] Re: i18n support for Archiver In-Reply-To: Message from "Bob Puff@NLE" of "Mon, 26 Aug 2002 23:58:26 EDT." <20020827035826.M37023@nleaudio.com> References: <20020827035826.M37023@nleaudio.com> Message-ID: <26111.1030435874@kanga.nu> On Mon, 26 Aug 2002 23:58:26 -0400 bob > wrote: > A note / plea for those working on Pipermail archives. It would be > really nice if Mailman would store the archives in a 8.3 > dos-compatible filename. This makes the storing of archives on CDROM > much easier, and cross-platform friendly. Easier to use one of the extended CDROM formats which supports long filenames. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From bob@nleaudio.com Tue Aug 27 16:45:47 2002 From: bob@nleaudio.com (Bob Puff@NLE) Date: Tue, 27 Aug 2002 11:45:47 -0400 Subject: [Mailman-Developers] Re: i18n support for Archiver References: <20020827035826.M37023@nleaudio.com> <26111.1030435874@kanga.nu> Message-ID: <3D6B9EAB.B8F33FAE@nleaudio.com> > Easier to use one of the extended CDROM formats which supports long > filenames A few months ago I went through this with a customer who wanted a copy of the archives on CDROM from their list. The extended filenames work fine under Windows, but not under the MacOS. They have a different format for their extended filenames. The only common denominator I found was the 8.3 dos filenames. Bob From nb@cisto.com Tue Aug 27 17:10:25 2002 From: nb@cisto.com (Norbert Bollow) Date: Tue, 27 Aug 2002 18:10:25 +0200 Subject: [Mailman-Developers] (More) pristine archives In-Reply-To: <26074.1030435734@kanga.nu> (message from J C Lawrence on Tue, 27 Aug 2002 01:08:54 -0700) References: <15722.56232.271718.506588@anthem.wooz.org> <26074.1030435734@kanga.nu> Message-ID: <200208271610.g7RGAP003261@quill.local> J C Lawrence wrote: > Specifically that I want to archive the exact message, down to the byte, > that subscriber's receive. Beyond that I don't care. I'd love to have this, and in addition (perhaps in a separate file) the exact headers and first ten lines of all incoming messages (postings, admin requests, subscription confirmations, everything). Greetings, Norbert. -- Founder & Steering Committee member of http://gnu.org/projects/dotgnu/ Norbert Bollow, Weidlistr.18, CH-8624 Gruet (near Zurich, Switzerland) Tel +41 1 972 20 59 Fax +41 1 972 20 69 http://norbert.ch List hosting with GNU Mailman on your own domain name http://cisto.com From lrosa@mail.hypertrek.info Tue Aug 27 20:05:07 2002 From: lrosa@mail.hypertrek.info (Luigi Rosa) Date: Tue, 27 Aug 2002 21:05:07 +0200 Subject: [Mailman-Developers] Confirm and delete "collision Message-ID: <1414267546.20020827210507@mail.hypertrek.info> Hello, few minutes ago a user of one on my lists posted a message with an unsubcrpted address. I received the warning and I went to the administrative page to approve the message (this happened at 20:33:14). Few minutes later (20:33:14) the user followed the link in the message he received (http://mail.hypertrek.info/mailman/confirm/staff/a196ba5fee54310b572b369fd8675e84b7788a12) to delete the message and resend it with a valid address, but got this Bug page: Bug in Mailman version 2.1b3 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 82, in run_main main() File "/usr/local/mailman/Mailman/Cgi/confirm.py", line 141, in main heldmsg_prompt(mlist, doc, cookie, *content[1:]) File "/usr/local/mailman/Mailman/Cgi/confirm.py", line 614, in heldmsg_prompt ign, sender, msgsubject, givenreason, ign, ign = mlist.GetRecord(id) File "/usr/local/mailman/Mailman/ListAdmin.py", line 164, in GetRecord type, data = self.__db[id] KeyError: 31 -------------------------------------------------------------------------------- Python information: Variable Value sys.version 2.2.1 (#1, May 31 2002, 17:44:41) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-110)] sys.executable /usr/local/bin/python sys.prefix /usr/local sys.exec_prefix /usr/local sys.path /usr/local sys.platform linux2 -------------------------------------------------------------------------------- Environment variables: Variable Value PYTHONPATH /usr/local/mailman SERVER_SOFTWARE Apache/2.0.40 (Unix) PHP/4.2.3-dev SCRIPT_FILENAME /usr/local/mailman/cgi-bin/confirm SERVER_ADMIN lrosa@mail.hypertrek.info SCRIPT_NAME /mailman/confirm SERVER_SIGNATURE Apache/2.0.40 Server at mail.hypertrek.info Port 80 REQUEST_METHOD GET HTTP_HOST mail.hypertrek.info PATH_INFO /staff/a196ba5fee54310b572b369fd8675e84b7788a12 SERVER_PROTOCOL HTTP/1.1 QUERY_STRING REQUEST_URI /mailman/confirm/staff/a196ba5fee54310b572b369fd8675e84b7788a12 HTTP_ACCEPT image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint, */* HTTP_USER_AGENT Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Q312461) HTTP_CONNECTION Keep-Alive SERVER_NAME mail.hypertrek.info REMOTE_ADDR 10.10.10.1 REMOTE_PORT 1334 HTTP_ACCEPT_LANGUAGE en,it;q=0.5 PATH_TRANSLATED /var/www/html/staff/a196ba5fee54310b572b369fd8675e84b7788a12 SERVER_PORT 80 GATEWAY_INTERFACE CGI/1.1 REMOTE_HOST neo HTTP_ACCEPT_ENCODING gzip, deflate SERVER_ADDR 10.10.10.2 DOCUMENT_ROOT /var/www/html -- Best regards, Luigi mailto:lrosa@mail.hypertrek.info From noreply@sourceforge.net Tue Aug 27 20:00:17 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 27 Aug 2002 12:00:17 -0700 Subject: [Mailman-Developers] [ mailman-Patches-413752 ] Coerce posts to plain text. Message-ID: Patches item #413752, was opened at 2001-04-04 14:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=413752&group_id=103 Category: mail delivery Group: Mailman 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: Geoffrey T. Dairiki (dairiki) Assigned to: Nobody/Anonymous (nobody) Summary: Coerce posts to plain text. Initial Comment: This patch adds the ability to have all posts to a mailing list forced into a MIME text/plain format. Many mailing lists have a charter which forbids binary and HTML posts to the list. This patch allows such a charter to be enforced is a maximally transparent manner. The feature is configurable on a per-list basis. If enabled, all posts to the list are run through a filter which: Squashes multipart messages into a single flat message (it picks the most plain-text-like alternative from multipart/alternative entities.) Converts 'text/html', 'text/enriched', and 'text/richtext' entities to 'text/plain'. Deletes cruft headers from content of type 'message/rfc822'. Deletes any uuencoded files from 'text/plain' entities. Entities of any other types are assumed to be binary attachements are are deleted. This patch is on mailman-2.0.3. ---------------------------------------------------------------------- Comment By: Jozeph Brasil (jozeph) Date: 2002-08-27 16:00 Message: Logged In: YES user_id=17693 Hello dairiki... do you have this patch for Mailman-2.0.13 ? ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2002-08-13 12:43 Message: Logged In: YES user_id=45814 I don't have strong feelings, but my druthers would be to wait until 2.1 is officially designated "stable". A link from the wiki would be great! (There is/was already a link from the FAQ.) ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-13 12:29 Message: Logged In: YES user_id=12800 Since this patch is against 2.0.x and since MM2.1 provides support for stuff like this, I'm inclined to close this patch. I'd be willing to add a link to this from the unofficial patches wiki. What do you think? ---------------------------------------------------------------------- Comment By: Seb Wills (sebwills) Date: 2002-02-23 13:20 Message: Logged In: YES user_id=467580 This patch seems to leave any preamble above the first part of a multipart message intact. Many mailers put blurb such as "This is a MIME-encoded message; you will need a MIME- aware mail client to see all of this message." here, which it makes no sense to reproduce after the mail has be coerced into plaintext. Looks like it's easy enough to change this behaviour by commenting out the line mimetools.copybinary(infp, outfp) # copy preamble from Mailman/FilteringMimeWriter.py ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-12-15 16:15 Message: Logged In: YES user_id=45814 Another bug fix. Lines which contain nothing but the word 'end' mysteriously dissapear. (Reported by David Gibbs.) The only changed file in Mailman/FilteringMimeWriter.py, I've attached the latest version of that file to this page. As usual, patches on mailman 2.0.8 are also attached. Diffs and a patched Mailman-2.0.8 tarball are at ftp://www.dairiki.org/pub/mailman/ ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-09-08 17:08 Message: Logged In: YES user_id=45814 More fixes. * Mailman/FilteringMimeWriter.py: Fixes for bugs in python 1.5.2's quopri library module. The plaintext patches are at version 0.14. Look for the patches on Mailman 2.0.6, as well as a complete tarball of patched Mailman 2.0.6 code at ftp://www.dairiki.org/pub/mailman/ Patches on 2.0.6 are also attached to this page. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-08-25 16:34 Message: Logged In: YES user_id=45814 More fixes: * Mailman/PlaintextMimeWriter.py: Change Message-ID: of filtered messages. * Mailman/pythonlib/multifile.py: Fix obscure but occasionally fatal bug. The first fix is very minor. The second fix fixes a bug which caused the plaintext filter to fail occasionally. Diffs from mailman-2.0.6 are available from this page and are also at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.6-plaintext-0.13.patch.gz Pre-patched mailman-2.0.6 source code is at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.6-plaintext-0.13.tgz ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-06-16 15:33 Message: Logged In: NO After applying this patch to 2.0.5, I found that I had to add this line manually to my existing config file $prefix/Mailman/mm_cfg.py... DEFAULT_FORCE_PLAIN_TEXT = 0 If this line is not added, any web requests and any messages posted will produce an error "AttributeError : DEFAULT_FORCE_PLAIN_TEXT". Not sure if I did something wrong or if this is normal, but I wanted to advise others just in case ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-19 20:49 Message: Logged In: YES user_id=45814 More fixes: * Mailman/FilteringMimeWriter.py: Handle 'content-type: multipart' (no subtype) gracefully. * Mailman/Handlers/PlainText.py: Catch exceptions (fatal errors) from plaintext filter. When exception is caught, an error is logged, but the message is passed on unfiltered. (A diagnostic message is added to the message headers.) This should make it so little piddly bugs in the filter will get noticed, but at the same time will not cause messages to get stuck in the queue. Patches from mailman-2.0.5 are available from this page and are also at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.5-plaintext-0.10.patch.gz Pre-patched mailman-2.0.5 source code is at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.5-plaintext-0.10.tgz ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-17 16:27 Message: Logged In: YES user_id=45814 Another minor bugfix: it turns out pythons mimetools doesn't treat the content-transfer-encoding is a case insensitive fashion --- so now we smash the case ourself. A new patch set on mailman-2.0.5 is available on this page. Pre-patched mailman source code can be found at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.5-plaintext-0.9.tgz ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-08 01:38 Message: Logged In: YES user_id=45814 Disregard last. (Apparently one can't attache files bigger than 256 kb.) Mailman-2.0.5 with plaintext patches applied can be found (for a limited time) at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.5-plaintext-0.8.tgz ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-08 01:33 Message: Logged In: YES user_id=45814 If you don't want to mess with patching the source, I've also attached (below) a tarball of the mailman-2.0.5 source with my patches already applied. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-08 01:16 Message: Logged In: YES user_id=45814 Here's a rough outline of how to proceed: 1. Start by unpacking a fresh copy of mailman-2.0.5.tgz 2. Change into the top source directory (which was created in the previous step. 3. Try applying my patches with: patch -p1 < [where.ever]/mailman-2.0.5-plaintext-0.8.patch (that's "dash pee one") That should work --- you should not get any warnings or prompts from patch. If you do, something is fishy. 4. Run ./configure and 'make install' as usual (read mailman's INSTALL for instructions on this.) Feel free to write me at . ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-05-08 00:30 Message: Logged In: NO For *some* reason when I apply the patch (the newest one) to my freshly downloaded version of Mailman 2.0.5 and compile and install mail never reaches the list. I've tried without the patch and everything works fine... perhaps I'm patching wrong? I'm just saying: patch < name_of_patch It makes me fix a few paths to some of the files, but that's it... :-/ Any help would be appriciated! ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-07 13:25 Message: Logged In: YES user_id=45814 Fixed bug (reported by Pug Bainter -- thanks!) New patches, on mailman-2.0.5 uploaded (below). The only real change is: --- 0.5/Mailman/FilteringMimeWriter.py Wed, 04 Apr 2001 10:04:36 -0700 dairiki (mailman/k/4_FilteringM 1.2 664) +++ 0.8(w)/Mailman/FilteringMimeWriter.py Mon, 07 May 2001 09:05:18 -0700 dairiki (mailman/k/4_FilteringM 1.3 664) @@ -185,8 +185,12 @@ pname, pval = string.split(param, '=', 1) return (string.lower(pname), rfc822.unquote(pval)) - return map(split_param, message.getplist()) - + def valid_param(param): + return '=' in param + + # Trailing ;'s in content-type yield empty strings from getplist(). + return map(split_param, + filter(valid_param, message.getplist())) def discards_data(fp): """Determine whether file object ignores data written to it. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-04-05 12:37 Message: Logged In: YES user_id=45814 I've just made a minor change: HTML converted to plain-text now includes a list of links at the end of the message. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=413752&group_id=103 From barry@python.org Tue Aug 27 20:07:51 2002 From: barry@python.org (Barry A. Warsaw) Date: Tue, 27 Aug 2002 15:07:51 -0400 Subject: [Mailman-Developers] Confirm and delete "collision References: <1414267546.20020827210507@mail.hypertrek.info> Message-ID: <15723.52743.213277.774464@anthem.wooz.org> >>>>> "LR" == Luigi Rosa writes: LR> few minutes ago a user of one on my lists posted a message LR> with an unsubcrpted address. I received the warning and I went LR> to the administrative page to approve the message (this LR> happened at 20:33:14). LR> Few minutes later (20:33:14) the user followed the link in the LR> message he received I believe this is fixed in cvs. -Barry From lrosa@mail.hypertrek.info Tue Aug 27 20:15:34 2002 From: lrosa@mail.hypertrek.info (Luigi Rosa) Date: Tue, 27 Aug 2002 21:15:34 +0200 Subject: [Mailman-Developers] Confirm and delete "collision In-Reply-To: <15723.52743.213277.774464@anthem.wooz.org> References: <1414267546.20020827210507@mail.hypertrek.info> <15723.52743.213277.774464@anthem.wooz.org> Message-ID: <1994893937.20020827211534@mail.hypertrek.info> Hello Barry, Tuesday, August 27, 2002, 9:07:51 PM, you wrote: BAW> I believe this is fixed in cvs. FYI, I synched my sources with CVS last sunday. I am synching now, but the CVS is stuck with this message: cvs server: [12:12:19] waiting for anoncvs_mailman's lock in /cvsroot/mailman/mailman/templates/ja -- Best regards, Luigi mailto:lrosa@mail.hypertrek.info From barry@python.org Tue Aug 27 21:00:32 2002 From: barry@python.org (Barry A. Warsaw) Date: Tue, 27 Aug 2002 16:00:32 -0400 Subject: [Mailman-Developers] Confirm and delete "collision References: <1414267546.20020827210507@mail.hypertrek.info> <15723.52743.213277.774464@anthem.wooz.org> <1994893937.20020827211534@mail.hypertrek.info> Message-ID: <15723.55904.285486.355226@anthem.wooz.org> >>>>> "LR" == Luigi Rosa writes: LR> I am synching now, but the CVS is stuck with this message: LR> cvs server: [12:12:19] waiting for anoncvs_mailman's lock in LR> /cvsroot/mailman/mailman/templates/ja I know, I've already lodged an SF support request about this one. :( -Barry From dan.mick@sun.com Tue Aug 27 21:23:12 2002 From: dan.mick@sun.com (Dan Mick) Date: Tue, 27 Aug 2002 13:23:12 -0700 (PDT) Subject: [Mailman-Developers] Re: i18n support for Archiver Message-ID: <200208272023.g7RKNMqY025651@utopia.West.Sun.COM> > > Easier to use one of the extended CDROM formats which supports long > > filenames > > A few months ago I went through this with a customer who wanted a copy of the archives on CDROM from their list. The extended filenames work fine under Windows, but not > under the MacOS. They have a different format for their extended filenames. The only common denominator I found was the 8.3 dos filenames. Mac doesn't support RockRidge extensions? That would suck. Unfortunately a lot of CDROM-burning programs "just assume" you want the Windows-specific Joliet stuff. :( :( From nb@cisto.com Wed Aug 28 00:35:03 2002 From: nb@cisto.com (Norbert Bollow) Date: Wed, 28 Aug 2002 01:35:03 +0200 Subject: [Mailman-Developers] Re: i18n support for Archiver In-Reply-To: <3D6B9EAB.B8F33FAE@nleaudio.com> (bob@nleaudio.com) References: <20020827035826.M37023@nleaudio.com> <26111.1030435874@kanga.nu> <3D6B9EAB.B8F33FAE@nleaudio.com> Message-ID: <200208272335.g7RNZ3q06610@quill.local> Bob Puff wrote: > A few months ago I went through this with a customer who wanted a > copy of the archives on CDROM from their list. The extended > filenames work fine under Windows, but not under the MacOS. They > have a different format for their extended filenames. The only > common denominator I found was the 8.3 dos filenames. Ouch! Do you know whether 11-character directory names (which do not contain any dots) will work portably? Greetings, Norbert. -- Founder & Steering Committee member of http://gnu.org/projects/dotgnu/ Norbert Bollow, Weidlistr.18, CH-8624 Gruet (near Zurich, Switzerland) Tel +41 1 972 20 59 Fax +41 1 972 20 69 http://norbert.ch List hosting with GNU Mailman on your own domain name http://cisto.com From noreply@sourceforge.net Wed Aug 28 01:22:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 27 Aug 2002 17:22:07 -0700 Subject: [Mailman-Developers] [ mailman-Patches-413752 ] Coerce posts to plain text. Message-ID: Patches item #413752, was opened at 2001-04-04 10:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=413752&group_id=103 Category: mail delivery Group: Mailman 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: Geoffrey T. Dairiki (dairiki) Assigned to: Nobody/Anonymous (nobody) Summary: Coerce posts to plain text. Initial Comment: This patch adds the ability to have all posts to a mailing list forced into a MIME text/plain format. Many mailing lists have a charter which forbids binary and HTML posts to the list. This patch allows such a charter to be enforced is a maximally transparent manner. The feature is configurable on a per-list basis. If enabled, all posts to the list are run through a filter which: Squashes multipart messages into a single flat message (it picks the most plain-text-like alternative from multipart/alternative entities.) Converts 'text/html', 'text/enriched', and 'text/richtext' entities to 'text/plain'. Deletes cruft headers from content of type 'message/rfc822'. Deletes any uuencoded files from 'text/plain' entities. Entities of any other types are assumed to be binary attachements are are deleted. This patch is on mailman-2.0.3. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-08-27 17:22 Message: Logged In: NO Hi Dairiki, It's me... I added your patch in my latest version and it's running OK... you can post the patch here! :) ---------------------------------------------------------------------- Comment By: Jozeph Brasil (jozeph) Date: 2002-08-27 12:00 Message: Logged In: YES user_id=17693 Hello dairiki... do you have this patch for Mailman-2.0.13 ? ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2002-08-13 08:43 Message: Logged In: YES user_id=45814 I don't have strong feelings, but my druthers would be to wait until 2.1 is officially designated "stable". A link from the wiki would be great! (There is/was already a link from the FAQ.) ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-13 08:29 Message: Logged In: YES user_id=12800 Since this patch is against 2.0.x and since MM2.1 provides support for stuff like this, I'm inclined to close this patch. I'd be willing to add a link to this from the unofficial patches wiki. What do you think? ---------------------------------------------------------------------- Comment By: Seb Wills (sebwills) Date: 2002-02-23 08:20 Message: Logged In: YES user_id=467580 This patch seems to leave any preamble above the first part of a multipart message intact. Many mailers put blurb such as "This is a MIME-encoded message; you will need a MIME- aware mail client to see all of this message." here, which it makes no sense to reproduce after the mail has be coerced into plaintext. Looks like it's easy enough to change this behaviour by commenting out the line mimetools.copybinary(infp, outfp) # copy preamble from Mailman/FilteringMimeWriter.py ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-12-15 10:15 Message: Logged In: YES user_id=45814 Another bug fix. Lines which contain nothing but the word 'end' mysteriously dissapear. (Reported by David Gibbs.) The only changed file in Mailman/FilteringMimeWriter.py, I've attached the latest version of that file to this page. As usual, patches on mailman 2.0.8 are also attached. Diffs and a patched Mailman-2.0.8 tarball are at ftp://www.dairiki.org/pub/mailman/ ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-09-08 13:08 Message: Logged In: YES user_id=45814 More fixes. * Mailman/FilteringMimeWriter.py: Fixes for bugs in python 1.5.2's quopri library module. The plaintext patches are at version 0.14. Look for the patches on Mailman 2.0.6, as well as a complete tarball of patched Mailman 2.0.6 code at ftp://www.dairiki.org/pub/mailman/ Patches on 2.0.6 are also attached to this page. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-08-25 12:34 Message: Logged In: YES user_id=45814 More fixes: * Mailman/PlaintextMimeWriter.py: Change Message-ID: of filtered messages. * Mailman/pythonlib/multifile.py: Fix obscure but occasionally fatal bug. The first fix is very minor. The second fix fixes a bug which caused the plaintext filter to fail occasionally. Diffs from mailman-2.0.6 are available from this page and are also at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.6-plaintext-0.13.patch.gz Pre-patched mailman-2.0.6 source code is at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.6-plaintext-0.13.tgz ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-06-16 11:33 Message: Logged In: NO After applying this patch to 2.0.5, I found that I had to add this line manually to my existing config file $prefix/Mailman/mm_cfg.py... DEFAULT_FORCE_PLAIN_TEXT = 0 If this line is not added, any web requests and any messages posted will produce an error "AttributeError : DEFAULT_FORCE_PLAIN_TEXT". Not sure if I did something wrong or if this is normal, but I wanted to advise others just in case ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-19 16:49 Message: Logged In: YES user_id=45814 More fixes: * Mailman/FilteringMimeWriter.py: Handle 'content-type: multipart' (no subtype) gracefully. * Mailman/Handlers/PlainText.py: Catch exceptions (fatal errors) from plaintext filter. When exception is caught, an error is logged, but the message is passed on unfiltered. (A diagnostic message is added to the message headers.) This should make it so little piddly bugs in the filter will get noticed, but at the same time will not cause messages to get stuck in the queue. Patches from mailman-2.0.5 are available from this page and are also at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.5-plaintext-0.10.patch.gz Pre-patched mailman-2.0.5 source code is at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.5-plaintext-0.10.tgz ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-17 12:27 Message: Logged In: YES user_id=45814 Another minor bugfix: it turns out pythons mimetools doesn't treat the content-transfer-encoding is a case insensitive fashion --- so now we smash the case ourself. A new patch set on mailman-2.0.5 is available on this page. Pre-patched mailman source code can be found at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.5-plaintext-0.9.tgz ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-07 21:38 Message: Logged In: YES user_id=45814 Disregard last. (Apparently one can't attache files bigger than 256 kb.) Mailman-2.0.5 with plaintext patches applied can be found (for a limited time) at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.5-plaintext-0.8.tgz ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-07 21:33 Message: Logged In: YES user_id=45814 If you don't want to mess with patching the source, I've also attached (below) a tarball of the mailman-2.0.5 source with my patches already applied. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-07 21:16 Message: Logged In: YES user_id=45814 Here's a rough outline of how to proceed: 1. Start by unpacking a fresh copy of mailman-2.0.5.tgz 2. Change into the top source directory (which was created in the previous step. 3. Try applying my patches with: patch -p1 < [where.ever]/mailman-2.0.5-plaintext-0.8.patch (that's "dash pee one") That should work --- you should not get any warnings or prompts from patch. If you do, something is fishy. 4. Run ./configure and 'make install' as usual (read mailman's INSTALL for instructions on this.) Feel free to write me at . ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-05-07 20:30 Message: Logged In: NO For *some* reason when I apply the patch (the newest one) to my freshly downloaded version of Mailman 2.0.5 and compile and install mail never reaches the list. I've tried without the patch and everything works fine... perhaps I'm patching wrong? I'm just saying: patch < name_of_patch It makes me fix a few paths to some of the files, but that's it... :-/ Any help would be appriciated! ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-07 09:25 Message: Logged In: YES user_id=45814 Fixed bug (reported by Pug Bainter -- thanks!) New patches, on mailman-2.0.5 uploaded (below). The only real change is: --- 0.5/Mailman/FilteringMimeWriter.py Wed, 04 Apr 2001 10:04:36 -0700 dairiki (mailman/k/4_FilteringM 1.2 664) +++ 0.8(w)/Mailman/FilteringMimeWriter.py Mon, 07 May 2001 09:05:18 -0700 dairiki (mailman/k/4_FilteringM 1.3 664) @@ -185,8 +185,12 @@ pname, pval = string.split(param, '=', 1) return (string.lower(pname), rfc822.unquote(pval)) - return map(split_param, message.getplist()) - + def valid_param(param): + return '=' in param + + # Trailing ;'s in content-type yield empty strings from getplist(). + return map(split_param, + filter(valid_param, message.getplist())) def discards_data(fp): """Determine whether file object ignores data written to it. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-04-05 08:37 Message: Logged In: YES user_id=45814 I've just made a minor change: HTML converted to plain-text now includes a list of links at the end of the message. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=413752&group_id=103 From bob@nleaudio.com Wed Aug 28 01:54:51 2002 From: bob@nleaudio.com (Bob Puff@NLE) Date: Tue, 27 Aug 2002 20:54:51 -0400 Subject: [Mailman-Developers] Re: i18n support for Archiver References: <20020827035826.M37023@nleaudio.com> <26111.1030435874@kanga.nu> <3D6B9EAB.B8F33FAE@nleaudio.com> <200208272335.g7RNZ3q06610@quill.local> Message-ID: <3D6C1F5B.C62AC75B@nleaudio.com> > Ouch! > > Do you know whether 11-character directory names (which do not > contain any dots) will work portably? I do not think they will work. 95% sure they won't. Bob From noreply@sourceforge.net Wed Aug 28 02:19:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 27 Aug 2002 18:19:46 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-601082 ] personalized recip should be MIMEed Message-ID: Bugs item #601082, was opened at 2002-08-28 01:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=601082&group_id=103 Category: mail delivery Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: personalized recip should be MIMEed Initial Comment: If the list delivery is personalized, user's name is placed in To: header. When the user choose to register non-ascii character in the name, To: header contain non-ascii and breaks RFC(number?Idontknow). A quick and dirty patch is included. I hope Barry can inspect and revise it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=601082&group_id=103 From noreply@sourceforge.net Wed Aug 28 04:44:37 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 27 Aug 2002 20:44:37 -0700 Subject: [Mailman-Developers] [ mailman-Patches-413752 ] Coerce posts to plain text. Message-ID: Patches item #413752, was opened at 2001-04-04 10:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=413752&group_id=103 Category: mail delivery Group: Mailman 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: Geoffrey T. Dairiki (dairiki) Assigned to: Nobody/Anonymous (nobody) Summary: Coerce posts to plain text. Initial Comment: This patch adds the ability to have all posts to a mailing list forced into a MIME text/plain format. Many mailing lists have a charter which forbids binary and HTML posts to the list. This patch allows such a charter to be enforced is a maximally transparent manner. The feature is configurable on a per-list basis. If enabled, all posts to the list are run through a filter which: Squashes multipart messages into a single flat message (it picks the most plain-text-like alternative from multipart/alternative entities.) Converts 'text/html', 'text/enriched', and 'text/richtext' entities to 'text/plain'. Deletes cruft headers from content of type 'message/rfc822'. Deletes any uuencoded files from 'text/plain' entities. Entities of any other types are assumed to be binary attachements are are deleted. This patch is on mailman-2.0.3. ---------------------------------------------------------------------- >Comment By: Geoffrey T. Dairiki (dairiki) Date: 2002-08-27 20:44 Message: Logged In: YES user_id=45814 It seems the patches continue to work (basically unchanged) for Mailman-2.0.13. Updated patches are attached below. The patches as well as a pre-patched Mailman-2.0.13 tarball are at ftp://www.dairiki.org/pub/mailman/ ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-08-27 17:22 Message: Logged In: NO Hi Dairiki, It's me... I added your patch in my latest version and it's running OK... you can post the patch here! :) ---------------------------------------------------------------------- Comment By: Jozeph Brasil (jozeph) Date: 2002-08-27 12:00 Message: Logged In: YES user_id=17693 Hello dairiki... do you have this patch for Mailman-2.0.13 ? ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2002-08-13 08:43 Message: Logged In: YES user_id=45814 I don't have strong feelings, but my druthers would be to wait until 2.1 is officially designated "stable". A link from the wiki would be great! (There is/was already a link from the FAQ.) ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-13 08:29 Message: Logged In: YES user_id=12800 Since this patch is against 2.0.x and since MM2.1 provides support for stuff like this, I'm inclined to close this patch. I'd be willing to add a link to this from the unofficial patches wiki. What do you think? ---------------------------------------------------------------------- Comment By: Seb Wills (sebwills) Date: 2002-02-23 08:20 Message: Logged In: YES user_id=467580 This patch seems to leave any preamble above the first part of a multipart message intact. Many mailers put blurb such as "This is a MIME-encoded message; you will need a MIME- aware mail client to see all of this message." here, which it makes no sense to reproduce after the mail has be coerced into plaintext. Looks like it's easy enough to change this behaviour by commenting out the line mimetools.copybinary(infp, outfp) # copy preamble from Mailman/FilteringMimeWriter.py ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-12-15 10:15 Message: Logged In: YES user_id=45814 Another bug fix. Lines which contain nothing but the word 'end' mysteriously dissapear. (Reported by David Gibbs.) The only changed file in Mailman/FilteringMimeWriter.py, I've attached the latest version of that file to this page. As usual, patches on mailman 2.0.8 are also attached. Diffs and a patched Mailman-2.0.8 tarball are at ftp://www.dairiki.org/pub/mailman/ ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-09-08 13:08 Message: Logged In: YES user_id=45814 More fixes. * Mailman/FilteringMimeWriter.py: Fixes for bugs in python 1.5.2's quopri library module. The plaintext patches are at version 0.14. Look for the patches on Mailman 2.0.6, as well as a complete tarball of patched Mailman 2.0.6 code at ftp://www.dairiki.org/pub/mailman/ Patches on 2.0.6 are also attached to this page. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-08-25 12:34 Message: Logged In: YES user_id=45814 More fixes: * Mailman/PlaintextMimeWriter.py: Change Message-ID: of filtered messages. * Mailman/pythonlib/multifile.py: Fix obscure but occasionally fatal bug. The first fix is very minor. The second fix fixes a bug which caused the plaintext filter to fail occasionally. Diffs from mailman-2.0.6 are available from this page and are also at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.6-plaintext-0.13.patch.gz Pre-patched mailman-2.0.6 source code is at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.6-plaintext-0.13.tgz ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-06-16 11:33 Message: Logged In: NO After applying this patch to 2.0.5, I found that I had to add this line manually to my existing config file $prefix/Mailman/mm_cfg.py... DEFAULT_FORCE_PLAIN_TEXT = 0 If this line is not added, any web requests and any messages posted will produce an error "AttributeError : DEFAULT_FORCE_PLAIN_TEXT". Not sure if I did something wrong or if this is normal, but I wanted to advise others just in case ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-19 16:49 Message: Logged In: YES user_id=45814 More fixes: * Mailman/FilteringMimeWriter.py: Handle 'content-type: multipart' (no subtype) gracefully. * Mailman/Handlers/PlainText.py: Catch exceptions (fatal errors) from plaintext filter. When exception is caught, an error is logged, but the message is passed on unfiltered. (A diagnostic message is added to the message headers.) This should make it so little piddly bugs in the filter will get noticed, but at the same time will not cause messages to get stuck in the queue. Patches from mailman-2.0.5 are available from this page and are also at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.5-plaintext-0.10.patch.gz Pre-patched mailman-2.0.5 source code is at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.5-plaintext-0.10.tgz ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-17 12:27 Message: Logged In: YES user_id=45814 Another minor bugfix: it turns out pythons mimetools doesn't treat the content-transfer-encoding is a case insensitive fashion --- so now we smash the case ourself. A new patch set on mailman-2.0.5 is available on this page. Pre-patched mailman source code can be found at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.5-plaintext-0.9.tgz ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-07 21:38 Message: Logged In: YES user_id=45814 Disregard last. (Apparently one can't attache files bigger than 256 kb.) Mailman-2.0.5 with plaintext patches applied can be found (for a limited time) at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.5-plaintext-0.8.tgz ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-07 21:33 Message: Logged In: YES user_id=45814 If you don't want to mess with patching the source, I've also attached (below) a tarball of the mailman-2.0.5 source with my patches already applied. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-07 21:16 Message: Logged In: YES user_id=45814 Here's a rough outline of how to proceed: 1. Start by unpacking a fresh copy of mailman-2.0.5.tgz 2. Change into the top source directory (which was created in the previous step. 3. Try applying my patches with: patch -p1 < [where.ever]/mailman-2.0.5-plaintext-0.8.patch (that's "dash pee one") That should work --- you should not get any warnings or prompts from patch. If you do, something is fishy. 4. Run ./configure and 'make install' as usual (read mailman's INSTALL for instructions on this.) Feel free to write me at . ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-05-07 20:30 Message: Logged In: NO For *some* reason when I apply the patch (the newest one) to my freshly downloaded version of Mailman 2.0.5 and compile and install mail never reaches the list. I've tried without the patch and everything works fine... perhaps I'm patching wrong? I'm just saying: patch < name_of_patch It makes me fix a few paths to some of the files, but that's it... :-/ Any help would be appriciated! ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-07 09:25 Message: Logged In: YES user_id=45814 Fixed bug (reported by Pug Bainter -- thanks!) New patches, on mailman-2.0.5 uploaded (below). The only real change is: --- 0.5/Mailman/FilteringMimeWriter.py Wed, 04 Apr 2001 10:04:36 -0700 dairiki (mailman/k/4_FilteringM 1.2 664) +++ 0.8(w)/Mailman/FilteringMimeWriter.py Mon, 07 May 2001 09:05:18 -0700 dairiki (mailman/k/4_FilteringM 1.3 664) @@ -185,8 +185,12 @@ pname, pval = string.split(param, '=', 1) return (string.lower(pname), rfc822.unquote(pval)) - return map(split_param, message.getplist()) - + def valid_param(param): + return '=' in param + + # Trailing ;'s in content-type yield empty strings from getplist(). + return map(split_param, + filter(valid_param, message.getplist())) def discards_data(fp): """Determine whether file object ignores data written to it. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-04-05 08:37 Message: Logged In: YES user_id=45814 I've just made a minor change: HTML converted to plain-text now includes a list of links at the end of the message. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=413752&group_id=103 From noreply@sourceforge.net Wed Aug 28 05:40:31 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 27 Aug 2002 21:40:31 -0700 Subject: [Mailman-Developers] [ mailman-Patches-413752 ] Coerce posts to plain text. Message-ID: Patches item #413752, was opened at 2001-04-04 13:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=413752&group_id=103 Category: mail delivery Group: Mailman 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: Geoffrey T. Dairiki (dairiki) Assigned to: Nobody/Anonymous (nobody) Summary: Coerce posts to plain text. Initial Comment: This patch adds the ability to have all posts to a mailing list forced into a MIME text/plain format. Many mailing lists have a charter which forbids binary and HTML posts to the list. This patch allows such a charter to be enforced is a maximally transparent manner. The feature is configurable on a per-list basis. If enabled, all posts to the list are run through a filter which: Squashes multipart messages into a single flat message (it picks the most plain-text-like alternative from multipart/alternative entities.) Converts 'text/html', 'text/enriched', and 'text/richtext' entities to 'text/plain'. Deletes cruft headers from content of type 'message/rfc822'. Deletes any uuencoded files from 'text/plain' entities. Entities of any other types are assumed to be binary attachements are are deleted. This patch is on mailman-2.0.3. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-28 00:40 Message: Logged In: YES user_id=12800 BTW, I've finally added that link from the wiki to this patch. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2002-08-27 23:44 Message: Logged In: YES user_id=45814 It seems the patches continue to work (basically unchanged) for Mailman-2.0.13. Updated patches are attached below. The patches as well as a pre-patched Mailman-2.0.13 tarball are at ftp://www.dairiki.org/pub/mailman/ ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-08-27 20:22 Message: Logged In: NO Hi Dairiki, It's me... I added your patch in my latest version and it's running OK... you can post the patch here! :) ---------------------------------------------------------------------- Comment By: Jozeph Brasil (jozeph) Date: 2002-08-27 15:00 Message: Logged In: YES user_id=17693 Hello dairiki... do you have this patch for Mailman-2.0.13 ? ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2002-08-13 11:43 Message: Logged In: YES user_id=45814 I don't have strong feelings, but my druthers would be to wait until 2.1 is officially designated "stable". A link from the wiki would be great! (There is/was already a link from the FAQ.) ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-13 11:29 Message: Logged In: YES user_id=12800 Since this patch is against 2.0.x and since MM2.1 provides support for stuff like this, I'm inclined to close this patch. I'd be willing to add a link to this from the unofficial patches wiki. What do you think? ---------------------------------------------------------------------- Comment By: Seb Wills (sebwills) Date: 2002-02-23 11:20 Message: Logged In: YES user_id=467580 This patch seems to leave any preamble above the first part of a multipart message intact. Many mailers put blurb such as "This is a MIME-encoded message; you will need a MIME- aware mail client to see all of this message." here, which it makes no sense to reproduce after the mail has be coerced into plaintext. Looks like it's easy enough to change this behaviour by commenting out the line mimetools.copybinary(infp, outfp) # copy preamble from Mailman/FilteringMimeWriter.py ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-12-15 13:15 Message: Logged In: YES user_id=45814 Another bug fix. Lines which contain nothing but the word 'end' mysteriously dissapear. (Reported by David Gibbs.) The only changed file in Mailman/FilteringMimeWriter.py, I've attached the latest version of that file to this page. As usual, patches on mailman 2.0.8 are also attached. Diffs and a patched Mailman-2.0.8 tarball are at ftp://www.dairiki.org/pub/mailman/ ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-09-08 16:08 Message: Logged In: YES user_id=45814 More fixes. * Mailman/FilteringMimeWriter.py: Fixes for bugs in python 1.5.2's quopri library module. The plaintext patches are at version 0.14. Look for the patches on Mailman 2.0.6, as well as a complete tarball of patched Mailman 2.0.6 code at ftp://www.dairiki.org/pub/mailman/ Patches on 2.0.6 are also attached to this page. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-08-25 15:34 Message: Logged In: YES user_id=45814 More fixes: * Mailman/PlaintextMimeWriter.py: Change Message-ID: of filtered messages. * Mailman/pythonlib/multifile.py: Fix obscure but occasionally fatal bug. The first fix is very minor. The second fix fixes a bug which caused the plaintext filter to fail occasionally. Diffs from mailman-2.0.6 are available from this page and are also at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.6-plaintext-0.13.patch.gz Pre-patched mailman-2.0.6 source code is at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.6-plaintext-0.13.tgz ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-06-16 14:33 Message: Logged In: NO After applying this patch to 2.0.5, I found that I had to add this line manually to my existing config file $prefix/Mailman/mm_cfg.py... DEFAULT_FORCE_PLAIN_TEXT = 0 If this line is not added, any web requests and any messages posted will produce an error "AttributeError : DEFAULT_FORCE_PLAIN_TEXT". Not sure if I did something wrong or if this is normal, but I wanted to advise others just in case ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-19 19:49 Message: Logged In: YES user_id=45814 More fixes: * Mailman/FilteringMimeWriter.py: Handle 'content-type: multipart' (no subtype) gracefully. * Mailman/Handlers/PlainText.py: Catch exceptions (fatal errors) from plaintext filter. When exception is caught, an error is logged, but the message is passed on unfiltered. (A diagnostic message is added to the message headers.) This should make it so little piddly bugs in the filter will get noticed, but at the same time will not cause messages to get stuck in the queue. Patches from mailman-2.0.5 are available from this page and are also at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.5-plaintext-0.10.patch.gz Pre-patched mailman-2.0.5 source code is at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.5-plaintext-0.10.tgz ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-17 15:27 Message: Logged In: YES user_id=45814 Another minor bugfix: it turns out pythons mimetools doesn't treat the content-transfer-encoding is a case insensitive fashion --- so now we smash the case ourself. A new patch set on mailman-2.0.5 is available on this page. Pre-patched mailman source code can be found at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.5-plaintext-0.9.tgz ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-08 00:38 Message: Logged In: YES user_id=45814 Disregard last. (Apparently one can't attache files bigger than 256 kb.) Mailman-2.0.5 with plaintext patches applied can be found (for a limited time) at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.5-plaintext-0.8.tgz ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-08 00:33 Message: Logged In: YES user_id=45814 If you don't want to mess with patching the source, I've also attached (below) a tarball of the mailman-2.0.5 source with my patches already applied. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-08 00:16 Message: Logged In: YES user_id=45814 Here's a rough outline of how to proceed: 1. Start by unpacking a fresh copy of mailman-2.0.5.tgz 2. Change into the top source directory (which was created in the previous step. 3. Try applying my patches with: patch -p1 < [where.ever]/mailman-2.0.5-plaintext-0.8.patch (that's "dash pee one") That should work --- you should not get any warnings or prompts from patch. If you do, something is fishy. 4. Run ./configure and 'make install' as usual (read mailman's INSTALL for instructions on this.) Feel free to write me at . ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-05-07 23:30 Message: Logged In: NO For *some* reason when I apply the patch (the newest one) to my freshly downloaded version of Mailman 2.0.5 and compile and install mail never reaches the list. I've tried without the patch and everything works fine... perhaps I'm patching wrong? I'm just saying: patch < name_of_patch It makes me fix a few paths to some of the files, but that's it... :-/ Any help would be appriciated! ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-07 12:25 Message: Logged In: YES user_id=45814 Fixed bug (reported by Pug Bainter -- thanks!) New patches, on mailman-2.0.5 uploaded (below). The only real change is: --- 0.5/Mailman/FilteringMimeWriter.py Wed, 04 Apr 2001 10:04:36 -0700 dairiki (mailman/k/4_FilteringM 1.2 664) +++ 0.8(w)/Mailman/FilteringMimeWriter.py Mon, 07 May 2001 09:05:18 -0700 dairiki (mailman/k/4_FilteringM 1.3 664) @@ -185,8 +185,12 @@ pname, pval = string.split(param, '=', 1) return (string.lower(pname), rfc822.unquote(pval)) - return map(split_param, message.getplist()) - + def valid_param(param): + return '=' in param + + # Trailing ;'s in content-type yield empty strings from getplist(). + return map(split_param, + filter(valid_param, message.getplist())) def discards_data(fp): """Determine whether file object ignores data written to it. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-04-05 11:37 Message: Logged In: YES user_id=45814 I've just made a minor change: HTML converted to plain-text now includes a list of links at the end of the message. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=413752&group_id=103 From barry@python.org Wed Aug 28 05:45:33 2002 From: barry@python.org (Barry A. Warsaw) Date: Wed, 28 Aug 2002 00:45:33 -0400 Subject: [Mailman-Developers] Re: i18n support for Archiver References: <20020827035826.M37023@nleaudio.com> <26111.1030435874@kanga.nu> <3D6B9EAB.B8F33FAE@nleaudio.com> Message-ID: <15724.21869.360358.42595@anthem.wooz.org> >>>>> "B" == Bob writes: >> Easier to use one of the extended CDROM formats which supports >> long filenames B> A few months ago I went through this with a customer who wanted B> a copy of the archives on CDROM from their list. The extended B> filenames work fine under Windows, but not under the MacOS. B> They have a different format for their extended filenames. The B> only common denominator I found was the 8.3 dos filenames. That must have been an old version of MacOS. I just tested a CD I burned w/Toast using (IIRC) Mac+PC Hybrid, which is probably ISO 9660 with some fairly universal extensions (Rockridge, but not Joliet????). In any event the long file names were easily readable under MacOS 9.2.2 and OSX 10.1.5. Python finally abandoned 8.3 names at least a few years ago, and I think we shouldn't go there either. -Barry From barry@python.org Wed Aug 28 05:51:23 2002 From: barry@python.org (Barry A. Warsaw) Date: Wed, 28 Aug 2002 00:51:23 -0400 Subject: [Mailman-Developers] Re: i18n support for Archiver References: <200208272023.g7RKNMqY025651@utopia.West.Sun.COM> Message-ID: <15724.22219.461727.274724@anthem.wooz.org> >>>>> "DM" == Dan Mick writes: DM> Mac doesn't support RockRidge extensions? That would suck. DM> Unfortunately a lot of CDROM-burning programs "just assume" DM> you want the Windows-specific Joliet stuff. :( :( It may be that MacOS has trouble with Joliet. That may be limited to just OS9. My wife was sent some image disks for her work some months back that we couldn't read on either Linux or MacOS. At the time we didn't have OSX up so I couldn't check that, but the folks who sent her the disk claimed they could read them on their Windows boxes. I don't have any Windows machines anymore so I couldn't verify that. So far though, I haven't found a CDROM that I could read on Linux but not MacOS{9,X} or vice versa. Long file names and all. I personally don't have much sympathy for Windows-only disks, since it's easy enough to burn cross-platform CDROMs. -Barry From noreply@sourceforge.net Wed Aug 28 06:07:22 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 27 Aug 2002 22:07:22 -0700 Subject: [Mailman-Developers] [ mailman-Patches-601117 ] add sequencial number in subject prefix Message-ID: Patches item #601117, was opened at 2002-08-28 05:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=601117&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: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=601117&group_id=103 From Dan.Mick@sun.com Wed Aug 28 10:00:15 2002 From: Dan.Mick@sun.com (Dan Mick) Date: Wed, 28 Aug 2002 02:00:15 -0700 Subject: [Mailman-Developers] Re: i18n support for Archiver References: <20020827035826.M37023@nleaudio.com> <26111.1030435874@kanga.nu> <3D6B9EAB.B8F33FAE@nleaudio.com> <15724.21869.360358.42595@anthem.wooz.org> Message-ID: <3D6C911F.9050001@sun.com> Barry A. Warsaw wrote: >>>>>>"B" == Bob writes: >>>>> > > >> Easier to use one of the extended CDROM formats which supports > >> long filenames > > B> A few months ago I went through this with a customer who wanted > B> a copy of the archives on CDROM from their list. The extended > B> filenames work fine under Windows, but not under the MacOS. > B> They have a different format for their extended filenames. The > B> only common denominator I found was the 8.3 dos filenames. > > That must have been an old version of MacOS. I just tested a CD I > burned w/Toast using (IIRC) Mac+PC Hybrid, which is probably ISO 9660 > with some fairly universal extensions (Rockridge, but not Joliet????). "Hybrid" probably means "HFS *and* Joliet on the same disc". It's completely sad, the state of CD filesystems. Sigh. From noreply@sourceforge.net Wed Aug 28 13:22:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 28 Aug 2002 05:22:36 -0700 Subject: [Mailman-Developers] [ mailman-Feature Requests-601256 ] Date time Message-ID: Feature Requests item #601256, was opened at 2002-08-28 09:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=601256&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jozeph Brasil (jozeph) Assigned to: Nobody/Anonymous (nobody) Summary: Date time Initial Comment: Hi Poeple, We are um August... but in my Archive I have messages from JUNE... how I setup the DATA TIME using the local machine? Look the Archive of MAILMAN-USERS... have messages from 2024, 2005... in future! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=601256&group_id=103 From noreply@sourceforge.net Wed Aug 28 14:19:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 28 Aug 2002 06:19:19 -0700 Subject: [Mailman-Developers] [ mailman-Feature Requests-601256 ] Date time Message-ID: Feature Requests item #601256, was opened at 2002-08-28 08:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=601256&group_id=103 Category: None Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Jozeph Brasil (jozeph) Assigned to: Nobody/Anonymous (nobody) Summary: Date time Initial Comment: Hi Poeple, We are um August... but in my Archive I have messages from JUNE... how I setup the DATA TIME using the local machine? Look the Archive of MAILMAN-USERS... have messages from 2024, 2005... in future! ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-28 09:19 Message: Logged In: YES user_id=12800 You likely need to set clobber_date (see the Archiver admin options) so that the current date is believed over the Date: header, which can sometimes lie. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=601256&group_id=103 From barry@zope.com Wed Aug 28 14:26:29 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 28 Aug 2002 09:26:29 -0400 Subject: [Mailman-Developers] (More) pristine archives References: <15722.56232.271718.506588@anthem.wooz.org> <3D6AE383.9000800@is.kochi-u.ac.jp> Message-ID: <15724.53125.362976.939752@anthem.wooz.org> >>>>> "TK" == Tokio Kikuchi writes: >> An interesting issue came up today while we were playing with a >> Bayesian spam classifier. Mailman's archives aren't very >> clean. Messages are sent to the archiver after various >> headering munging steps, including the adding of the List-* >> headers and the Subject prefix. TK> The headers are in the raw archive and not in the monthly (or TK> quaterly, weekly) text format archive. I would rather stop TK> publicizing the raw archive even if the other archives are TK> public accessible. At least it should be configurable (in TK> mm_cfg). Some headers are stripped before being added to the quarterly/weekly mini-archive, but both see messages /after/ they've been munged. (On the second point, I'll try to look at patch #594771. That would see like a good opportunity to make raw archives optional.) >> We still want to do some munging, e.g. for anonymous lists. >> This tells me that we may want to move ToArchive up before >> CookHeaders in the global pipeline. TK> We use a modified version of mailman 2.0.x in Japan and we TK> like a feature of adding numbers in the subject header. The TK> users tend to reference articles by the number not by the TK> archive URL. So, we want the archive to be munged. That seems to be the concensus, i.e. the archive should reflect what the members get. Makes sense -- if you want a more pristine archive, you can interpose a tee to a file before the message gets to Mailman, or you could add a different handler module. I'll leave things as is. TK> BTW, I'm preparing a patch for numbering the subject prefix. Cool. But this is likely a new feature that will have to wait until after 2.1 final. Thanks, -Barry From barry@zope.com Wed Aug 28 14:27:24 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 28 Aug 2002 09:27:24 -0400 Subject: [Mailman-Developers] (More) pristine archives References: <15722.56232.271718.506588@anthem.wooz.org> <26074.1030435734@kanga.nu> Message-ID: <15724.53180.531692.628375@anthem.wooz.org> >>>>> "JCL" == J C Lawrence writes: >> What do you think? JCL> Specifically that I want to archive the exact message, down JCL> to the byte, that subscriber's receive. Of course, that's literally impossible, but I get the intention. Okay, no changes here. -Barry From barry@zope.com Wed Aug 28 14:29:29 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 28 Aug 2002 09:29:29 -0400 Subject: [Mailman-Developers] (More) pristine archives References: <15722.56232.271718.506588@anthem.wooz.org> <26074.1030435734@kanga.nu> <200208271610.g7RGAP003261@quill.local> Message-ID: <15724.53305.885745.123950@anthem.wooz.org> >>>>> "NB" == Norbert Bollow writes: >> Specifically that I want to archive the exact message, down to >> the byte, that subscriber's receive. Beyond that I don't care. NB> I'd love to have this, and in addition (perhaps in a separate NB> file) the exact headers and first ten lines of all incoming NB> messages (postings, admin requests, subscription NB> confirmations, everything). If someone where to work up a patch , the way I'd do this would be to add a IncomingLogger.py handler module that logged the information you want to logs/incoming. Then I'd stick this at the top of GLOBAL_PIPELINE. -Barry From nb@cisto.com Wed Aug 28 16:43:23 2002 From: nb@cisto.com (Norbert Bollow) Date: Wed, 28 Aug 2002 17:43:23 +0200 Subject: [Mailman-Developers] (More) pristine archives In-Reply-To: <15724.53305.885745.123950@anthem.wooz.org> (barry@zope.com) References: <15722.56232.271718.506588@anthem.wooz.org> <26074.1030435734@kanga.nu><200208271610.g7RGAP003261@quill.local> <15724.53305.885745.123950@anthem.wooz.org> Message-ID: <200208281543.g7SFhN011930@quill.local> Barry A. Warsaw <> wrote: > If someone where to work up a patch I think it's not likely for any such patches to come from me anytime soon, as I have bigger fish to fry. Specifically I'm going forward with implementing a MySQL-based archives system which can be used as a drop-in replacement for Pipermail which which will also provide the functionalities of a web board and a search engine optimization system. (Yes, it'll be 100% Python, and GPL'd Free Software). Greetings, Norbert. -- Founder & Steering Committee member of http://gnu.org/projects/dotgnu/ Norbert Bollow, Weidlistr.18, CH-8624 Gruet (near Zurich, Switzerland) Tel +41 1 972 20 59 Fax +41 1 972 20 69 http://norbert.ch List hosting with GNU Mailman on your own domain name http://cisto.com From Dale@Newfield.org Wed Aug 28 16:44:26 2002 From: Dale@Newfield.org (Dale Newfield) Date: Wed, 28 Aug 2002 11:44:26 -0400 (EDT) Subject: [Mailman-Developers] (More) pristine archives In-Reply-To: <200208281543.g7SFhN011930@quill.local> Message-ID: On Wed, 28 Aug 2002, Norbert Bollow wrote: > Specifically I'm going forward with implementing a MySQL-based archives > system which can be used as a drop-in replacement for Pipermail which > which will also provide the functionalities of a web board and a search > engine optimization system. Can I request that you build this in an SQL implementation independant manner (so one could drop in PostgreSQL in place of MySQL and have it work)? I'm building my DB-backed piece against MySQL, but I'm trying to build it in an implementation independant manner as I'd like to change over to Postgres... (Since MySQL doesn't support transactions, I'm not sure how I'll handle the .Save() piece yet...) -Dale From barry@zope.com Wed Aug 28 16:47:45 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 28 Aug 2002 11:47:45 -0400 Subject: [Mailman-Developers] (More) pristine archives References: <15722.56232.271718.506588@anthem.wooz.org> <26074.1030435734@kanga.nu> <200208271610.g7RGAP003261@quill.local> <15724.53305.885745.123950@anthem.wooz.org> <200208281543.g7SFhN011930@quill.local> Message-ID: <15724.61601.960504.889670@anthem.wooz.org> >>>>> "NB" == Norbert Bollow writes: >> If someone where to work up a patch NB> I think it's not likely for any such patches to come from me NB> anytime soon Maybe lodge a feature request. NB> , as I have bigger fish to fry. Specifically I'm NB> going forward with implementing a MySQL-based archives system NB> which can be used as a drop-in replacement for Pipermail which NB> which will also provide the functionalities of a web board and NB> a search engine optimization system. NB> (Yes, it'll be 100% Python, and GPL'd Free Software). Okay, that will be cool! You're off the hook. :) -Barry From barry@zope.com Wed Aug 28 16:49:20 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 28 Aug 2002 11:49:20 -0400 Subject: [Mailman-Developers] (More) pristine archives References: <200208281543.g7SFhN011930@quill.local> Message-ID: <15724.61696.44082.607216@anthem.wooz.org> >>>>> "DN" == Dale Newfield writes: DN> (Since MySQL doesn't support transactions, I'm not sure how DN> I'll handle the .Save() piece yet...) It still doesn't support transactions? -Barry From chuqui@plaidworks.com Wed Aug 28 17:04:41 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Wed, 28 Aug 2002 09:04:41 -0700 Subject: [Mailman-Developers] (More) pristine archives In-Reply-To: <15724.61696.44082.607216@anthem.wooz.org> Message-ID: On Wednesday, August 28, 2002, at 08:49 AM, Barry A. Warsaw wrote: > DN> (Since MySQL doesn't support transactions, I'm not sure how > DN> I'll handle the .Save() piece yet...) > > It still doesn't support transactions? > It does on InnoDB files, which seem to be their file structure of the future. Not on MyISAM. But for an archiving system, is that really a big deal? But in any event, using InnoDB files, it's a non-issue. (frankly, I've found you can do a lot of stuff without transactions quite nicely. For this, I just can't believe you need transacations, the volume of inserts and reads just isn't that large.) -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ Stress is when you wake up screaming and you realize you haven't fallen asleep yet. -- Chuq Von Rospach, Architech, Apple IS&T E-mail systems chuq@apple.com From chuqui@plaidworks.com Wed Aug 28 17:06:24 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Wed, 28 Aug 2002 09:06:24 -0700 Subject: [Mailman-Developers] (More) pristine archives In-Reply-To: <15724.61696.44082.607216@anthem.wooz.org> Message-ID: <19DEEF8E-BAA0-11D6-8287-0003934516A8@plaidworks.com> On Wednesday, August 28, 2002, at 08:49 AM, Barry A. Warsaw wrote: > DN> (Since MySQL doesn't support transactions, I'm not sure how > DN> I'll handle the .Save() piece yet...) > > It still doesn't support transactions? > It does on InnoDB files, which seem to be their file structure of the future. Not on MyISAM. But for an archiving system, is that really a big deal? But in any event, using InnoDB files, it's a non-issue. (frankly, I've found you can do a lot of stuff without transactions quite nicely. For this, I just can't believe you need transacations, the volume of inserts and reads just isn't that large.) -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ Stress is when you wake up screaming and you realize you haven't fallen asleep yet. -- Chuq Von Rospach, Architech, Apple IS&T E-mail systems chuq@apple.com From noreply@sourceforge.net Wed Aug 28 17:13:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 28 Aug 2002 09:13:50 -0700 Subject: [Mailman-Developers] [ mailman-Feature Requests-601256 ] Date time Message-ID: Feature Requests item #601256, was opened at 2002-08-28 09:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=601256&group_id=103 Category: None Group: None Status: Closed Resolution: Invalid Priority: 5 Submitted By: Jozeph Brasil (jozeph) Assigned to: Nobody/Anonymous (nobody) Summary: Date time Initial Comment: Hi Poeple, We are um August... but in my Archive I have messages from JUNE... how I setup the DATA TIME using the local machine? Look the Archive of MAILMAN-USERS... have messages from 2024, 2005... in future! ---------------------------------------------------------------------- >Comment By: Jozeph Brasil (jozeph) Date: 2002-08-28 13:13 Message: Logged In: YES user_id=17693 Hi, i'm using mailman-2.0.13... and in the Archive Admin section, don't have any options about clobber_date... Thanks to reply me! ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-28 10:19 Message: Logged In: YES user_id=12800 You likely need to set clobber_date (see the Archiver admin options) so that the current date is believed over the Date: header, which can sometimes lie. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=601256&group_id=103 From claw@kanga.nu Wed Aug 28 17:15:47 2002 From: claw@kanga.nu (J C Lawrence) Date: Wed, 28 Aug 2002 09:15:47 -0700 Subject: [Mailman-Developers] (More) pristine archives In-Reply-To: Message from Dale Newfield of "Wed, 28 Aug 2002 11:44:26 EDT." References: Message-ID: <14333.1030551347@kanga.nu> On Wed, 28 Aug 2002 11:44:26 -0400 (EDT) Dale Newfield wrote: > (Since MySQL doesn't support transactions, I'm not sure how I'll > handle the .Save() piece yet...) MySQL supports transactions. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From barry@zope.com Wed Aug 28 17:15:52 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 28 Aug 2002 12:15:52 -0400 Subject: [Mailman-Developers] (More) pristine archives References: <15724.61696.44082.607216@anthem.wooz.org> Message-ID: <15724.63288.396144.931109@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: CVR> (frankly, I've found you can do a lot of stuff without CVR> transactions quite nicely. For this, I just can't believe you CVR> need transacations, the volume of inserts and reads just CVR> isn't that large.) Right, sorry, I was asking for a different reason. ;) -Barry From barry@zope.com Wed Aug 28 17:17:24 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 28 Aug 2002 12:17:24 -0400 Subject: [Mailman-Developers] (More) pristine archives References: <19DEEF8E-BAA0-11D6-8287-0003934516A8@plaidworks.com> <3D6CF559.1D06B9CA@whatevernet.com> Message-ID: <15724.63380.891793.873770@anthem.wooz.org> >>>>> "AL" == Albino Lopes writes: AL> " I would like to unsubscribe your mailling list please. Send a message to mailman-developers-leave@python.org MM2.1-ly y'rs, -Barry From noreply@sourceforge.net Wed Aug 28 17:19:40 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 28 Aug 2002 09:19:40 -0700 Subject: [Mailman-Developers] [ mailman-Feature Requests-601256 ] Date time Message-ID: Feature Requests item #601256, was opened at 2002-08-28 08:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=601256&group_id=103 Category: None Group: None Status: Closed Resolution: Invalid Priority: 5 Submitted By: Jozeph Brasil (jozeph) Assigned to: Nobody/Anonymous (nobody) Summary: Date time Initial Comment: Hi Poeple, We are um August... but in my Archive I have messages from JUNE... how I setup the DATA TIME using the local machine? Look the Archive of MAILMAN-USERS... have messages from 2024, 2005... in future! ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-28 12:19 Message: Logged In: YES user_id=12800 It should, see http:///mailman/admin//?VARHELP=archive/clobber_date ---------------------------------------------------------------------- Comment By: Jozeph Brasil (jozeph) Date: 2002-08-28 12:13 Message: Logged In: YES user_id=17693 Hi, i'm using mailman-2.0.13... and in the Archive Admin section, don't have any options about clobber_date... Thanks to reply me! ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-28 09:19 Message: Logged In: YES user_id=12800 You likely need to set clobber_date (see the Archiver admin options) so that the current date is believed over the Date: header, which can sometimes lie. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=601256&group_id=103 From Dale@Newfield.org Wed Aug 28 18:14:10 2002 From: Dale@Newfield.org (Dale Newfield) Date: Wed, 28 Aug 2002 13:14:10 -0400 (EDT) Subject: [Mailman-Developers] (More) pristine archives In-Reply-To: <15724.61696.44082.607216@anthem.wooz.org> Message-ID: On Wed, 28 Aug 2002, Barry A. Warsaw wrote: > It still doesn't support transactions? No. :-( -Dale From Dale@Newfield.org Wed Aug 28 18:20:39 2002 From: Dale@Newfield.org (Dale Newfield) Date: Wed, 28 Aug 2002 13:20:39 -0400 (EDT) Subject: [Mailman-Developers] (More) pristine archives In-Reply-To: Message-ID: On Wed, 28 Aug 2002, Dale Newfield wrote: > On Wed, 28 Aug 2002, Barry A. Warsaw wrote: > > It still doesn't support transactions? > > No. :-( D'oh! Um, I guess I should've read the rest of the posts before responding. Now to go read up on that new table type, and how they tables of differing types interact with one another. I'm still concerned about having all of the operations in the lifetime of a mailman session reside in a single (possibly never confirmed) transaction, and whether that provides the interface we want (I.E., set values not actually getting set until .Save() time). -Dale From claw@kanga.nu Wed Aug 28 18:23:25 2002 From: claw@kanga.nu (J C Lawrence) Date: Wed, 28 Aug 2002 10:23:25 -0700 Subject: [Mailman-Developers] (More) pristine archives In-Reply-To: Message from Dale Newfield of "Wed, 28 Aug 2002 13:14:10 EDT." References: Message-ID: <15230.1030555405@kanga.nu> On Wed, 28 Aug 2002 13:14:10 -0400 (EDT) Dale Newfield wrote: > On Wed, 28 Aug 2002, Barry A. Warsaw wrote: >> It still doesn't support transactions? > No. :-( Check again. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From pioppo@ferrara.linux.it Wed Aug 28 19:06:52 2002 From: pioppo@ferrara.linux.it (Simone Piunno) Date: Wed, 28 Aug 2002 20:06:52 +0200 Subject: [Mailman-Developers] (More) pristine archives In-Reply-To: References: <15724.61696.44082.607216@anthem.wooz.org> Message-ID: <20020828180652.GA2021@ferrara.linux.it> On Wed, Aug 28, 2002 at 09:04:41AM -0700, Chuq Von Rospach wrote: > > DN> (Since MySQL doesn't support transactions, I'm not sure how > > DN> I'll handle the .Save() piece yet...) > > > >It still doesn't support transactions? > > > > It does on InnoDB files, which seem to be their file structure of the > future. Not on MyISAM. It does on BerkeleyDB too. Also: MyISAM has table-level locking BDB has page-level locking InnoDB has row-level locking -- Adde parvum parvo magnus acervus erit. Simone Piunno, FerraraLUG - http://members.ferrara.linux.it/pioppo From nb@cisto.com Thu Aug 29 09:15:26 2002 From: nb@cisto.com (Norbert Bollow) Date: Thu, 29 Aug 2002 10:15:26 +0200 Subject: [Mailman-Developers] (More) pristine archives In-Reply-To: (message from Dale Newfield on Wed, 28 Aug 2002 11:44:26 -0400 (EDT)) References: Message-ID: <200208290815.g7T8FQq16685@quill.local> Dale Newfield wrote: > On Wed, 28 Aug 2002, Norbert Bollow wrote: > > Specifically I'm going forward with implementing a MySQL-based archives > > system which can be used as a drop-in replacement for Pipermail which > > which will also provide the functionalities of a web board and a search > > engine optimization system. > > Can I request that you build this in an SQL implementation independant > manner (so one could drop in PostgreSQL in place of MySQL and have it > work)? I have to focus on building this to meet my needs, and my customers' needs... PostgreSQL support isn't among these needs as far as I can see. However since there is a standard for Python database API's, it shouldn't be too hard for someone to replace MySQLdb with the PostgreSQL equivalent, or even make this a configuration option. (I'll welcome patches for making this a configuration option :-) Greetings, Norbert. -- Founder & Steering Committee member of http://gnu.org/projects/dotgnu/ Norbert Bollow, Weidlistr.18, CH-8624 Gruet (near Zurich, Switzerland) Tel +41 1 972 20 59 Fax +41 1 972 20 69 http://norbert.ch List hosting with GNU Mailman on your own domain name http://cisto.com From Dale@Newfield.org Thu Aug 29 13:12:59 2002 From: Dale@Newfield.org (Dale Newfield) Date: Thu, 29 Aug 2002 08:12:59 -0400 (EDT) Subject: [Mailman-Developers] (More) pristine archives In-Reply-To: <200208290815.g7T8FQq16685@quill.local> Message-ID: On Thu, 29 Aug 2002, Norbert Bollow wrote: > I have to focus on building this to meet my needs, and my customers' > needs... You're already using Python's DB abstraction--I'm just asking you to write queries in pure SQL rather than using calls specific to that vendor. -Dale From barry@zope.com Thu Aug 29 18:49:52 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 29 Aug 2002 13:49:52 -0400 Subject: [Mailman-Developers] (More) pristine archives References: Message-ID: <15726.24256.951830.459164@anthem.wooz.org> >>>>> "DN" == Dale Newfield writes: DN> I'm still concerned about having all of the operations in the DN> lifetime of a mailman session reside in a single (possibly DN> never confirmed) transaction, and whether that provides the DN> interface we want (I.E., set values not actually getting set DN> until .Save() time). The intent is that .Save() markes the transaction boundary and is equivalent to a transaction commit. The qrunners are careful to only lock the lists when they need to modify list attributes, and they're always save the list inside the try clause, but unlock the list in the finally clause, e.g.: mlist.Lock() try: # do some stuff to mlist's attributes mlist.Save() finally: mlist.Unlock() Thus, if the code in the try causes an exception, the list will still get unlocked (otherwise the list would be hosed), but the transaction is aborted by virtue of not getting saved. A subsequent load of the mlist would begin a new transaction, with the old data. It's this last bit that's dodgy. There should probably be an explicit abort on exceptions inside the try, but there's no way to spell that with the current, legacy persistence mechanism, so it isn't in any of the code. I /think/ that if your MailList.Load() implicitly aborts any active transaction, you should be okay, but of course, none of that's tested. -Barry From barry@python.org Thu Aug 29 18:59:54 2002 From: barry@python.org (Barry A. Warsaw) Date: Thu, 29 Aug 2002 13:59:54 -0400 Subject: OT: Berkeley databases (was Re: [Mailman-Developers] (More) pristine archives) References: <15724.61696.44082.607216@anthem.wooz.org> <20020828180652.GA2021@ferrara.linux.it> Message-ID: <15726.24858.348894.152229@anthem.wooz.org> Are there any BerkeleyDB experts on this list? Apologies for the off-topic message, but if anybody has any clues I'd appreciate an *off-list* response. >>>>> "SP" == Simone Piunno writes: SP> It does on BerkeleyDB too. SP> Also: | MyISAM has table-level locking | BDB has page-level locking | InnoDB has row-level locking I've been doing a lot of work with straight BerkeleyDBs for Zope's ZODB, and I've run into a possibly fatal problem, for our application. The basic problem is that a Zope transaction is essentially unbounded in the number of objects it touches. Each object modified translates into updates to one or more BDB tables. I'm using BDB BTrees and transactions, so that translates to one lock per level of the database plus one lock per page. It's /possible/ that transactions can touch a huge number of pages, and because BDB allocates a static number of locks (growable, but only before the environment is opened), it's likely that we'll hit a transaction that exhausts the locks. There seems to be no way to avoid this. Cranking the BDB locks up just begs the question; eventually we run out of locks anyway, plus the more locks you allocate the more resources you consume. We could 'solve' this if BDB supported table-level locking, because we'd just lock the one or two tables that have unbounded updates and be done with it. Any suggestions folks have would be greatly appreciated. If more information is needed, contact me directly. ObMailman: It would be cool if MM3.0 had a ZODB backend, and I'd love to use a Berkeley based storage for that backend. No, this won't be /required/ for MM3.0 so you can stop fretting. ;) Thanks, -Barry From wheakory@isu.edu Thu Aug 29 19:49:40 2002 From: wheakory@isu.edu (Kory Wheatley) Date: Thu, 29 Aug 2002 12:49:40 -0600 Subject: [Mailman-Developers] Pause or queue message delivery Message-ID: <3D6E6CC4.2040304@isu.edu> I've got a Mailman mailing list that contains 14,000 subscribers, on a Linux box that's using sendmail has the delivery agent that sends all of the messages to one mail host, because all 14,000 subscribers have an email account on our mail server. This Linux box is only used to deliver our Mailman mailing to our Mail server which is a HPUX 11 server, using sendmail as the routing agent. We sent a message to the 14,000 recipient mailing list the other day and it put the load on our Unix Box that contains our mail server to the roof How can I setup sendmail or Mailman to not kill the system so hard when I send to this mailing list, can I change something in sendmail to maybe pause or queue delivery, after a certain number of messages that have been delivered and keep that sequence happening, or deliver 15 at a time and then pause 40 seconds or something, to cause better performance. I know that when I send to the mailing list, in our server logs sendmail creates a envelope of 21 recipients, is this the problem? It's not real critical that these messages when sent to the mailing list are received right away, so having a pause or delay between messages is not a problem. I've not done much configuration changes to sendmail or Mailman so, I would appreciate any help that would allow this delivery to allow better performance. -- ######################################### Kory Wheatley Academic Computing Analyst Sr. Phone 282-3874 ######################################### Everything must point to him. From Dale@Newfield.org Thu Aug 29 20:08:30 2002 From: Dale@Newfield.org (Dale Newfield) Date: Thu, 29 Aug 2002 15:08:30 -0400 (EDT) Subject: [Mailman-Developers] (More) pristine archives In-Reply-To: <15726.24256.951830.459164@anthem.wooz.org> Message-ID: On Thu, 29 Aug 2002, Barry A. Warsaw wrote: > The intent is that .Save() markes the transaction boundary and is > equivalent to a transaction commit. Right. > Thus, if the code in the try causes an exception, the list will still > get unlocked (otherwise the list would be hosed), but the transaction is > aborted by virtue of not getting saved. A subsequent load of the mlist > would begin a new transaction, with the old data. Right, but since .UnLock doesn't reload the data, any code refering to that mlist after unlocking would have different semantics depending upon which MemberAdaptor implementation is backing the list: With OldStyle, membership data in that mlist object is whatever it's been (temporarily) set to (but not saved); with SQL, membership data in that mlist has reverted to whatever it was when .Lock() was called. > It's this last bit that's dodgy. There should probably be an explicit > abort on exceptions inside the try, but there's no way to spell that > with the current, legacy persistence mechanism, so it isn't in any of > the code. Wouldn't that abort be triggered by a call to .UnLock() without a call to .Save()? I would think that all calls to .Lock() and any calls to .UnLock() without a prior call to .Save() should abort any current transaction. > I /think/ that if your MailList.Load() implicitly aborts any active > transaction, you should be okay, but of course, none of that's tested. MailList.Load() or MailList.Lock()? Having .Load() abort any active transaction means that you cannot load other mlists (even read-only) inside a .Lock();try....Save();finally .UnLock() block and have the transaction succeed... The place these two models (SQL transactions and mailList load, lock/save/unlock) break down is what happens when there are more than one MailList object in memory at a time. SQL transactions assumes only one MailList can be modified at a time, and the lock/save/unlock model doesn't make that assumption. If we can assume that only one mlist gets locked at a time, the SQL system will work, but I see no way to enforce mailman developers to abide by that assumption. (Except to implicitly abort active transactions as described above--and since the MailList.Save() method doesn't have a success/failure return code, there would be no indication that anything went wrong except silently ignoring requested DB changes.) -Dale From noreply@sourceforge.net Thu Aug 29 20:49:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 29 Aug 2002 12:49:01 -0700 Subject: [Mailman-Developers] [ mailman-Patches-602056 ] observing srcdir configure option Message-ID: Patches item #602056, was opened at 2002-08-29 19:49 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=602056&group_id=103 Category: None Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Donn Cave (donnc) Assigned to: Nobody/Anonymous (nobody) Summary: observing srcdir configure option Initial Comment: See attached (I hope) diffs for most Makefile.ins. The configure --srcdir option is very useful here. These minor changes allow it to work, mostly affecting the install phase. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=602056&group_id=103 From noreply@sourceforge.net Thu Aug 29 21:19:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 29 Aug 2002 13:19:59 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-602077 ] make install fails with import error Message-ID: Bugs item #602077, was opened at 2002-08-29 20:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=602077&group_id=103 Category: configuring/installing Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Goeran Zaengerlein (timetrack) Assigned to: Nobody/Anonymous (nobody) Summary: make install fails with import error Initial Comment: I tried to install Mailman 2.1b3 and I followed the installation instruction exactly but make install fails with the following message: --- snip --- Compiling /usr/local/mailman/Mailman/versions.py ... Traceback (most recent call last): File "bin/update", line 44, in ? import paths ImportError: No module named paths make: *** [update] Error 1 --- snap --- SuSE 7.2 Python 2.2.1 gcc 2.95.3 The problem was already described here: http://mail.python.org/pipermail/mailman-users/2002- July/020991.html but no solution has been posted as far as I could see... Any idea what I did wrong? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=602077&group_id=103 From noreply@sourceforge.net Thu Aug 29 21:34:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 29 Aug 2002 13:34:12 -0700 Subject: [Mailman-Developers] [ mailman-Patches-602082 ] lists_of_member optimization Message-ID: Patches item #602082, was opened at 2002-08-29 20:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=602082&group_id=103 Category: Web UI Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Donn Cave (donnc) Assigned to: Nobody/Anonymous (nobody) Summary: lists_of_member optimization Initial Comment: Well, really just avoiding it during application of user options. We ran the list count up to 5K, and found that the options form was very slow. It will still be slow if you ask for your options to be applied across the site, but this patch will alleviate the problem if you don't ask for that. It just tests whether globalopts actually has had any attributes applied to it, and only then calls lists_of_member. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=602082&group_id=103 From noreply@sourceforge.net Thu Aug 29 21:38:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 29 Aug 2002 13:38:24 -0700 Subject: [Mailman-Developers] [ mailman-Patches-602084 ] options.py lists_of_member optimization Message-ID: Patches item #602084, was opened at 2002-08-29 20:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=602084&group_id=103 Category: Web UI Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Donn Cave (donnc) Assigned to: Nobody/Anonymous (nobody) Summary: options.py lists_of_member optimization Initial Comment: Call lists_of_member() and apply globalopts only if called for, i.e., if globalopts is not empty. Empirically, this is a lot faster (if no global options requested), with ca. 5K lists. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=602084&group_id=103 From noreply@sourceforge.net Thu Aug 29 21:40:30 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 29 Aug 2002 13:40:30 -0700 Subject: [Mailman-Developers] [ mailman-Patches-602082 ] lists_of_member optimization Message-ID: Patches item #602082, was opened at 2002-08-29 20:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=602082&group_id=103 Category: Web UI Group: Mailman 2.1 >Status: Deleted Resolution: None Priority: 5 Submitted By: Donn Cave (donnc) Assigned to: Nobody/Anonymous (nobody) Summary: lists_of_member optimization Initial Comment: Well, really just avoiding it during application of user options. We ran the list count up to 5K, and found that the options form was very slow. It will still be slow if you ask for your options to be applied across the site, but this patch will alleviate the problem if you don't ask for that. It just tests whether globalopts actually has had any attributes applied to it, and only then calls lists_of_member. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=602082&group_id=103 From noreply@sourceforge.net Thu Aug 29 21:41:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 29 Aug 2002 13:41:10 -0700 Subject: [Mailman-Developers] [ mailman-Patches-602056 ] observing srcdir configure option Message-ID: Patches item #602056, was opened at 2002-08-29 19:49 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=602056&group_id=103 Category: None Group: Mailman 2.1 >Status: Deleted Resolution: None Priority: 5 Submitted By: Donn Cave (donnc) Assigned to: Nobody/Anonymous (nobody) Summary: observing srcdir configure option Initial Comment: See attached (I hope) diffs for most Makefile.ins. The configure --srcdir option is very useful here. These minor changes allow it to work, mostly affecting the install phase. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=602056&group_id=103 From noreply@sourceforge.net Thu Aug 29 21:44:17 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 29 Aug 2002 13:44:17 -0700 Subject: [Mailman-Developers] [ mailman-Patches-602087 ] observe configure srcdir Message-ID: Patches item #602087, was opened at 2002-08-29 20:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=602087&group_id=103 Category: None Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Donn Cave (donnc) Assigned to: Nobody/Anonymous (nobody) Summary: observe configure srcdir Initial Comment: (2nd try, hopefully with attached file this time.) These patches to Makefile.in in several directories make the --srcdir configure option work. Which can be very useful if you have a multi-platform build system. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=602087&group_id=103 From wheakory@isu.edu Fri Aug 30 05:45:53 2002 From: wheakory@isu.edu (Kory Wheatley) Date: Thu, 29 Aug 2002 22:45:53 -0600 Subject: [Mailman-Developers] Forget password form and unsubscribe without password Message-ID: <3D6EF881.CA59B84D@isu.edu> In mailman 2.0.13 is there a way for users to unsubscribe without remembering their password. I know you can send a message to listname-request@domain.com, and in the body put unsubscribe, but this requires a password. Has anyone developed a web forget password form, where the user can type in their email address and it will send them their mailman subscribers password. I would appreciate it if anyone would share their code. I'm trying to learn python. Kory Wheatley From claw@kanga.nu Fri Aug 30 06:34:26 2002 From: claw@kanga.nu (J C Lawrence) Date: Thu, 29 Aug 2002 22:34:26 -0700 Subject: OT: Berkeley databases (was Re: [Mailman-Developers] (More) pristine archives) In-Reply-To: Message from barry@python.org (Barry A. Warsaw) of "Thu, 29 Aug 2002 13:59:54 EDT." <15726.24858.348894.152229@anthem.wooz.org> References: <15724.61696.44082.607216@anthem.wooz.org> <20020828180652.GA2021@ferrara.linux.it> <15726.24858.348894.152229@anthem.wooz.org> Message-ID: <4335.1030685666@kanga.nu> On Thu, 29 Aug 2002 13:59:54 -0400 Barry A Warsaw wrote: > ObMailman: It would be cool if MM3.0 had a ZODB backend... Agreed. The ZODB semantics are quite nice, tho cleanly implementing purging (some will wish to never purge) could be interesting. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From barry@python.org Fri Aug 30 14:42:48 2002 From: barry@python.org (Barry A. Warsaw) Date: Fri, 30 Aug 2002 09:42:48 -0400 Subject: OT: Berkeley databases (was Re: [Mailman-Developers] (More) pristine archives) References: <15724.61696.44082.607216@anthem.wooz.org> <20020828180652.GA2021@ferrara.linux.it> <15726.24858.348894.152229@anthem.wooz.org> <4335.1030685666@kanga.nu> Message-ID: <15727.30296.291899.270529@anthem.wooz.org> >>>>> "JCL" == J C Lawrence writes: >> ObMailman: It would be cool if MM3.0 had a ZODB backend... JCL> Agreed. The ZODB semantics are quite nice, tho cleanly JCL> implementing purging (some will wish to never purge) could be JCL> interesting. You mean packing? One of the reasons for my question on BerkeleyDB is because I'm working on an autopacking storage based on BerkeleyDB. I think it would be a better choice for the back-back-end, although the insanity of BerkeleyDB on Linux distros might make that problematic. If we were to go with a FileStorage, then yes, packing is an issue. Of course, with a Berkeley storage you get all the headaches of Berkeley maintenance too. This is still a long ways off, so there's time to think about it. -Barry From noreply@sourceforge.net Fri Aug 30 16:02:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 30 Aug 2002 08:02:54 -0700 Subject: [Mailman-Developers] [ mailman-Patches-413752 ] Coerce posts to plain text. Message-ID: Patches item #413752, was opened at 2001-04-04 10:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=413752&group_id=103 Category: mail delivery Group: Mailman 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: Geoffrey T. Dairiki (dairiki) Assigned to: Nobody/Anonymous (nobody) Summary: Coerce posts to plain text. Initial Comment: This patch adds the ability to have all posts to a mailing list forced into a MIME text/plain format. Many mailing lists have a charter which forbids binary and HTML posts to the list. This patch allows such a charter to be enforced is a maximally transparent manner. The feature is configurable on a per-list basis. If enabled, all posts to the list are run through a filter which: Squashes multipart messages into a single flat message (it picks the most plain-text-like alternative from multipart/alternative entities.) Converts 'text/html', 'text/enriched', and 'text/richtext' entities to 'text/plain'. Deletes cruft headers from content of type 'message/rfc822'. Deletes any uuencoded files from 'text/plain' entities. Entities of any other types are assumed to be binary attachements are are deleted. This patch is on mailman-2.0.3. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-08-30 08:02 Message: Logged In: NO I'm new to Mailman. I don't understand why you don't have a patch for the current version of Mailman, 2.0.10. Can I apply an earlier patch safely? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-27 21:40 Message: Logged In: YES user_id=12800 BTW, I've finally added that link from the wiki to this patch. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2002-08-27 20:44 Message: Logged In: YES user_id=45814 It seems the patches continue to work (basically unchanged) for Mailman-2.0.13. Updated patches are attached below. The patches as well as a pre-patched Mailman-2.0.13 tarball are at ftp://www.dairiki.org/pub/mailman/ ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-08-27 17:22 Message: Logged In: NO Hi Dairiki, It's me... I added your patch in my latest version and it's running OK... you can post the patch here! :) ---------------------------------------------------------------------- Comment By: Jozeph Brasil (jozeph) Date: 2002-08-27 12:00 Message: Logged In: YES user_id=17693 Hello dairiki... do you have this patch for Mailman-2.0.13 ? ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2002-08-13 08:43 Message: Logged In: YES user_id=45814 I don't have strong feelings, but my druthers would be to wait until 2.1 is officially designated "stable". A link from the wiki would be great! (There is/was already a link from the FAQ.) ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-13 08:29 Message: Logged In: YES user_id=12800 Since this patch is against 2.0.x and since MM2.1 provides support for stuff like this, I'm inclined to close this patch. I'd be willing to add a link to this from the unofficial patches wiki. What do you think? ---------------------------------------------------------------------- Comment By: Seb Wills (sebwills) Date: 2002-02-23 08:20 Message: Logged In: YES user_id=467580 This patch seems to leave any preamble above the first part of a multipart message intact. Many mailers put blurb such as "This is a MIME-encoded message; you will need a MIME- aware mail client to see all of this message." here, which it makes no sense to reproduce after the mail has be coerced into plaintext. Looks like it's easy enough to change this behaviour by commenting out the line mimetools.copybinary(infp, outfp) # copy preamble from Mailman/FilteringMimeWriter.py ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-12-15 10:15 Message: Logged In: YES user_id=45814 Another bug fix. Lines which contain nothing but the word 'end' mysteriously dissapear. (Reported by David Gibbs.) The only changed file in Mailman/FilteringMimeWriter.py, I've attached the latest version of that file to this page. As usual, patches on mailman 2.0.8 are also attached. Diffs and a patched Mailman-2.0.8 tarball are at ftp://www.dairiki.org/pub/mailman/ ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-09-08 13:08 Message: Logged In: YES user_id=45814 More fixes. * Mailman/FilteringMimeWriter.py: Fixes for bugs in python 1.5.2's quopri library module. The plaintext patches are at version 0.14. Look for the patches on Mailman 2.0.6, as well as a complete tarball of patched Mailman 2.0.6 code at ftp://www.dairiki.org/pub/mailman/ Patches on 2.0.6 are also attached to this page. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-08-25 12:34 Message: Logged In: YES user_id=45814 More fixes: * Mailman/PlaintextMimeWriter.py: Change Message-ID: of filtered messages. * Mailman/pythonlib/multifile.py: Fix obscure but occasionally fatal bug. The first fix is very minor. The second fix fixes a bug which caused the plaintext filter to fail occasionally. Diffs from mailman-2.0.6 are available from this page and are also at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.6-plaintext-0.13.patch.gz Pre-patched mailman-2.0.6 source code is at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.6-plaintext-0.13.tgz ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-06-16 11:33 Message: Logged In: NO After applying this patch to 2.0.5, I found that I had to add this line manually to my existing config file $prefix/Mailman/mm_cfg.py... DEFAULT_FORCE_PLAIN_TEXT = 0 If this line is not added, any web requests and any messages posted will produce an error "AttributeError : DEFAULT_FORCE_PLAIN_TEXT". Not sure if I did something wrong or if this is normal, but I wanted to advise others just in case ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-19 16:49 Message: Logged In: YES user_id=45814 More fixes: * Mailman/FilteringMimeWriter.py: Handle 'content-type: multipart' (no subtype) gracefully. * Mailman/Handlers/PlainText.py: Catch exceptions (fatal errors) from plaintext filter. When exception is caught, an error is logged, but the message is passed on unfiltered. (A diagnostic message is added to the message headers.) This should make it so little piddly bugs in the filter will get noticed, but at the same time will not cause messages to get stuck in the queue. Patches from mailman-2.0.5 are available from this page and are also at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.5-plaintext-0.10.patch.gz Pre-patched mailman-2.0.5 source code is at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.5-plaintext-0.10.tgz ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-17 12:27 Message: Logged In: YES user_id=45814 Another minor bugfix: it turns out pythons mimetools doesn't treat the content-transfer-encoding is a case insensitive fashion --- so now we smash the case ourself. A new patch set on mailman-2.0.5 is available on this page. Pre-patched mailman source code can be found at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.5-plaintext-0.9.tgz ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-07 21:38 Message: Logged In: YES user_id=45814 Disregard last. (Apparently one can't attache files bigger than 256 kb.) Mailman-2.0.5 with plaintext patches applied can be found (for a limited time) at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.5-plaintext-0.8.tgz ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-07 21:33 Message: Logged In: YES user_id=45814 If you don't want to mess with patching the source, I've also attached (below) a tarball of the mailman-2.0.5 source with my patches already applied. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-07 21:16 Message: Logged In: YES user_id=45814 Here's a rough outline of how to proceed: 1. Start by unpacking a fresh copy of mailman-2.0.5.tgz 2. Change into the top source directory (which was created in the previous step. 3. Try applying my patches with: patch -p1 < [where.ever]/mailman-2.0.5-plaintext-0.8.patch (that's "dash pee one") That should work --- you should not get any warnings or prompts from patch. If you do, something is fishy. 4. Run ./configure and 'make install' as usual (read mailman's INSTALL for instructions on this.) Feel free to write me at . ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-05-07 20:30 Message: Logged In: NO For *some* reason when I apply the patch (the newest one) to my freshly downloaded version of Mailman 2.0.5 and compile and install mail never reaches the list. I've tried without the patch and everything works fine... perhaps I'm patching wrong? I'm just saying: patch < name_of_patch It makes me fix a few paths to some of the files, but that's it... :-/ Any help would be appriciated! ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-07 09:25 Message: Logged In: YES user_id=45814 Fixed bug (reported by Pug Bainter -- thanks!) New patches, on mailman-2.0.5 uploaded (below). The only real change is: --- 0.5/Mailman/FilteringMimeWriter.py Wed, 04 Apr 2001 10:04:36 -0700 dairiki (mailman/k/4_FilteringM 1.2 664) +++ 0.8(w)/Mailman/FilteringMimeWriter.py Mon, 07 May 2001 09:05:18 -0700 dairiki (mailman/k/4_FilteringM 1.3 664) @@ -185,8 +185,12 @@ pname, pval = string.split(param, '=', 1) return (string.lower(pname), rfc822.unquote(pval)) - return map(split_param, message.getplist()) - + def valid_param(param): + return '=' in param + + # Trailing ;'s in content-type yield empty strings from getplist(). + return map(split_param, + filter(valid_param, message.getplist())) def discards_data(fp): """Determine whether file object ignores data written to it. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-04-05 08:37 Message: Logged In: YES user_id=45814 I've just made a minor change: HTML converted to plain-text now includes a list of links at the end of the message. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=413752&group_id=103 From noreply@sourceforge.net Fri Aug 30 17:07:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 30 Aug 2002 09:07:19 -0700 Subject: [Mailman-Developers] [ mailman-Patches-413752 ] Coerce posts to plain text. Message-ID: Patches item #413752, was opened at 2001-04-04 10:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=413752&group_id=103 Category: mail delivery Group: Mailman 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: Geoffrey T. Dairiki (dairiki) Assigned to: Nobody/Anonymous (nobody) Summary: Coerce posts to plain text. Initial Comment: This patch adds the ability to have all posts to a mailing list forced into a MIME text/plain format. Many mailing lists have a charter which forbids binary and HTML posts to the list. This patch allows such a charter to be enforced is a maximally transparent manner. The feature is configurable on a per-list basis. If enabled, all posts to the list are run through a filter which: Squashes multipart messages into a single flat message (it picks the most plain-text-like alternative from multipart/alternative entities.) Converts 'text/html', 'text/enriched', and 'text/richtext' entities to 'text/plain'. Deletes cruft headers from content of type 'message/rfc822'. Deletes any uuencoded files from 'text/plain' entities. Entities of any other types are assumed to be binary attachements are are deleted. This patch is on mailman-2.0.3. ---------------------------------------------------------------------- >Comment By: Geoffrey T. Dairiki (dairiki) Date: 2002-08-30 09:07 Message: Logged In: YES user_id=45814 Enh? The current version of Mailman is 2.0.13. That said, the latest patch set (named mailman-2.0.13-plaintext-0.17.patch, and attached below) will work fine, I think, for Mailmain versions 2.0.x back to at least 2.0.8, and probably earlier. Feel free to e-mail me privately for more help. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-08-30 08:02 Message: Logged In: NO I'm new to Mailman. I don't understand why you don't have a patch for the current version of Mailman, 2.0.10. Can I apply an earlier patch safely? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-27 21:40 Message: Logged In: YES user_id=12800 BTW, I've finally added that link from the wiki to this patch. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2002-08-27 20:44 Message: Logged In: YES user_id=45814 It seems the patches continue to work (basically unchanged) for Mailman-2.0.13. Updated patches are attached below. The patches as well as a pre-patched Mailman-2.0.13 tarball are at ftp://www.dairiki.org/pub/mailman/ ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-08-27 17:22 Message: Logged In: NO Hi Dairiki, It's me... I added your patch in my latest version and it's running OK... you can post the patch here! :) ---------------------------------------------------------------------- Comment By: Jozeph Brasil (jozeph) Date: 2002-08-27 12:00 Message: Logged In: YES user_id=17693 Hello dairiki... do you have this patch for Mailman-2.0.13 ? ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2002-08-13 08:43 Message: Logged In: YES user_id=45814 I don't have strong feelings, but my druthers would be to wait until 2.1 is officially designated "stable". A link from the wiki would be great! (There is/was already a link from the FAQ.) ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-13 08:29 Message: Logged In: YES user_id=12800 Since this patch is against 2.0.x and since MM2.1 provides support for stuff like this, I'm inclined to close this patch. I'd be willing to add a link to this from the unofficial patches wiki. What do you think? ---------------------------------------------------------------------- Comment By: Seb Wills (sebwills) Date: 2002-02-23 08:20 Message: Logged In: YES user_id=467580 This patch seems to leave any preamble above the first part of a multipart message intact. Many mailers put blurb such as "This is a MIME-encoded message; you will need a MIME- aware mail client to see all of this message." here, which it makes no sense to reproduce after the mail has be coerced into plaintext. Looks like it's easy enough to change this behaviour by commenting out the line mimetools.copybinary(infp, outfp) # copy preamble from Mailman/FilteringMimeWriter.py ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-12-15 10:15 Message: Logged In: YES user_id=45814 Another bug fix. Lines which contain nothing but the word 'end' mysteriously dissapear. (Reported by David Gibbs.) The only changed file in Mailman/FilteringMimeWriter.py, I've attached the latest version of that file to this page. As usual, patches on mailman 2.0.8 are also attached. Diffs and a patched Mailman-2.0.8 tarball are at ftp://www.dairiki.org/pub/mailman/ ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-09-08 13:08 Message: Logged In: YES user_id=45814 More fixes. * Mailman/FilteringMimeWriter.py: Fixes for bugs in python 1.5.2's quopri library module. The plaintext patches are at version 0.14. Look for the patches on Mailman 2.0.6, as well as a complete tarball of patched Mailman 2.0.6 code at ftp://www.dairiki.org/pub/mailman/ Patches on 2.0.6 are also attached to this page. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-08-25 12:34 Message: Logged In: YES user_id=45814 More fixes: * Mailman/PlaintextMimeWriter.py: Change Message-ID: of filtered messages. * Mailman/pythonlib/multifile.py: Fix obscure but occasionally fatal bug. The first fix is very minor. The second fix fixes a bug which caused the plaintext filter to fail occasionally. Diffs from mailman-2.0.6 are available from this page and are also at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.6-plaintext-0.13.patch.gz Pre-patched mailman-2.0.6 source code is at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.6-plaintext-0.13.tgz ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-06-16 11:33 Message: Logged In: NO After applying this patch to 2.0.5, I found that I had to add this line manually to my existing config file $prefix/Mailman/mm_cfg.py... DEFAULT_FORCE_PLAIN_TEXT = 0 If this line is not added, any web requests and any messages posted will produce an error "AttributeError : DEFAULT_FORCE_PLAIN_TEXT". Not sure if I did something wrong or if this is normal, but I wanted to advise others just in case ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-19 16:49 Message: Logged In: YES user_id=45814 More fixes: * Mailman/FilteringMimeWriter.py: Handle 'content-type: multipart' (no subtype) gracefully. * Mailman/Handlers/PlainText.py: Catch exceptions (fatal errors) from plaintext filter. When exception is caught, an error is logged, but the message is passed on unfiltered. (A diagnostic message is added to the message headers.) This should make it so little piddly bugs in the filter will get noticed, but at the same time will not cause messages to get stuck in the queue. Patches from mailman-2.0.5 are available from this page and are also at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.5-plaintext-0.10.patch.gz Pre-patched mailman-2.0.5 source code is at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.5-plaintext-0.10.tgz ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-17 12:27 Message: Logged In: YES user_id=45814 Another minor bugfix: it turns out pythons mimetools doesn't treat the content-transfer-encoding is a case insensitive fashion --- so now we smash the case ourself. A new patch set on mailman-2.0.5 is available on this page. Pre-patched mailman source code can be found at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.5-plaintext-0.9.tgz ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-07 21:38 Message: Logged In: YES user_id=45814 Disregard last. (Apparently one can't attache files bigger than 256 kb.) Mailman-2.0.5 with plaintext patches applied can be found (for a limited time) at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.5-plaintext-0.8.tgz ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-07 21:33 Message: Logged In: YES user_id=45814 If you don't want to mess with patching the source, I've also attached (below) a tarball of the mailman-2.0.5 source with my patches already applied. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-07 21:16 Message: Logged In: YES user_id=45814 Here's a rough outline of how to proceed: 1. Start by unpacking a fresh copy of mailman-2.0.5.tgz 2. Change into the top source directory (which was created in the previous step. 3. Try applying my patches with: patch -p1 < [where.ever]/mailman-2.0.5-plaintext-0.8.patch (that's "dash pee one") That should work --- you should not get any warnings or prompts from patch. If you do, something is fishy. 4. Run ./configure and 'make install' as usual (read mailman's INSTALL for instructions on this.) Feel free to write me at . ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-05-07 20:30 Message: Logged In: NO For *some* reason when I apply the patch (the newest one) to my freshly downloaded version of Mailman 2.0.5 and compile and install mail never reaches the list. I've tried without the patch and everything works fine... perhaps I'm patching wrong? I'm just saying: patch < name_of_patch It makes me fix a few paths to some of the files, but that's it... :-/ Any help would be appriciated! ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-07 09:25 Message: Logged In: YES user_id=45814 Fixed bug (reported by Pug Bainter -- thanks!) New patches, on mailman-2.0.5 uploaded (below). The only real change is: --- 0.5/Mailman/FilteringMimeWriter.py Wed, 04 Apr 2001 10:04:36 -0700 dairiki (mailman/k/4_FilteringM 1.2 664) +++ 0.8(w)/Mailman/FilteringMimeWriter.py Mon, 07 May 2001 09:05:18 -0700 dairiki (mailman/k/4_FilteringM 1.3 664) @@ -185,8 +185,12 @@ pname, pval = string.split(param, '=', 1) return (string.lower(pname), rfc822.unquote(pval)) - return map(split_param, message.getplist()) - + def valid_param(param): + return '=' in param + + # Trailing ;'s in content-type yield empty strings from getplist(). + return map(split_param, + filter(valid_param, message.getplist())) def discards_data(fp): """Determine whether file object ignores data written to it. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-04-05 08:37 Message: Logged In: YES user_id=45814 I've just made a minor change: HTML converted to plain-text now includes a list of links at the end of the message. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=413752&group_id=103 From R.Barrett@ftel.co.uk Fri Aug 30 17:39:06 2002 From: R.Barrett@ftel.co.uk (Richard Barrett) Date: Fri, 30 Aug 2002 17:39:06 +0100 Subject: OT: Berkeley databases (was Re: [Mailman-Developers] (More) pristine archives) In-Reply-To: <15726.24858.348894.152229@anthem.wooz.org> References: <15724.61696.44082.607216@anthem.wooz.org> <20020828180652.GA2021@ferrara.linux.it> Message-ID: <5.1.0.14.2.20020830151009.00adf598@pop.ftel.co.uk> At 13:59 29/08/2002 -0400, Barry A. Warsaw wrote: >Are there any BerkeleyDB experts on this list? Apologies for the >off-topic message, but if anybody has any clues I'd appreciate an >*off-list* response. > > >>>>> "SP" == Simone Piunno writes: > > SP> It does on BerkeleyDB too. > > SP> Also: > | MyISAM has table-level locking > | BDB has page-level locking > | InnoDB has row-level locking > >I've been doing a lot of work with straight BerkeleyDBs for Zope's >ZODB, and I've run into a possibly fatal problem, for our application. > >The basic problem is that a Zope transaction is essentially unbounded >in the number of objects it touches. Each object modified translates >into updates to one or more BDB tables. I'm using BDB BTrees and >transactions, so that translates to one lock per level of the database >plus one lock per page. It's /possible/ that transactions can touch a >huge number of pages, and because BDB allocates a static number of >locks (growable, but only before the environment is opened), it's >likely that we'll hit a transaction that exhausts the locks. > >There seems to be no way to avoid this. Cranking the BDB locks up >just begs the question; eventually we run out of locks anyway, plus >the more locks you allocate the more resources you consume. We could >'solve' this if BDB supported table-level locking, because we'd just >lock the one or two tables that have unbounded updates and be done >with it. > >Any suggestions folks have would be greatly appreciated. If more >information is needed, contact me directly. > >ObMailman: It would be cool if MM3.0 had a ZODB backend, and I'd love >to use a Berkeley based storage for that backend. No, this won't be >/required/ for MM3.0 so you can stop fretting. ;) > >Thanks, >-Barry Although I'm no expert, my impression is that the Multi-Version Concurrency Control approach of PostgreSQL is a better fit with the transaction model of ZODB, certainly as it is used in Zope for instance, than record and table locking schemes used by such other databases that even encompass the concept of a transaction. It is also my impression that MVCC gives a better fit for doing transaction rollback and retry to resolve database update contention. That said, any application doing bulk updates of a database that doesn't split the activity into coherent, commit-able sub-transactions is looking for trouble. I would venture that if you have to do such an update then it would be best done by locking the whole database and ripping through the job and then letting everybody else back in. Rolling back and retrying a transaction involving very large numbers of database changes is not good stuff and if you get enough contention the big transaction will never succeed. From terri@zone12.com Fri Aug 30 17:53:42 2002 From: terri@zone12.com (Terri Oda) Date: Fri, 30 Aug 2002 12:53:42 -0400 Subject: [Mailman-Developers] Forget password form and unsubscribe without password In-Reply-To: <3D6EF881.CA59B84D@isu.edu> References: <3D6EF881.CA59B84D@isu.edu> Message-ID: <20020830165342.GA560@ostraya.zone12.com> > Has anyone developed a web forget password form, where the user can > type in their email address and it will send them their mailman > subscribers password. I would appreciate it if anyone would share their > code. I'm trying to learn python. That's already there but not, as far as I've seen with my users, quite as obvious as people would like. >From the listinfo page, enter the email address in the box where it says "Edit Options" (if you read the text, it *does* tell you that this is where to go to get a password reminder) and from that page, click on the "Email my password to me" button. I suspect putting the two boxes on one page would be a good exercise for someone trying to learn python, if you're picky about having them together. :) Terri From noreply@sourceforge.net Fri Aug 30 18:16:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 30 Aug 2002 10:16:03 -0700 Subject: [Mailman-Developers] [ mailman-Patches-413752 ] Coerce posts to plain text. Message-ID: Patches item #413752, was opened at 2001-04-04 10:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=413752&group_id=103 Category: mail delivery Group: Mailman 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: Geoffrey T. Dairiki (dairiki) Assigned to: Nobody/Anonymous (nobody) Summary: Coerce posts to plain text. Initial Comment: This patch adds the ability to have all posts to a mailing list forced into a MIME text/plain format. Many mailing lists have a charter which forbids binary and HTML posts to the list. This patch allows such a charter to be enforced is a maximally transparent manner. The feature is configurable on a per-list basis. If enabled, all posts to the list are run through a filter which: Squashes multipart messages into a single flat message (it picks the most plain-text-like alternative from multipart/alternative entities.) Converts 'text/html', 'text/enriched', and 'text/richtext' entities to 'text/plain'. Deletes cruft headers from content of type 'message/rfc822'. Deletes any uuencoded files from 'text/plain' entities. Entities of any other types are assumed to be binary attachements are are deleted. This patch is on mailman-2.0.3. ---------------------------------------------------------------------- >Comment By: Geoffrey T. Dairiki (dairiki) Date: 2002-08-30 10:16 Message: Logged In: YES user_id=45814 Note also that the recent patch sets also incorporate patch #415448 [1]: a minor patch so that Mailman recognizes bounce messages from swbell.net ("Sun Internet Mail Server"). This patch inadvertently slipped in, but it does no harm. If you don't like it just delete the patches to Mailman/Bouncers/SimpleMatch.py. Reference: [1] http://sf.net/tracker/?func=detail&aid=415448&group_id=103&atid=300103 ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2002-08-30 09:07 Message: Logged In: YES user_id=45814 Enh? The current version of Mailman is 2.0.13. That said, the latest patch set (named mailman-2.0.13-plaintext-0.17.patch, and attached below) will work fine, I think, for Mailmain versions 2.0.x back to at least 2.0.8, and probably earlier. Feel free to e-mail me privately for more help. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-08-30 08:02 Message: Logged In: NO I'm new to Mailman. I don't understand why you don't have a patch for the current version of Mailman, 2.0.10. Can I apply an earlier patch safely? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-27 21:40 Message: Logged In: YES user_id=12800 BTW, I've finally added that link from the wiki to this patch. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2002-08-27 20:44 Message: Logged In: YES user_id=45814 It seems the patches continue to work (basically unchanged) for Mailman-2.0.13. Updated patches are attached below. The patches as well as a pre-patched Mailman-2.0.13 tarball are at ftp://www.dairiki.org/pub/mailman/ ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-08-27 17:22 Message: Logged In: NO Hi Dairiki, It's me... I added your patch in my latest version and it's running OK... you can post the patch here! :) ---------------------------------------------------------------------- Comment By: Jozeph Brasil (jozeph) Date: 2002-08-27 12:00 Message: Logged In: YES user_id=17693 Hello dairiki... do you have this patch for Mailman-2.0.13 ? ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2002-08-13 08:43 Message: Logged In: YES user_id=45814 I don't have strong feelings, but my druthers would be to wait until 2.1 is officially designated "stable". A link from the wiki would be great! (There is/was already a link from the FAQ.) ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-13 08:29 Message: Logged In: YES user_id=12800 Since this patch is against 2.0.x and since MM2.1 provides support for stuff like this, I'm inclined to close this patch. I'd be willing to add a link to this from the unofficial patches wiki. What do you think? ---------------------------------------------------------------------- Comment By: Seb Wills (sebwills) Date: 2002-02-23 08:20 Message: Logged In: YES user_id=467580 This patch seems to leave any preamble above the first part of a multipart message intact. Many mailers put blurb such as "This is a MIME-encoded message; you will need a MIME- aware mail client to see all of this message." here, which it makes no sense to reproduce after the mail has be coerced into plaintext. Looks like it's easy enough to change this behaviour by commenting out the line mimetools.copybinary(infp, outfp) # copy preamble from Mailman/FilteringMimeWriter.py ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-12-15 10:15 Message: Logged In: YES user_id=45814 Another bug fix. Lines which contain nothing but the word 'end' mysteriously dissapear. (Reported by David Gibbs.) The only changed file in Mailman/FilteringMimeWriter.py, I've attached the latest version of that file to this page. As usual, patches on mailman 2.0.8 are also attached. Diffs and a patched Mailman-2.0.8 tarball are at ftp://www.dairiki.org/pub/mailman/ ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-09-08 13:08 Message: Logged In: YES user_id=45814 More fixes. * Mailman/FilteringMimeWriter.py: Fixes for bugs in python 1.5.2's quopri library module. The plaintext patches are at version 0.14. Look for the patches on Mailman 2.0.6, as well as a complete tarball of patched Mailman 2.0.6 code at ftp://www.dairiki.org/pub/mailman/ Patches on 2.0.6 are also attached to this page. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-08-25 12:34 Message: Logged In: YES user_id=45814 More fixes: * Mailman/PlaintextMimeWriter.py: Change Message-ID: of filtered messages. * Mailman/pythonlib/multifile.py: Fix obscure but occasionally fatal bug. The first fix is very minor. The second fix fixes a bug which caused the plaintext filter to fail occasionally. Diffs from mailman-2.0.6 are available from this page and are also at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.6-plaintext-0.13.patch.gz Pre-patched mailman-2.0.6 source code is at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.6-plaintext-0.13.tgz ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-06-16 11:33 Message: Logged In: NO After applying this patch to 2.0.5, I found that I had to add this line manually to my existing config file $prefix/Mailman/mm_cfg.py... DEFAULT_FORCE_PLAIN_TEXT = 0 If this line is not added, any web requests and any messages posted will produce an error "AttributeError : DEFAULT_FORCE_PLAIN_TEXT". Not sure if I did something wrong or if this is normal, but I wanted to advise others just in case ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-19 16:49 Message: Logged In: YES user_id=45814 More fixes: * Mailman/FilteringMimeWriter.py: Handle 'content-type: multipart' (no subtype) gracefully. * Mailman/Handlers/PlainText.py: Catch exceptions (fatal errors) from plaintext filter. When exception is caught, an error is logged, but the message is passed on unfiltered. (A diagnostic message is added to the message headers.) This should make it so little piddly bugs in the filter will get noticed, but at the same time will not cause messages to get stuck in the queue. Patches from mailman-2.0.5 are available from this page and are also at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.5-plaintext-0.10.patch.gz Pre-patched mailman-2.0.5 source code is at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.5-plaintext-0.10.tgz ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-17 12:27 Message: Logged In: YES user_id=45814 Another minor bugfix: it turns out pythons mimetools doesn't treat the content-transfer-encoding is a case insensitive fashion --- so now we smash the case ourself. A new patch set on mailman-2.0.5 is available on this page. Pre-patched mailman source code can be found at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.5-plaintext-0.9.tgz ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-07 21:38 Message: Logged In: YES user_id=45814 Disregard last. (Apparently one can't attache files bigger than 256 kb.) Mailman-2.0.5 with plaintext patches applied can be found (for a limited time) at: ftp://www.dairiki.org/pub/mailman/mailman-2.0.5-plaintext-0.8.tgz ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-07 21:33 Message: Logged In: YES user_id=45814 If you don't want to mess with patching the source, I've also attached (below) a tarball of the mailman-2.0.5 source with my patches already applied. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-07 21:16 Message: Logged In: YES user_id=45814 Here's a rough outline of how to proceed: 1. Start by unpacking a fresh copy of mailman-2.0.5.tgz 2. Change into the top source directory (which was created in the previous step. 3. Try applying my patches with: patch -p1 < [where.ever]/mailman-2.0.5-plaintext-0.8.patch (that's "dash pee one") That should work --- you should not get any warnings or prompts from patch. If you do, something is fishy. 4. Run ./configure and 'make install' as usual (read mailman's INSTALL for instructions on this.) Feel free to write me at . ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-05-07 20:30 Message: Logged In: NO For *some* reason when I apply the patch (the newest one) to my freshly downloaded version of Mailman 2.0.5 and compile and install mail never reaches the list. I've tried without the patch and everything works fine... perhaps I'm patching wrong? I'm just saying: patch < name_of_patch It makes me fix a few paths to some of the files, but that's it... :-/ Any help would be appriciated! ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-05-07 09:25 Message: Logged In: YES user_id=45814 Fixed bug (reported by Pug Bainter -- thanks!) New patches, on mailman-2.0.5 uploaded (below). The only real change is: --- 0.5/Mailman/FilteringMimeWriter.py Wed, 04 Apr 2001 10:04:36 -0700 dairiki (mailman/k/4_FilteringM 1.2 664) +++ 0.8(w)/Mailman/FilteringMimeWriter.py Mon, 07 May 2001 09:05:18 -0700 dairiki (mailman/k/4_FilteringM 1.3 664) @@ -185,8 +185,12 @@ pname, pval = string.split(param, '=', 1) return (string.lower(pname), rfc822.unquote(pval)) - return map(split_param, message.getplist()) - + def valid_param(param): + return '=' in param + + # Trailing ;'s in content-type yield empty strings from getplist(). + return map(split_param, + filter(valid_param, message.getplist())) def discards_data(fp): """Determine whether file object ignores data written to it. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-04-05 08:37 Message: Logged In: YES user_id=45814 I've just made a minor change: HTML converted to plain-text now includes a list of links at the end of the message. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=413752&group_id=103 From davek@mail.commercedata.com Wed Aug 28 18:57:32 2002 From: davek@mail.commercedata.com (Dave Klingler) Date: Wed, 28 Aug 2002 11:57:32 -0600 (MDT) Subject: [Mailman-Developers] (More) pristine archives In-Reply-To: <15230.1030555405@kanga.nu> from "J C Lawrence" at Aug 28, 2002 10:23:25 AM Message-ID: <200208281757.LAA27868@mail.commercedata.com> > On Wed, 28 Aug 2002 13:14:10 -0400 (EDT) > Dale Newfield wrote: > > > On Wed, 28 Aug 2002, Barry A. Warsaw wrote: > >> It still doesn't support transactions? > > > No. :-( > > Check again. Or better yet, check out PostgreSQL. :) I've been noodling around with this same idea, but I hadn't had the time to get very far with it. I am, however, much happier with Postgres. Dave Klingler From barry@zope.com Thu Aug 29 22:13:49 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 29 Aug 2002 17:13:49 -0400 Subject: [Mailman-Developers] (More) pristine archives References: <15726.24256.951830.459164@anthem.wooz.org> Message-ID: <15726.36493.78699.947964@geddy.zope.com> >>>>> "DN" == Dale Newfield writes: >> Thus, if the code in the try causes an exception, the list will >> still get unlocked (otherwise the list would be hosed), but the >> transaction is aborted by virtue of not getting saved. A >> subsequent load of the mlist would begin a new transaction, >> with the old data. DN> Right, but since .UnLock doesn't reload the data, any code DN> refering to that mlist after unlocking would have different DN> semantics depending upon which MemberAdaptor implementation is DN> backing the list: With OldStyle, membership data in that mlist DN> object is whatever it's been (temporarily) set to (but not DN> saved); with SQL, membership data in that mlist has reverted DN> to whatever it was when .Lock() was called. You're right, and it should be cleaned up, but in practice it should be okay. For the one-shot scripts (cron, cgi), you're restarting the process each time anyway, so no worries. For the qrunner daemons, I basically had to solve the same problem, i.e. the next iteration through the loop needs to have consistent data or you're screwed. Each runner should either do a .Load() or a .Lock() at the top of their _dispose() methods, depending on if they only need read access to the list data or read-write access. >> It's this last bit that's dodgy. There should probably be an >> explicit abort on exceptions inside the try, but there's no way >> to spell that with the current, legacy persistence mechanism, >> so it isn't in any of the code. DN> Wouldn't that abort be triggered by a call to .UnLock() DN> without a call to .Save()? I would think that all calls to DN> .Lock() and any calls to .UnLock() without a prior call to DN> .Save() should abort any current transaction. What about the qrunners that don't lock the list because they only need read access to the data? That's why I think we need an explicit abort, even if it's no-op'd for the old-style persistence. >> I /think/ that if your MailList.Load() implicitly aborts any >> active transaction, you should be okay, but of course, none of >> that's tested. DN> MailList.Load() or MailList.Lock()? Having .Load() abort any DN> active transaction means that you cannot load other mlists DN> (even read-only) inside a .Lock();try....Save();finally DN> .UnLock() block and have the transaction succeed... DN> The place these two models (SQL transactions and mailList DN> load, lock/save/unlock) break down is what happens when there DN> are more than one MailList object in memory at a time. SQL DN> transactions assumes only one MailList can be modified at a DN> time, and the lock/save/unlock model doesn't make that DN> assumption. Ah, so the problem probably isn't the transaction boundaries, but that Mailman assumes that each list's persistence is completely independent of other lists. I think the one place where you'll get hosed by this is in the cgi's where "global" operations loop through all the lists (yes, this sucks and is inefficient, but its the best we can currently do). I'm not sure how to get around this, except through some kind of elaborate nested transaction support. DN> If we can assume that only one mlist gets locked at a time, DN> the SQL system will work, but I see no way to enforce mailman DN> developers to abide by that assumption. (Except to implicitly DN> abort active transactions as described above--and since the DN> MailList.Save() method doesn't have a success/failure return DN> code, there would be no indication that anything went wrong DN> except silently ignoring requested DB changes.) Hmm. I'm going to have to think about this some more. I'm off line right now so can't look at code details. -Barry