Autor: W B Hacker Data: Para: exim users Asunto: Re: [exim] Default enabling of dnsdb
Dean Brooks wrote: > On Wed, May 06, 2009 at 04:41:55AM +0800, W B Hacker wrote:
>
>> There may well be cute and clever things that only DNSDB enables.
>>
>> But DNSDB is *not* needed to test for a PTR RR.
>
> Checking for the presence of a PTR record, and looking for valid reverse
> DNS are not the same things.
True - BUT .. they rely on 'one of' the same components - (at least) the
'presence' of a PTR RR.
>
> The reverse_host_lookup functions in Exim will fail if the
> forward-check also fails.
>
Yes BUT .. the *manner* in which it reports that fail differs enough
that one can tell which part failed.
As was illustrated in my two original log snippets.
One is not restricted to doing a 'deny' on that fail.
One may act on just the subset wanted (the lack of a PTR).
> If you only want to check for the presence of a PTR record, and do not
> care about the forward-check, I haven't been able to find any way to do it
> without using dnsdb.
>
> --
> Dean Brooks
> dean@???
>
The increasing prevalence of 'generic' PTR which fail the 'whole' test
leads me to prefer that. It is no longer good enough just to 'have' a
PTR RR.
I do not want to ALSO have to do REGEX parsing for 'adsl', 'dsl','dial',
or the interspersed hyphens between IP numerals.
But while the mere existence of a PTR is not what *I* want, that doesn't
stop anyone who DOES want that finer granularity from selective use of
the 'portion of' the reverse_host_lookup fail that indicates it did not
even find a PTR RR.
"..host lookup failed (failed to find host name from IP address)"
did not find a PTR RR *at all*.
".. host lookup failed (189.79.203.161 does not match any IP address for
189-79-203-161.dsl.telesp.net.br)"
...found a PTR RR, but one that did not forward-match. Mark-One eyeball
sez you wouldn't expect or want it to. That one is a WinBot.
Both are the default Exim log strings, hence 'stable', and they differ
in string length as well as content.
Now .. DNSDB may very well be a lighter' lookup in terms of resource use
and handing back results - or not.
But if DNSDB is to be presented as an advantage of sufficently general
use to warrant inclusion in the default, not just be 'available' in the
source-tree...
... then a mere PTR seek is probably a poor example on which to build
the case.
The spf check is more elegant - but perhaps of less general use.
So ... somewhere out there in Exim-land may lie a 'killer app' for DNSDB.
That is what we should be asking to see before throwing in extra code.