[Mailman-Developers] Preventing spam to list admins.

[J C Lawrence]

On Mon, 27 Aug 2001 22:56:32 -0700 
Chuq Von Rospach <chuqui@plaidworks.com> wrote:
> On 8/27/01 10:14 PM, "J C Lawrence" <claw@kanga.nu> wrote:

> I like the idea of having mail funnel through
> listname-owner@domain, and have that point to the list of all
> admins (or with 2.1, where we have list admins, content admins and
> site admins, how weill this breakout change?  Hmm). Seems to me
> the answer is to bridge access to that address through some kind
> of interface that spambots can't traverse, but humans can. That
> would mean not putting mailtos on the page, but doing something
> that would let the user mail the admin. I'm not necessarily a fan
> of the "send email" form thing, either, since if mailman breaks,
> that form also probably breaks (and how will they email us to tell
> us It's broken?), but I'm not sure there's are many alternatives
> that solve all of these problems...

Okay, have the text on the page read listname-admin@domain, but have
the link invoke a CGI which presents a form to write/send a message.

> I do believe that shifting the listinfo page to be a mailto to the
> -owner address will only get that address on the spam lists and
> solve nothing....

I don't know that that problem is, or should be, resolvable.  Humans
need to see/get that address.  That means that harvesters can too.

>> There are two conflicting requirements here:
>> 
>> 1) The list admin address needs to be cannonical, well known, and
>> always supported.
>> 
>> 2) We can't tell anybody about it.

> Does it have to be well-known? Canonical? 

Yes, and yes.  Users will know and learn the pattern, will expect
it, and will use it (they do already).  This is a Good Thing.

> Or is it something that simply has to be available on request?

Won't work if Mailman is down.  The admin-address is specifically
needed be direct.

> There ARE addresses that have to be canonical and well-known, but
> are list-admin addresses one of those? Or can we, say, generate
> them dynamically or simply hide them through some accessible
> interface?

I don't believe so.

>> What we can do is try and institute methods for sites to help
>> them control the damage wreaked by #1.  Sadly, I don't have a lot
>> of suggestions there. other than the fact that doing away with #1
>> is not an acceptable answer.

> The first answer is to run it all through whatever mailman uses
> for anti-spam for the posting addresses. Which would at least
> allow us to define auto-bounce rules for the "easy" stuff, like
> pr0n, judicial judgements and the like. We could filter out the
> "low hanging fruit" with a decent tool, if it filters admin mail
> through it.

> But that's only low hanging fruit. And a partial solution. But
> it's a start.

<nod>

I'm leery of trying to do too much.  We don't need to.  If we do
just enough and make it easy for others to follow, they can and will
do the rest.  We can then cherry pick.

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

>> Well, of course we can.  Many do precisely this (little).  Its
>> just that we'd do better and be better if we didn't.  Its more
>> admirable to step up to the plate, even if you do miss the ball.

> Or foul it off. Tell your admins running lists from AOL that all
> they need to do is install procmail...

> No, I think if we create a problem (and we are) we have some
> responsibility to minimize it and do what we can about it. It
> might not be easy for Mailman developers, but then, by the same
> rationale, we could do away with subscription validation, no?

You misunderstand.  I'm agreeing with you above.

-- 
J C Lawrence                                    )\._.,--....,'``.	    
---------(*)                                   /,   _.. \   _\  ;`._ ,.
claw@kanga.nu                                 `._.-(,_..'--(,_..'`-.;.'
http://www.kanga.nu/~claw/                     Oh Freddled Gruntbuggly