Mailman Virtual Hosts: Still Wrong After All These Years

in

One of my chores this weekend was to reconfigure a server to convert the Mailman mailing list manager already installed to support virtual domains. I've been using this package ever since its early releases, but it's been several years since I've reviewed what's changed.

One of the greatest limitations of Mailman has been its "virtual domain" support. That's where a single server supports mailing lists that live under different domains, such as list1 [at] example1 [dot] com and list2 [at] example2 [dot] com.

Unfortunately, the virtual domain support hasn't improved recently.

Here is how Mailman supports virtual domains, at least when using the Postfix mail transport. When you want to setup a mailing list called listname, you create an alias file entry that says something like:

listname: "|/usr/local/mailman/mail/mailman post listname"

This takes incoming email messages sent to listname and feeds then into the Mailman system.

If this list lives under a virtual domain, say example.com, then you also create a virtual file entry that says:

listname [at] example [dot] com listname

This maps the fully qualified virtual domain name of the list (listname [at] example [dot] com) to its alias (listname).

This approach requires that list names are unique across virtual domains. That is, you couldn't create one mailing list called discuss [at] example1 [dot] com and another called discuss [at] example2 [dot] com on the same Mailman installation. That's because both of them want to map to a single alias called discuss.

This is a widely known limitation. It's discussed in the Mailman FAQ here: http://www.python.org/cgi-bin/faqw-mm.py?file=faq04.047.htp&req=show

I wish that Mailman used a qualified name internally, rather than the bare listname, to identify mailing lists. That way you could have one list called example1.com-discuss and exampl2.com-discuss and the two lists would be internally distinct.

I investigated some possible kludge workarounds, but they required changing the real_name configuration setting (the listname displayed to the public) for the list, which Mailman prohibits.

So the solution seems to be either apply some official patches (noted in that FAQ entry) or wait for Mailman release 3.0.