Majordomo

Majordomo is a nifty piece of perl that maintains mailing lists. The clever bit is that, once the system administrator at a site has completed the basic setup, the owner of the list, who doesn't actually have to have an account on the computer running Majordomo, can handle day-to-day maintenance via e-mail messages.

Majodomo was originally written by Brent Chapman after he got frustrated trying to compile and set up ListProc. The latest versions of Majordomo are maintained by John Rouillard.

Majordomo and its associated programs were designed with the Unix guiding principle in mind; that of using suites of small, easily understood tools to do surprisingly complex tasks; and it does those tasks remarkably well. It also makes for an easily extensible system. There are some problems, but—and this brings us to the second big advantage of using Majordomo—you can fix them yourself.

Majordomo is free. This means that you get all the source code and you can modify it to your heart's content. Not only that, but that source is remarkably well commented and easy to understand, especially considering how easy it is to write obfuscated perl code.

Of course, there are things about Majordomo that things like LISTSERV and ListProc do better—it doesn't handle large, busy mailing lists as efficiently as they do. It is, however, easier to administer (once you've got the aliases set up) than either of these, you don't have to pay for it, and it works with Linux.

First make sure you have the most up-to-date copy you can lay your hands on. This discussion will cover Majordomo 1.93, but who knows: 2.0 might be out by the time you read this. Whatever you do, don't use 1.92, since it had a rather nasty security hole. Majordomo's home site is ftp://ftp.greatcircle.com/pub/majordomo/.

You'll also need perl, at least version 4.035, preferably 4.036. Majordomo does run under perl 5.000 but it was developed (and is being developed) under perl 4.036. The site here is running sendmail 8.6.91, but things should work okay with smail, although I haven't tried it. See footnote 1.

Compiling Majordomo is easy. Just a couple of caveats:

For what follows, I'll assume you have set up a /etc/majordomo.cf which looks like this:

$whereami="yourhost.yourdomain";
$whoami="Majordomo@$whereami";
$whoami_owner="Owner-Majordomo@$whereami";
$homedir="/usr/lib/majordomo";
$listdir="/var/spool/majordomo/lists";
$digest_work_dir="/var/spool/majordomo/digest";
$log="$homedir/Log";
$mailer="/usr/lib/sendmail -f$sender";
$filedir="/var/spool/majordomo/archive";
$filedir_suffix="";
$index_command="/bin/ls -lRL";
$return_subject=1;
$majordomo_request=0;
umask(007);
@archive_dirs=();

and that the directories /var/spool/majordomo/lists, /var/spool/majordomo/digest and /var/spool/majordomo/archive exist and are owned by majordomo.majordomo with mode 775.

For this I'll assume you're using sendmail 8.6.9 (purely because that's the mailer that we use here at Frontier). If you're not using a version 8 sendmail you will need to add majordom to the list of “trusted” users that sendmail allows to spoof the sender of a mail envelope (find the T line in sendmail.cf and add majordom to the list).

As root, add the following lines to your /etc/aliases file:

majordomo: "|/usr/lib/majordomo/wrapper majordomo"
owner-majordomo: postmaster

Now assume you want to set up a list “test” with all the bells, whistles, and gongs that Majordomo provides. You'll need to add the lines shown in Listing 1 to your /etc/aliases file.

Run newaliases to make the aliases visible.

Now, su to majordomo and run the commands in Listing 2.

Edit /var/spool/majordomo/lists/test.config, set a new list password, and add a moderator if necessary. Hopefully it's all pretty self-explanatory. Copy test.config to test-digest.config and edit things like message_footer and message_fronter.

For example:

message_fronter << END
  In test today:
_SUBJECTS_
END
message_footer << END
--
To switch to the undigested list,
send this to majordomo@host.domain
unsubscribe test-digest
subscribe test
end
END

Watch out for the config sections advertise and noadvertise. These expect a list of perl regular expressions, complete with /'s. These are used when someone queries your Majordomo server for a list of lists. So, say you had a list “local-jellygarglers” which you didn't want anybody off your site to know about (and who would), you could put the following in your local-jellygarglers.config file:

advertise << END /yourdomain$/
EOF

which means that Majordomo will only mention the list in its list of lists if the sender's address is in the domain yourdomain.

The default digesting provided by Majordomo is not bad for busy lists. It waits until the digest size reaches a certain specified size (use the maxlength setting in test-digest.config to set this) then sends the digest. However, this is not a good solution if you're looking at a list which has periods of infrequent posting—especially if the majority of the lists subscribers go for the digestified version, there is the potential for a message to hang around unread in the digest queue for weeks. There are two solutions to this. The first method is to copy contrib/digest.send into /usr/lib/majordomo, editting the value of DIGESTDIR to correspond with the directory where you stash your digests, then add the line

0 2 * * * /usr/lib/majordomo/digest.send

to Majordomo's crontab file. The digest will be sent every morning at 2, no problems.

The second (and to my mind neater) method is to apply Paul Close's patch to digest and use a slightly different crontab line. The patch to digest does a couple of things. It adds the variables digest_maxlines and digest_maxdays to the list.config files. (If you do this after you've created a config file you'll need to mail the commands writeconfig test and writeconfig test-digest to majordomo so it can write out a new, valid config file again, so this is really best done before you make the config files.) These two parameters mean you can tune the digester so that a digest should never get sent with any messages older than (say) a week in it.

The patch also adds a -p switch to digest. When digest is invoked with this switch it checks to see if the digest should be sent (i.e., it checks to see if any articles in the digest are too old), and sends it out if necessary. To use this, simply change the -m to -p in the line that invokes the digest program from digest.send.

I'm assuming for this that you're going to be using rouilj's archive2.pl for your archiving work. This can be found in contrib/archive2.pl in the Majordomo source directory and it should also be linked to archive in the Majordomo home directory.

The only thing you need to do to get archive2 to work for the test mailing list is change the

@archive_dirs lines in /etc/majordomo.cf to
@archive_dirs=("/var/spool/majordomo/archive/test");

and, as they say, voilá!

Since you've set up the rules for finding a given list's archive, Majordomo itself knows that a list's files are stashed in that directory (in our case /var/spool/majordomo/archive/test), and anything in there can be retrieved by members of that mailing list (or others depending on how you've configured the list) using the get command in mail messages to Majordomo.

Majordomo neither knows nor cares about the contents of this directory. It simply returns a list of files when asked for an index, or returns the file when asked for that. These files don't actually have to be mail archives, so you can put anything there that may be of interest to the list's users. For example, we have a client who is running a play-by-mail game and he puts the files that are freely available to all the game's players within the archive directory so that his players can retrieve them using mail.

However, there is a caveat associated with Majordomo's file handling. Since Majordomo doesn't know about the contents of a file, it doesn't know if that file is a binary file. (This is a conscious design decision—if you need to do heavy duty file work Majordomo can interface with ftpmail, but that's another story.) Thus, if you want to make binary files available you will need to uuencode and split them up by hand first.

The list is now virtually ready to hand over to the list administrator to operate via mail. The only thing left to do is to create a temporary info file (/var/spool/lists/test.info) for the mailing list—this should be a short file which gives a description of the list, what it's about, who's in charge, policy, that sort of thing. If you don't know all this, just put a dummy info file in place and let the list administrator worry about setting it correctly.

Now you are ready to set up the list's first subscriber. This is usually the list's owner (the chap that test-approval and owner-list point at), in this case pdcawley@ftech.co.uk. Send the following mail message to Majordomo:

To: majordomo
Subject: This bit is irrelevant
approve foo subscribe test pdcawley@ftech.co.uk
end

where foo is the list password and pdcawley@ftech.co.uk is the owner of the list.

You should also send this user a copy of the file Doc/list-owner-info from the Majordomo source directory, which you have editted to take account of the list details (these are all set at the top of the file) so that she/he will be able to administer the list remotely without having to ask you too many questions.

Of course, if you are both the system administrator and the mailing list administrator you'll need to read this file yourself.

What do you know—Majordomo has a bunch of assorted mailing lists. I strongly recommend that you at least join Majordomo-users. To do that, send the following in the body of a mail message to majordomo@greatcircle.com :

subscribe majordomo-users
lists
end

This will subscribe you to majordomo-users and also send you a list of all the mailing lists available.