> 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

Reply via email to