[Mailman-Users] mailman setup for vhosts

[Richard Barrett]

On 14 Jun 2004, at 16:14, Scott R. Godin wrote:

> I have a website client that would like a push-only mailing list that 
> his
> customers can subscribe to to receive announcements of special sales 
> and
> new products, and trade show schedules.
>
> His website, however, is hosted on an ISP (running FreeBSD) who vhosts 
> many
> different other sites.
>
> In the Features page, I don't really see any specific mention of 
> whether
> mailman would handle a server with many different vhosted sites. 
> Obviously
> one would like the clients to be able to subscribe and unsubscribe
> themselves via a web-interface, but how to provide a link to the
> client-side-admin page within the vhosted domain would be one question.
>
> Also I'm sure the ISP themselves would have questions regarding how 
> this may
> affect their other vhosted sites.
>
> Can anyone provide me with some information and explanation of these 
> issues?
> I'd be most grateful.

This recent post discusses some relevant issues:

http://mail.python.org/pipermail/mailman-users/2004-June/037415.html

In a private follow-up to that post I further discussed some of the 
issues:

On 13 Jun 2004, at 13:07, Richard Barrett wrote:

> Eric
>
> On 13 Jun 2004, at 03:40, Eric Pretorious wrote:
>
>> Hi, Richard!
>>
>> On Friday 11 June 2004 11:23 pm, you wrote:
>>> With unmodified, standard Mailman source code, there is a single
>>> namespace for list names shared by all virtual host supported by a
>>> given Mailman installation. Multiple installations on the same 
>>> machine
>>> can be used to avoid the list naming restrictions this creates.
>>
>> Is this difficult to configure?
>
> Not done this myself but I would not expect the Mailman end of it to 
> be much harder than a normal Mailman source install; you just have to 
> do it more than once.
>
> Say you would normally have installed Mailman into a directory called 
> /mailman/run and run the Mailman ./configure with 
> --prefix=/mailman/run and then make.
>
> My approach would be to perform per-hostname installs into directories 
> named after the  hostname, called for example /mailman/run/domX.tld, 
> running the Mailman ./configure with --prefix=/mailman/run/domX.tld 
> before running make install for each hostname to be supported
>
> You probably also want to use the --with-mailhost and --with-urlhost 
> ./configure option to get the appropriate DEFAULT_URL_HOST and 
> DEFAULT-MAIL_HOST in each installation's Defaults.py although you 
> could fix this after make'ing by assignment in mm_cfg.py
>
> In practice you will probably not have any add_virtualhost() calls in 
> your mm_cfg.py except for the single 
> DEFAULT_URL_HOST/DEFAULT_EMAIL_HOST call as the use of "real" hosting 
> removes the purpose of the normal Mailman virtual hosting setup.
>
> You are going to need separate Alias and ScriptAlias (and related) 
> directives in each per-host VirtualHost container in your Apache 
> httpd.conf, each of which refers to the matching host's Mailman 
> installation directory. Behaviour when an HTTP client does not provide 
> a Host: request header is going to be a little different if you use 
> Apache named virtual hosts rather than numbered virtual hosts with 
> distinct IP numbers. But practically all modern browsers supply the 
> Host: header so I would not expect this to be a problem.
>
> Where thing may get more complicated is setting up your local MTA to 
> support virtual hosts. For instance, aliases generated by the per-host 
> copies of $per-host-prefix/bin/newlist will generate alias definitions 
> that pipe to the correct per-host instance of the Mailman delivery 
> agent script but getting your MTA to recognise the aliases belong to 
> one host rather than another is not something I am familiar with. My 
> impression is that doing this with Postfix or Exim (and possibly 
> Qmail) is likely to be easier than with Sendmail; but I seem to have 
> struggled for half a lifetime to understand Sendmail configuration, 
> with little success, and am likely to die before that task is 
> complete.
>
> Final thoughts:
>
> 1. each per-host installation has to have its own 'mailman' site list
>
> 2. moving lists between virtual hosts is a different ballgame and 
> $prefix/bin/fix_url.py is no longer what you need to change a list's 
> virtual host
>
>>
>>> The modified version of Mailman, shipped by Cpanel as part of their
>>> commercial hosting product for ISPs, adopts a different,
>>> list-name-munging solution to the problem but Cpanel have not made 
>>> the
>>> modified source code generally available in the public domain.
>>
>> Do you know where I could get it?
>>
>
> I do not know much about Cpanel but messages asking for support from 
> users have cropped up fairly frequently which is where the 
> list-name-munging trick of Cpanel has come to notice.
>
> I would not go this route myself unless I was considering to run a 
> hosting business as such but you could try starting your journey of 
> discovery here http://www.cpanel.net/