[Mailman-Developers] Migration of header_filter_rules

[Aurelien Bompard]

Hey all!

I'm hitting another issue in my migration from 2.1 to 3.x. In 2.1,
there was an option called "header_filter_rules" used mainly for spam
control, and advertised as such in the CGIs. These rules contained a
regex and an action to take on a match : defer, approve, reject,
discard, (un)subscribe, accept or hold.

In 3.x, this has been replaced by the list attribute "header_matches",
which is just a list of regexes. These list-specific regexes will be
added to the list of regexes in the antispam section of the
configuration file. If any of those matches, the action taken will be
the one set in the same section of the configuration file.

I'm having two issues with this. First, different list admins may want
different actions taken on spam, like discard, reject or hold. In 3.x
there's only one action possible.
Second, and that's the biggest problem for me, some of my lists admins
have been considering this feature as a generic filtering system
(because that's what it is in the end). Here are some of the usages
I've seen:
1. Have a rule that matches obvious spam ('^Subject: .*loan.*') and
discard those instead of rejecting
2. Have a rule that would accept an email based on the presence of a
header (X-Git-Module or Approved) and reject all other emails
3. On an automated list where commits are posted, have a series of
rules that would drop emails from the devel branches, accept emails if
they came from the right servers (Received header), and hold all the
rest
They refer to this feature as "regular Mailman filtering".

Use case 1 would need at least list-specific actions, use cases 2 and
3 would need rule-specific actions, like it is now in 2.1.

I don't think our current system of just collecting the header_matches
rules and applying a site-specific action is going to be enough in the
long run anyway, since list admins may want different actions taken on
their spam. For example a list about finance or pharmaceuticals may
want to hold and inspect what the spam detector flagged as spam,
because it's more likely to have false positives.
And if we're going to change this system, I'd suggest going all the
way to rule-specific actions, to ease migrations and give more
flexibility to list admins.

I'm willing to write this change, if you think it's a good idea. If
you think it should be handled differently, I'm all ears.

Thanks for your attention and input

Aurélien