Hi!
I am a new comer on this list. I am an old cyberactivist and an administrator of more than 100 mailman lists and I would need to operate much more for a budled project trough a user/feature database. It means a way (1) to set-up scores of same style mailing lists and (2) for a person being a member of my directory to easiliy select the lists she wants to attend or quit. My idea is to get it simple, non interfering and robust by having an independent database used to generate an update script on a cron basis and that scri^pt being run to create/update the necessary mailman instances.
- would such a system already exist?
- considered your experience of mailman do you think such a system could realisticly be feasible and work?
- I never looked at the mailman code yet : where in it should I have a look?
- would this be a big work?
- where could I get some help to develop it?
Thank you for attention and response. Best jfcm
On 2016-01-21 1:47 AM, JFC Morfin wrote:
You could add this pretty easily in Mailman 3, which uses data structures that can handle that. Basically, take a look at the postorius "subscription based preferences" page under "my settings", and all you'd need to do is add a column that allowed people to choose to subscribe or unsubscribe. (you can right now turn mail delivery on/off and edit the other preferences, but not actually unsubscribe from that page.)
In Mailman 2, it's much harder, because the data structures are such that there's not really a concept of a user, so you'd have to fake it by going through each list, seeing if a given email address was in it, and collating all that information. If you look at the code that runs when you click "list my other subscriptions" in the user options page, and that would give you a good idea of how it can be done.
Terri
I see I'm duplicating much of what Terri wrote but there's some new information here. With that caveat (must run, no time to edit), here we go:
JFC Morfin writes:
For (1), Mailman 3 lists are database-backed (currently PostgreSQL, MySQL, and SQLite are supported, either of the first two should easily scale to your requirements). Setting up list styles easily is not yet well-supported, but we hope to have a Google Summer of Code student work on that feature this summer. The Postorius web interface supports (2) quite well.
This turns out to work but it's not as easy as you would hope. Mailman 3 should soon include the necessary features, but on the other hand it is already working with Mailman 2. AFAIK systems like cPanel don't really support (1) or (2) all that well. But I know that there are lots of homebrew systems out there at universities and corporations.
On Jan 22, 2016, at 02:27 PM, Stephen J. Turnbull wrote:
Just another bit of Mailman 3 obscurity: there is a handler called 'file-recipients' which can be used to populate a message's recipient list from a static file. It looks on the file system, inside the mailing list's data directory for a members.txt file. If found, this can contain one email address per line which is used as the recipient list for the message.
Of course, you need file system access to edit this file because it's not currently available via REST, and thus not available to Postorius.
A few things could make this nicer:
- Expose the file to REST so that it can be updated via Postorius
- Use 'parseaddr' style lines so that they can contain anything parseable by the email.utils.parseaddr() function
- Allow it to augment any other recipient list already calculated, instead of short-circuiting when any other recipient list is already present
- Add file-recipients to the default pipeline handler list
Contributions welcome of course.
Cheers, -Barry
On 01/21/2016 01:47 AM, JFC Morfin wrote:
Just to add a bit to what Terri and Steve have already said.
For MM 2.1, for (1) you can setup a list in the style you want, export its config with Mailman's bin/config_list, delete a few list specific things from that output like real_name, owner and subject_prefix, and then for a new list, create it with bin/newlist and update the config with bin/config_list with the prior style as input.
for (2) if you can export from your directory a flat file of
Display Name <email@example.com>
entries that represent who should be on a list, then you can use bin/sync_members to sync the list membership with that file.
I do that for the 'all members announce list' for my bike club. A cron runs nightly to export the member list from the member database and then runs sync_members to update the list membership. This could be done for any number of lists if you have a way to create the desired membership list for each list.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 2016-01-21 1:47 AM, JFC Morfin wrote:
You could add this pretty easily in Mailman 3, which uses data structures that can handle that. Basically, take a look at the postorius "subscription based preferences" page under "my settings", and all you'd need to do is add a column that allowed people to choose to subscribe or unsubscribe. (you can right now turn mail delivery on/off and edit the other preferences, but not actually unsubscribe from that page.)
In Mailman 2, it's much harder, because the data structures are such that there's not really a concept of a user, so you'd have to fake it by going through each list, seeing if a given email address was in it, and collating all that information. If you look at the code that runs when you click "list my other subscriptions" in the user options page, and that would give you a good idea of how it can be done.
Terri
I see I'm duplicating much of what Terri wrote but there's some new information here. With that caveat (must run, no time to edit), here we go:
JFC Morfin writes:
For (1), Mailman 3 lists are database-backed (currently PostgreSQL, MySQL, and SQLite are supported, either of the first two should easily scale to your requirements). Setting up list styles easily is not yet well-supported, but we hope to have a Google Summer of Code student work on that feature this summer. The Postorius web interface supports (2) quite well.
This turns out to work but it's not as easy as you would hope. Mailman 3 should soon include the necessary features, but on the other hand it is already working with Mailman 2. AFAIK systems like cPanel don't really support (1) or (2) all that well. But I know that there are lots of homebrew systems out there at universities and corporations.
On Jan 22, 2016, at 02:27 PM, Stephen J. Turnbull wrote:
Just another bit of Mailman 3 obscurity: there is a handler called 'file-recipients' which can be used to populate a message's recipient list from a static file. It looks on the file system, inside the mailing list's data directory for a members.txt file. If found, this can contain one email address per line which is used as the recipient list for the message.
Of course, you need file system access to edit this file because it's not currently available via REST, and thus not available to Postorius.
A few things could make this nicer:
- Expose the file to REST so that it can be updated via Postorius
- Use 'parseaddr' style lines so that they can contain anything parseable by the email.utils.parseaddr() function
- Allow it to augment any other recipient list already calculated, instead of short-circuiting when any other recipient list is already present
- Add file-recipients to the default pipeline handler list
Contributions welcome of course.
Cheers, -Barry
On 01/21/2016 01:47 AM, JFC Morfin wrote:
Just to add a bit to what Terri and Steve have already said.
For MM 2.1, for (1) you can setup a list in the style you want, export its config with Mailman's bin/config_list, delete a few list specific things from that output like real_name, owner and subject_prefix, and then for a new list, create it with bin/newlist and update the config with bin/config_list with the prior style as input.
for (2) if you can export from your directory a flat file of
Display Name <email@example.com>
entries that represent who should be on a list, then you can use bin/sync_members to sync the list membership with that file.
I do that for the 'all members announce list' for my bike club. A cron runs nightly to export the member list from the member database and then runs sync_members to update the list membership. This could be done for any number of lists if you have a way to create the desired membership list for each list.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (5)
-
Barry Warsaw -
JFC Morfin -
Mark Sapiro -
Stephen J. Turnbull -
Terri Oda