Aggressive anti email address harvesting measure

Bug #558097 reported by ppsys
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
GNU Mailman
New
Undecided
Unassigned

Bug Description

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.
#
#####

Revision history for this message
ppsys (ppsys-users) wrote :

The file antispam-2.1.3-0.1.patch was added: Patch for MM 2.1.3

Revision history for this message
ppsys (ppsys-users) wrote :

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.

Revision history for this message
mmokrejs (mmokrejs-users) wrote :

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'

Revision history for this message
mmokrejs (mmokrejs-users) wrote :

Logged In: YES
user_id=696559

Ohh, sorry, the patch really wasn't applied. After proper
installation, I can confirm it works fine.

Revision history for this message
tkikuchi (tkikuchi-users) wrote :

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.

Revision history for this message
tkikuchi (tkikuchi-users) wrote :

Logged In: YES
user_id=67709

Sorry, patch itself is for 2.1 (not 3.0).

Revision history for this message
olaf (olaf-users) wrote :

Logged In: YES
user_id=11209

please, make these harvesting prevention measures per list configurable.

Revision history for this message
ppsys (ppsys-users) wrote :

The file antispam-2.1.8-0.1.patch.gz was added: MM 2.1.8 compatible version of patch

Revision history for this message
ppsys (ppsys-users) wrote :

Logged In: YES
user_id=75166

antispam-2.1.9-0.1.patch.gz is a MM 2.1.9 compatible version of
the patch

Revision history for this message
ppsys (ppsys-users) wrote :

The file antispam-2.1.9-0.1.patch.gz was added: Patch revised for MM 2.1.9 compatibility

Revision history for this message
ppsys (ppsys-users) wrote :

Logged In: YES
user_id=75166
Originator: YES

File Added: antispam-2.1.10-0.1.patch.gz

Revision history for this message
ppsys (ppsys-users) wrote :

The file antispam-2.1.10-0.1.patch.gz was added: Patch revised for MM 2.1.10 compatibility

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.