> I can think of several options: > > (1) Take them from the first sublist that the subscriber appears on. > > (2) Take them from the last sublist that the subscriber appears on. > > (3) Ignore the subscriber options but apply the Default-options from > the superlist. LISTSERV takes the options from one of the sub-lists that the subscriber appears on and that qualifies the subscriber for receiving the message. That is, LISTSERV first ignores subscriptions which would not lead to the message being delivered to the recipient (for instance because the topics do not match). From the remaining sub-lists, it picks one as close as possible to the super-list (ie a first-level sub-list pre-empts a second-level one). NOMAIL subscriptions disqualify the sub-tree under the NOMAIL list for purposes of supplying subscriber options (and selecting the subscriber as a recipient), but are pre-empted by non-NOMAIL subscriptions at the same level. Given that any list can potentially be the sub-list of any other list(s), there is no easy and intuitive way for a user who does not know anything about the details of the sub-list structures implemented by the list owner to understand where the options come from. The users will typically know which sub-list(s) they are on, but may not even have known that the super-list existed until they received their first message and wondered what this list is and why they have been subscribed to it! The most popular super-list setup has a depth of one (ie you have one or more super-lists which each point to a number of sub-lists that are normal lists with no further sub-lists), in which case the user cannot predict which sub-list the options were taken from, as it depends on the order in which the list owner happened to list them in the super-list. Besides, the sub-lists in question are generally similar (dept. of X, dept. of Y and so on) and there is usually no logical choice for a "better" list to get the options from. Finally, if you leave list X, your options will be taken from list Y and your subscription to the super-list will effectively change, even though you still receive the messages. The only way for the process to be intuitive to users who may have a hard time understanding the concept of recursion is for them to be subscribed to the super-list. In this case, the options are always taken from the super-list (there is no other list at the same depth) and things are simple and straightforward. Another way of course would be for each user to be subscribed to only one sub-list, but usually the reason super-lists are used is that this is not the case and duplicates are undesirable. > The current situation, in which there is no control over subscriber > options, seems the least ddesirable. The REPRO option does not work because the fate of the REPRO copy is decided before the sub-lists are scanned. The procedure that reads the lists and decides who gets the message is provided with a list of addresses that should be skipped, and this will include the sender's addresses unless REPRO was previously detected. REPRO does have a strange implementation, but this is not really the problem. Options like NOPOST or REVIEW also operate long before the mailing is prepared and the list of recipients is extracted, which makes a lot of sense since this is a resource-intensive operation and it would be silly to abort it when you suddenly realise that the sender has NOPOST after all. The current super-list implementation cannot consistently apply recursive options to the sender. This may be solved in a future version by doing two passes on the super-list structure, but currently only the top-level list is searched for a subscription entry. Eric