Re: [Mailman-Developers] MM3: list disabling/enabling?
![](https://secure.gravatar.com/avatar/173371753ea2206b9934a9be1bdce423.jpg?s=120&d=mm&r=g)
On Jul 11, 2011, at 12:22 AM, Paul Wise wrote:
For the Indymedia Mailman 2 install, we have a patch that allowed list disabling (and later re-enabling). Disabled lists had their settings/archives saved, did not accept mail and were listed on a separate page to listinfo. For a long-lived large mailman server serving local groups in many locations, management of the complete list life cycle was and still is essential for us.
AFAICT Mailman 3 doesn't yet support such a concept, is that the case?
I've thought about this on and off over the years and still think it's a good idea. No, MM3 does not have such a thing yet.
If not, would it be acceptable to add that?
Yep, but I'd like to understand the semantics first. Do messages to the list get bounced, and if so, by Mailman or the MTA? Currently, deleting a list does remove its configuration, but (by default) retains its archives, which can be deleted later. A disabled list would always have its archives available I think.
Any pointers if I were to try and add that?
I think the core feature would not be too hard to implement, but some specifics would depend on answering the main question above. Here's an outline of what you'd probably need to touch:
IMailingList interface to add a
enabled
flag, along with (possibly) methods to disable and re-enable a list. It's possible that the flag would be a property and just settingmlist.enabled = False
would be enough.mailman.sql to add that flag to the schema.
MailingList model to plumb the flag through and implement the switching logic.
Add a new command class, probably in cli_lists.py to expose disable/enable to
bin/mailman
. Perhaps implement this as options on the existingremove
command.Plumb this through to the REST API, either by extended the AList class in src/mailman/rest/lists.py, or by exposing the flag in the ListConfiguration class in src/mailman/rest/configuration.py.
Tests and documentation!
It sounds like a lot, but I'd think it's only a day or two of work, and I'm happy to answer questions, review code, etc.
-Barry
![](https://secure.gravatar.com/avatar/3bf5f3b29a3d68ddf11eb1a3d8c5dc65.jpg?s=120&d=mm&r=g)
On Mon, Jul 11, 2011 at 5:40 PM, Barry Warsaw <barry@list.org> wrote:
I've thought about this on and off over the years and still think it's a good idea. No, MM3 does not have such a thing yet. ... Yep
Ok, great.
but I'd like to understand the semantics first. Do messages to the list get bounced, and if so, by Mailman or the MTA? Currently, deleting a list does remove its configuration, but (by default) retains its archives, which can be deleted later. A disabled list would always have its archives available I think.
With our current setup the disabled (or "graveyarded") list is removed from the /var/lib/mailman/lists dir and the aliases regenerated, so the MTA bounces messages to it and the admin interface for it cannot be logged into. Disabled lists are listed in a separate page in the web interface to the normal listinfo page. Some disabled lists might get their archives removed and some not.
I think bouncing at the MTA is slightly sub-optimal and that mailman could generate a more informative bounce indicating how to contact the server admin to get the list revived. Probably in the web interface there could be a "disabled lists" category. Server admins would probably want to be able to login to the disabled lists in the web interface, but maybe not the list admins.
I think the core feature would not be too hard to implement, but some specifics would depend on answering the main question above. Here's an outline of what you'd probably need to touch:
Thanks for the pointers, I will try that this week.
-- bye, pabs
![](https://secure.gravatar.com/avatar/e79bca9298af0eb7bf7457054d752e6a.jpg?s=120&d=mm&r=g)
On Mon, Jul 11, 2011 at 5:40 PM, Barry Warsaw wrote:
It sounds like a lot, but I'd think it's only a day or two of work, and I'm happy to answer questions, review code, etc.
I would like to get the design right first, after reading the full thread a couple of times, some thoughts:
By bounce I meant SMTP-time rejection, sounds like the LMTP stuff provides that (and mailman 2 doesn't use that IIRC).
Temporarily failing lists were not an objective.
The design of list objects seems to be heavily similar to how the UI is in mailman 2, I think it should be much more generic.
For example:
In the web UI turning on emergency moderation should set the first item in the receive pipeline to a hold() function.
Disabling a list would set the first item in the receive pipeline to reject_disabled, set the first item in the subscription pipeline to reject_disabled, set the first item in the settings pipeline to admin_read_only etc.
List objects should be flexible to support different kinds of lists, but the UI should hide most of that behind simple labels like "retired list", "public list", "private list" and the "emergency moderation" button.
PS: Is there a Mailman UI yet? The link on the Mailman branches wiki page points to one with only one commit in it and no working code.
PPS: It seems Mailman 3 will be quite different to Mailman 2 so I'm thinking configuration filenames, data directories etc should be named mailman3 instead of mailman.
-- bye, pabs
participants (3)
-
Barry Warsaw
-
Paul Wise
-
Paul Wise