On 5 Jun 2016, at 2:30, Peter wrote:
On 05/06/16 17:10, Michael Fox wrote:
Right. As I mentioned, I understand that part. My question was
about v3.1+
where the default for postscreen_dnsbl_min_ttl is only 60s. And, as
I
understand it, the defaults for v3.1 would cause both the postscreen
cache
ttl and the system resolver's cache ttl to be based on the same ttl
from the
actual DNSBL record, thus rendering the same result for both, and the
same
timeout for both.
Unless I've got that wrong, no need to respond.
I think you have it mostly right, but there are some cases where the
results could differ between postscreen and smtpd:
1. There will be a very small window of time (we're talking
milliseconds) between when postscreen checks the expire time and when
smtpd attempts to lookup the record. The DNS record could expire
during
this very small window of time and if it has changed since the last
time
that the resolver fetched the record the result could be different.
2. The resolver might be broken and not caching the record, or
caching
it for a shorter or longer period of time than the TTL states.
3. You could (as is common) have two different resolvers listed in
your
resolv.conf (or your OSes equivalent) file. These resolvers could
have
cached the record at different times, and if the record was updated in
between they could have different results. It is possible that
postscreen could have randomly hit one resolver and smtpd hits the
other
thereby giving different results.
4. The resolver cache honors (as most do) a DNSBL's negative cache TTL
which is less than 60 seconds, e.g. Spamcop (0 seconds) or the various
Spamhaus lists (10) and others.
