[Mailman-Users] cascaded lists -- any tips?
r.barrett at openinfo.co.uk
Thu Feb 19 12:09:11 CET 2004
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
>>> 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
> 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
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:
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
> 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
More information about the Mailman-Users