[Mailman-Users] Untangling an unruly jungle of lists

[Mark Sapiro]

mailmanu-20100705 at billmail.scconsult.com wrote:
>This has left me with 4 questions:
>
>1. Am I correct in my understanding that regular_include_lists does a 
>de-duplication of the aggregate of all included lists?


Yes.


>2. Are the direct subscribers to the parent list included in the 
>de-duplication? In other words: could I have left the direct subscribers in 
>place without causing duplicates?


Yes.


>3. Since regular_include_lists is part of the non-digest settings, what 
>exactly does a member of one or more of the included lists who is set to 
>digest mode get when the parent list is mailed?


Nothing.


>4. Are there non-obvious aspects of the regular_include_lists feature that I 
>should be aware of, i.e. anything that argues in favor of using a script to 
>assemble and de-dupe a membership list for it instead?


Bounce processing currently doesn't work for members of the included
lists if a post from the the parent list to a member of an included
list bounces. This is fixed for 2.1.14 and the fix is committed at
<http://bazaar.launchpad.net/~mailman-coders/mailman/2.1/revision/1250>.

As I answer above, digest members of included lists don't receive a
message at all. However if someone is a digest member of one included
list and a regular member of another included list, she will receive a
copy of a post to the parent.


>To handle the mailings to arbitrary sets of overlapping lists, I gather that 
>regular_exclude_lists is the tool to use, but I am not sure exactly how to 
>build the configuration. I have a set of 21 lists that have some users in 
>common with 2-17 others members of that set. To evade the complexity of that 
>setup, I'm starting with a set of 4 that the customer has cited as 
>particularly problematic, and I think what I need to do to get 
>cross-mailings to arbitrary combinations of them de-duped I need something 
>like these regular_exclude_lists:
>
>list1: list2, list3, list4
>list2: list3, list4
>list3: list4
>list4: (empty)


I think that is correct.


>So, if I really want to de-dupe arbitrary cross-mailings between all 21 
>lists that have common members, I'd have to put lists 2-21 in for list1, 
>3-21 for list2, etc., and if the customer wants a new list that might 
>overlap, it would need to get all of the existing lists in its 
>regular_exclude_lists.  Ugh. The questions I have about this:
>
>1. Is that config correct?


Yes, I think so.


>2. Is there any useful basis for ordering the 4 lists I am making siblings? 
>Should I make the biggest one list1 and the shortest list4 or should I order 
>them based on the degree of overlap  or something else?


I don't think it matters in any significant way. However, the addition
of a list is simplified if you add it to the "top" as that won't
require changing the other lists.


>3. Does setting regular_exclude_lists have any effect on how lists are 
>handled as members of another list's regular_include_lists?


No.


>4. Has anyone devised an easier and less fragile approach? Maybe for Mailman 
>3? What I'd like most is a simple setting to have Mailman look at each 
>message for other lists in the same domain or handled by the same server and 
>work out the de-dupe cascade itself as needed.
>
>More broadly and philosophically, I am curious about how others handle 
>similar list jungles. My first instinct is to decree that there shall be a 
>sane hierarchy of parent lists with regular_include_lists such that there 
>shall be no need to cross-post, but that seems a bit unrealistic at this 
>point. Any helpful clues?


I have an installation where there is a large, general list and a few
smaller, more specific lists. I have the more specific lists in
regular_exclude_lists of the general lists.

This generally works OK, but there are some issues.

One person who is a member of multiple lists wants the duplicates. The
solution here was to subscribe to the different lists with 'variant'
addresses. This may not work for MM 3 depending on how this feature is
implemented there.

A more serious problem is when list1 excludes list2 and someone who is
a member of only list1, does a 'reply all' to a cross-posted message
and this reply is rejected by list2 as a non-member post. In this case
members of both list1 and list2 do not receive the reply. They don't
receive it from list1 because they are members of list2 and they don't
receive it from list2 because it was rejected by list2. For this
reason, I implemented a setting "regular_exclude_ignore, Ignore
regular_exlude_lists of which the poster is not a member." This
doesn't address other possible reasons why a post might not be
accepted by list2, but it does address the most common one, although
it can result in duplicates if the non-member post is actually
accepted by list2.

This setting is not implemented on the 2.1 branch for i18n reasons, but
it is available on the branch at
<https://code.launchpad.net/~mailman-coders/mailman/2.2> which is
essentially the 2.1 branch with the addition of a few features that
won't be in 2.1, mostly for i18n reasons.
	
-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan