[Mailman-Developers] Preventing spam to list admins.

[Barry A. Warsaw]

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

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

Agreed.

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

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

You've been reading my mind, you know.  I've been hesitant to suggest
this, but for quite some time I've thought that the next release ought
to be 3.0 intead of 2.1.  I've stopped short of that because 1) what I
promised would be in a 2.1 release; 2) I've been talking about "MM2.1"
for so long now; 3) all the things I've been pushing off to MM3.0.

I really really really want to get the next release out as soon as
possible.  I don't want a decision to call this thing MM3.0 to mean a
delay in the release schedule.  But truth-in-advertising makes me
think it really should be called 3.0.  OTOH, will that deter too many
people from upgrading?  Sigh, I don't know.  Opinions?

I'd like to make a final decision on this by the first beta.
(Remember, there /will/ be one more alpha... RSN! ;).

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

    JCL>   Definitions at each level which lower levels CANNOT
    JCL> override.

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

This is much more what I've been thinking of doing.  You're right that
doing it the other way would probably be just too complicated and
error prone.

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

-Barry