W B Hacker wrote:
>> Yeah, that is frustrating. I've run into that a few times too, again
>> usually with regards to testing for PTR records.
>
> There may well be cute and clever things that only DNSDB enables.
>
> But DNSDB is *not* needed to test for a PTR RR.
[strip extraneous logs]
> What is in the #CONNECT_C3 acl?
>
> !verify = reverse_host_lookup
>
> Keeping in mind that at 'connect' all one has on which to base a
> 'reverse_host_lookup' ... is an IP....
>
> And the only record 'of interest' that can be found with a 'bare' IP..
>
> ... is a PTR RR.... Or NOT.
>
> QED
>
> Whether it is 'proper' or 'generic' is for another phase.
Does reverse_host_lookup check for a PTR, or does it check for the
existance of a PTR which resolves back to the same IP after doing an A
record lookup? I've never used it, but from the documentation it looks
to me as though it does the second thing. Which is not what was being
talked about.
http://www.exim.org/exim-html-current/doc/html/spec_html/ch40.html
"verify = reverse_host_lookup
This condition ensures that a *verified* host name has been looked up
from the IP address of the client host."
And
"Verification ensures that the host name obtained from a reverse DNS
lookup, or one of its aliases, does, when it is itself looked up in the
DNS, yield the original IP address."
Or do you not see the difference? And if you do see the difference, do
you want to retract this statement?
"But DNSDB is *not* needed to test for a PTR RR."
Because it seems quite false to me...
--
Mike Cardwell
(
https://secure.grepular.com/) (
http://perlcv.com/)
