[Mailman-Developers] New sender-centric moderation rules

[Barry A. Warsaw]

I'm about to checkin a bunch of changes implementing new
sender-centric moderation rules.  I think this will make moderation
based on sender (i.e. From:) more flexible and more understandable.

One of the things that I dislike intensely, and I often get negative
email about is the overloading of the `posters' attribute, with its
semantics dependent on the value of `member_posting_only'.  Quick:
what are the rules for these two variables?  See? :)

My changes were inspired by Larry McVoy's recent request, and are now
twofold:

>>>>> "LM" == Larry McVoy <lm@bitmover.com> writes:

    LM> Forgive me if this is glaring at me in the docs, but does any
    LM> mailman version have the ability to have some users be
    LM> moderated and some be not moderated on the same list?

    LM> This would rock my world and a lot of other people's as well.
    LM> I'd love to be able run my lists as "you're trusted until you
    LM> screw up" and/or "you're untrusted until you prove
    LM> trustyworthy" and be able to pick and choose on a per person
    LM> basis.

First, each member has a "moderate" bit associated with their options.
If their bit is on, their postings are held for moderation regardless
of any other setting.  If their bit is off, then the message is passed
on to other phases of hold checking.  Only list admins can get to a
user's moderation bit, so only they can change them.  Each list has a
default value for the bit, which will be used to initialize new
members.

Second, I've gotten rid of the following configuration variables,
which were previously available in the "Privacy" section: `moderated',
`forbidden_posters', `posters', and `member_posting_only'.

Now, when a posting is received by a list, it follows these rules
(note: see misc/posting-flow-chart.ps in cvs):

- If the sender is a member
    - If the member's moderate bit is on, hold the message
    - If the member's moderate bit is off, pass on to the next
      pipeline handler

- If the sender is not a member
    - Check the sender's address against the list in
      accept_these_nonmembers.  If so, pass on to the next pipeline
      handler
    - Check against hold_these_nonmembers.  If found, hold the message
      for moderation
    - Check against reject_these_nonmembers.  If found, automatically
      reject (i.e. bounce) this message.
    - Check against discard_these_nonmembers.  If found, simply
      discard the posting.  Optionally, send the list moderators a
      copy of the discarded message.
    - If the sender wasn't found in any of those 4 lists, then apply
      the generic_nonmember_action, which may be one of accept, hold,
      reject, discard.

I believe this covers all the possibilities and it should be easier to
understand how everything interacts.  The auto-upgrade feature should
map the old configuration variables to the new ones as closely as is
possible.

Some examples:

- A traditional, members-only list: turn off the default member
  moderate bit, set the generic_nonmember_action to reject or hold.

- A completely open list: turn off default member moderate bit, set
  generic_nonmember_action to accept.

- A member-only list, with trust required before unmoderated posting
  is allowed: turn on default member moderate bit, set
  generic_nonmember_action to reject or hold.

Etc.

Some things to think about adding:

- A global switch to set or unset the moderate bit of all members.

- Make it so list moderators can set or unset the per-user moderate
  bit (right now only list admins can do that).

- Add some hooks to admindb so that held messages can be sorted by
  sender, and so that you could automatically add the non-member to
  one of the 4 lists (accept, hold, reject, discard), or automatically
  un-moderate a moderated member.

- Much of the framework to support the sender-centric moderation stuff
  could be used to automatically dispose of messages based on other
  criteria.  I.e. I could see that we might have a default action for
  each of the remaining hold criteria, and we might be able to offer a
  bodytext-based regexp matcher with a default action.

One of the other things I've added will hopefully make admin
notifications of held messages a little more convenient.  With these
changes, the admin notification contains the traditional notice, along
with two embedded messages (rfc822/message).  The first is the
original held message, and the second is a confirmation message.

What this allows you to do is to approve or discard held messages from
email, without having to go through the web.  If you simply respond to
the confirmation, the held message will be discarded.  If you add an
"Approved: password" header (or first line of response), then the
message will be approved just as if you approved it through the web.
I figure these are the two most likely responses, so if you wanted to
reject it, forward it, or preserve it, you still need to go through
the web.

Anyway, comments are welcome.  Checkins will follow shortly.

-Barry