[Mailman-Developers] Preventing spam to list admins.

[Barry A. Warsaw]

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

    >> 1. "Contact the Mylist administrators", where contact is
    >> hyperlinked to the mailto: url of the -owner address.

    >> 2. Like now with a slight variation: "Mylist list run by barry
    >> at zope.com", where Mylist is hyperlinked to the listinfo page
    >> and "barry at zope.com" is mailto: linked to the -owner
    >> address.

    >> I think I prefer #2.

    JCL> I very slightly prefer #1.  I don't consider this a
    JCL> significant item however, #2 is just fine.

Okay.

    >> Chuq brings up the issue of whether the moderators are included
    >> in email to -admin or -owner, and the current answer is no.  I
    >> can see either adding a standard -moderators address, or always
    >> including the moderators in the -owner address.

    JCL> I consider "moderator" largely synonymous with "owner".
    JCL> Loosely the breakdown I use is:

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

    >> 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
    JCL> out 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).

    >> 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
    JCL> lists 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).

-Barry