Andrew - Supernews wrote:
>>>>>>"W" == W B Hacker <wbh@???> writes:
>
>
> W> Folks,
> W> Trying to get my virtual 'arms' around an apparent anomaly within
> W> dnsdb lookups:
>
> W> From the 4.6X spec:
>
> W> ${lookup dnsdb{mx=a.b.example}{$value}fail}
>
> W> When implemented as:
>
> W> # C1X Test DNS lookup for A record
> W> warn
> W> condition = ${lookup dnsdb{a=$sender_host_address}{$value}fail}
>
> This is wrong for three reasons.
>
> Firstly, you're trying to look up the A record for "71.247.128.142.", which
> of course should not exist. (Some DNS resolvers, i.e. djb's, will fake one
> for you.)
Well - therein lies the problem. Details below...
>
> Secondly, the value in a condition = clause is supposed to be a true/false
> indication, not the value of the dnsdb lookup, so returning {$value} is
> always wrong there.
No disagreement - but the spec is what I am going by (as pasted at the top..
Not *yet* as concerned with pass/fail as just what happens with by-the-book-example.
>
> Thirdly, exim already looked up the A and PTR records for you if host_lookup
> matched the address or you referred to $sender_host_name somewhere, or
> used verify = reverse_host_lookup.
>
ACK. *However*, per archives from a few years ago, Exim then used
gethostbyaddr() - whih could ONLY be satisfied by a PTR record.
It *seems* to now be more flexible. At least it gives a 'pass' to many sources
for whom a 'host -v' or 'dig ...' are less forgiving.
And I can create specifc by altering one of my own DNS services.
> Using dnsdb correctly is trickier than it looks because of the need to
> handle temporary failures sanely.
Absolutely! Hence the post...
>
> As for your results, don't bother with redacted logs, just show us the
> exim -bh session.
>
ah - given that it creates an 82 KB file of 1807 lines (wrapped), I don't see
the relevance.
> W> Second, is there a better 'road well traveled' to discern whether
> W> and when Exim's host lookup has (already) specifically found a PTR
> W> record, or has been satisfied by an 'A' (or other) record only?
>
> verify = reverse_host_lookup can only be satisfied by a matching set
> of: PTR record(s) for the client IP, and an A record for one of the
> PTR record values found which points back to the client IP.
>
... usually. Or so it is intended.
> The only time it is meaningful to consider finding an A record _without_
> having found a PTR record is when verifying the _HELO_, which is a
> totally separate matter.
>
..and generally of diminishing value in a world where even major-vendor ISP's
choose to hello with strings that are totally devoid of any relevance to their
DNS entries - or even subnetted hostnames. :-(
No - this is about a different issue, i.e just what *was* found/not found.
Dodgy/cheating DNS resolvers quite aside - what records DOES the caller have?
- and do we wish to continue a session if they are:
1) perfect match (yes)
2) slightly flawed, but not trying to hide (practical necessity)
3) 'Acceptable' only IF we sort out subnetting/prefixes that are NOT in DNS (all
too common, 'Yes, but *how best* to do so')
4) NOT if they have NO records (nearly all zombies, but quite a few major-ISP
outbound 'pools' as well). Trying to find a solution for those beside
manual/semi-auto whitelisting.
Looks as if this may require a call to external tools.
Thanks,
Bill
