Mailman 3 September 2015 - Mailman-Developers

Re: [Mailman-Developers] Migration of header_filter_rules
by Barry Warsaw 10 Sep '15

10 Sep '15

On Sep 08, 2015, at 09:38 AM, Aurelien Bompard wrote: >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 agree, and I think it's a good idea to go all the way to rule-specific actions. The [antispam] section serves the purpose of site-wide filtering, so that site owners can handle global problems. Some of this may overlap with what you can do in the MTA, and editing Mailman's global configuration files probably requires about the same permissions as editing the MTA's configs. This is in Mailman because it may be easier to configure than an MTA and it provides some consistency with the basic semantics of message handling in Mailman. So let's keep that. The default-posting-chain takes a detour through the header-match chain which implements the list-specific header matching as you've described. The trick then is going to be how to match actions to headers regexps, both internally and in the "ui". It's probably going to require a separate table foreign keyed to the mailing list which contain a list of regexps and their actions, and HeaderMatchChain.get_links() will likely have to be rewritten. Then this has to be exposed through the REST API so Postorius can present it to the list admin. 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. 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. Happy to talk more about implementation details, in whatever forum you want, but +1 on the feature. Cheers, -Barry

2 1

User-centric authentication and access control
by Waldbieser, Carl 10 Sep '15

10 Sep '15

I know that currently, mailman roles are set up such that the roles themselves have a shared password per role. I want to be able to move away from that model and have roles assigned to individual user accounts that would allow access to the admin interfaces for individual lists. For example, say we have mail lists "Campus" and "Board of Trustees". I might have roles "campus_moderators", "campus_admins", "boardoftrustees_moderators", and "boardoftrustees_admins". If I assign the role campus_admins to user "johnsmith", I would like this user to be able to access the mailman admin interface for the "Campus" list using his own credentials. Ideally, "johnsmith" would not have to present his primary credentials to the mailman interface because our institution has a web single sign-on infrastructure (Web SSO). I would like to actually move the authentication and role management *outside* of mailman and have the administrative interface consume the role based information from external sources (e.g. LDAP, CAS or SAML2 attribute release), so I am looking for a more "pluggable" authentication and access management architecture. Does anything like this exist for Mailman, or is it on the roadmap? Are there technical guidelines for how one might contribute toward something like this? Thanks, Carl Waldbieser ITS Systems Programmer Lafayette College

6 13

Migration of header_filter_rules
by Aurelien Bompard 08 Sep '15

08 Sep '15

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

1 0

Re: [Mailman-Developers] Merging users
by Aurelien Bompard 08 Sep '15

08 Sep '15

> Abhilash's fix is good but I need to actually merge users, so here's > how I would do it. > https://gitlab.com/mailman/mailman/merge_requests/32 > The change sits on top of Abhilash's, so there's no conflict. > > I don't think I'm missing anything as far as users are concerned, but > please have a look :-) Hey guys, do you have any feedback on this? On the principle and/or the implementation? Thanks! Aurélien

1 0