Mailman-coders November 2003

mailman-coders@python.org

1 participants
52 discussions

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

29 Nov '03

Patches item #850805, was opened at 2003-11-28 16:23 Message generated for change (Comment added) made by ppsys 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: None 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: 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

[ mailman-Patches-851419 ] Clam AntiVirus handler for Mailman
by SourceForge.net 29 Nov '03

29 Nov '03

Patches item #851419, was opened at 2003-11-30 02:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=851419&group_i… Category: None Group: Mailman 2.2 / 3.0 Status: Open Resolution: None Priority: 5 Submitted By: Sean Reifschneider (jafo) Assigned to: Nobody/Anonymous (nobody) Summary: Clam AntiVirus handler for Mailman Initial Comment: Included is a Handler for passing messages through Clam AntiVirus, and holding or discarding messages that are determined to be viruses. Similar to modules that interface SpamAssassin, particularly useful with the "discard" option enabled so that list managers don't have to manually deal with viruses sent to their lists. Currently, this tar file is oriented towards installation by administrators into their existing setups, as it's likely to be a while before this functionality is available in the base. For the final release I imagine that a README.ClamAV, a section in the main README, or simply a good set of comments for the Defaults.py file would do the job. I'll build patches to support these, please provide feedback on which mechanism is preferred. Sean ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=851419&group_i…

1 0

[ mailman-Bugs-851416 ] No HTML quoting of address on "Subscription results" page
by SourceForge.net 29 Nov '03

29 Nov '03

Bugs item #851416, was opened at 2003-11-30 13:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=851416&group_i… Category: Web/CGI Group: 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: Peter J. R. Moulder (pjrm) Assigned to: Nobody/Anonymous (nobody) Summary: No HTML quoting of address on "Subscription results" page Initial Comment: When subscribing using the web interface (e.g. http://lists.sourceforge.net/lists/listinfo/inkscape-devel), the resulting "mylist Subscription results" page includes the literal text "<jrl(a)host.domain>" ("Instructions are being sent to you at <jrl(a)host.domain>"), whereas HTML contains no such element. Subscriber address ought to be html-escaped using <, >, &. (Also, as mentioned in #596215, this page contains other bad HTML such as an unterminated "<body" tag, and a <html>...</html> element within a <BODY ...>...</body> element.) version 2.0.9-sf.net pjrm. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=851416&group_i…

1 0

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

28 Nov '03

Patches item #850805, was opened at 2003-11-28 16:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=850805&group_i… Category: Pipermail Group: Mailman 2.1 Status: Open Resolution: None 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. # ##### ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=850805&group_i…

1 0

[ mailman-Feature Requests-849711 ] Challenge/Response for held postings
by SourceForge.net 26 Nov '03

26 Nov '03

Feature Requests item #849711, was opened at 2003-11-26 16:33 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=849711&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin Schröder (oneiros) Assigned to: Nobody/Anonymous (nobody) Summary: Challenge/Response for held postings Initial Comment: With moderated or member-only lists the lists get a multitude of spam which the admin has to discard manually (Listserv does this automagically). Mailman could discard most of the spam automatically if it would implement a challenge/response for all messages hold for moderator approval: Mail the sender (usually forged) and ask them to confirm the message (by mail or www). If the message isn't confirmed after 24h, drop it silently and don't bother the admin. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=849711&group_i…

1 0

[ mailman-Bugs-849036 ] fully remove product and version information
by SourceForge.net 25 Nov '03

25 Nov '03

Bugs item #849036, was opened at 2003-11-25 16:40 Message generated for change (Comment added) made by floeff You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=849036&group_i… Category: security/privacy Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Florian Effenberger (floeff) Assigned to: Nobody/Anonymous (nobody) Summary: fully remove product and version information Initial Comment: I would like to see an option in the configuration files to fully remove product and version information from the CGIs and the mail headers. It is part of my security concept to NOT show anything like that to outside users. ---------------------------------------------------------------------- >Comment By: Florian Effenberger (floeff) Date: 2003-11-25 20:17 Message: Logged In: YES user_id=240337 Ah, sorry, the comment from 2003-11-25 20:15 was meant for another bug, please ignore it. The feature request is still valid, though. ---------------------------------------------------------------------- Comment By: Florian Effenberger (floeff) Date: 2003-11-25 20:15 Message: Logged In: YES user_id=240337 No problem, it was just a suggestion :) I know views may vary on this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=849036&group_i…

1 0

[ mailman-Bugs-849036 ] fully remove product and version information
by SourceForge.net 25 Nov '03

25 Nov '03

Bugs item #849036, was opened at 2003-11-25 16:40 Message generated for change (Comment added) made by floeff You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=849036&group_i… Category: security/privacy Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Florian Effenberger (floeff) Assigned to: Nobody/Anonymous (nobody) Summary: fully remove product and version information Initial Comment: I would like to see an option in the configuration files to fully remove product and version information from the CGIs and the mail headers. It is part of my security concept to NOT show anything like that to outside users. ---------------------------------------------------------------------- >Comment By: Florian Effenberger (floeff) Date: 2003-11-25 20:15 Message: Logged In: YES user_id=240337 No problem, it was just a suggestion :) I know views may vary on this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=849036&group_i…

1 0

[ mailman-Bugs-825143 ] build with multiple submake jobs fails
by SourceForge.net 25 Nov '03

25 Nov '03

Bugs item #825143, was opened at 2003-10-16 18:11 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=825143&group_i… Category: configuring/installing Group: 2.1 (stable) Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Kyle Lanclos (lanclos) Assigned to: Nobody/Anonymous (nobody) Summary: build with multiple submake jobs fails Initial Comment: Well, it doesn't so much fail, as it quietly screws up many a binary. On a Solaris 9 machine with four processors, I set: MAKE="gmake -j4" ...and proceed to configure/build mailman. No errors. Nothing creeps up until I try to use the binaries in cgi-bin. Depending on the time of day, cosmic rays, etc., several of the binaries will all end up being the same file; for example, the "admin" wrapper will really be another copy of the "create" wrapper. This seems to happen with at least half of them, and the arrangement is random each time I do it. The solution was simple: MAKE="gmake" ...reconfigure, rebuild, reinstall. Everything was exactly as it should be. Somewhere in the relevant makefile, -jN needs to be disabled. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-11-25 12:06 Message: Logged In: YES user_id=12800 If you want to develop a patch, I would definitely take a look at it. ---------------------------------------------------------------------- Comment By: Kyle Lanclos (lanclos) Date: 2003-11-25 11:51 Message: Logged In: YES user_id=888067 Enabling parallel compilation is, I agree, not worthwhile for mailman-- however, disabling parallel compilation is, given that the errors produced by multiple active submake jobs are completely silent to the person building the software. It'd be nice if mailman would just shutdown the jobserver mode completely given that it is unnecessary. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-11-24 23:55 Message: Logged In: YES user_id=12800 Mailman doesn't have enough C code to justify supporting parallel makes IMO. Mailman doesn't do anything special here, so if something like this does get set automatically, it's probably because of the configure script. I don't think there's anything for us to do (but if you come up with a patch you think will help your cause, feel free to attach it here). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=825143&group_i…

1 0

[ mailman-Bugs-825143 ] build with multiple submake jobs fails
by SourceForge.net 25 Nov '03

25 Nov '03

Bugs item #825143, was opened at 2003-10-16 15:11 Message generated for change (Comment added) made by lanclos You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=825143&group_i… Category: configuring/installing Group: 2.1 (stable) Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Kyle Lanclos (lanclos) Assigned to: Nobody/Anonymous (nobody) Summary: build with multiple submake jobs fails Initial Comment: Well, it doesn't so much fail, as it quietly screws up many a binary. On a Solaris 9 machine with four processors, I set: MAKE="gmake -j4" ...and proceed to configure/build mailman. No errors. Nothing creeps up until I try to use the binaries in cgi-bin. Depending on the time of day, cosmic rays, etc., several of the binaries will all end up being the same file; for example, the "admin" wrapper will really be another copy of the "create" wrapper. This seems to happen with at least half of them, and the arrangement is random each time I do it. The solution was simple: MAKE="gmake" ...reconfigure, rebuild, reinstall. Everything was exactly as it should be. Somewhere in the relevant makefile, -jN needs to be disabled. ---------------------------------------------------------------------- >Comment By: Kyle Lanclos (lanclos) Date: 2003-11-25 08:51 Message: Logged In: YES user_id=888067 Enabling parallel compilation is, I agree, not worthwhile for mailman-- however, disabling parallel compilation is, given that the errors produced by multiple active submake jobs are completely silent to the person building the software. It'd be nice if mailman would just shutdown the jobserver mode completely given that it is unnecessary. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-11-24 20:55 Message: Logged In: YES user_id=12800 Mailman doesn't have enough C code to justify supporting parallel makes IMO. Mailman doesn't do anything special here, so if something like this does get set automatically, it's probably because of the configure script. I don't think there's anything for us to do (but if you come up with a patch you think will help your cause, feel free to attach it here). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=825143&group_i…

1 0

[ mailman-Feature Requests-849039 ] How to disable lists
by SourceForge.net 25 Nov '03

25 Nov '03

Feature Requests item #849039, was opened at 2003-11-25 15:42 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=849039&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: b_user (b_user) Assigned to: Nobody/Anonymous (nobody) Summary: How to disable lists Initial Comment: Hi, I want to disable lists. It should be impossible to post messages after disableing a list. Everything else shall work like before. I thought its just to comment out the list refering lies in data/aliases but this dosn´t help. I´m very appreciated for any idea, thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=849039&group_i…

1 0

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

Mailman-coders November 2003