We use Pete's "common listowner" technique on occasion, but a cousin of that in the form of sub-lists much more frequently.
For example, we have a number of lists which have a client-facing super list and a back-end sub-list. The sub-list subscriptions are periodically refreshed/replaced, while the client-facing list has permanent subscriptions, exceptions, ... and where all posts are made. (While some of these sub-lists will be discarded in favor of database/ldap queries, the model will still fit a good number of lists for us).
One problem with this model is there is no perfect answer for exceptions to the refreshed set of subscriptions. Say, for example, we get a request to terminate a subscription. This means we *add* a subscription to the super list and set it to "nomail". If the "subscriber" learns one of the Listserv ways to unsubscribe, and sends it, there goes the entry that stopped his distributions. Most people don't want to understand that their subscription is really an unsubscription ... they just want off the mailing list. For this to work better would require Listserv to have a subscription flag "unsubscribed" ... with unsubscribe setting this flag instead of deleting the subscription (I think!).
Another problem with this model ... or any model that includes refreshed or query subscriptions is how to implement "unsubscribe me from all mailing lists NOW!" requests. While a site-wide unsubscribe works for static, normal lists, it's only temporary for refreshed and query lists.
LSoft implementing an "unsubscribe flag" would allow me to create a sub-list of addresses, all with the unsubscribe flag set on. We could then use this sub-list wherever we wanted to honor an "unsubscribe everywhere" request, from the subscriber or HR department or whomever.
Summary: I've included 2 list types ... (1) sub-lists that are back-office and never posted to directly, and (2) unsubscribe lists (which don't exist to my knowledge with current Listserv capabilities).
Cheers, Wayne
On Tue, Jan 31, 2012 at 10:51 AM, Paul Russell
<[log in to unmask]> wrote, in part:
On 1/31/2012 09:47, Pete Weiss wrote:
This technique is useful in the management of organizational lists (been there ... done that) -
A common list-owners list this is used to indirectly reference a common set of lists' owners so that
when the common lists' owners change, each individual list need not be updated, just the common list e.g.
Call list C, th list of related lists' owners composed of the following subscribers:
address1@host1
address2@host2
address3@host1
Further, define list headers for lists X, Y, Z
OWNERS= (c)
Thus when an owner is added (or removed) for lists X, Y, Z, only the subscriber(s) from list C must be
altered.
We make extensive use of this technique. We use the same technique to define common sets of list editors (people who can post, not people who moderate).
We use this technique to provide our permanent full-time Help Desk staff with owner-level access to most lists hosted on our LISTSERV servers (2 servers, ~50K lists). This makes it much easier for Help Desk staff to provide assistance to list owners. The Help Desk staff has been instructed to "look but don't touch" without the list owner's explicit knowledge and permission.
To unsubscribe from the LSTOWN-L list, click the following link:
http://peach.ease.lsoft.com/scripts/wa.exe?SUBED1=LSTOWN-L&A=1