[Mailman-Users] Domain problem in post action on admindb forms for multi-domain mailman

[Martin N Brampton]

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
> server.
>
>
>> 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
>> problem?
>
>
> 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.
>