[Mailman-Users] V2.1 breaks virtual hosting?

[Richard Barrett]

At 14:49 04/06/2003, Dave Lane wrote:
>At 08:03 PM 6/2/2003 +0100, Richard Barrett wrote:
>
>>>DEFAULT_EMAIL_HOST = 'native.stmarys.ca'
>>>DEFAULT_URL_HOST = 'native.stmarys.ca'
>>>DEFAULT_URL_PATTERN = 'http://%s/mm21/'
>>>add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)
>>>add_virtualhost(DEFAULT_URL_HOST, 'lists.domain1.ca')
>>>add_virtualhost(DEFAULT_URL_HOST, 'lists.domain2.ca')
>>
>>The add_virtualhost calls insert key/values into a dictionary. The key is 
>>the first parameter to the add_virtualhost call and the value is the 
>>second parameter.
>>
>>You are not generating three entries in the dictionary with your 
>>add_virtualhost calls. The effect is as if the first two were not made 
>>and the only virtual host you are defining is the last one.
>>
>>This might be part of your problem.
>
>Richard,
>
>I've tried a number of things since (as gleaned from the archives) and 
>mail from mailman seems to go silent as soon as I either use either 
>"add_virtual_host" setting or change a list to a virtual domain from the 
>web interface. Received mail sent to the virtual address does end up in 
>the digest .mbox file for the list, so it *is* receiving the virtual mail.
>
>In another example, after changing the domain to the virtual one, 
>subscribe notices aren't received -- change it back, that it works again.
>
>I wish the documentation actually described in detail how this works, 
>especially since it worked well and was easy to use in V2.0.
>
>... Dave

Just some notes; all in respect of MM 2.1.2:

1. In Defaults.py, the DEFAULT_URL_HOST and DEFAULT_EMAIL_HOST as 
determined at configure and install time are added to the VIRTUAL_HOSTS 
dictionary variable declared in Defaults.py by a call to add_virtualhost(). 
If these values of DEFAULT_URL_HOST and DEFAULT_EMAIL_HOST are redefined in 
mm_cfg.py then before you use add_virtualhost() to declare new values you 
probably want to insert a following statement to flush away the value set 
in Defaults.py:

VIRTUAL_HOSTS.clear()

2. When a list is created two of its attributes are set: web_page_url and 
host_name. By default they will use DEFAULT_URL_HOST and DEFAULT_EMAIL_HOST 
respectively. If you specify a URL host when creating the list (run 
$prefix/bin/newlist --help to see how) then the web_page_url uses that host 
and MM tries to set host_name to the value returned by looking up the 
specified host in VIRTUAL_HOSTS. If that lookup fails then host_name is set 
to the _same_ host as is used for web_page_url. The lookup is being 
controlled by the web host looking up the mail host, not the other way around.

3. Changing the VIRTUAL_HOSTS dictionary does nothing to existing lists. If 
you want to change an existing list's web_page_url or host_name in response 
to a change in VIRTUAL_HOSTS then you must use the $prefix/bin/withlist 
script fix_url.py (run it to get its usage). N.B. with MM 2.0.13 you could 
change web_page_url on the admin GUI but you have to use fix_url.py on MM 2.1.2

4. You can change a list's host_name attribute using the "Host name this 
list prefers for email" field on the admin GUI general Options page. This 
is changing the eamil host the list wants to be associated with but NOT the 
web host and may well not fit with the key/values of the VIRTUAL_HOSTS 
dictionary. I reckon running fix_url.py in those circumstances would loose 
you the change mage via the GUI.

5. Your add_virtualhosts() calls all boil down to having made only one 
call; the one to add_virtualhost(DEFAULT_URL_HOST, 'lists.domain2.ca') all 
the others are being overwritten in the VIRTUAL_HOSTS dictionary by the 
following call; only the last stays in place because they are all 
specifying the same key value; that of DEFAULT_URL_HOST.

Other thoughts:

Have you checked the smtp-failure log. If perchance the host_name attribute 
for a list is not DNS resolving then the MTA might be refusing to accept 
the outgoing traffic and you may find 553 response codes recorded in log 
entries in the $prefix/logs/smtp-failure log. This would also show up in 
post and smtp logs as well as your MTA's logs so you are not likely to have 
missed.

Apart from that I'm stumped. Be interesting to see if someone else can 
diagnose the problem. Let us know if you resolve the problem.



------------------------------------------------------------------------------
Richard Barrett                                      http://www.openinfo.co.uk