[Mailman-Developers] Preventing spam to list admins.

[J C Lawrence]

On Mon, 27 Aug 2001 14:02:54 -0700 
Chuq Von Rospach <chuqui@plaidworks.com> wrote:
> 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.

Aye, that's a long term niggle for me: The admins on the listinfo
pages et al should be reported as listname-admin@domain, not the
actual addresses.

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

Which tends to break on those site which use gang moderation.
Actually some of the more interesting cases are where the admin
address for a list is actually another list.  This form is commonly
used for IS depts and the lists they manage for their company.

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

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.

#2 just doesn't work.

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.

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

<nod>

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

I think we can mandate Mailman specific processing for *SOME*
addresses, ala SPAM filters, but mandating that they can only be
accessed via a web CGI versus SMTP mail is posit is fundamentally
wrong.

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

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.

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