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.

______________________

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState