Mike Cardwell wrote:
> 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?
That depends on where and how you invoke it, and what you do with what
it returns.
IOW those logs tell a tale.
At the beginning of acl_smtp_connect the *only* information you have is
the arriving IP:port, and *your* IP:port to which it has connected.
log_selector = +all will show these as;
2009-05-05 21:33:35 [896] SMTP connection from [89.122.157.22]:1059
I=[203.194.153.81]:25 (TCP/IP connection count = 1)
... no action, just information ...
2009-05-05 21:33:36 [48760] no host name found for IP address 89.122.157.22
.. a 'built in' Exim report - not necessarily associated with an action
verb..
2009-05-05 21:33:54 [48760] H=[89.122.157.22]:1059 I=[203.194.153.81]:25
rejected connection in "connect" ACL: C3 rDNS Fail: host lookup failed
(failed to find host name from IP address)
My bespoke acl, which relies on that test Exim makes, BUT wants to apply
it differently, AND allow for exceptions.
When you call for 'reverse-host_lookup' specifically in acl_smtp_connect
there is no hostname to match *to*.
But that is the reason for 'negation' of the case and use of a 'deny'
class verb.
The whole clause is carrying ;flags' and values from prior steps:
===
# CONNECT_3: Test for rDNS - delayed to allow whitelisting
#
deny
message = Sender on $sender_address is not a mail server. \
RFC mandated PTR RR was not found.\
# logwrite = C3 rDNS fail check on $sender_host_address \
$sender_address
condition = ${if eq{$interface_port}{25}}
!hosts = : +relay_from_hosts
!condition = ${if ge{$acl_c4}{1}}
!verify = reverse_host_lookup
set acl_c2 = $acl_c2 $sender_address invalid rDNS=650
set acl_c5 = ${eval:$acl_c5 + 650}
set acl_c13 = 1
log_message = C3 rDNS Fail
delay = MAINDELAYs
===
The 'logwrite' is for testing 'traversal' vs 'trigger' of an acl,
switched-on for debugging. Every clause in my config has one, and every
clause has a code.
Unlike the narrower case in your DNSDB example, however, it DOES go on
to take, for example, a 'generic' PTR RR and see if THAT can also
resolve back to the original IP.
'Generic' PTR RR are generally just timesaver tags for an ISP to better
sort out which user was involved what issue at a given point in time, as
*they* know who was connected to a given backside IP and which
front-side IP they were mapped to from DHCP lease logs.
These fail *also* - if/as/when a PTR RR exist, is found, but is not
'proper':
Ex:
2009-05-05 21:31:01 [48721] H=[201.103.137.96]:61856
I=[203.194.153.81]:25 rejected connection in "connect" ACL: C3 rDNS
Fail: host lookup failed (201.103.137.96 does not match any IP address
for dsl-201-103-137-96-dyn.prod-infinitum.com.mx)
At this point, I've wiped out nearly all zombots, AND the
spam-supporting dynamic remapper organizations. Plus, to be fair, more
than a few wannabees running MTA on residential / SME broadband w/o
fixed-IP or PTR RR.
Too Sad. That is not a 'false positive'.
> 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.
>
As above, it WILL do 'the second thing' - IF, and ONLY IF, there is a
PTR RR found.
Invoke it before you have a hostname (from HELO, for example) to match
against, and it does the 'first thing', i.e. - seek a PTR RR *of any kind*.
Further, it is 'tolerant' of multiple PTR RR per IP, prefixes, and other
'fuzzy' logic wherein the records are at least 'in the right family' - a
very common case with major ISP's using 'pools' of servers.
To do either of those, you would have to add extra code to (at least)
the example you cited fro DNSDB.
A great deal of extra code in the edge cases.
So your cited 4K of code for the *tool* now begs a great deal of code
and effort and *testing* whatever is to use the tool..
..to get back to what is already IN Exim, ELSE - may not have much to do
with an MTA's function..
Absent that programmed-in 'fuzzy logic', you cannot 'just' accept on
mere presence of a PTR RR.
You need also to 'taste' it or 'quantify' it.
> 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?
Not at all. I stand on it.
>
> "But DNSDB is *not* needed to test for a PTR RR."
>
'Test for' it does do. That it can do more does not negate that.
The rejection on a 'generic' PTR RR may seem a fiddle to you - after
all, one *exists* - but the *absence* of any PTR RR *at all* ('test
for') is certainly unequivocal. 'test for' AND 'qualify' is still 'test
for' and that is not just semantics, as a 'hard fail' is just that.
I say again - it depends on where you make the call (acl_smtp_connect),
and whether you use the 'positive' (accept) case, as in the docs, or the
*negation* (deny on fail).
... or something else again in acl_smtp_helo if you want even more
complex conditionals..
> Because it seems quite false to me...
>
'Seems'. As you said - you've never used it.
Docs are docs. Actual practice goes beyond..
I've relied on it for *years*, on many servers, and as either the 'hard
reject', (my personal boxen, nowadays), or a point-scored per-domain or
per-user preference as part of a complex weighted scoring system that
basically built a 'quality' picture of arrivals - back in the day when
too few legitimate ISP's *bothered* to make the DNS entries they should
have had and/or HELO with a FQDN (still a problem), etc.
Once every mailadmin started to realize that a 40-million PC bot-farm
probably didn't own five matching PTR RR among the whole lot of 'em ..
the PTR RR test became essential as well as 'cheap'.
But switch it on only as a 'warn' first. Check the logs, and see whom
you might not want to reject.
That's why it is not the first step...
Bill
