I'm not sure if we should add this. There were a couple of requests on the irc lately.
Corporations would probably appreciate it being built in or at least documentation on how this is done.
Edited
Designs
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related or that one is blocking others.
Learn more.
This was actually discussed in our original 3.0 architecture plans, but it's not going to make the 3.1 release. This bug needs a better explanation of the use cases; if you are likely to use ldap, please let us know how and how you'd expect it to behave.
I would like to see ezmlm-web ldap integration: for every list you can specify one or more LDAP accounts which are allowed to manage a list. With that account you can login to the webinterface and you'll see a list of all mailing lists that you can manage.
@terriko As I am interested in this feature, I'll try to outline the use cases that come to my mind:
simple:
Users only are taken from LDAP, user information (email, Name, password) is extracted from LDAP, list assignments are managed by mailman as before.
Advantages: Authentication can happen based on LDAP credentials, per account passwords are possible, users can manage their subscriptions
per group mailing lists:
Users and groups are taken from LDAP, users as above, but there is a 1 to 1 relationship between groups and mailing lists. Some of the mailing list information meta information could be stored in LDAP too (list admins, list address)
support for groups:
Users and groups are taken from LDAP, but each mailing list can have groups and/or users as members. Mailing list is not identical to a group, so information is still stored in a separate database. If you want to support per user signing/unsigning the information needs to be stored in the database.
My personal usecase is the following:
I have several groups, Customer1, Customer2, .... on the one side, and employee accounts & groups on the other. Each ml gets one(?) customer group and some employee accounts assigned, there are mailing list administrators assigned as single user accounts or as a group, and after all you have one Superadministrator group to manage all mailing lists (creation, deletion, etc.)
I hope this helps a bit, I would be very pleased to see this going forward.
We do not touch the authentication part at all, so this is mostly a matter of making Django work with LDAP. From the above comments it looks like people have done it using just new configuration options.
I changed the title to just document this somewhere on Wiki or Docs so that we can point people to it.
Has anyone looked at implementing case 2 (per group mailing lists)? We've currently got this working for Mailman 2, but would like to switch to Mailman 3 at some point.
@aragilar if your setup is public or if you can share it, we can get it to work with Mailman 3 too. There are equivalent commands to create/delete a ML and add/remove members to the list, which I assume is what you'd have with Mailman 2.1. We'd just need to change to the new commands.
@luizluca It should be doable, if not out of the box, with some simple django event handlers that add and verify the emails in Mailman after the integration with Django. I am sure there are Django packages that would let you hook up auth system with LDAP, but we don't have that setup tested or documented with Postorius or Mailman really.
@maxking The instance is not public (private lists for research teams). The creation/deletion of lists is done via scripts which call the mailman2 commands (and modify the list configs via config_list). The added config uses Mailman.LDAP3Memberships (which if I recall is a modified version of https://bugs.launchpad.net/mailman/+bug/558106), so list membership is handled entirely by LDAP (which is a major part of the setup, it means users get added to systems all in one place).
Last time I looked at mailman 3, all that metadata needed to be in django, which isn't ideal for us (as django could easily get out of sync with LDAP), but if it's possible to have that metadata in something external, that could work.
I think we'd look at moving to https://www.sympa.org/ (entirely due to the LDAP handling). This isn't a reflection on mailman, but instead on our requirements (when I've interacted with mailman 3 for public lists, I've found it really nice, and would consider using it for any public lists I run).
Last time I looked at mailman 3, all that metadata needed to be in django, which isn't ideal for us (as django could easily get out of sync with LDAP), but if it's possible to have that metadata in something external, that could work.
The membership related information is stored in Mailman Core, not in Django. Django is simply a front-end to manage lists and it handles the authentication for emails to let the owner manage their membership or lists. If you are managing memberships and ownerships through LDAP, you can in theory skip the entire web frontend. Although, I agree that you'd have to have some sort of sync service to make changes.
To do it in a first class way, you can create a simple Mailman handler that calculates the recipients using an ldap query(similar to class MemberRecipients: in here) and sets it up in the msgdata['recipients']. You can probably salvage most of the code there is for the Mailman 2, as you can see the Handler isn't doing a lot of things. Although, I am not sure if there are parts in the code which would expect those recipients to be 'Member' records in database, but it wouldn't be too hard to figure out if there is any interest in pursuing this direction :)
@maxking Oh, cool, that might just work! When we look at the mailing lists again, I'll keep that in mind. We'd like users to have a web interface to browse, and can do the django authentication for that part, it's more if the system required users to log in to appear in the system, when most will have not (which appears maybe not).