[Mailman-Users] Domain problem in post action on admindb forms for multi-domain mailman
Martin N Brampton
martin at black-sheep-research.com
Tue Sep 6 00:20:04 CEST 2011
Thanks very much for the various suggestions. Sorry I evidently didn't
make it immediately clear that the servers are not all on the same IP
address. Use of reverse proxy should work, although I'd prefer to avoid
loading mod_proxy if possible, to avoid having to think about ensuring
it is secure.
There is no specific naming scheme in operation in my setup, except that
the mailman web server is called lists.example.org. The other domains
that have mailing lists could have any name, unrelated to the mailman
domain, and could be at several possible IP addresses. Mailing lists
have email addresses that are simply listname at domain.tld or similar.
It doesn't seem too unreasonable to ask for mailman to work in this
environment, and it very nearly does :) It doesn't seem too outrageous
to run all mail services on a single server, and to run several web
servers, none of which runs mail services at all. Web servers
definitely run better without mail, and a single mail server can handle
a lot of mail.
The simplest and immediately effective (I've done it!) solution is the
hack to admindb.py.
I also like the subdomain scheme (to avoid hacking mailman), except I
don't know how to implement it in mailman. Would the "lists" be added
to the basic domain name by:
DEFAULT_URL_PATTERN = 'http://lists.%s/'
and would that work across all the uses of URLs? Would it be necessary
to knock off the "lists" in the primary domain of lists.example.com by:
DEFAULT_URL_HOST = 'example.com'
so as to counteract the "lists" being added by DEFAULT_URL_PATTERN? Or
would that have other ramifications?
But I fear a problem then arises at my mailman server, because there is
a further redirect to the SSL version of the site (because I don't like
passwords being sent as plain text for anything that matters), and there
are liable to be problems with the SSL certificate if a variety of
domains are pointed into an SSL site.
So maybe I should reconsider reverse proxying!
On 05/09/2011 18:22, Mark Sapiro wrote:
> Martin Brampton wrote:
>> I'm running Mailman 2.1.13 from the Debian Squeeze repositories (on
>> Debian Squeeze) to provide mailing lists across several domains. The
>> domains that are not the primary mailing list domain have 301 redirects
>> of URLs such as .../listinfo/xxxx or .../admin/xxxx to the primary domain.
> This is the root of your problem. The domains which are not primary
> should be defined in the web server as virtual hosts in your web
>> In most cases this works, because the action in the form is relative,
>> and the page is showing on the primary domain on account of the
>> redirects. When the form is submitted, the request therefore goes to
>> the primary mailman domain. (Other domains are typically on different
>> servers from Mailman, and do not have Mailman installed at all).
> Oh. So the other domain's A record points to a different box and it's
> that box that redirects it to the Mailman box. Mailman is not designed
> to work in that way.
>> However, the .../admindb/xxxx pages seem to have a specific domain in
>> the action attribute of the form, and it is the actual domain of the
>> mailing list, not the primary domain. Although the redirect sends the
>> post to the mailman server, redirecting a post request loses all the
>> data, so nothing happens.
>> Is there something wrong with my setup? Is there a way to resolve this
> I suggest the following. Using say www.example.com as a domain hosted
> on a foreign box, establish a new domain, say list.example.com with an
> A record pointing to the Mailman box, and make list.example.com a
> virtual host in the web server on the Mailman box.
> If this won't work for some reason, or if you prefer, you could look at
> Mailman/Cgi/admindb.py on the Mailman host. Find the line
> admindburl = mlist.GetScriptURL('admindb', absolute=1)
> in the definition of the main() function. If you change that to
> admindburl = mlist.GetScriptURL('admindb')
> it should make the action URL in the forms relative. There are other
> occurrences of mlist.GetScriptURL('admin', absolute=1) in the module,
> but they are for non-POST links.
More information about the Mailman-Users