Mailman 3 November 2004 - Mailman-coders

[ mailman-Feature Requests-1070016 ] Better way to manage google & co
by SourceForge.net 20 Nov '04

20 Nov '04

Feature Requests item #1070016, was opened at 2004-11-20 15:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1070016&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peer Heinlein (pheinlein) Assigned to: Nobody/Anonymous (nobody) Summary: Better way to manage google & co Initial Comment: It`s possible to disallow google to index a public web-archive of a mailinglist by a robots.txt. But it would be much nicer if a admin could change this behavior in the MM-admin-config-interface. If a flag like "robots_allow_index" is set to NO, pipermail should add a HTML-Header <META NAME="ROBOTS" CONTENT="NOINDEX, NOFOLLOW"> to each html-page generated by pipermail. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1070016&group_…

1 0

[ mailman-Bugs-1069319 ] Digests not sent
by SourceForge.net 19 Nov '04

19 Nov '04

Bugs item #1069319, was opened at 2004-11-19 10:34 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1069319&group_… Category: mail delivery Group: Unreproducible Status: Open Resolution: None Priority: 5 Submitted By: Tom Allen (djpeanut) Assigned to: Nobody/Anonymous (nobody) Summary: Digests not sent Initial Comment: Hi, I run a very active mailing list with digest mode enabled as the default for all members. The digest were set to send daily when not empty and did so from the 5th Oct to the 25th Oct without any problems. However, at this point the digests inexplicably stopped being sent automatically. No settings were changed. I've checked all the settings in the digest page but they are fine, and the only way I can get a digest to send is to do it manually. I am running version 2.1.5. Nearly a hundred other mailing lists are running on the machine and to my knowledge, they are all unaffected. ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-11-19 13:29 Message: Logged In: YES user_id=67709 Looks like one of the messages stored in lists/<listname>/digest.mbox is causing a error and stop the digest processing. If you can find the cause of error, you can edit the mbox file and issue cron/senddigest command, I think. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1069319&group_…

1 0

[ mailman-Bugs-1069319 ] Digests not sent
by SourceForge.net 19 Nov '04

19 Nov '04

Bugs item #1069319, was opened at 2004-11-19 10:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1069319&group_… Category: mail delivery Group: Unreproducible Status: Open Resolution: None Priority: 5 Submitted By: Tom Allen (djpeanut) Assigned to: Nobody/Anonymous (nobody) Summary: Digests not sent Initial Comment: Hi, I run a very active mailing list with digest mode enabled as the default for all members. The digest were set to send daily when not empty and did so from the 5th Oct to the 25th Oct without any problems. However, at this point the digests inexplicably stopped being sent automatically. No settings were changed. I've checked all the settings in the digest page but they are fine, and the only way I can get a digest to send is to do it manually. I am running version 2.1.5. Nearly a hundred other mailing lists are running on the machine and to my knowledge, they are all unaffected. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1069319&group_…

1 0

[ mailman-Feature Requests-788314 ] personal option for explicit reply-to header
by SourceForge.net 15 Nov '04

15 Nov '04

Feature Requests item #788314, was opened at 2003-08-13 22:22 Message generated for change (Comment added) made by ber You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=788314&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bernhard Reiter (ber) Assigned to: Nobody/Anonymous (nobody) Summary: personal option for explicit reply-to header Initial Comment: Some list members have a broken email reader that will not give them a list reply option. Outlook for instance. People using some email readers just don't use it, because the functionality is hidden (like many KMail users). They beg the adminstrator to mangle the reply-to header. Other users of course find that harmful. A per user (and per list?) option to set an explicit reply-to header to the list seems to be a good solution. ---------------------------------------------------------------------- >Comment By: Bernhard Reiter (ber) Date: 2004-11-15 15:02 Message: Logged In: YES user_id=113859 This is not the duplicate, but the original. ;-) ---------------------------------------------------------------------- Comment By: Brad Knowles (shub) Date: 2004-11-13 01:15 Message: Logged In: YES user_id=18417 Duplicate of 828564? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=788314&group_i…

1 0

[ mailman-Feature Requests-828564 ] per-user " Reply-To:" configuration
by SourceForge.net 15 Nov '04

15 Nov '04

Feature Requests item #828564, was opened at 2003-10-23 00:54 Message generated for change (Comment added) made by ber You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=828564&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jorge Bernal (koke) Assigned to: Nobody/Anonymous (nobody) Summary: per-user "Reply-To:" configuration Initial Comment: In order to prevent the periodic flame about "Reply-To-harmful" and "Reply-To-is-good", it would be a great feature if any user could choose if he/she wants the "Reply-To" header to be modified or not ---------------------------------------------------------------------- Comment By: Bernhard Reiter (ber) Date: 2004-11-15 15:01 Message: Logged In: YES user_id=113859 Yes, 788314 was there earlier. ---------------------------------------------------------------------- Comment By: Brad Knowles (shub) Date: 2004-11-13 01:15 Message: Logged In: YES user_id=18417 Duplicate of 788314? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=828564&group_i…

1 0

[ mailman-Patches-955819 ] fix: [ 926034 ] Crashes on encoding errors
by SourceForge.net 14 Nov '04

14 Nov '04

Patches item #955819, was opened at 2004-05-18 11:14 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=955819&group_i… Category: mail delivery Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Károly Segesdi (vm303) Assigned to: Nobody/Anonymous (nobody) Summary: fix: [ 926034 ] Crashes on encoding errors Initial Comment: Actually the bug title is wrong, the problem is (I think) python not supporting windows-1250 and windows-1252. The problem can be fixed in the email library in $MAILMANDIR/pythonlib/email/Header.py I don't know if newer pythons (afaik python 2.3 contains this email package and maybe it does handle windows codepages) still suffer the same problem. So here's my solution for mailman-2.1.3 (I think it's applicable to 2.1.4 too) and python 2.2.2: --- Header.py.orig 2003-03-30 22:39:05.000000000 +0200 +++ Header.py 2004-05-18 12:01:35.000000000 +0200 @@ -284,7 +284,7 @@ outcodec = charset.output_codec or 'us-ascii' s = s.encode(outcodec, errors) break - except UnicodeError: + except (UnicodeError, LookupError): pass else: assert False, 'utf-8 conversion failed' this way if s.encode does not understand the original encoding (like windows-1250 or windows-1252) then it resorts to use utf-8 ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-11-14 11:26 Message: Logged In: YES user_id=67709 This patch is for email package which belongs to Python language distribution. Please submit this report to the Python patch/bug tracker. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=955819&group_i…

1 0

[ mailman-Patches-807016 ] dutch translation breaks e-mail confirmation instructions
by SourceForge.net 14 Nov '04

14 Nov '04

Patches item #807016, was opened at 2003-09-16 09:14 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=807016&group_i… Category: internationalization Group: Mailman 2.1 >Status: Closed Resolution: None Priority: 5 Submitted By: Ward Vandewege (ward) Assigned to: Nobody/Anonymous (nobody) Summary: dutch translation breaks e-mail confirmation instructions Initial Comment: The Dutch translation in templates/nl/invite.txt translates the 'confirm' command for e-mail replies to an invitation by list owners into Dutch. Mailman does not respond to Dutch commands, so this breaks Mailman. The attached patch fixes this. ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-11-14 11:18 Message: Logged In: YES user_id=67709 fixed in CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=807016&group_i…

1 0

[ mailman-Patches-850805 ] Aggressive anti email address harvesting measure
by SourceForge.net 14 Nov '04

14 Nov '04

Patches item #850805, was opened at 2003-11-28 17:23 Message generated for change (Comment added) made by olaf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=850805&group_i… Category: Pipermail Group: Mailman 2.1 Status: Open Resolution: Postponed Priority: 5 Submitted By: Richard Barrett (ppsys) Assigned to: Nobody/Anonymous (nobody) Summary: Aggressive anti email address harvesting measure Initial Comment: This patch is prompted by discussion on the mailman- developers list won the following subject: Re: [Mailman-Developers] bugtraq submission warning: email address harvesting exploit For those with deep concerns about email address harvesting this patch offers a more aggressive masking of email addresses in Mailman mail archive files. The patch modifes two files in the standard Mailman distribution: Mailman/Defaults.py and Mailman/Cgi/ private.py and can be applied using the following command from within the Mailman build directory: path -p1 < path-to-patch-file It would be fairly trivial to make enabling this feature per- list configurable rather than it being a site admin decision and I will enhance this patch for that purpose if people show an interest in it being done. The following notes about the patch can be found in Defaults.py. Rather idiosyncratically most of the operational elements of this patch are in that file. My reasoning behind this decision is that if people want to fool with the regexes that are at the heart of this patch they can see what will be affected by the changes more readily if the related bits are in the same place. ##### # Anti-spam email address harvesting prevention measures. # # These measures are to limit the ability of spam generators to acquire # email address from archived material in Mailman's list archives. # Implementation is via a dynamic search and replace for email # addresses, appearing in files of MIME type text/html or text/plain, as # those files are requested. The underlying archive file content as # generated by the archiving software remains unchanged. # # The implementation requires that archive files are all delivered by a # modified private.py CGI script which only requires user authentication # if the list whose archive material is being requested is set up as a private # list. In order to get public archives served by private.py a RewriteRule # like this: # # RewriteRule ^/pipermail/(.*) /mailman/private/$1 [PT] # # needs to be used in the Apache httpd.conf to transparently redirect # public arechive file requests. # # When email addresses are found, the domain part of the addressed is replaced # with a string of 'x' characters. If the local part of the address appears to # have been VERP'ed then the VERP information is similarly obscured. This is # a fairly brutal set of irreversible modifications to any email addresses in # the returned text and will break any mailto: links in the text. # # Th eamil address regex looks for either an '@' character or its HTML escaped # version '%40' as the local-part/domain separator. You should set # ARCHIVER_OBSCURES_EMAILADDRS = 0 and run bin/arch to rebuild existing archives # to prevent that feature interfering with the operation of these harvesting # prevention measures. # # If you decide to change the regexes then copy all of this stuff into # mm_cfg.py and make the changes there. # ##### ---------------------------------------------------------------------- Comment By: O.S. (olaf) Date: 2004-11-14 01:41 Message: Logged In: YES user_id=11209 please, make these harvesting prevention measures per list configurable. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-11-14 01:28 Message: Logged In: YES user_id=67709 Sorry, patch itself is for 2.1 (not 3.0). ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-11-14 01:27 Message: Logged In: YES user_id=67709 It looks nice but it may be too much for 2.1.x where the archives are generated static. Also, I'm a little bit anxious writing such a function in Defaults.py. It would be better to include this feature in 3.0 or later. ---------------------------------------------------------------------- Comment By: Martin Mokrejs (mmokrejs) Date: 2004-04-20 11:52 Message: Logged In: YES user_id=696559 Ohh, sorry, the patch really wasn't applied. After proper installation, I can confirm it works fine. ---------------------------------------------------------------------- Comment By: Martin Mokrejs (mmokrejs) Date: 2004-04-20 02:00 Message: Logged In: YES user_id=696559 What sould I do with this error caused by the patch? Traceback (most recent call last): File "/usr/local/mailman/scripts/driver", line 87, in run_main main() File "/usr/local/mailman/Mailman/Cgi/private.py", line 165, in main sys.stdout.write(mm_cfg.deny_harvest(f.read())) AttributeError: 'module' object has no attribute 'deny_harvest' ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2003-11-30 08:02 Message: Logged In: YES user_id=75166 As pointed out on the mailman-developers list, potential users of this patch should be aware that the simple approach to masking email addresses used by this patch will also capture and munge any other strings in the archive data that resemble email addresses. This can include mailto URLs, other URLs and Message ids. This side-effect may make the patch unsuitable for use with your system, although you also need to consider that the patch does not irreversibly change the source pipermail archived material held on the server; the changes are only made in the copy of the archive material sent to the requesting browser by the server. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=850805&group_i…

1 0

[ mailman-Patches-674433 ] Add post_id information to messages
by SourceForge.net 14 Nov '04

14 Nov '04

Patches item #674433, was opened at 2003-01-25 03:09 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=674433&group_i… Category: None Group: Mailman 2.1 Status: Open >Resolution: Wont Fix Priority: 3 Submitted By: Steve Huston (srhuston) Assigned to: Nobody/Anonymous (nobody) Summary: Add post_id information to messages Initial Comment: This patch will add the value of mlist.post_id to the mail during processing. It adds a X-Post-ID header, which can then be searched for and placed in the header/footer of the message (non-digest only). It will also grab this information to put it in the archives, so if you use a searchable archive you can search for a message by post_id. This part is a little 'iffy'. The patch assumes you have the ht://Dig patches installed, but should work fine without them; will likely complain about templates/en/article.html and templates/en/htdig-conf.txt There is also added the ability to inflate the post_id value from the "General" section in the GUI. It makes sure you keep the value as a float, as well as only lets you increase it. This is handy if you are importing messages from an old archive and need to start the post_id at a larger number so as not to interfere with old messages. Left to do as of this writing: i18n (somebody?), documentation in Gui/General.py explaining post_id better (and why you might want/need to mess with it), documentation in Gui/NonDigest.py or templates/en/headfoot.html explaining %(post_id)s variable. ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-11-14 00:35 Message: Logged In: YES user_id=67709 Now you can add post_id in subject_prefix if you get the latest Release_2_1-maint branch from CVS. (You should put [listname %d] in subject_prefix to activate the numbering.) This patch may be replaced by the subject-numbering feature described above. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=674433&group_i…

1 0

[ mailman-Patches-850805 ] Aggressive anti email address harvesting measure
by SourceForge.net 14 Nov '04

14 Nov '04

Patches item #850805, was opened at 2003-11-28 16:23 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=850805&group_i… Category: Pipermail >Group: Mailman 2.1 Status: Open Resolution: Postponed Priority: 5 Submitted By: Richard Barrett (ppsys) Assigned to: Nobody/Anonymous (nobody) Summary: Aggressive anti email address harvesting measure Initial Comment: This patch is prompted by discussion on the mailman- developers list won the following subject: Re: [Mailman-Developers] bugtraq submission warning: email address harvesting exploit For those with deep concerns about email address harvesting this patch offers a more aggressive masking of email addresses in Mailman mail archive files. The patch modifes two files in the standard Mailman distribution: Mailman/Defaults.py and Mailman/Cgi/ private.py and can be applied using the following command from within the Mailman build directory: path -p1 < path-to-patch-file It would be fairly trivial to make enabling this feature per- list configurable rather than it being a site admin decision and I will enhance this patch for that purpose if people show an interest in it being done. The following notes about the patch can be found in Defaults.py. Rather idiosyncratically most of the operational elements of this patch are in that file. My reasoning behind this decision is that if people want to fool with the regexes that are at the heart of this patch they can see what will be affected by the changes more readily if the related bits are in the same place. ##### # Anti-spam email address harvesting prevention measures. # # These measures are to limit the ability of spam generators to acquire # email address from archived material in Mailman's list archives. # Implementation is via a dynamic search and replace for email # addresses, appearing in files of MIME type text/html or text/plain, as # those files are requested. The underlying archive file content as # generated by the archiving software remains unchanged. # # The implementation requires that archive files are all delivered by a # modified private.py CGI script which only requires user authentication # if the list whose archive material is being requested is set up as a private # list. In order to get public archives served by private.py a RewriteRule # like this: # # RewriteRule ^/pipermail/(.*) /mailman/private/$1 [PT] # # needs to be used in the Apache httpd.conf to transparently redirect # public arechive file requests. # # When email addresses are found, the domain part of the addressed is replaced # with a string of 'x' characters. If the local part of the address appears to # have been VERP'ed then the VERP information is similarly obscured. This is # a fairly brutal set of irreversible modifications to any email addresses in # the returned text and will break any mailto: links in the text. # # Th eamil address regex looks for either an '@' character or its HTML escaped # version '%40' as the local-part/domain separator. You should set # ARCHIVER_OBSCURES_EMAILADDRS = 0 and run bin/arch to rebuild existing archives # to prevent that feature interfering with the operation of these harvesting # prevention measures. # # If you decide to change the regexes then copy all of this stuff into # mm_cfg.py and make the changes there. # ##### ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-11-14 00:28 Message: Logged In: YES user_id=67709 Sorry, patch itself is for 2.1 (not 3.0). ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-11-14 00:27 Message: Logged In: YES user_id=67709 It looks nice but it may be too much for 2.1.x where the archives are generated static. Also, I'm a little bit anxious writing such a function in Defaults.py. It would be better to include this feature in 3.0 or later. ---------------------------------------------------------------------- Comment By: Martin Mokrejs (mmokrejs) Date: 2004-04-20 09:52 Message: Logged In: YES user_id=696559 Ohh, sorry, the patch really wasn't applied. After proper installation, I can confirm it works fine. ---------------------------------------------------------------------- Comment By: Martin Mokrejs (mmokrejs) Date: 2004-04-20 00:00 Message: Logged In: YES user_id=696559 What sould I do with this error caused by the patch? Traceback (most recent call last): File "/usr/local/mailman/scripts/driver", line 87, in run_main main() File "/usr/local/mailman/Mailman/Cgi/private.py", line 165, in main sys.stdout.write(mm_cfg.deny_harvest(f.read())) AttributeError: 'module' object has no attribute 'deny_harvest' ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2003-11-30 07:02 Message: Logged In: YES user_id=75166 As pointed out on the mailman-developers list, potential users of this patch should be aware that the simple approach to masking email addresses used by this patch will also capture and munge any other strings in the archive data that resemble email addresses. This can include mailto URLs, other URLs and Message ids. This side-effect may make the patch unsuitable for use with your system, although you also need to consider that the patch does not irreversibly change the source pipermail archived material held on the server; the changes are only made in the copy of the archive material sent to the requesting browser by the server. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=850805&group_i…

1 0