On 22 Oct 2021, at 01:09, Gerben Wierda <[email protected]> wrote:
>
>>
>> On 21 Oct 2021, at 14:35, Wietse Venema <[email protected]
>> <mailto:[email protected]>> 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 <http://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
> <http://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
> <http://zen.spamhaus.org/>; Error: open resolver;
> https://www.spamhaus.org/returnc/pub/74.63.25.250
> <https://www.spamhaus.org/returnc/pub/74.63.25.250>;
> from=<[email protected]
> <mailto:[email protected]>>
> to=<[email protected] <mailto:[email protected]>> proto=ESMTP
> helo=<mta-222-103.sparkpostmail.com <http://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 <http://zen.spamhaus.org/>
>
> to
>
> postscreen_dnsbl_sites = zen.spamhaus.org
> <http://zen.spamhaus.org/>=127.0.0.[2..11]
And of course, this also holds for:
reject_rbl_client zen.spamhaus.org=127.0.0.[2..11],
Actually, I have noticed I have both now,
smtpd_client_restrictions/reject_rbl_client and postscreen_dnsbl_sites
Hmm, if I have the postscreen one, isn’t the smtpd_client_restrictions one
superfluous?
G
>
> 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
