[Mailman-Users] cascaded lists -- any tips?

[Richard Barrett]

On 19 Feb 2004, at 09:24, martin f krafft wrote:

> also sprach Tokio Kikuchi <tkikuchi at is.kochi-u.ac.jp> [2004.02.19.0036 
> +0100]:
>>> This works okay until someone posts a message to A, which is to be
>>> moderated. I accept the message for A, and then am asked to do the
>>> same for B and C, then for D, E, F and then for G, H. Thus, I have
>>> to visit the moderation interface 8 times for a single message.
>>
>> You can register A address in acceptable_aliases from
>> admin/(B|C|D|E|F|G|H)/privacy/recipient.
>
> that's not my problem. i already have the above in place. but now,
> when e.g. a nonmember posts to A and I let it through. i already
> decided in A's interface that the message may pass. however, i have
> to tell all the other lists that it may pass as well. that's mildly
> annoying.
>

Maybe, but it is an inevitable consequence of Mailman's model as 
currently in use. You might be advised to look into the list archives 
for alternative approaches to your problem see, for instance:

http://www.mail-archive.com/mailman-users@python.org/msg19796.html

See below for my analysis of why umbrella lists are not the answer to 
every maidens prayer.

What you have to remember is that your lists on a given Mailman 
installation are all quasi-independent entities. It may just happen 
that an address on one subscription list is resolved by the MTA 
handling the outgoing message from the upper list in your "umbrella 
hierarchy" (note: NOT by Mailman) and redelivered by it to Mailman for 
the lower list, where it is processed again like any other incoming 
message. When the Mailman code is processing the incoming message on 
behalf of the lower list, information you want brought to bear is no 
longer available. Also keep in mind that in your case is a narrow 
subset of the problem, where you are presumably admin for both upper 
and lower lists. Your approval for the upper list posting can be 
implied to grant approval for the subsequent lower list posting but if 
you did not own both lists this might well not be the case.

The type of optimization you want does not fit well with the current 
Mailman model and, I suspect, would take a fairly untidy hack of the 
code to achieve it, and would create as . For instance, for Mailman to 
assume that it can reliably compute whether an upper list's 
subscription meber address is for delivery to another mailing list it 
is handling would be wrong; a system manager could have made valid 
changes to the alias database of the MTA so that what Mailman computed 
to be another list it was servicing was in fact supposed be handled 
entirely differently according to information the MTA has.

A proper resolution of this problem requires an enrichment of the 
Mailman model so that a list admin can add subscribers in the present 
sense and can also say "subscsribe this listname that you (this Mailman 
installation) are also supporting". The passing down of the incoming 
message from upper to lower subscribed lists could then be done safely 
and entirely within Mailman, rather than via the MTA. Rules for 
interpretation of posting/moderation/other restrictions can be 
optimised for any case including the one you are concerned with. If you 
have a week or two free I am sure the Mailman developers would welcome 
another volunteer to implement the changes.

btw: The umbrella list construct as at present is just a way of 
inhibiting the distribution of subscriber passwords for upper lists to 
lower lists in a subscription hierarchy. It works for both lists 
serviced by the same Mailman installation and for externally supported 
lists. The semantics are quite simple and not up to supporting what you 
want.

> -- 
> martin;              (greetings from the heart of the sun.)
>   \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net at madduck
>
> invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver!
>
> "we are ready for any unforeseen event that may or may not occur."
>                                                       - george w. bush
>
-----------------------------------------------------------------------
Richard Barrett                               http://www.openinfo.co.uk