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