[Mailman-Developers] Interesting study -- spam on posted addresses...

Damien Morton dm-temp-310102@nyc.rr.com
Mon, 18 Feb 2002 07:12:42 -0500

There are some very simple solutions to the problem of email harvesting.

The first is to whitelist all mail. Anything not on the whitelist (be it
list membership, or whatever) is responded to with an invitation to fill
in a web based form to join the whitelist, the mail is held in abeyance
until the whitelist is joined. You can hide the whitelist join function
behind a POST operation, but can also do a reverse turing test of the
'type what you read in the image above' type to verify that it's a human
joining the list.

The second is to avoid publishing email addresses to the world in
machine readable form. There are several approaches to this, including
the use of javascript email decryptors and/or publishing email addresses
as rendered images.

-----Original Message-----
From: mailman-developers-admin@python.org
[mailto:mailman-developers-admin@python.org] On Behalf Of John Morton
Sent: Monday, 18 February 2002 00:25
To: Chuq Von Rospach
Cc: mailman-developers@python.org
Subject: Re: [Mailman-Developers] Interesting study -- spam on posted

On Monday 18 February 2002 17:56, Chuq Von Rospach wrote:
> On 2/17/02 8:39 PM, "John Morton" <jwm@plain.co.nz> wrote:
> > If they can set up admin specific accounts that redirect to 
> > /dev/null, then they can set up procmail to drop HTML mail, and say 
> > they're doing so anywhere they're advertising the admin email 
> > address. That would filter 90% of the spam they're likely to recieve

> > for a start.
> And a bunch of legitimate mail, since more and more users are using 
> HTML, and more and more systems are set up to send it by default. Not 
> a solution, unless you primarily admin to geeks.

It's better than > /dev/null :-). Let's face it - if you're going to
an admin address to help the lowest common denominator of netizen, then
can't munge it, so it will get spam. Mailman doesn't provide filtering
email accounts, nor should it. So the best you can do is advise admins
of good filtering software, and best practice ways of using it. Droping
mail happens to be one practice that works pretty well for a given type
list membership.

> > Something that mailman can help with, though - assistance in 
> > filtering based on whether the sender is joined to a list that the 
> > admin account is tied to. Just a simple boolean is/isn't on the list

> > should be enough; leave the policy to the delivery agent/user.
> And how odes that does the "I'm trying to subscribe and can't make it 
> work!"

It doesn't. But you can put all the requests from list members into
folder, or give them a higher priority. It all helps. If you need to 
prioritize subscription problems then you could use a feedback form, and
maybe Mailman should provide one.

> "My stupid IS department changed my address again and I need help!" 
> problems?

I never understood why mailman wasn't changed to allow users to change
own addresses years ago. Being able to add valid receiving addresses
help, too. That is also something mailman can help with.


Mailman-Developers mailing list