owner alias bounces
Hello,
on all my mailing lists, I have the problem that mails to the -owner alias seem to bounce. The sender doesn't receive a bounce, but the list owners don't receive the e-mail -- instead, failures are logged in mailman's bounce log. The owners are the same as the subscribers (it's an internal list), and mails to the list reach these destinations itself, so it can't be a general problem. The receipients are within and outside of our domain.
I'm a bit clueless and can't find much in the logs. Any idea where to start searching?
Thanks, Florian
Addendum:
Shortly afterwards, I fully receive a bounce probe message, with the message sent to -owner as attachment. So, the message reaches me, Mailman somehow bounces it anyways...
2010/12/14 Florian Effenberger <floeff@gmail.com>:
Hello,
on all my mailing lists, I have the problem that mails to the -owner alias seem to bounce. The sender doesn't receive a bounce, but the list owners don't receive the e-mail -- instead, failures are logged in mailman's bounce log. The owners are the same as the subscribers (it's an internal list), and mails to the list reach these destinations itself, so it can't be a general problem. The receipients are within and outside of our domain.
I'm a bit clueless and can't find much in the logs. Any idea where to start searching?
Thanks, Florian
Another thing I just found out:
The mailman-owner alias is only generated for the 2nd of our two virtual domains. Maybe that's related? (The other -owner aliases, including the one for the list I'm testing with, are correct, however.)
2010/12/14 Florian Effenberger <floeff@gmail.com>:
Addendum:
Shortly afterwards, I fully receive a bounce probe message, with the message sent to -owner as attachment. So, the message reaches me, Mailman somehow bounces it anyways...
Hello,
2010/12/14 Florian Effenberger <floeff@gmail.com>:
Another thing I just found out:
The mailman-owner alias is only generated for the 2nd of our two virtual domains. Maybe that's related? (The other -owner aliases, including the one for the list I'm testing with, are correct, however.)
interestingly, a withlist -l -r fix_url -a seems to have cured the problem. Of course, copy-pasting it out of my documentation without thinking led to the hostnames for 50% of the lists being wrong, which I manually corrected in the list interface, but now things seem to work. Maybe it also has something to do with the nightly cronjobs, resetting the bounce counter?
Strange...
Anyone knows an easier solution when migration another host to our mailing list server while adding another hostname?
Thanks, Florian
On 12/15/2010 1:40 AM, Florian Effenberger wrote:
interestingly, a withlist -l -r fix_url -a seems to have cured the problem. Of course, copy-pasting it out of my documentation without thinking led to the hostnames for 50% of the lists being wrong, which I manually corrected in the list interface, but now things seem to work. Maybe it also has something to do with the nightly cronjobs, resetting the bounce counter?
Strange...
The only thing fix_url would "fix" is the domain of the sender of the mail and the domain of the list-owner@domain recipient (much but not all mail to owners/moderators is sent first to the list-owner@... address and only then resent to the actual owner/moderator addresses. Possibly this domain was not valid or didn't have a -owner alias.
Anyone knows an easier solution when migration another host to our mailing list server while adding another hostname?
The procedure for adding a host name is
- Put the appropriate add_virtualhost() in mm_cfg.py.
- If Postfix is to generate virtual alias maps for this domain, add it to POSTFIX_STYLE_VIRTUAL_DOMAINS in mm_cfg.py.
- To move any lists to that domain, run fix_url with the -u option on the list(s)
I don't think there's any 'easier' solution.
Note, if you don't care about the web domain, you can set the host_name on the list's General Options page instead of step 3.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Hi Mark,
thanks for your reply, and sorry for my delay!
2010/12/18 Mark Sapiro <mark@msapiro.net>:
The procedure for adding a host name is
- Put the appropriate add_virtualhost() in mm_cfg.py.
- If Postfix is to generate virtual alias maps for this domain, add it to POSTFIX_STYLE_VIRTUAL_DOMAINS in mm_cfg.py.
- To move any lists to that domain, run fix_url with the -u option on the list(s)
hm, do I get it right that I have to add the hostnames twice in mm_cfg.py when using Postfix, once in add_virtualhost, once in POSTFIX_STYLE_VIRTUAL_DOMAINS?
Right now, I have DEFAULT_EMAIL_HOST and DEFAULT_URL_HOST to lists.domain1.tld with the only add_virtualhost line being add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST). In addition, I have set POSTFIX_STYLE_VIRTUAL_DOMAINS = ['lists.domain1.tld', 'lists.domain2.tld'], so the only occurence of domain2 is in POSTFIX_STYLE_VIRTUAL_DOMAINS.
However, I have already wondered where to set the web URL. Right now, lists.domain2 still have lists.domain1 e.g. in the List-Archive header.
Thanks, Florian
Florian Effenberger wrote:
2010/12/18 Mark Sapiro <mark@msapiro.net>:
The procedure for adding a host name is
- Put the appropriate add_virtualhost() in mm_cfg.py.
- If Postfix is to generate virtual alias maps for this domain, add it to POSTFIX_STYLE_VIRTUAL_DOMAINS in mm_cfg.py.
- To move any lists to that domain, run fix_url with the -u option on the list(s)
hm, do I get it right that I have to add the hostnames twice in mm_cfg.py when using Postfix, once in add_virtualhost, once in POSTFIX_STYLE_VIRTUAL_DOMAINS?
Maybe. It depends on what you are ultimately doing.
Right now, I have DEFAULT_EMAIL_HOST and DEFAULT_URL_HOST to lists.domain1.tld with the only add_virtualhost line being add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST).
OK. That's good.
In addition, I have set POSTFIX_STYLE_VIRTUAL_DOMAINS = ['lists.domain1.tld', 'lists.domain2.tld'], so the only occurence of domain2 is in POSTFIX_STYLE_VIRTUAL_DOMAINS.
That may be OK. If lists.domain1.tld and lists.domain2.tld are both virtual_alias_domains in postfix or otherwise require virtual_alias_maps, then you need POSTFIX_STYLE_VIRTUAL_DOMAINS as you have it. This controls what lists get entries generated in virtual-mailman for virtual_alias_maps.
However, I have already wondered where to set the web URL. Right now, lists.domain2 still have lists.domain1 e.g. in the List-Archive header.
You want an additional add_virtualhost like
add_virtualhost('lists.domain2.tld', 'lists.domain2.tld')
This is so that you can go to http://lists.domain2.tld/mailman/create (or whatever this translates to in your installation) and create a list and it will be created with the proper http://lists.domain2.tld/mailman/ web_page_url and lists.domain2.tld host_name.
Also you can use "bin/newlist -u lists.domain2.tld" to create a list properly in this domain, and you can use
bin/withlist -l -r fix_url -u lists.domain2.tld existing-listname
to fix the web_page_url and host_name for an existing domain2 list (after doing that, you may need to run bin/genaliases to update virtual-mailman).
This will make appropriate links with host lists.domain2.tld in the List-* headers in posts, on all dynamic web pages and all new or modified archive pages for the list. However, existing static archive pages will still have "listinfo" links with the old domain. These either have to be ignored, edited manually or updated by rebuilding the list's entire archive with "bin/arch --wipe listname".
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Hi Mark,
2011/1/22 Mark Sapiro <mark@msapiro.net>:
However, I have already wondered where to set the web URL. Right now, lists.domain2 still have lists.domain1 e.g. in the List-Archive header.
You want an additional add_virtualhost like
add_virtualhost('lists.domain2.tld', 'lists.domain2.tld')
This is so that you can go to http://lists.domain2.tld/mailman/create (or whatever this translates to in your installation) and create a list and it will be created with the proper http://lists.domain2.tld/mailman/ web_page_url and lists.domain2.tld host_name.
Ok, I added this and restarted mailman.
Also you can use "bin/newlist -u lists.domain2.tld" to create a list properly in this domain, and you can use
bin/withlist -l -r fix_url -u lists.domain2.tld existing-listname
to fix the web_page_url and host_name for an existing domain2 list (after doing that, you may need to run bin/genaliases to update virtual-mailman).
That doesn't seem to work for me, it throws out "option -u not recognized". :-( If I manually invoke fix_url.py, the -u option is indeed offered. What'sw rong?
This will make appropriate links with host lists.domain2.tld in the List-* headers in posts, on all dynamic web pages and all new or modified archive pages for the list. However, existing static archive pages will still have "listinfo" links with the old domain. These either have to be ignored, edited manually or updated by rebuilding the list's entire archive with "bin/arch --wipe listname".
Florian
On 1/23/2011 3:59 AM, Florian Effenberger wrote:
2011/1/22 Mark Sapiro <mark@msapiro.net>:
Also you can use "bin/newlist -u lists.domain2.tld" to create a list properly in this domain, and you can use
bin/withlist -l -r fix_url -u lists.domain2.tld existing-listname
to fix the web_page_url and host_name for an existing domain2 list (after doing that, you may need to run bin/genaliases to update virtual-mailman).
That doesn't seem to work for me, it throws out "option -u not recognized". :-( If I manually invoke fix_url.py, the -u option is indeed offered. What'sw rong?
My mistake. That should be
bin/withlist -l -r fix_url existing-listname -u lists.domain2.tld
The -u option needs to come after the list name. Otherwise it is interpreted as a withlist option rather than a fix_url option.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (2)
-
Florian Effenberger
-
Mark Sapiro