[Mailman-Developers] Preventing spam to list admins.

[J C Lawrence]

On Tue, 28 Aug 2001 16:35:46 -0400 
Barry A Warsaw <barry@zope.com> wrote:

>>>>>> "JCL" == J C Lawrence <claw@kanga.nu> writes:

>     | SiteOwner | ListAdmin | ListOwner == ListModerator |
> ListMember

> Okay, I think I can live with that, even though strictly speaking
> "moderators" won't have all the privileges of "owners" (owners can
> hit the admin pages, while both groups can hit the admindb pages).

I'm counting ListAdmin and above as the only one able to hit the
admin page.  ListOwner/Moderator can only hit the admindb pages and
everything below, and members, well, they can hit their options.

>>> Then what about -admin?  Currently the only distinction between
>>> -admin and -owner is that the former runs the bounce detector
>>> first.  Should -admin go to the moderators too?

JCL> Admin is useful for bounce processing (tho I'd prefer seeing
JCL> that using a -bounce address rather than conflating it onto
JCL> -admin as it makes filtering easier), and for those who
JCL> actually have write privilege to the list configs (not just
JCL> post approval).

JCL> Actually, I'd *really* like to see bounce processing split out
JCL> to its own address.

> Me too.  I remember we had a thread about this a while back.
> Doing so would require regeneration of your alias database, which
> I seem to recall was considered to disruptive to backwards
> compatibility to adopt for MM2.1.  Maybe we should reconsider (or
> perhaps I remember the decision incorrectly).

It would be disruptive.  I was hesitant to recommend for 2.1 as at
the time it was looked at as an incremental release.  This is no
longer true.  2.1 at this point almost (perhaps not quite) warrants
a pull number increment.  Certainly 2.1 already has a list of
backward incompatabilities (qrunner/cronjobs, mimelib, etc).  I
don't see much problem splitting it out into its own address
concurrently with 2.1, and frankly, I'd rather get the pain over
sooner than later.

>>> To complete the circle, we can pass -owner messages through the
>>> SpamDetect.py filter, but not the Hold.py filter.  This isn't
>>> ideal, because I don't think there will be time to make
>>> SpamDetect configurable thru-the-web for 2.1, but it does give a
>>> site admin /some/ ability to filter out the most egregious
>>> spammers.  And I'll posit that spam detection/prevention filters
>>> really ought to be applied site-wide instead of per-list.

JCL> Grrrr.  No.  There's to much variation in what particular lists
JCL> might want, especially in vhosting situations.

> I'm not saying that vhosts and/or lists shouldn't be able to
> augment site-specific spam controls, but I also don't want to
> burden every list admin with having to install their own spam
> controls to block /anything/.  It's analogous to MTA spam blocks,
> which by their nature are site-wide.

> Remember that in post-2.1 I plan on implementing delegation of
> configuration: site->vhost->list(->user).

Quite, so we're going to get a hierarchy of config values and
ranges.  

  Site installation has a set of configs which all lists inherit
  and can't create exceptions to.

Which really raises the question of definition strength.  If you
have such a layered model with each level inheriting the values from
above and (generally) not able to do anything except more go
tighter/more_limited than their parent it makes creating exceptions
nightmarish.  While it adds a horrible level of complexity, what I'd
suggest is doing a two layer job:

  Definitions at each level which lower levels CANNOT override.

  Definitions at each level which provide defaults, but which can be
  overridden.

In the first category would fit Chuq's list and the ListReplyTo
setting.  In the latter category might fit site SPAM checking
suggestions.

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