In his first article on installing and configuration mail servers, " Building a High-Volume Newsletter Server ," Steven covered Majordomo, one of the most popular command-line mail servers available. In this follow-up article, he looks at Mailman, a GUI-driven utility that makes newsletter administration easy.
Mailman is the free software contender to mail-server products such as Lyris, which feature GUI-driven administration, user-level access to preferences, and built-in archives, digests, and the like. Based on the popular Python programming language, Mailman is intended to be used on UNIX systems, and can be installed alongside Majordomo on the same server, without conflicts. It has a few notable weaknesses, like that it can't easily be made aware of virtual hosts (although with a good dose of Apache configuration and some virtusertable tweaks it could probably be made to work.) I won't discuss that in this article, however, so let's not dawdle.
To install Mailman, first ensure that the Python interpreter is installed on your server, as Mailman is written in the Python language. You'll need at least version 1.5, although 1.5.1 is recommended, as Mailman expects certain advanced features not present in earlier versions of the language. Download the Mailman 1.1 source from the Web site and unpack it into a temporary directory (such as /usr/local/src). This won't be your final destination directory, so just put the files somewhere where you can delete them later. If you're on a Linux system or a system running GNU tar, you can just type tar xvzf mailman.tar.gz and it will unpack the distribution. On other systems, you may need to use gunzip -c mailman.tar.gz | tar -xvf - .
Once the distribution is unpacked, take a look at the main README file, as well as any other READMEs particular to your choice of platform and mail transfer agent. I use sendmail as my transfer agent and will cover that here, but if you use qmail, be sure to read the README.QMAIL file. You do not need to be the root user to install Mailman. In fact, the documentation insists that you be a normal user during installation.
For the next step, you'll have to create a new UNIX user called mailman and set the appropriate permissions. Start by creating the mailman user account and then add a new group called mailman to your system. These tasks do require extended privileges, so if you don't have the appropriate access to do this, ask an administrator to set this part up for you. When you're ready, choose a directory for the user. This is usually /usr/local/mailman or /home/mailman and it's important to remember that this directory is also where you will install the Mailman files. Set the appropriate permissions for the directory as follows:
cd /usr/local/mailman chgrp mailman . chmod a+rx,g+ws .
If you take advantage of the GNU autoconf facility, configuring Mailman is a piece of cake. You may need to customize your installation, though, especially if you've chosen a non-standard installation directory. I recommend that you use the --with-mail-gid , --with-cgi-gid and --with-cgi-ext switches at the very least, to ensure that the group IDs you've chosen above match those expected by Mailman. You should also ensure that your Web server can run the Mailman scripts via CGI, and that the scripts are properly installed with a ".cgi" extension if that is required by your local Web server policy. When you've determined which switches you need, just run ./configure from the UNIX command prompt (with the appropriate switches tacked on to the end.) And when the configuration is complete, run make install from the prompt.
When the make is done, navigate into the Mailman installation directory you specified earlier. As with Majordomo's wrapper config-test utility, you can check the installation of Mailman by running bin/check-perms from the UNIX prompt. Fix any problems that are reported before you proceed, either by reinstalling (potentially after running configure again) or by running bin/check_perms -f . The latter command will actually attempt to fix any problems it encounters, rather than simply reporting them. You may need to run it a few times.
Because much of Mailman's power is in its GUI-driven administration facility, you now need to configure your Web server, or a virtual host on an existing server, to support Mailman's CGI tools. We'll use the Apache Web server as an example. The lines you'll need to add to your srm.conf file are shown in Example 1 . You will need to restart your Web server when you're done to ensure that the changes take effect.
If you want to advertise your support of free software by displaying the Mailman logo in your messages, you can also create an /images/ subdirectory inside the htdocs/ subdirectory. Copy the provided Mailman logo file to that new directory, and be sure to name it mailman.jpg. To set the Mailman configuration so that it knows where to find the image, add the following line to your mm_cfg.py configuration file found in the Mailman installation directory:
DELIVERED_BY_URL = '/images/mailman.jpg'
In case you already have an /images/ subdirectory and a graphic named mailman.jpg that you don't want to overwrite, you can rename the Mailman logo graphic file to anything you want. Just be sure to change the DELIVERED_BY_URL line accordingly.
After you've installed Mailman and configured and restarted your Web server, you will need to add a few cron jobs and set up a few email aliases for trouble reports. To add the cron jobs, simply become the mailman user and import the cron jobs by entering the follow commands at the UNIX prompt:
su - mailman crontab /usr/local/mailman/cron/crontab.in
The aliases should be a piece of cake if you've read this far into the article. Simply add the following to your /etc/mail/aliases file, making adjustments as necessary so that the mail actually goes to the maintainer of the Mailman server:
mailman: postmaster mailman-owner: mailman
On a small system, this may well be the Postmaster, so feel free to use that address (if you're the Postmaster.) When you're done, don't forget to run the newaliases command to make your changes take effect.
Setting the system-wide password is the second-to-last step before you go to the Web interface to configure and customize your Mailman list. To set the system password, run the following command:
Specify the real password instead of mypassword , of course. This password may be used to override any normal user's password, if something gets badly out of joint and needs to be fixed.
Creating a List
Creating a new list is easy in Mailman, though at present it can only be done from the command line. Navigate into the Mailman installation directory and pick a name for your new list. You will need to decide on the list name, the email address of the list owner, and the list administrator's address. When you have all this down, run bin/newlist from the command line, and follow the instructions that appear. This program will create the necessary links and configuration files. It will also email the list owner a set of instructions on how to manage the list, including the default list password. Finally, the program will print out a set of aliases to be added to the sendmail aliases file. Copy and paste these into your aliases file, then run newaliases to ensure that they take effect. In my experience, you want to check that the aliases are working before proceeding, by testing one of the aliases before answering the newlist prompt. To test an alias, run sendmail -bv example . You should see some output similar to the following:
"|/usr/local/mailman/mail/wrapper post example"... deliverable: mailer prog, user "|/usr/local/mailman/mail/wrapper post example"
If you don't, run newaliases again, or double check the aliases file to make sure you've copied and pasted everything correctly.
That's it! Just follow the directions in the email you receive from Mailman after you create the list, and enjoy the ease of GUI mailing list management. If you have problems, rest assured that someone else has already experienced them and probably has some solutions. Check the documentation, which includes extensive troubleshooting tips, or the FAQ, which also addresses many common (and some not so common) problems.
If you're serving multiple domains off the same machine, you'll have to make some adjustments to get Mailman to recognize the virtual hosting environment. This can get a bit tricky, because you'll need to make up your own virtusertable alias entries based on those Mailman gives you. Let's create a new list and walk through the required tweaks. First, run bin/newlist . When you are asked for the name of the list, call it wtexample . The person running the list will be email@example.com and the initial password is fidget . The program will then output aliases similar to that in Example 2 .
Copy and paste these entries into the appropriate aliases file (I use /etc/mail/mailman.aliases, and specify it as one of the alias files in my M4 macro configuration for sendmail). Before acknowledging the newlist prompt that sends a notification to the list owner, be sure that you create the appropriate entries in the virtusertable.aliases file for each of the regular aliases provided. The entries are shown in Example 3 . Run whatever command your system requires in order for the virtusertable to be regenerated. This is often as follows:
makemap -v hash /etc/mail/virtusertable.db < /etc/mail/virtusertable.aliase
Then check the new aliases using the sendmail -bv firstname.lastname@example.org command. Then, and only then, acknowledge the newlist prompt.
The list owner will receive a notice via email from Mailman, containing a summary of the new list's administrative information, password, URLs, and so forth. Here's where things get tricky. We're going to set up a virtual host on a Web server such that your users can access the Mailman tools via that server. The tricky part is that the Web server needs to be running with the same group ID as Mailman expects (see what I said about the --with-mail-gid extension earlier). Once that has been changed, you will need to go to the Mailman Web interface and make a couple of small changes. First, visit the URL in the email received by the list owner. This will bring you to a page containing the general options for the Mailman installation. Modify the last two settings — "Host name this list prefers" and "Base URL for Mailman Web interface" — to reflect the domain under which your Mailman installation and Web server are hosted.
The only problem with this approach is that it only works if your mail server thinks it is on one domain, and your Web server thinks it is on another. As of the latest version of Mailman (which is 1.1, although the 2.0 beta was recently released), there is only one way for Mailman to host lists for multiple domains, and that involves installing the package once for each domain. (Here's a tip: use directories such as /usr/local/mailman/domain1 and /usr/local/mailman/domain2). This restriction is enforced because the "Base URL" discussed above is a system-wide setting, and changes to it affects all lists managed by that package. At best, it's annoying. At worst, it can confuse the daylights out of your users, as the setting affects the URLs sent out in monthly password reminders, among other things. Mailman is perfectly happy running via CGI under multiple Web servers, but the basic support for multiple independent virtual domains is lacking for now.
Having done all that, you should be set, with a new and powerful GUI-driven mailing list manager just waiting to do its thing. Be sure to check out the extensive administrative interface, where you can modify the list configuration to your heart's — and your users' — content.