Re: postscreen appears to be misinterpreting zen.spamhaus.org's error return codes
On 2021-05-29 at 10:22:23 UTC-0400 (Sat, 29 May 2021 10:22:23 -0400) Timo Geusch is rumored to have said: The fix/workaround in my case is relatively easy as I mostly need to update the configuration for my local DNS server. That said, I'm not sure if postscreen should treat this kind of error as a denylisted server? If you *TELL* postscreen to treat different DNSBL reply values differently, then it will. For example: postscreen_dnsbl_sites = zen.spamhaus.org=127.0.0.2*2 zen.spamhaus.org=127.0.0.3*2 zen.spamhaus.org=127.0.0.4*2 zen.spamhaus.org=127.0.0.10*2 zen.spamhaus.org=127.0.0.11*2 psbl.surriel.com=127.0.0.2*1 ix.dnsbl.manitu.net=127.0.0.2*1 postscreen_dnsbl_threshold = 2 That has existed for as long as postscreen has existed. The syntax is similar for reject_rbl_client (without the '*weight' component) which goes backs to v2.1. DNSBLs have a long history of dying in "list the world" events after their domains are abandoned to DNS-wildcarding domain vultures, so not using the available facilities to specify expected reply values is well-known to be risky configuration. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: postscreen appears to be misinterpreting zen.spamhaus.org's error return codes
On 30/05/2021 12:47, Laura Smith wrote: It is a fairly recent change, perhaps a year ago, that they return the .254 and .255 codes rather than just ignoring the request, as a hint that you need to fix your configuration. Seems the change is dated 11/2/2021 (https://www.spamhaus.org/news/article/807/using-our-public-mirrors-check-your-return-codes-now) In defence of my earlier comment, I'm a paid Spamhaus customer so I don't use the public mirrors anyway. ;-) Hello, non-professional (amateur?) postfixer here. May i suggest updating the http://www.postfix.org/SMTPD_ACCESS_README.html to reflect the most recent handling of codes by spamhaus? While postfix' reject_rbl_client restriction clearly is documented that by default any found A record is considered rejected, and as Wietse pointed out in Message-Id: <4fslfb2xxmzj...@spike.porcupine.org> this is due to postfix not implementing provider-specific parsing (note: which seems sensible to me), the Spamhaus DNSBL Usage FAQ https://www.spamhaus.org/faq/section/DNSBL%20Usage#200 documents that certain codes (returned A records) decidedly do not confer reputation information. Since the aforementioned SMTPD-ACCESS-README includes an example for spamhaus, i think this example should include the provider-specific settings. A quick google found this HowTo, which seems somehow associated with the Spamhaus Project https://docs.spamhaustech.com/datasets/docs/source/40-real-world-usage/PublicMirrors/MTAs/020-Postfix.html and which recommends the following reject_rbl_client restriction: smtpd_recipient_restrictions = ... reject_rbl_client zen.spamhaus.org=127.0.0.[2..11] ... However, the aforementioned DNSBL Usage FAQ would indicate that any A record from the 127.0.0.0/24 range should be considered rejected, not only 2..11. Therefore i propose to update the relevant section in SMTPD-ACCESS-README as follows (only new version shown): .. BEGIN # Spam control: exclude local clients and authenticated clients # from DNSBL lookups. smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, # reject_unauth_destination is not needed here if the mail # relay policy is specified under smtpd_relay_restrictions # (available with Postfix 2.10 and later). reject_unauth_destination reject_rbl_client zen.spamhaus.org=127.0.0.[0..255], reject_rhsbl_reverse_client dbl.spamhaus.org=127.0.1.[0..255], reject_rhsbl_helo dbl.spamhaus.org=127.0.1.[0..255], reject_rhsbl_sender dbl.spamhaus.org=127.0.1.[0..255] .. END * please double-check for any typos. * I think the example should be sensible for most postfix users from the "newbie" sub-group of users. I am unsure if the ZRD domain list should also be queried for this example. If yes, the respective patterns would need change from "=127.0.1.[0..255]" to "=127.0.[12].[0..255]". Faced with doubt, i didn't include ZRD (Spamhaus Zero Reputation Domains list). with best regards, Max
Re: postscreen appears to be misinterpreting zen.spamhaus.org's error return codes
> It is a fairly recent change, perhaps a year ago, that they return the .254 > and .255 > codes rather than just ignoring the request, as a hint that you need to fix > your > configuration. > > Seems the change is dated 11/2/2021 (https://www.spamhaus.org/news/article/807/using-our-public-mirrors-check-your-return-codes-now) In defence of my earlier comment, I'm a paid Spamhaus customer so I don't use the public mirrors anyway. ;-)
Re: postscreen appears to be misinterpreting zen.spamhaus.org's error return codes
On 5/29/21 2:19 PM, John Levine wrote: According to Bastian Blank : Already addressed it, however I figured it would be worth mentioning on here as it seem to be a fairly recent change at SpamHaus's end. No, it is not a recent change. SpamHaus rejects requests via done public resolvers since a long time. It is a fairly recent change, perhaps a year ago, that they return the .254 and .255 codes rather than just ignoring the request, as a hint that you need to fix your configuration. Based on this discussion, I suspect that it was a combination of one or more of the resolvers I used being (re)classified as public ones, and the change in return values that ended up making the problem visible. Fortunately once I figured out what the issue was, it was a relatively easy fix in my local resolver config without having to touch the Postfix configuration.
Re: postscreen appears to be misinterpreting zen.spamhaus.org's error return codes
According to Bastian Blank : >> Already addressed it, however I figured it would be worth mentioning on here >> as it seem to be a fairly recent change at SpamHaus's end. > >No, it is not a recent change. SpamHaus rejects requests via done >public resolvers since a long time. It is a fairly recent change, perhaps a year ago, that they return the .254 and .255 codes rather than just ignoring the request, as a hint that you need to fix your configuration. -- Regards, John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
Re: postscreen appears to be misinterpreting zen.spamhaus.org's error return codes
On Sat, May 29, 2021 at 11:55:02AM -0400, Timo Geusch wrote: > On 5/29/21 11:03 AM, Wietse Venema wrote: > > Timo Geusch: > > > Based on zen.spamhaus.org's documentation 127.255.255.25[245] are > > > actually error codes and not indicators of allow/denylisting - in this > > > case, their error is that I was querying via a public resolver, see link > > > here: https://www.spamhaus.org/faq/section/DNSBL%20Usage#200 > > So don't do that. > Already addressed it, however I figured it would be worth mentioning on here > as it seem to be a fairly recent change at SpamHaus's end. No, it is not a recent change. SpamHaus rejects requests via done public resolvers since a long time. Maybe you changed resolver or they recently recategorized your resolver as public. So don't do that, but always use a dedicated one. Bastian -- Is truth not truth for all? -- Natira, "For the World is Hollow and I have Touched the Sky", stardate 5476.4.
Re: postscreen appears to be misinterpreting zen.spamhaus.org's error return codes
On Saturday, 29 May 2021 16:55, Timo Geusch wrote: > On 5/29/21 11:03 AM, Wietse Venema wrote: > > > Timo Geusch: > > > > > Based on zen.spamhaus.org's documentation 127.255.255.25[245] are > > > actually error codes and not indicators of allow/denylisting - in this > > > case, their error is that I was querying via a public resolver, see link > > > here: https://www.spamhaus.org/faq/section/DNSBL%20Usage#200 > > > > So don't do that. > > Already addressed it, however I figured it would be worth mentioning on here > as it seem to be a fairly recent change at SpamHaus's end. > Not sure how "fairly recent" you are implying that change is ? Certainly not in the past year based on the main.cf on my server which hasn't been edited since May 2020 (and perhaps longer than that since I think my edit back then was unrelated).
Re: postscreen appears to be misinterpreting zen.spamhaus.org's error return codes
On 5/29/21 11:40 AM, Phil Stracchino wrote: On 5/29/21 10:22 AM, Timo Geusch wrote: Based on zen.spamhaus.org's documentation 127.255.255.25[245] are actually error codes and not indicators of allow/denylisting - in this case, their error is that I was querying via a public resolver, see link here: https://www.spamhaus.org/faq/section/DNSBL%20Usage#200 The fix/workaround in my case is relatively easy as I mostly need to update the configuration for my local DNS server. That said, I'm not sure if postscreen should treat this kind of error as a denylisted server? I ran into the same issue. The solution in my case was to remove the DNSBL checks from Postscreen, and reconfigure rspamd to use Spamhaus's free Data Query Service. As a bonus, rspamd learns more about recognizing spam if it is performing the RBL checks itself. Thanks, that's good to know. I'm planning to switch to rspamd when I redo the server so I'll add that to my todo list.
Re: postscreen appears to be misinterpreting zen.spamhaus.org's error return codes
On 5/29/21 11:03 AM, Wietse Venema wrote: Timo Geusch: Based on zen.spamhaus.org's documentation 127.255.255.25[245] are actually error codes and not indicators of allow/denylisting - in this case, their error is that I was querying via a public resolver, see link here: https://www.spamhaus.org/faq/section/DNSBL%20Usage#200 So don't do that. Already addressed it, however I figured it would be worth mentioning on here as it seem to be a fairly recent change at SpamHaus's end. The fix/workaround in my case is relatively easy as I mostly need to update the configuration for my local DNS server. That said, I'm not sure if postscreen should treat this kind of error as a denylisted server? postscreen has no provider-specific parsing of DNSBL status codes. Instead, postscreen assumes that all replies are true positives. To select specific responses, see the fine postscreen_dnsbl_sites documentation. Makes sense, thanks for the pointer.
Re: postscreen appears to be misinterpreting zen.spamhaus.org's error return codes
On 5/29/21 10:22 AM, Timo Geusch wrote: > Based on zen.spamhaus.org's documentation 127.255.255.25[245] are > actually error codes and not indicators of allow/denylisting - in this > case, their error is that I was querying via a public resolver, see link > here: https://www.spamhaus.org/faq/section/DNSBL%20Usage#200 > > The fix/workaround in my case is relatively easy as I mostly need to > update the configuration for my local DNS server. That said, I'm not > sure if postscreen should treat this kind of error as a denylisted server? I ran into the same issue. The solution in my case was to remove the DNSBL checks from Postscreen, and reconfigure rspamd to use Spamhaus's free Data Query Service. As a bonus, rspamd learns more about recognizing spam if it is performing the RBL checks itself. -- Phil Stracchino Babylon Communications ph...@caerllewys.net p...@co.ordinate.org Landline: +1.603.293.8485 Mobile: +1.603.998.6958
Re: postscreen appears to be misinterpreting zen.spamhaus.org's error return codes
Timo Geusch: > Based on zen.spamhaus.org's documentation 127.255.255.25[245] are > actually error codes and not indicators of allow/denylisting - in this > case, their error is that I was querying via a public resolver, see link > here: https://www.spamhaus.org/faq/section/DNSBL%20Usage#200 So don't do that. > The fix/workaround in my case is relatively easy as I mostly need to > update the configuration for my local DNS server. That said, I'm not > sure if postscreen should treat this kind of error as a denylisted server? postscreen has no provider-specific parsing of DNSBL status codes. Instead, postscreen assumes that all replies are true positives. To select specific responses, see the fine postscreen_dnsbl_sites documentation. Wietse
postscreen appears to be misinterpreting zen.spamhaus.org's error return codes
Hello, I just noticed this particular behaviour as I was trying to track down some issues as apparently my mail server was bouncing legitimate emails from a few senders (including some freebsd mailing lists and also postfix-users as I discovered afterwards). This is on the FreeBSD port of Postfix 3.6.0. Here's snippet from the maillog: May 29 04:31:47 mail-server postfix/postscreen[57886]: CONNECT from [remote-mail-server-ip]:51120 to [my-mail-server-ip]:25 May 29 04:31:47 mail-server postfix/dnsblog[59708]: addr remote-mail-server-ip listed by domain zen.spamhaus.org as 127.255.255.254 May 29 04:31:53 mail-server postfix/postscreen[57886]: DNSBL rank 2 for [remote-mail-server-ip]:51120 May 29 04:31:53 mail-server postfix/tlsproxy[60045]: CONNECT from [remote-mail-server-ip]:51120 May 29 04:31:53 mail-server postfix/tlsproxy[60045]: Anonymous TLS connection established from [remote-mail-server-ip]:51120: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 May 29 04:31:53 mail-server postfix/postscreen[57886]: NOQUEUE: reject: RCPT from [remote-mail-server-ip]:51120: 550 5.7.1 Service unavailable; client [remote-mail-server-ip] blocked using zen.spamhaus.org; [...redacted...] Based on zen.spamhaus.org's documentation 127.255.255.25[245] are actually error codes and not indicators of allow/denylisting - in this case, their error is that I was querying via a public resolver, see link here: https://www.spamhaus.org/faq/section/DNSBL%20Usage#200 The fix/workaround in my case is relatively easy as I mostly need to update the configuration for my local DNS server. That said, I'm not sure if postscreen should treat this kind of error as a denylisted server? With best regards, Timo
