>>>>> "Tor" == Tor Slettnes <tor@???> writes:
>> That'll lose you some mail from sites where the HELO name is
>> actually a valid FQDN, but isn't resolvable from outside the
>> sender's network (I've seen that happen several times for various
>> reasons). In such cases the "deny" above may end up deferring the
>> mail indefinitely, since the dnsdb lookup will cause it to defer
>> on a query timeout or SERVFAIL.
Tor> No, that is bad information.
You are mistaken.
Tor> Note that the statement above does NOT read:
Tor> ${if eq {${lookup dnsdb{a=$sender_helo_name}{$value}fail}}} ...
Tor> ^^^^
Tor> Without the "fail", if the "dnsdb" lookup fails, an empty string
Tor> is extracted. No harm done.
This is not true if the dnsdb lookup fails due to timeout or SERVFAIL.
In that case, the entire expansion is aborted and the acl defers.
There is no way to override this behaviour, except (for 4.33 and
later) to do the expansion in a "warn" statement.
The second result parameter of the lookup is used _only_ if the lookup
returns a definitive failure (NODATA or NXDOMAIN).
Tor> BTW, I know what I am talking about.
No, I'm sorry but you don't.
(The behaviour change in 4.33 was the result of my patch, posted here,
which in turn was the result of investigating the entire code path
between DNS lookup failure and ACL processing in order to find the
easiest place to fix.)
Tor> As you probably could tell, I am using this condition myself.
So? I'd been using dnsdb lookup conditions in ACLs for several weeks
at least before I noticed the expansion deferral problems, and that
only because I was paranoid enough to check the logs rather carefully.
This isn't a particularly common problem.
Test your configuration by finding a hostname that gives SERVFAIL when
you try and resolve it; use it in the HELO parameter of a -bh test, and
post the results here.
--
Andrew, Supernews
http://www.supernews.com
