The situation is this: A single server with multiple IP addresses and related hostnames acts as a mailman server. Mailman is a mailing list manager with a builtin web archive and subscription management system written in php. As shipped it injects a file called mailman.conf into /etc/httpd/conf.d that uses mod_alias to redirect traffic of the form http://host.domain.tld/mailman to run the php scripts necessary to provide the management and archive service. The RedirectMatch statement used to effect this is:
RedirectMatch ^/mailman/?$ http://www.example.com/mailman/listinfo
However, this arrangement is awkward in that it requires a URL in the form http://host.domain.tld/mailman to reach the mailman web interface. What is desired is that a URL in the form http://mailman.domain.tld achieve the same result.
Solution. The key to this lies in removing the default mailman.conf file and setting up a virtual host configuration that contains the directives in mailman.conf and provides two rewrite rules specifically tailored to the mailman virtual host. The first directive produces the same effect as the default RedirectMatch in mailman.conf:
RewriteRule ^/mailman/?$ http://mailman.example.com/mailman/listinfo [L,R]
The second provides the identical effect if the user simply uses the host name (mailman.example.com).
RewriteRule ^/$ http://mailman.example.com/mailman/listinfo [L,R]
The [L,] flag tells the rewrite engine to stop processing with this ruleset. The [,R] tells it to process the redirect without stripping the host part.
The entire virtual host configuration file follows:
<VirtualHost mailman.example.com>
DocumentRoot /var/lib/mailman/archives/public
ServerName mailman.example.com
ScriptAlias /mailman/ /usr/lib/mailman/cgi-bin/
<Directory /usr/lib/mailman/cgi-bin/>
AllowOverride None
Options ExecCGI
Order allow,deny
Allow from all
</Directory>
Alias /pipermail/ /var/lib/mailman/archives/public/
<Directory /var/lib/mailman/archives/public>
Options Indexes MultiViews FollowSymLinks
AllowOverride None
Order allow,deny
Allow from all
</Directory>
<Directory "/var/lib/mailman/archives/public">
Options +Indexes +FollowSymLinks
Order allow,deny
allow from all
</Directory>
RewriteEngine on
RewriteLog "/var/log/httpd/rewrite_log"
RewriteLogLevel 0
RewriteRule ^/mailman/?$ http://mailman.example.com/mailman/listinfo [L,R]
RewriteRule ^/$ http://mailman.example.com/mailman/listinfo [L,R]
</VirtualHost>
Now what I need to do is to find out how one disguises the internal URI so that calls to mailman.example.com only display http://mailman.example.com/ in the address bar of the browser and not http://mailman.example.com/mailman/listinfoBut the essential part is working now.
P.S.
One more thing. Do not forget that this change may require that mm_cfg.py be altered to use the hostname alias mailman.example.com rather than the fqdn of the host and mailman restarted. Otherwise the internal links to the archives may not work.
From http://www.unicom.com/blog/entry/518:
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@example1.com and list2@example2.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 them 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@example.com listname
This maps the fully qualified virtual domain name of the list (listname@example.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@example1.com and another called discuss@example2.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.
Majordomo apparently has better support for virtual domains out of the box. There's a chart here comparing it and mailman.
Here's a message from one of the many mailman lists:
You can run all virtual domains off one mailman installation as long as the LISTNAME portion of LISTNAME@DOMAIN is unique across all lists. E.g., you couldn't have admin@FOO.com and admin@BAR.com under the same installation.
If administratively feasible, a good way to accomplish this would be
to assign all of your domains some unique tag, so that their lists are
FOO-admin@FOO.com, etc.
That said, you should be able to alias admin@FOO.com to FOO-admin and
admin@BAR.com to BAR-admin, but you'd have to take special care not to
confuse the users. This was discussed earlier, I believe, but I don't
recall the final conclusion.
