[exim] dnsdb anomaly?

Page principale
Supprimer ce message
Répondre à ce message
Auteur: W B Hacker
Date:  
À: exim users
Sujet: [exim] dnsdb anomaly?
Folks,

Trying to get my virtual 'arms' around an apparent anomaly within dnsdb lookups:

From the 4.6X spec:

${lookup dnsdb{mx=a.b.example}{$value}fail}

When implemented as:

   # C1X Test DNS lookup for A record
   warn
     condition   = ${lookup dnsdb{a=$sender_host_address}{$value}fail}
     log_message = C1X A $sender_host_address, $sender_host_name


   # C1X Test DNS lookup for PTR record
   warn
     condition   = ${lookup dnsdb{ptr=$sender_host_address}{$value}fail}
     log_message = C1X PTR $sender_host_address, $sender_host_name


Note: timestamps, etc. redacted below to reduce MU wrapping confusion, not to
obfuscate.

Regardless if in the above order, or reversed ('PTR' seek first, 'A' seek
second) this *may* result in:

====
...Warning: C1X A 71.247.128.142, pool-71-247-128-142.nycmny.east.verizon.net,

...Warning: ACL "warn" statement skipped: condition test deferred: invalid
"condition" value "pool-71-247-128-142.nycmny.east.verizon.net"

====

This seems to indicate that the first test leaves the result, not in '$value',
but overwritten in $sender_host_address.

*However* - if a subsequent 'warn' verb calls for $sender_host_address, it will
still get the original IP, above, 71.247.128.142.

So, perhaps, the returned data is remaining in some internal structure and
$sender_host_address is NOT being called

Note that whenever there is a 'simple' match - no subnet, and *both* A and PTR
present, this does not occur:

====
Warning: C1X PTR 203.194.153.83, triligon.to

Warning: C1X A 203.194.153.83, triligon.to
====

Nor does it occur when there is *neither* an A nor PTR record found (note empty
second field after the comma for each):

====
Warning: C1X A 202.69.34.36,

Warning: C1X PTR 202.69.34.36,
====

First, am I missing something in entering/exiting/invoking/returning results
from the 'dnsdb' tool?

Or is this an 'undocumented feature'?

Second, is there a better 'road well traveled' to discern whether and when
Exim's host lookup has (already) specifically found a PTR record, or has been
satisfied by an 'A' (or other) record only?

Thanks,

Bill