On Fri, Oct 16, 2020 at 06:04:20PM -0300, David Wells wrote:
> > smtpd_recipient_restrictions =
> > permit_mynetworks, permit_sasl_authenticated,
> > check_sender_access hash:/etc/postfix/sender_access,
> > check_recipient_access hash:/etc/postfix/protected_destinations,
> > check_client_access hash:/etc/postfix/rbl_whitelist,
> > check_client_access regexp:/etc/postfix/rbl_whitelist_regexp,
> > reject_unauth_destination,
Wietse's answer is the most obvious starting point, but if you want
to also look elsewhere:
Why is there a "check_sender_access" *before*
"reject_unauth_destination", and before the RBL checks? Does the
"sender_access" table have anything other than REJECT rules?
> > reject_rbl_client zen.spamhaus.org,
> > reject_rbl_client bl.spamcop.net,
> > reject_rbl_client dnsbl.sorbs.net,
> > reject_rbl_client dyna.spamrats.com,
> > reject_rbl_client spam.spamrats.com,
> > reject_rbl_client noptr.spamrats.com,
> > reject_rbl_client auth.spamrats.com,
> > reject_rbl_client dnsbl-1.uceprotect.net,
> > reject_rbl_client dnsbl-2.uceprotect.net,
> > reject_rbl_client dnsbl-3.uceprotect.net,
> > reject_rbl_client b.barracudacentral.org,
> > reject_rbl_client dnsbl.spfbl.net,
> > reject_rbl_client rbl.blockedservers.com,
> > reject_rbl_client bl.mailspike.net,
> > reject_rbl_client bl.nosolicitado.org,
> > reject_rbl_client all.s5h.net
That's way too many, and many certainly too aggressive to be sufficient
on their own for a definitive reject. Just zen.spamhaus.org is
generally all you can use without combining results for scoring.
And you certainly don't need a "noptr" list, just use:
reject_unknown_reverse_client_hostname
> > smtpd_restriction_classes = insiders_only
Where does this come into play?
--
Viktor.
