On 2022-11-23 at 04:58:09 UTC-0500 (Wed, 23 Nov 2022 01:58:09 -0800)
Doug Hardie <bc...@lafn.org>
is rumored to have said:
I originally had incoming_smtpd_restrictions set to:
reject_unverified_recipient
reject_rbl_client bl.spamcop.net,
reject_rbl_client dnsbl.sorbs.net,
reject_rbl_client zen.spamhaus.org,
permit
Later I added postscreen and commented out the reject_rbl_... entries.
I included in main.cf:
postscreen_dnsbl_action = enforce
postscreen_dnsbl_sites = bl.spamcop.net
zen.spamhaus.org=127.0.0.[2..11] b.barracudacentral.org
This works as expected. However, I believe that postscreen is
processed prior to smtpd. I am experiencing a lot of emails that are
being sent to non-existent users. I don't have accurate counts, but
the vast majority of email is that. Postscreen is doing a DNS lookup
for every one of those. It seems it might be better to remove the
dnsrbl from postscreen and reinstate the reject_rbl statements into
incoming_smtpd_restrictions. I believe that way, only the mail that
has a valid recipient will have the dns rbls checked. Am I
understanding this correctly?
Yes and no.
If you use only postscreen for DNSBLs you do lookups on every IP, even
if it is eventually going to send garbage recipients.
If you use only smtpd_*_restrictions lists for DNSBLs and put
reject_unverified_recipient aherad of them, you save the DNS queries at
the cost of recipient queries to whatever verifies your recipients
(probably trivial, maybe not) for recipients offered by clients that
might have been shunned by postscreen.
If you use *both* and have a proper local DNS cache, the second DNS
query (in cases where you make it) will come from cache and be extremely
fast and cheap. In some edge cases (e.g. SORBS) you may find some
clients get through postscreen only because of slow DNS response and the
answer is oin cached by the time the smtpd query is made.
I use DNSBLs in both places because the second check is practically free
and the useful lists for the two are not the same. For example, I know
that I will probably not want to accept mail from machines on the
Spamhaus PBL, but there are exceptions so a listing there alone is not
adequate to block at the postscreen level without additional listings,
but if I have not seen a positive reason to accept the mail by the end
of smtpd_recipient_restrictions, a PBL listing will kill it.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire