Listserv to Mailman Part 1.1: Installing Mailman

Installing from Source

This page describes how I installed Mailman from source on our development server (a shared web hosting environment). However, it’s also possible to install through a binary package manager such as RPM or Apt, which is actually how our list host admins installed it onto our production server. So things might end up in different locations depending on how Mailman is installed.

Choosing a Version and Downloading

My first question for installing Mailman on our dev box was which version. This mattered because we had not yet chosen a list host but I assumed that whatever host we ultimately chose would probably have the latest stable and mature version.

Figuring out the latest stable and mature version of Mailman turned out to be a bit challenging. By examining the “timeline” graph at (specifically, by hovering over the graph and hitting the little magnify-minus sign several times so I could eventually see all the way to the right), I found that at the time of checking (early Dec 2009), version 2.1.12 was the latest stable version since it was the most recent on the 2.1 “latest stable release” line.

I tried to download mailman-2.1.12.tgz from several times, but it never worked, so I finally downloaded it from;O=D

(Both of the above download sites were found on the main Mailman site at

Installing Mailman to a Custom Directory

I’ll skip past the usual technical details of downloading and unpacking files (I did it from the shell command line with: wget and then: tar xvfz mailman-2.1.12.tgz).

In fact I wouldn’t even mention the installation process except that my first attempt failed because the web host I was using (which is not the one I am happily using now, Dreamhost) had pre-mapped the /mailman URL for me, and it resisted any attempts to override/fix it.

This was a problem because when I first installed Mailman on our dev box, created a test list (with the newlist command), and then tried to go to something like it told me there was no such list—even though I had just created it. I banged my head against the wall for a while until I figured out that my web host had pre-mapped /mailman and that there was no way around it.

(If you want to see if your web host has done this, I recommend going to before installing Mailman, and seeing if you get the same error page as when going to or if you get some unexpectedly-different page instead.)

So eventually I had to delete that first installation and install again into a different directory with the following options:

./configure --prefix=/home/ouruser/public_html/mm
--with-username=ouruser --with-groupname=ouruser
--with-mail-gid=ouruser --with-cgi-gid=ouruser --with-cgi-ext=.cgi

(I had to use the –prefix option, rather than accepting the default installation location, because my dev box was a shared hosting environment where I was just a regular user, rather than having root/admin permissions and being able to install into system directories like /var/mailman.)

After running configure and make install I then created a test list by running the mailman “bin” program newlist test-list (in ~/public_html/mm/bin). Then I tried going to and things seemed to work fine until I tried to log in, at which point the fact that Mailman insists on setting cookies with a Path of /mailman caused my logins to not “stick”.

I thought this would be easy to fix by editing the cookie set by Mailman from /mailman to /mm, but it turned out that most of the cookie-related add-ons for Firefox do not allow you to edit cookie values.

The Add N Edit Cookies Firefox add-on seemed promising, but when I edited the Path value of the cookies set after logging in to Mailman, to change from /mailman to /mm, it didn’t actually save the changes. But I figured out a workaround: copying the cookie values for the old login cookie (Name, Content, Host, Path, Expires) to a temp text file, deleting the cookie, then creating a new cookie with the same values except a different Path (and plus 20 years for the Expires value too).

All these machinations were just to deal with having to install Mailman to /mm instead of /mailman on our dev box because the web host had pre-mapped /mailman for us and we couldn’t override it. Hopefully you won’t have that problem at all; I highly recommend just installing using the defaults if you can!

For more information about installing Mailman see the official GNU Mailman Installation Manual. There’s also a helpful page covering more technical aspects of installing on various flavors of Linux (including the easy way of just installing from an RPM or YUM package) at the YoLinux Tutorial: GNU Mailman Email List Installation and Configuration.

Testing the Installation

If you’ve installed Mailman into the default /mailman and used newlist to create a “test-list”, you should be able to use the following URLs to check if your installation is correct:

  • for info about the test list
  • for admin pages about test list
  • for info on all lists on the server

If you had to install Mailman to a custom directory like /mm and/or use a custom CGI file extension like .cgi, then you’d want to use something like the following:

  • for info about the test list
  • for admin pages for test list
  • for info on all lists on the server

I haven’t covered setting up the automatic Mailman daemons and cron jobs because I couldn’t do that on our dev box’s shared hosting environment, and they were already set up on our production server. If you’re installing on your own box as root, the default options to configure and make install should take care of all that for you.

Next: Installing Swish for Archive Searching or Up: Table of Contents