[Mailman-Users] umbrella lists

[Jon Carnes]

On Thu, 2003-10-23 at 10:14, Dave Stern - Former Rocket Scientist wrote:
> We've had probs with nested lists in the past. I think the issue had to do
> with private lists (ie only members can post) for both the sublist(s) and
> the umbrella list. If set, how could a member of a sublist post to the
> umbrella list unless either the umbrella list was unrestricted or the
> user was also on the umbrella list?

A user does not have to be a member of a list to post.  Posting
privileges can be added either individually or via a regular expression.

I generally go the route of hourly sync's to do "master" lists formed
from sub-lists, so that isn't a problem I deal with regularly.

>  As I understand it, an umbrella list
> should *ONLY* be a list of lists and have no users. But that still wont
> allow a sublist member from posting to the umbrella, right?   So one
> option we've entertained is to wipe and rebuild superlists each night
> (ie dump sublist member addresses, wipe and reload them into superlist
> instead of having nested list). This also makes employee-exit procedures
> harder (how to find all lists a person is a member.

Nope.

Look at the "remove_members" command in Mailman.
  --fromall
    Removes the given addresses from all the lists on this
    system regardless of virtual domains if you have any.
    This option cannot be used with -a/--all.  Also, you
    should not specify a listname when using this option.
 

>  I wrote a script that
> lists_lists and recursivesly list_members and greps, kinda slow for many
> lists.   OTOH, superlists guarantee someone isn't on two sublists and thus
> gets two iterations of lists.
> 
You also might want to look at the "find_member" command.

> What have others done on this issue?
> 
> Another concern is; what happens if someone sends to a superlist during a
> list rebuild? Is sync_members robust enough to at least always keep one
> list of addresses around?

No problems.  Lists are "locked" during changes, so the sent email will
simply be queued until the lock is removed.

Hope that's helpful - Jon Carnes