>>>>> "W" == W B Hacker <wbh@???> writes:
W> From the 4.6X spec:
W> ${lookup dnsdb{mx=a.b.example}{$value}fail}
The spec does not show this being used as the value of a condition=
clause in an ACL.
>> 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.)
W> Well - therein lies the problem. Details below...
No, that's not the problem, it's just you trying to look up completely
the wrong thing.
>> 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.
W> No disagreement - but the spec is what I am going by (as pasted at
W> the top..
W> Not *yet* as concerned with pass/fail as just what happens with
W> by-the-book-example.
At least read the correct part of the spec. The description of the
condition= clause in an ACL is this:
condition = <string>
This feature allows you to make up custom conditions. If the
result of expanding the string is an empty string, the number
zero, or one of the strings "no" or "false", the condition is
false. If the result is any non-zero number, or one of the strings
"yes" or "true", the condition is true. For any other values, some
error is assumed to have occurred, and the ACL returns "defer".
The ${lookup expansion you are supplying isn't going to return true/1
or false/0, it's going to either return the result of the lookup, in
which case the ACL returns "defer" as described above, or force a
failure causing the condition to skip. Neither is what you want.
>> 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.
W> ACK. *However*, per archives from a few years ago, Exim then used
W> gethostbyaddr() - whih could ONLY be satisfied by a PTR record.
W> It *seems* to now be more flexible. At least it gives a 'pass' to
W> many sources for whom a 'host -v' or 'dig ...' are less forgiving.
You'll have to give an example (watch out for caching effects, which
can result in the first lookup of something succeeding, but subsequent
lookups returning SERVFAIL).
>> Using dnsdb correctly is trickier than it looks because of the
>> need to handle temporary failures sanely.
W> Absolutely! Hence the post...
I don't think you're thinking clearly enough yet about what you're
doing to worry about the finer points.
That said, the way to use dnsdb is something like this:
warn set acl_c0 = :defer
set acl_c0 = ${lookup dnsdb{ptr=...}{$value}{:fail}}
# do not try and add any other conditions to this "warn",
# as they won't be run in the event of a soft-fail,
# but instead follow with another acl verb
# At this point, acl_c0 contains one of three things:
# if the lookup succeeded, it contains the result
# if the lookup hard-failed, it contains ":fail"
# if the lookup soft-failed, it contains ":defer"
>> As for your results, don't bother with redacted logs, just show us
>> the exim -bh session.
W> ah - given that it creates an 82 KB file of 1807 lines (wrapped),
W> I don't see the relevance.
The relevence is that you're asking for debugging of a complex ACL
condition while only giving snippets of information.
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.
W> ... 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.
W> ..and generally of diminishing value in a world where even
W> major-vendor ISP's choose to hello with strings that are totally
W> devoid of any relevance to their DNS entries - or even subnetted
W> hostnames. :-(
W> No - this is about a different issue, i.e just what *was*
W> found/not found.
W> Dodgy/cheating DNS resolvers quite aside - what records DOES the
W> caller have?
Initially, you only know the caller by its IP address. The only thing
that it makes sense to look up in DNS, given an IP address, is the
corresponding PTR record.
If the PTR record you find does not resolve back to the IP, then it is
worthless, and verify = reverse_host_lookup will ignore it (and it will
not appear in $sender_host_name).
You can find out the value(s) of the bogus PTR record(s), if any, using
dnsdb as described above.
W> - and do we wish to continue a session if they are:
W> 1) perfect match (yes)
W> 2) slightly flawed, but not trying to hide (practical necessity)
How do you define "not trying to hide"?
I see hundreds of spam zombies connecting with PTR records that don't
forward-resolve. I see the rare case of a legitimate mail source doing
the same, but it really is rare, and many mail flows will not see this
at all.
W> 3) 'Acceptable' only IF we sort out subnetting/prefixes that are
W> NOT in DNS (all too common, 'Yes, but *how best* to do so')
Subnetting has nothing to do with DNS.
W> 4) NOT if they have NO records (nearly all zombies, but quite a
W> few major-ISP outbound 'pools' as well). Trying to find a solution
W> for those beside manual/semi-auto whitelisting.
W> Looks as if this may require a call to external tools.
Unlikely.
--
Andrew, Supernews
http://www.supernews.com
