On 22 May 2013, at 11:02, Noel Jones wrote:
so, the RBLs are getting utilized by postscreen before it even hits
the smtp service. So, am I right to assume that the
reject_rbl_client lines in my smtpd_recipient_restrictions are no
longer needed?
No, not needed. But some folks like to leave them in anyway because
1) they're "free" if the DNS response is currently cached and 2)
postscreen internally caches "PASS" status, possibly after a bad
client is newly listed in an rbl.
And 3) there are more fine-tuned configurations available via the core
Postfix settings to handle cases where you can tolerate "false positive"
hits for some addresses but not others. For example: my own system
serving family and friends has a handful of older addresses whose
history has left them with massive spam loads, but the overwhelming
volume of its legitimate mail is aimed at other addresses using a couple
of different "tagging" patterns that are aliases for those legacy
addresses. Because the tagged addresses are shared in narrower ways,
they rarely get spam of any sort and are easily burned when they do. I
use DNSBLs that can be overaggressive which alone each fall short of my
postscreen limit, but which also are in a reject_rbl_client rules AFTER
a check_recipient_access rule which OK's the alias patterns. The result
is that mail to tagged addresses has more lenient treatment with respect
to those FP-prone DNSBLs and I don't have to work out the issue of how
and whether to whitelist legit mail from problematic mixed sources in
Postfix.
