Re: [exim] Default enabling of dnsdb

Top Page
Delete this message
Reply to this message
Author: W B Hacker
Date:  
To: exim users
Subject: 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.

Bill