[Mailman-Developers] Preventing spam to list admins.

[Chuq Von Rospach]

On 8/27/01 11:23 AM, "J C Lawrence" <claw@kanga.nu> wrote:

> On Mon, 27 Aug 2001 09:27:30 -0700
> Chuq Von Rospach <chuqui@plaidworks.com> wrote:
> 
>> But -- it's a legitimate problem. You can't exactly hide those
>> pages behind a security realm. As Mailman is structured, you can't
>> really remove them, and there's no way to protect them.
> 
> I would argue conversely that listname-owner@domain needs to be
> publicly known and accessable in the same way that postmaster@domain
> is.  The fact that postmaster is now often used as an alias for
> /dev/null is unfortunate, but seems to be part of the territory.

I don't disagree -- but that's not the address on the listinfo pages,
either. And that's ANOTHER problem to deal with, now that you mention it.

I think what this implies is that mailman ought to have all incoming mail
proccessed through the same anti-spam rejection filters that it uses for
posting e-mail (especially since we plan on upgrading that in 2.1 for better
scripting and auto-reject, right?). So maybe the listinfo pages report the
admin addresses as Chuq Von rospach <list-name-owner@mydomain>, and that
goes through some kind of filter.

But -- I still don't like that option a huge amount, since it requires an
admin to manually work to staunch the flow of spam. Mailman needs to do what
it can to keep addresses out of the spam harvesters grasp in the first
place, to the greatest extent possible -- both subscribers AND admins.

I dunno that there's a damn thing we can do about the hardwired addresses,
but I don't think that also gives us the right to take someone's email
address and stuff it on a web page without an attempt to protect it. Some of
us have taken great pains to protect those addresses in the archives from
harvesters. I'm quite chagrined to realize I've been doing it happily to the
admins at the same time.

> Sure, adding a web form blinder to Mailman might be nice as an
> optional feature, but in a great many circumstances that address
> needed to be exposed (and should be).  We shouldn't mandate the CGI.
> The cheap approach is allow for edits and substitutions and then
> later perhaps add some of those substitutions in as optional
> features.

I think we DO need to mandate the CGI for SOME addresses. But we can discuss
what addresses should be stuck behind the garrison, and what addresses can't
be, and for those, see what armor we can give them in other ways. I don't
think we can do nothing, and I don't think the answer is "have them filter
with procmail" -- mailman is creating this problem, and not only doesn't
everyone have access to tools like procmail (or the interest in hacking it),
it's a problem created by mailman, and I don't think the program should
shirk it's responsibility onto the admin or some other tool. The less we
deal with this RIGHT, the more we contribute to things like
postmaster=>/dev/null issues.....



-- 
Chuq Von Rospach, Internet Gnome <http://www.chuqui.com>
[<chuqui@plaidworks.com> = <me@chuqui.com> = <chuq@apple.com>]
Yes, yes, I've finally finished my home page. Lucky you.

Shroedinger:
 We can never really be sure which side of the road the chicken is on.  It's
all a matter of chance.  Like a game of dice.

Einstein, refuting Schroedinger:
 God does not play dice with chickens.
Heisenburg:
We can determine how fast the chicken travelled, or where it ended up, but
we cannot determine why it did so.