Re: [Exim] hosts_override not overriding?

Góra strony
Delete this message
Reply to this message
Autor: Philip Hazel
Data:  
Dla: Brett Thorson
CC: exim-users
Temat: Re: [Exim] hosts_override not overriding?
On Mon, 21 Apr 2003, Brett Thorson wrote:

> dns_to_virus_scanner:
> driver = dnslookup
> domains = ! +local_domains
> transport = dns_filtered_smtp
> ignore_target_hosts = 0.0.0.0 : 127.0.0.0/8
> self = send
> no_more
>
> Its corresponding Transport
>
> dns_filtered_smtp:
> driver=smtp
> port=888
> allow_localhost
> hosts = ietf-mx.ietf.org
> hosts_override


> I am trying to also send another domain through the same setup, and am getting
> relaying errors, I ran it in debug mode, and here is what I see:


You apparently didn't try to *send* in debug mode, because...

> 4161 routed by dns_to_virus_scanner router
> 4161 envelope to: bthorson@???
> 4161 transport: dns_filtered_smtp
> 4161 host colossus.foretec.com [132.151.1.197] MX=10
> 4161 Attempting full verification using callout

        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Exim doesn't do this when it is deliverying. It does it only when it is
verifying an address (if you have callout configured). What was the
debug command you actually ran?


> If I am doing a hosts_override, shouldn't it be going out to ietf-mx and not
> colossus.foretec.com?


To test a delivery without actually doing the delivery, you can use the
-N flag. This makes Exim go through almost all the motions of delivering
a message except actually transporting it.

> Now I do realize that my MX record for this domain is not set to
> ietf-mx.ietf.org I am trying to migrate over and do some pre-cutover
> testing. In the process I noticed that hosts_override doesn't seem to be
> overriding the callout. (Or maybe it is, and the hosts_override is just a
> low level kind of thing that isn't spit out into the debug logs?)


That's precisely it. hosts_override doesn't override the callout,
because the callout just looks at the routing. Because no delivery is
taking place, the transport is not involved.

I suppose one could argue that this is a bug. I will have to think about
whether something can be done to improve this behaviour, but for the
moment, it is as expected.





--
Philip Hazel            University of Cambridge Computing Service,
ph10@???      Cambridge, England. Phone: +44 1223 334714.