Phillip Baker
2010-12-13 01:06:32 UTC
I could be missing something but it seems an awful lot like since I upgraded Exim on a Debian host (now running 4.69-9+lenny1) that it's no longer correctly flowing mail that is eventually destined for a catchall (that is relayed off host) I am *reasonably* sure that this was working before, but I could always be wrong.
Mail for ***@catchalldomain.com<mailto:***@catchalldomain.com> is handled by a local domain in vexim that has a catchall configured to forward to ***@localdomain.com<mailto:***@localdomain.com> (which in turn is an alias to ***@remotedomain.com<mailto:***@remotedomain.com> hosted on another server)
After one initial expansion on ***@catchalldomain.com<mailto:***@catchalldomain.com> (which results in eventually checking if catchalldomain.com is a relay), subsequent mail sent to ***@catchalldomain.com<mailto:***@catchalldomain.com> appears to result in one single query by exim; to check if catchalldomain.com exists as a relay domain. It does not because it is a local virtual domain, and so the mail is rejected in both cases.
On the change in behaviour: Is exim being 'clever' and caching the result of "***@catchalldomain.com -> ***@localdomain.com -> ***@remotedomain.com" as a remote_smtp operation and therefore jumping straight to checking for the domain being a relay?
Any thoughts on the best method for either disabling or accommodating this behaviour with vexim? I've had to add the mysql expansion for virtual (eg local) domains to the relay_to_domains stanza for the time being - I had a think about potential downsides of this workaround but couldn't immediately think of any as local domains will be evaluated properly still, so this just 'allows' local domains to have relay operations performed as well.
(Has this behaviour been happening for a while? Have I been missing mail for this domain for the last year and not noticed? It's mostly a 'junk goes here' domain, so it's possible. I only noticed because I needed a password reset mail :) )
--
Regards,
Phillip Baker
Technical Director
LCHost
***@lchost.co.uk<mailto:***@lchost.co.uk>
T 020 30 26 26 26 ext 50
F 020 79 00 34 90
M 07793 22 80 80
Managed Internet Solutions, Remote Hands & Network Engineering Services
Mail for ***@catchalldomain.com<mailto:***@catchalldomain.com> is handled by a local domain in vexim that has a catchall configured to forward to ***@localdomain.com<mailto:***@localdomain.com> (which in turn is an alias to ***@remotedomain.com<mailto:***@remotedomain.com> hosted on another server)
After one initial expansion on ***@catchalldomain.com<mailto:***@catchalldomain.com> (which results in eventually checking if catchalldomain.com is a relay), subsequent mail sent to ***@catchalldomain.com<mailto:***@catchalldomain.com> appears to result in one single query by exim; to check if catchalldomain.com exists as a relay domain. It does not because it is a local virtual domain, and so the mail is rejected in both cases.
On the change in behaviour: Is exim being 'clever' and caching the result of "***@catchalldomain.com -> ***@localdomain.com -> ***@remotedomain.com" as a remote_smtp operation and therefore jumping straight to checking for the domain being a relay?
Any thoughts on the best method for either disabling or accommodating this behaviour with vexim? I've had to add the mysql expansion for virtual (eg local) domains to the relay_to_domains stanza for the time being - I had a think about potential downsides of this workaround but couldn't immediately think of any as local domains will be evaluated properly still, so this just 'allows' local domains to have relay operations performed as well.
(Has this behaviour been happening for a while? Have I been missing mail for this domain for the last year and not noticed? It's mostly a 'junk goes here' domain, so it's possible. I only noticed because I needed a password reset mail :) )
--
Regards,
Phillip Baker
Technical Director
LCHost
***@lchost.co.uk<mailto:***@lchost.co.uk>
T 020 30 26 26 26 ext 50
F 020 79 00 34 90
M 07793 22 80 80
Managed Internet Solutions, Remote Hands & Network Engineering Services