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…
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…
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…
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…
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…
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…
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…
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…
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…
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…