Hey folks,
I'm sorry to announce that I had to rollback the migration of lists.fedorahosted.org to Mailman 3. There's a missing feature again, that is heavily used by two lists on this server, it's the header_filter_rules. It lets the admin decide on header regexes that will set a different action on the email (rejecting, holding, etc). It's designed for spam filtering: detect X-Spam-Flag and drop the email. Those lists use it to filter commit emails on the master branch only and drop the rest. The migration to Mailman3 caused an email avalanche on their list when someone pushed a branch, so... not very nice :-/
In Mailman3 this is implemented differently, you can only have a global action set for emails whoose headers match the filters. Not per regex as in Mailman 2, not even per list, only per server. So I'll discuss this on the mailman dev list and write this feature, in the meantime I had to rollback the migration.
I wish it had worked better, sorry for the inconvenience.
Aurélien
On Fri, Aug 21, 2015 at 04:40:34PM +0200, Aurelien Bompard wrote:
Hey folks,
I'm sorry to announce that I had to rollback the migration of lists.fedorahosted.org to Mailman 3. There's a missing feature again, that is heavily used by two lists on this server, it's the header_filter_rules. It lets the admin decide on header regexes that will set a different action on the email (rejecting, holding, etc). It's designed for spam filtering: detect X-Spam-Flag and drop the email. Those lists use it to filter commit emails on the master branch only and drop the rest. The migration to Mailman3 caused an email avalanche on their list when someone pushed a branch, so... not very nice :-/
In Mailman3 this is implemented differently, you can only have a global action set for emails whoose headers match the filters. Not per regex as in Mailman 2, not even per list, only per server. So I'll discuss this on the mailman dev list and write this feature, in the meantime I had to rollback the migration.
I wish it had worked better, sorry for the inconvenience.
Sorry this didn't work out better (and that I'm catching up to list mail late). Once you can implement upstream, do you plan to try again with a patched version while we await an upstream point-release?
Once you can implement upstream, do you plan to try again with a patched version while we await an upstream point-release?
Yes, that's my plan. My RPM already carries a few patches that are not released, and even still under review. I update them (and eventually remove them :-) ) as they get reviewed.
Aurélien _______________________________________________ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/postorius/infrastructure@lists.fedoraproject....
On Tue, Aug 25, 2015 at 04:19:17PM +0200, Aurelien Bompard wrote:
Once you can implement upstream, do you plan to try again with a patched version while we await an upstream point-release?
Yes, that's my plan. My RPM already carries a few patches that are not released, and even still under review. I update them (and eventually remove them :-) ) as they get reviewed.
Brilliant. Thanks Aurélien!
infrastructure@lists.fedoraproject.org
-
Aurelien Bompard -
Paul W. Frields