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 or switch to an SQL server-based system (see ezmlm support for SQL databases), 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
As you can see, the entire ‘edu’ domain is handled by ‘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
Next, split the subscribers of sub5@what.org into these 2 groups, as detailed in the ezmlm-split(1) man page. Create the two new lists, add the respective subscribers, and replace the ‘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.