Majordomo

Want to set up your own mailing list? Piers Cawley takes you step by step through the process of creating a proper mailing list with 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.

Why Majordomo?

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.

Fetching the Source

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/Installing Majordomo

Compiling Majordomo is easy. Just a couple of caveats:

  1. Majordomo expects perl to be in /usr/local/bin/perl

  2. As it comes out of the box there is a bug which causes Majordomo to read in the config file twice, once from /etc/majordomo.cf and once from $homedir/majordomo.cf. This is easily fixed though; simply remove the line: require `majordomo.cf'; from config_parse.pl.

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.

Configuring Basic Aliases

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.

______________________

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix