[Mailman-Developers] Moderation rules priority

Barry Warsaw barry at list.org
Mon Mar 17 15:43:34 CET 2014


On Mar 17, 2014, at 02:34 PM, Stephen J. Turnbull wrote:

>I don't understand what you're trying to say here.  Are you saying
>that rules should not have a "rules_to_run_before_this_rule" field,
>but it's OK if a chain "rule_B, rule_A" is buggy because rule_A should
>be run before rule_B?  Of course we should then fix the bug -- the
>point is that it is currently very easy for such bugs to occur,
>because rules may depend on metadata, and set/change metadata.

I know you remember these diagrams: :)

http://pythonhosted.org//mailman/src/mailman/docs/8-miles-high.html#basic-messaging-handling-workflow

>Perhaps rules should be allowed to add new metadata, but not change
>existing metadata?
>
>I think I already mentioned that I have a difficulty with the concept
>of "*pure* Boolean with side effects", too. :-)

I was being sloppy in my previous response.

Rules either hit or miss.  Their check() method is called and it must return
True or False.  They cannot depend on any other rule having been run before or
after them, i.e. they are self-contained.  The check() method gets a mailing
list object, the message, and a metadata dictionary.

Rules must not have a side-effect on either the mailing list or the message.
They may have a side-effect on the metadata dictionary, but as you say above,
they may only add new metadata, not delete or change existing metadata.  They
also can't refer to metadata from other rules, because you don't know what
order rules are run in.

After a message is accepted (and processed) by the LMTP server, it is dropped
into the `incoming` queue.  The incoming queue runner picks the message up and
processes messages through a chain.  By default this is the
`default-posting-chain`.  This chain is composed of list of rules and actions
(parlance, a 'chain of links').  Each link in the chain contains a rule, an
action, and a target.  If the rule hits, the action is taken.  If the rule
misses, the next link in the chain is processed.  Actions can be all kinds of
things (see the interface for details), but it is often 'defer', which more or
less acts like a rule miss in that the next link in the chain is processed.

(The difference is that the chain processing infrastructure records which
rules hit and which rules miss.  In the default processing chain, there is an
`any` rule which looks at the metadata recorded by the processing
infrastructure, and *it* takes a `jump` action if any of the deferred rules
have hit.)

(Please note that this logic is embodied in the built-in chain, which by
default is the chain that the incoming queue runner processes.  Other chains
do not usually have links of rules since their functionality is much simpler.
E.g. the discard chain just writes a log message, fires an event, and exits,
thus throwing away the message.)

>N.B. As far as *I* am concerned, you can take your time about
>responding to this.  I need to go review the docs and code on all this
>anyway.  But I suspect that if *I'm* confused about these concepts,
>*others* may be too, and they're pretty fundamental to customizing and
>extending Mailman 3.

Pictures help a lot here! :)

If you want to see where the metadata added by the member and nonmember
moderation rules gets used, look at the moderation chain.  If either of those
two rules hit, then processing jumps to the moderation chain.

All the moderation chain does though is dispatch to some other chain (in
parlance, it jumps to some other chain).  Which chain it jumps to depends on
the metadata written by one of those two rules, specifically the
'moderation_action'.  This piece of metadata corresponds directly to the
action that should be taken when a particular person posts to the mailing
list.  So if stephen@ posts and is a member and has an action of `discard`,
then the moderation chain jumps to the discard chain described above.

Let's make sure we have a whiteboard at Pycon. :)

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20140317/e15bd65c/attachment.sig>


More information about the Mailman-Developers mailing list