[Mailman-Developers] Moderation rules priority

[Barry Warsaw]

On Mar 13, 2014, at 05:06 PM, Stephen J. Turnbull wrote:

>I expressed myself poorly.  The parameters of the decision logic given
>the list of senders are different for the two rules so both rules are
>needed.  But I really think that determining the sender should be done
>in one place by one set of principles, separated from the "to post or
>to moderate" logic.  Maybe we could use all_senders, member_senders,
>and apparent_sender properties (where the last is Mailman's best guess
>at who's reponsible for sending the mail for the purpose of
>moderation), or perhaps just apparent_sender and sender_is_member
>properties.

This logic requires both the email message and the mailing list object.
Mailman's Message class has both a `sender` and `senders` property, but the
latter is the interesting one for this topic:

        The list will contain email addresses in the order determined by the
        configuration variable `sender_headers` in the `[mailman]` section.
        By default it uses this list of headers in order:

        1. From:
        2. envelope sender (i.e. From_, unixfrom, or RFC 2821 MAIL FROM)
        3. Reply-To:
        4. Sender:

The problem is the destination mailing list.  I don't think we can leave this
to a rule because rules are by definition unordered and self-contained, so
there's no guarantee -- and we shouldn't impose one -- that such a rule will
get executed early enough.

We *could* do it in the LMTP runner, but right now, that doesn't query for the
mailing list object, since it's not needed in order to dump the message into
the appropriate queue.  I don't think we can do it in the queue runners, and
the message could end up in different queues, so the LMTP runner would be the
only common preprocessing possibility (currently, at least).

> > I *think* the right solution may be to continue to keep the rules
> > separate, but add an extra check to the nonmember-moderation rule,
> > such that if any of the senders are members, then the rule cannot hit.
>
>This is horrible.  You've already done that check in the Member rule.

True, at least for the default processing chain.  But these chains are
configurable and extensible, so again, there's no guarantee that the member
rule will even be run.

>It's OK as a stop-gap, I don't really object applying to Aurelian's
>patch in principle, because I think it should be fixed now.  The
>meta-rules about how to compose rulesets need discussion before doing
>anything more invasive.

We can definitely have that discussion, but I feel quite strongly that rules
should be self-contained and unordered, with ordering imposed by the chain of
links that rules are associated with.

I agree though that for now Aurelian's patch is what we should do for now.

-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/20140315/9d033a60/attachment.sig>