> On 21 Oct 2021, at 14:35, Wietse Venema <wie...@porcupine.org> wrote: > > Gerben Wierda: >> My standard DNS forwards to cloud9 (9.9.9.9) because cloud9 blocks bad >> actors. But that means that DNSBL from spamhaus doesn?t work as the query to >> comes from a public DNS server. >> >> I am using: >> # Drop any SMTP client that talks before its turn (spam botnets in a hurry) >> postscreen_greet_action = drop >> # Drop any SMTP client that is in the DNSBL >> postscreen_dnsbl_sites = zen.spamhaus.org*2 >> postscreen_dnsbl_action = drop >> >> I have a secondary resolver that doesn?t forward to cloud9. Can I >> use that local DNS instead of the standard one in postfix, preferably >> for postscreen DNSBL only? > > Postfix does not choose its DNS resolvers. Instead, Postfix uses > the libresolv system library. Historically, that library has no API > to specify resolver IP address(es), and it is unlikely that Postfix > will implement its own libresolv functionality. > > On the wishlist is to have a Postfix resolver *plugin* API, like > Postfix has the XSASL API for different SASL backends (Cyrus, > Dovecot). Then, Postfix could call into alternative resolver > libraries. > > Meanwhile could you dnsmasq et al. to manage how queries are routed?
Actually, the whole question was based on a misunderstanding what was going wrong. In my log I saw this and this was a false positive for DNSBL Oct 21 11:15:35 mail smtp/smtpd[41623]: NOQUEUE: reject: RCPT from mta-222-103.sparkpostmail.com[147.253.222.103]: 554 5.7.1 Service unavailable; Client host [147.253.222.103] blocked using zen.spamhaus.org; Error: open resolver; https://www.spamhaus.org/returnc/pub/74.63.25.250; from=<msprvs1=18928J6ijWitt=bounces-1...@sp-mail.networkapp.eu> to=<gerben.wie...@rna.nl> proto=ESMTP helo=<mta-222-103.sparkpostmail.com> I wrongly concluded that this had to do with me using a forwarder in my DNS resolver setup (unbound forwarding to a public resolver like 9.9.9.9), but it had nothing to do with that. What actually was the case that I had to update my main.cf from postscreen_dnsbl_sites = zen.spamhaus.org to postscreen_dnsbl_sites = zen.spamhaus.org=127.0.0.[2..11] because spamhaus has added extra answers that are not about the IP checked, but about DNSBL itself and the query. What still eludes me is why this false positive was not happening all the time but only now and then. Most of the time DNSBL worked fine, More info: https://www.spamhaus.org/news/article/807/using-our-public-mirrors-check-your-return-codes-now <https://www.spamhaus.org/news/article/807/using-our-public-mirrors-check-your-return-codes-now> and Using postscreen instead <https://docs.spamhaus.com/datasets/docs/source/40-real-world-usage/PublicMirrors/MTAs/020-Postfix.html#using-postscreen-instead> The examples in the postfix doc might warn for false positives for DNSBL resolvers that have a wider range of answers, because those require the = part of the setting. G