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