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)
>>
>
> Correction: Owner= (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:
write to: mailto:[log in to unmask]
or click the following link:
http://peach.ease.lsoft.com/scripts/wa.exe?SUBED1=LSTOWN-L&A=1