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