Re: [exim] Multiple Backup DNS

On Mon, 13 Jun 2005 12:52:57 +0100 Tony Finch <dot@???> wrote:

> On Sat, 11 Jun 2005, Justin Richer wrote:
> >
> > dnslookup:
> > driver = dnslookup
> > domains = ! +local_domains
> > transport = remote_smtp
> > ignore_target_hosts = 0.0.0.0 : 127.0.0.0/8 : [host ip]/32
> > no_more
>
> Your bug is that you've put your mailserver's IP address in the
> ignore_target_hosts list. This takes effect before the RFC 974 routeing
> logic which ensures that email is never routed from a secondary to a
> tertiary MX. RFC 974 deals with the mail server's own IP address
> automatically, so you should not try to handle it yourself.

Aha! While this wasn't the root cause of the problem, it did point me in
the right direction. That bit with the host ip above was added in because
previously, in doing secondary MX duty, this particular mailserver would
route to itself. This caused an infinite mail loop and fairly quick
failures. I wasn't sure what was causing this to begin with, but adding the
host's IP address to the 'ignore_target_hosts' line made the problem go
away. Until I got a tertiary server, that is, when my previously-mentioned
problem started. As it turns out, this particular mail server is actually
in a virtual machine with a 192.168 address. Its associated firewall was
set to port-forward SMTP, IMAP, and associated mail-like functions to it
transparently from an external IP address. This meant that Exim had no idea
of the external IP address, which is what got entered on the line above.
Enter my digging today, which turned up the 'extra_local_interfaces'
configuration option. I set this to include the external IP address, and
the infinite route problem went away. Taking a cue from a Debian
configuration file, I also added the following router, directly above the
aforementioned one:

dnslookup_relay_to_domains:
driver = dnslookup
domains = ! +local_domains : +relay_to_domains
transport = remote_smtp
no_more

I'm not convinced this is strictly necessary, but it does tag valid relays
in the log file differently, so there's some merit in that. I ran some
tests this afternoon, and everything seems in order now. So yes: removing
the host's IP from the ignore_target_hosts line and adding it to
extra_local_interfaces was what ultimately solved this problem. Thank you
for your help!

-- Justin