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 <[EMAIL PROTECTED]> 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
_______________________________________________
Mailman-Developers mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-developers
