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


------------------------------------------------------ Mailman-Users mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/

This message was sent to: [EMAIL PROTECTED]
Unsubscribe or change your options at
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Reply via email to