Umbrella lists - why don't they do what I want?

For example, say you have set up the following mailing lists:

1. Three_Blind_Mice: Minnie@farm.org, Mighty@cartoon.net, Mickey@disney.com



2. Three_Bears: Smokey@usda.gov, Little@pbs.org, Momma@mgoose.net



3. Three_Men_In_aTub: Rub@tub.org, Dub@tub.org, Little@pbs.org

You can create an Umbrella List called, Threesomes and instead of email addresses of people, it will contain the email addresses of the list names above.

When you send a single email to Threesomes@mylists.com, a single copy of that message is sent out to each of the individual lists (Three_Blind_Mice@mylists.com, Three_Bears@mylists.com, Three_Men_In_aTub@mylists.com).

Each of these lists will then send out a copy of that message to the email address of each subscriber in that respective list.

The result is that a single message sent to the Umbrella list is on-sent to every subscriber in each of the sub-lists.

• Some listservers (including Mailman) prepend multiple list names and signature lines in the final message.



• When a list owner needs to approve a posting to an umbrella list, they also have to approve th posting for each sub-list.



• Where archives are kept, messages posted to umbrella lists are archived in multiple locations.



• When a listserv sends out a monthly password reminder, it sends an email to every person in its lists. If it did that for the Umbrella List "Threesomes", then it would treat "Three_Blind_Mice" as an ordinary user. Mailman would send an email to "Three_Blind_Mice" that contained the password for subscribing or unsubscribing it to the list "ThreeSomes". Everyone on the "Three_Blind_Mice" list would receive the password - which would allow any of them to unsubscribe ALL users from the list.... which may be fine in the case of Minnie and Mighty, but Mickey has been known to do a few silly things in his time!
  
  You can keep Mickey from getting the password by telling Mailman to send this type of information to "Three_Blind_Mice-owner" instead of to "Three_Blind_Mice". This relies on correct list configuration (activationg the "-owner" option in the umbrella list settings).
  
  By making "Threesomes" into an Umbrella List, you can tell Mailman to add "-owner" to any notices, confirmations and passwords that it sends out to list members.

If a message is sent to an Umbrella list and a user is on multiple sub-lists under that Umbrella list, then they will receive multiple copies of the message - one for each of the sub-lists that they are on. In the example above, Little@pbs.org would receive two messages everytime someone sent an email to "Threesomes".

As a result it is also possible that mail loops may be created due to external mail alias configuration beyond the control of the list admin!

If your subscribers are likely to be subscribed to multiple sub-lists, then Umbrella lists should be avoided if possible. If your subsribers will not be subscribed to multiple sub-lists, then using a conventional Umbrella list is probably still a good option as admin is easy.

Parent Lists:
The alternative to using standard Umbrella lists is to setup a script that builds a "Parent" list out of other "Children" (sub lists) on your server. The result is the same as using an umbrella list but it avoids some of the problems.

Using the above example, the subscription lists for Three_Blind_Mice, Three_Men_I_aTub, and Three_Bears would be processed and combined to form the membership list for a separaete list called "Threesomes". Three_Blind_Mice etc are NOT subsribed to the new list. Threesomes then becomes a "Parent"list, NOT an Umbrella list. Threesomes is an ordinary list in every way except its membership is taken from the children lists. Members subscribe or unsubscribe from the "Children" and this is automatically updated on the Parent list.

This is done to ensure that only a single copy of each unique message is sent out to each actual user, regardless of how many lists that user is on.

The easiest way to process and combine lists is if the sublists share a common but unique key in their list name. In the above example, this would would be the key "Three_" (each sub-list contains the expression /Three_/).

The following script illustrates how a subscriber list is taken from a number of sub-lists which include the key "saas". The membership from the sub lists is processed and used to create a subscriber list for the parent "SAAS_All" list. Messages are sent to all subscribers by simply posting to "SAAS_All"! Messages can still be sent to individual sub-lists when appropriate, and members may subscribe/unsubscribe themselves from sub-lists in the usual manner.

Problems With Parent Lists
Subscription and automated removal of invalid (bounce) adresses may need to be performed manually by the list administrator unless subscribers are aware that they must subscribe / unsubscibe from respective sub-lists, not the master!

Example script follows:

#!/bin/sh
#
# Process specified sub-lists and create a master subscriber list for parent
# SAAS_All@example.com mailing list

# The list includes everyone on a SAAS mailing list.
#  - All the sub-lists we want start with the word: "saas"
#  - Addresses for members of the Parent/Umbrella list itself must be EXcluded
#  - (to avoid infinite loop)!

# Create an empty file...
#
# echo " " >/tmp/build_list
touch /tmp/build_list

# Dump out all lists names that contain the word "saas" (case insensitive)
#  - BUT,  DO NOT include the "_all" list, since that is the list that we
#  - are re-creating with this script!!!
#
LISTS="`~mailman/bin/list_lists |grep -i saas | \
    grep -vi _all| awk '{ print $1 }'`"

   for i in "$LISTS"
   do
    # dump all user addresses from all saas lists to the file...
    ~mailman/bin/list_members $i >>/tmp/build_list
   done

# Sort the list and remove duplicate entries
#
cat /tmp/parent_list |sort -u >/tmp/process_list

### the above step is really unnecessary as "sync_members" already 
### does this automatically - still I like a clean orderly list...

# Feed the list of all saas users into the "_all" list
# - Note: You should turn off welcome messages for this list.
# - "saas-all" is the actual name of the mailman list
# 
~mailman/bin/sync_members -f /tmp/process_list saas_all >/dev/null

# Clean up the mess...
rm /tmp/build_list
rm /tmp/process_list

# Have cron run this script hourly and the "saas_all" list
# will be updated automatically every hour.
# ==EOF==

Kudos to Mark Merlins, Jon Carnes, and Shane Beasley for the above work-around.
Docs modified and updated Roger Buck 25 JAN 01:37:17 2002

Removing Excessive Headers
The following is taken from Bob's Unofficial Mailman Tips and Tricks.

Mailman conforms to all the latest RFCs regarding information that should be contained in the message headers... and there are plenty of them!

Despite the reassurance gained from being correct, it can be annoying scrolling through a page and a half of headers: Here's how to remove them:

1. Find the file called CookHeaders.py.

This should be located in: /var/mailman/Mailman/Handlers

Make a copy of this file, and call it something like CookHeaders.py.orig So you have a backup if things don't work!).

Note: you'll also see a .pyc file.  This is the compiled version of the file; but don't worry - when Python goes to run it, it will see the newer timestamp on your edited file, and re-compile it automatically.

2. Edit CookHeaders.py with your favorite editor.

Somewhere around line 116 (in version 2.0 final, at least), you'll see where the headers are added.  Simply delete each line.  Be careful not to upset the formatting - the indentation is important.

You can safely remove:

• List-Unsubscribe, List-Subscribe, List-Post, List-ID, List-Help

Site Menu
home
about us
projects
clients
solutions
training
feedback
search
schoolRadio
bookmark