A sublist is a list that receives its input from another mailing list, rather than from users directly. The sublist is just a regular subscriber of the main list. A sublist in e.g. Tasmania is very useful since only one message is sent from the main list and then the sublists servers all subscribers in Tasmania. Bounces and all administration is handled locally. The local sublist can have a digest, even though the main list may not. (See How sublists work for more info on how sublists work).
To set up a sublist to an ezmlm list, just use the
ezmlm-make ``-5 mainlist@mainhost'' switch. This will configure your list
as a sublist to the mainlist@mainhost mailing list.
To set up a sublist to an ezmlm list, just use the
ezmlm-make ``-5 mainlist@mainhost'' switch. This will configure your list
as a sublist to the mainlist@mainhost mailing list. Since the
main list may not use the ``Mailing-List'' header, you must identify another
header that the main list adds to all messages. See the ezmlm-reject(1)
man page for examples. Next, edit DIR/editor of your sublist and add
a ``-h Listprocessor-Version:'' option to the ezmlm-send(1) line, but
replacing ``Listprocessor-Version:'' with your mainlist header.
Now your list will accept only messages from mainlist@mainhost
and with the header specified.
ezmlm-0.53 allows sublists. The difference between a sublist and a main list is that the sublist requires that the SENDER of the message is the main list and that the message has a ``Mailing-List:'' header. Sublist messages have their own subscriber database and subscription mechanism, and use their own message number. This is very convenient if you want to create a private sublist. Since the subscribers have to interact with the appropriate sublist, it is difficult to administrate if you want to use it to distribute the load of a very large list, since users will have to address administrative requests such as unsubscribe to the correct sublist. Also, bounce messages refer to the sublist archive with sublist message numbers.
ezmlm-idx modifies this in several ways: First, the message number of the incoming message is used also for the outgoing message so that subscribers see the same message number no matter which sublist they get it from. For security reasons, this is enabled only if the sublist is NOT ARCHIVED. With this feature, bounce messages can refer the user to the main list archive instead, obviating multiple archives.
Second, ezmlm-split(1) can be used to forward administrative requests sent to the main list, to the appropriate sublist. Thus, subscribers interact only with the main list, and do not need to know which sublist that servers them. With bounce and administrative messages referring them to the main list, subscribers will usually be unaware of the sublisting.
To set this up:
ezmlm-make dir dot local host
Before the ezmlm-manage(1) line in DIR/manager add:
|/path/ezmlm-split dir
The main list sends to sublists and to any addresses not covered by the split table. You can split the load by domain (``geographically''), and any domain (including '') can be subdivided by ``hash'' by using different parts of the 0-52 range. Of course, you can also use hash alone. The request will go to the first row that matches, so although overlaps are not advisable (in case you later want to add sublists of switch to an SQL server-based system (see sql )), they have no negative effects. The domain for ezmlm-split can be the last TWO parts, i.e. ``edu.wustl'' to handle all *.wustl.edu subscribers. This is useful, but remember that the SQL version supports only one level.
An example:
domain:hash_lo:hash_hi:sublistname
edu:0:52:sub1@here.edu
com:0:26:sub2@there.net
com:27:52:sub3@some.com
:0:13:sub4@what.org
:14:39:sub5@what.org
sub1@here.edu.
The ``com'' domain is about evenly split between sub2@there.net
and sub3@some.com.
Everything else is split so that approximately 1/4 goes
to sub4@what.org,
1/2 to sub5@what.org and the rest falls through, i.e. is handled by
the main list.
Why are there 2 sublists on the same host? This is in preparation of adding
a host. It easy to just move the entire sub5@what.org
list to a new host.
All we have to do it to set up the new list, copy over the subscribers,
and change the name in the split table entry.
To split the split the sub5@what.org load onto 2 lists
requires a little
more work. First, create a dummy split table in a directory ``temp'':
:14:26:new1@new.net
:27:39:new1@other.net
sub5@what.org line with
the two lines above.
To add a totally new domain, e.g. jp:0:52:sub6@niko.jp requires
collection or subscribers from all lists that currently handle these
subscribers, (the ones with blank domain in the example), re-splitting
them, and adjusting the subscribers. Easiest here is to just unsubscribe
the sub6@niko.jp subscribers to be from the other
list with ezmlm-sub(1).
Since that program will silently ignore any addresses that are not on the
respective list, it will work fine.
Use ezmlmsubrc which sets up a minimal non-archived sublist with bounce texts pointing to the main list:
% ezmlm-make -Cezmlmsubrc -3mainlocal -4mainhost \
DIR dot sub1local sub1host
If you forget, the sublist will not get any messages to distribute. Add these addresses with ezmlm-sub(1) as subscribers to the main list.
A strong point of this system is that it is relatively simple and that only a fraction of the addresses are available to any given sublist. Thus, compromised security at a sublist threatens only the addresses and functions handled by that sublist.
As you can see, this works quite well, but it's not trivial to change the setup. If you modify it while the list is running, some subscribers may get duplicate messages or miss messages. Therefore, you should disable deliveries to the main list before the final step of the changes (removal of subscribers from old lists and adding new lists as subscribers to the main list). For most lists, this should work flawlessly, and some minimal planning and extra lines in ``split'' can markedly facilitate future expansion.
Another weak point is the authentication of messages between list and sublist. The requirements the sublist places on the message can be easily faked. This allows injection of messages at the sublist level as a way to circumvent moderation or other access control.
An associated disadvantage is that not even the main list has access to all the addresses. Thus, SENDER checks for archive access (relatively secure) and posts (relatively insecure) cannot directly be used. Also, sublist cooperation is required to determine the number of subscribers, or to access subscriber addresses for a purpose other than distribution of list messages.