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