On 2 Jun 2016, at 12:45, Michael Fox wrote:
So, as I understand it: as long as the weight assigned to a DNSBL in
postscreen is >= postscreen_dnsbl_threshold, then there is no harm in
also
adding the same DNSBL to smtpd_*_restrictions.
True.
But this is not the whole story...
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.
Consider this hypothetical example based on a substantial simplification
and minor obfuscation of my own personal system's config:
smtpd_recipient_restrictions = permit_mynetworks,
check_sender_access regexp:/opt/local/etc/postfix/badsenders
reject_unknown_sender_domain, reject_unauth_destination,
check_sender_access regexp:/opt/local/etc/postfix/goodsenders,
reject_unknown_reverse_client_hostname,
check_sender_mx_access cidr:/opt/local/etc/postfix/bogus_mx.cidr
reject_rbl_client zen.spamhaus.org
check_recipient_access
regexp:/opt/local/etc/postfix/recipient_checks.regex,
reject_rbl_client badrirblocks.local,
reject_rbl_client deathstarblocks.local,
reject_rbl_client overaggressive.example.com,
reject_rbl_client staleentries.example.com,
reject_rbl_client korea.services.net,
reject_rbl_client psbl.surriel.com,
reject_rbl_client ix.dnsbl.manitu.net,
check_client_access
regexp:/opt/local/etc/postfix/client_checks.regex,
permit
postscreen_access_list = permit_mynetworks,
cidr:/opt/local/etc/postfix/ps-noblock.cidr
postscreen_dnsbl_sites = zen.spamhaus.org*4
badrirblocks.local*1
deathstarblocks.local*2
overaggressive.example.com*2
staleentries.example.com*1
korea.services.net*3
psbl.surriel.com*3
ix.dnsbl.manitu.net*3
postscreen_dnsbl_threshold = 4
So, I have 2 distinct local DNSBLs. One (badrirblocks.local) includes
(hypothetically) every RIR-level allocation from which any of the few
users here have received one or more spams and no ham to untagged
addresses. In the other (deathstarblocks.local) I have tried imperfectly
to list all the ranges allocated to residential customers by a specific
very large (and hence inevitably a bit evil) ISP who shall remain
nameless. I also put almost absolute trust in SpamHaus and use various
other public DNSBLs that either have known false positive problems or
might occasionally correctly (by their standards) list an address from
which I'd like to be able to receive mail to SOME recipients. To be
rejected by postscreen, an address must either be in Zen OR at least 2
(maybe 3) of the other DNSBLs. (Note that I actually have a more
nuanced/messy config of different scores for various lists' specific
return values but I've reduced it to this level of simplicity for the
sake of clarity.)
Note that "goodsenders" is a kludge. It's a few magic sender patterns,
any of them entirely forgeable, but obscure enough that forgery is
hugely improbable: people whose mail I want NEVER to lose, even if
there's a momentary glitch listing at SpamHaus. So is ps-noblock.cidr: a
few networks which could earn 'escalated' SBL listings but sometimes
send mail here that is very much wanted as well as trusted networks from
whence I could accidentally trigger a PREGREET test in trying to
troubleshoot/verify mail functionality via telnet. (I have a lethal
tripwire on PREGREET...)
The key to this config pattern is recipient_checks.regex. It has a bunch
of special recipient addresses and patterns that are exempt from the
DNSBLs that follow it, as well as a number of addresses and patterns
that have been leaked and/or abused to the point where I've made them
traps. The overall result: I don't bother with DNSBL checks or content
filtering for addresses that have become spamtraps and I skip over some
DNSBL checks for recipient addresses that I deem special, including many
but not all tagged addresses. The overwhelming majority of mail hitting
this server which gets past postscreen either gets blocked ahead of the
DNSBL checks in smtpd or gets exempted from the latter set of DNSBLs,
which still manage to properly catch hundreds of messages per day that
would otherwise need to be content-filtered. I actually use PSBL and IX
with no whitelisting (and no known false positives) on some non-Postfix
systems where I don't have the luxury of nuance.
Of course, not everyone needs or wants this level of complexity. This is
for a server that has a small number of users with about half of us
trying to keep long-lived and heavily spam-targeted addresses usable. I
wouldn't do this for 500 users.
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.
