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
pgp9mKoWRBDlx.pgp
Description: OpenPGP digital signature
_______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
