[Mailman-Developers] Migration of header_filter_rules

[Aurelien Bompard]

> 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 :-)

> Then this has to be exposed through the REST API so Postorius can present it to the list
> admin.

Yes, and make edits.

> 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.

> 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).

> Happy to talk more about implementation details, in whatever forum you want,
> but +1 on the feature.

Cool, I'll do it :-)

Aurélien