> > And, conversely, DNSBLs with > > weights < postscreen_dnsbl_threshold should not be listed in > > smtpd_*_restrictions because they could block an email on their own, > > even > > though they are not trusted to do so by postscreen. > > Not in all cases. Where postscreen by necessity offers limited ability > to whitelist sessions from DNSBL interference, the threshold mechanism > allows lists with different sorts of exceptional cases to block mail > only when multiple lists concur on a listing, effectively whitelisting > IPs based on how many lists of what scores they appear on. Yet you may > want to trust those lists as a basis to reject mail by default on their > own, with exceptions based on criteria that postscreen cannot use. [hypothetical example clipped]
Thank you very much Bill! I had not thought of that type of situation and that's exactly the type of example that I needed to help me understand the nuance. > > > If a DNSBL in postscreen_dnsbl_sites has a weight >= > > postscreen_dnsbl_threshold, then is there any advantage to also > > listing it > > in smtpd_*_restrictions? For example, is there some failure mode that > > having the DNSBL listed in both places would protect against? > > As noted by Allen Coates, if postscreen_dnsbl_ttl (v2.8-v3.0) or > postscreen_dnsbl_min_ttl (3.1) is higher than the negative cache TTL for > a DNSBL, postscreen can 'PASS OLD' an IP which has been listed in the > period since its prior connection during which the resolver cache of the > negative result has expired, so smtpd can see a listing that postscreen > does not. This is what I'm still a little fuzzy on. In v2.8-3.0, and assuming the postscreen_dnsbl_ttl default of 1 hour, I can understand Alan's example. A new bad guy starts up and gets through the first time, which postscreen caches for a default of 1 hour. The bad guy then starts his attacks within that hour of time and gets added to DNSBLs. But postscreen doesn't see it for an hour, while smtpd does (assuming the actual DNSBL's TTL is < 1 hour). I think I understand that part. But in v3.1, with the default postscreen_dnsbl_min_ttl of 60 seconds, and postscreen using the actual TTL from the DNSBL, it seems like that issue no longer exists. Here's my understanding: Using the same scenario, postscreen caches the positive answer on the first connect. And, according to Wietse, smtpd uses the same caching resolver. So when smtpd does the lookup probably less than a second later, it should get the answer from the resolver's cache, which should be the same answer that postscreen got. Now the bad guy starts his attacks and gets added to the DNSBLs. If the TTL has not yet expired, then postscreen uses it's positive cached value and smtpd will still get a positive answer from the resolver's cache. If the TTL has expired, then both postscreen and smtpd would get a new, negative answer. There may be miniscule differences in timing. But I would think the results would be virtually identical. Is that right? If not, what am I missing? Also, for pre v3.1 users, is there a best practice recommended value for postscreen_dnsbl_ttl that is better than the default of 1 hour? Thanks, Michael
