Postfix should not handle DNSBLs anymore. We should let Postscreen handle this.

I went over #2976 and looked up some other resources and agree 👍

Everything below is primarily notes I put together while looking over the feature history, safe to ignore :)

This Spamhaus Postfix docs advises to defer to SpamAssassin or Rspamd via milter if either of those are setup, otherwise to prefer Postscreen. Should Postscreen still be enabled if Rspamd has the RBL module active?

This old Mailing list discussion with Postfix maintainers responding about reject_rbl_client vs postscreen_dnsbl_sites:

• The last quote cites one reason you may want both, but as Double zen.spamhaus.org check is excess? #2976 (comment) pointed out, that can likewise cause unwanted rejection from Postfix that a more advanced Postscreen check would have permitted.
• Postscreen typically only applies to inbound mail on port 25. Not likely a concern and a user can configure that if they need to? (besides postscreen shouldn't be used on submission ports)
• Overall favors preferring postscreen only.

Related issues / PRs for improved traceability

Mostly for my benefit 😅

• Dec 2022 feature request for Spamhaus DQS (Data Query Service) support. User appears to be manually approaching it with user-patches.sh and this may be a breaking change for them?
• Dec 2022 issue with change in Spamhaus policies with queries not configured for DQS (associated discussion thread), also references issues with SpamAssassin and Postscreen (resolved by @georglauterbach ). Also details benefit of approach with running your own recursive DNS resolver.
• Nov 2022 issue about Spamhaus changes and error code handling, resolved by this PR.
• July 2022 issue about Spamhaus causing blocks for all mail, despite not being listed, which is likely explained by issues referenced above. postscreen was still causing blocks due to the spamhaus response though, not only Postfix reject_rbl_client. They also state ENABLE_DNSBL=0 didn't help though 🤷‍♂️
• Jan 2022 introduced ENABLE_DNSBL. Releases with this feature onwards opt-out of DNSBLs.
• Feb 2021 issue about bl.spamcop.net failing due to expiry. Noted as any lookup to that blocklist was considered a failure preventing legitimate mail from being received. Removed by removing bl.spamcop.net for 8.0.1 #1782
• April 2020 issue about internal only setup being slowed down by DNSBLs that intentionally were unreachable, since fixed by opt-out with ENABLE_DNSBL=0.
• Jan 2018 introduced postscreen and postscreen_dnsbl_sites configured blocklists. Briefly asks about dropping Postgrey since Postscreen can replace it, but in the associated issue favors keeping Postgrey for more granular support. Both PR and issue quote from Postfix postscreen docs, such as the 4 layers of defense with Postscreen at the first layer, Postfix for the next two, and third-party service for the fourth on content (Amavis/SA, rspamd).
• April 2016 smtpd_recipient_restrictions updated to include three reject_rbl_client blocklists, one of these was removed not long after in May 2016 where it was reported as often blocking mail from popular vendors such as Gmail (the referenced wikipedia article also cites this), while the newer postscreen list has brought back that SORBS blocklist 😅 (NOTE: Possibly useful reference table of DNSBLs, one of these is Abusix, which DMS received a recent Feature Request to support)

DNS

Some advice over the years with the project for working around the many reports of false-positive blockings from the DNSBLs with public DNS resolvers:

• April 2018 - Googles 8.8.8.8 won't work, but Cloudflares 1.1.1.1 would: Logs & daily report contain lots of "warning: dnsblog_query: lookup error for DNS query" #948 (comment)

• June 2020 - Then neither of those but Quad9 9.9.9.9 would: XX.XX.XX.XX.list.dnswl.org: Host or domain name not found #1542 (comment)

• Jan 2021 - Use them all? 🤷‍♂️ : warning: dnsblog_query: lookup error for DNS query #1742 (comment)

• Nov 2021 - None will work, but 9.9.9.11 will because of ECS feature: 550 5.7.1 Service unavailable; client [xxx.xxx.xxx.xxx] blocked using zen.spamhaus.org #1927 (comment)

  The easiest solution would be to add a dns server which supports ECS.
  Spamhaus changed their policy in 2020 of accepting any query towards denying queries send via open resolvers due to misuse of their service.
  If you still identify yourself with your own IP they are still happy to serve you. And you'll keep their pretty good filter working.

    dns:
      - 9.9.9.11 #QUAD9 DNS Server with ECS enabled see: https://www.quad9.net/service/service-addresses-and-features/#ecssec

• July 2022 - None works properly, DIY: SpamAssassin local DNS lookups #2697 (comment)

  Spam filtering tools like SA, but also Postfix/Postscreen using DNSBLs, require a non-official, recursive DNS resolver.
  If you try to use official DNS servers (1.1.1.1, 9.9.9.9, etc.), you'll find that the answers to your queries are:

  1. at best, meaningless
  2. at worst, classifying legit mails as spam if Postfix for example is not configured correctly

  So, I figured: why not resolve the traffic to SpamHaus, Sorbs, DNSWL, SpamEatingMonkey etc. on my own and use official DNS servers for all the other DNS traffic.

Documentation preview for this PR is ready! 🎉

Built with commit: 0acf895