[Mailman-Developers] Migration of header_filter_rules

[Barry Warsaw]

On Sep 10, 2015, at 11:33 AM, Aurelien Bompard wrote:

>> It's probably going to require a separate table foreign
>> keyed to the mailing list which contain a list of regexps and their actions,
>
>Yeah, it's currently a python list pickled into the header_matches
>field of a mailinglist, we can do better :-)

Yes, let's eat the pickles! :)

>> I'm not sure that the current semantics of header-match need to be
>> preserved.  If a list admin wanted one of their regexps to trigger the
>> site-defined action, they could just choose it themselves.  I don't think
>> we need to keep it for backward compatibility reasons, but we do need to
>> migrate any existing header_checks to the new feature (i.e. for people
>> upgrading from MM 3.0 to 3.1, as this will obviously be a 3.1-only
>> feature).  I suggest using the config.antispam.jump_chain value as the
>> default value for the new header_checks regexp value.
>
>We could decide that the chain to be jumped to is nullable, in which
>case the action would be defer, which would end up in the site-defined
>chain like in the current model. Then the existing chain could just
>use that and get the same behavior.

That might indeed be a better way to go, so if the site-defined action is
changed, the change will get picked up.  The downside of course is that a
restart is needed.

It might be better to move the site checks out of the config file and into the
database.  It could work the way bans work, where if there is a list-id
context, it's a list-specific ban, and if there is no associated list-id, it's
a site-wide ban.

Don't feel you have to do this extra step, but it might be easy.

>> You'll have to disentangle the site-wide header checks with the
>> list-specific header checks, but maybe that can be done in the .get_links()
>> method.  Site-wide settings should take precedence.
>
>Hmm, do you think so? I would have thought that list settings should
>take precedence, since they are the most precise. A list could decide
>to not filter the spam and deal with it in their own manner (holding
>it instead of discarding it).

My thinking was that site owners have greater permission and responsibility,
so their preference should win.  It might be interesting to have a way for a
site admin to say "here's the default, but let list admins override"
vs. "here's site policy, you cannot override".

This seems like a not-uncommon pattern, especially if you add a domain-owner's
preferences here.  There's a hierarchy that's often repeated.  But
generalizing that, or even supporting it in this case can very definitely
happen in a future feature.

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