[pfx] Re: Ignoring postscreen DNSBL disposition by recipient address
On 2024-03-17 at 05:55:43 UTC-0400 (Sun, 17 Mar 2024 10:55:43 +0100) Matus UHLAR - fantomas via Postfix-users is rumored to have said: On 15.03.24 15:06, Noel Jones via Postfix-users wrote: Postscreen by design only looks at the IP, and has no mechanism to consider other envelope data. The solution is to not use a DNSBL that routinely blocks wanted mail in postscreen. Or, set postscreen_dnsbl_threshold high enough so it does not rely on listing in single list. You could e.g. set up: postscreen_dnsbl_sites = zen.spamhaus.org=127.0.0.[0..255] dnsbl.sorbs.net=127.0.0.[0..255] bl.spamcop.net=127.0.0.2 list.dnswl.org=127.0.[0..255].[0..255]*-1 list.dnswl.org=127.0.[0..255].3*-1 postscreen_dnsbl_threshold=2 maybe if you trust spamhaus enough, append *2 to it It is not about "trusting spamhaus" but rather understanding what Spamhaus intends the Zen aggregate to be. It is unsuitable for postscreen *by design* if you treat any last octet as a hit. The same problem exists for SORBS and SpamCop. The unwanted hit you might get out of some of the Zen subcomponents stand a real chance of being hit for the same reasons by the others. They are not entirely independent factors. Concretely: that combination is likely to cause you to block individual random behemoth mailbox provider outputs and chunks of VPS hosting space including non-spammers for hours to days at a time. That risk may acceptable for some sites, but it goes well beyond postscreen's explicit design intent. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Ignoring postscreen DNSBL disposition by recipient address
On 15.03.24 15:06, Noel Jones via Postfix-users wrote: Postscreen by design only looks at the IP, and has no mechanism to consider other envelope data. The solution is to not use a DNSBL that routinely blocks wanted mail in postscreen. Or, set postscreen_dnsbl_threshold high enough so it does not rely on listing in single list. You could e.g. set up: postscreen_dnsbl_sites = zen.spamhaus.org=127.0.0.[0..255] dnsbl.sorbs.net=127.0.0.[0..255] bl.spamcop.net=127.0.0.2 list.dnswl.org=127.0.[0..255].[0..255]*-1 list.dnswl.org=127.0.[0..255].3*-1 postscreen_dnsbl_threshold=2 maybe if you trust spamhaus enough, append *2 to it On 3/15/2024 1:11 PM, Matt Saladna via Postfix-users wrote: Mar 15 13:51:22 atlas postfix/postscreen[5978]: NOQUEUE: reject: RCPT from [1.2.3.4]:51944: 550 5.7.1 Service unavailable; client [1.2.3.4] blocked using zen.spamhaus.org; from=, to=, proto=ESMTP, helo= Postscreen config: postscreen_dnsbl_action=enforce postscreen_dnsbl_sites=bl.spamcop.net*2 b.barracudacentral.org*2 zen.spamhaus.org=127.0.[0;1;2].[0..254]*2 list.dnswl.org*-2 I'm somewhat surprised that your (fake) sample singles out zen. It's been pretty reliable for me. postscreen reports the first dns?l that replies. Thus, it can also report "blacklisted by dnswl" if dnswl catches first. That's why postscreen_dnsbl_reply_map exists postscreen_dnsbl_reply_map=texthash:/etc/postfix/dnsbl_map % cat /etc/postfix/dnsbl_map list.dnswl.org multiple DNS-based blocklists -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. I don't have lysdexia. The Dog wouldn't allow that. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Ignoring postscreen DNSBL disposition by recipient address
On 2024-03-15 at 14:11:03 UTC-0400 (Fri, 15 Mar 2024 13:11:03 -0500) Matt Saladna via Postfix-users is rumored to have said: Hello, I'm seeking a workaround for Microsoft's litany of IPs landing on DNSBL. They'd like all mail irrespective of DNSBL status to be delivered, which requires a skip if the sender IP is blacklisted in postscreen. With separation between postscreen and smtpd, postscreen rejects the connection before handing off to smtpd so smtpd_recipient_restrictions isn't triggered. Is there an appropriate workaround that allows postscreen to report DUNNO after DNSBL checks if the recipient matches in a table? No, which is because of how postscreen is designed, as a fit to its intended purpose. See the man page and supplementary README file for details. If you need to make recipient exceptions to postscreen, you are simply using it for the wrong function. It is a *lightweight* tool to dispose of pure spam sources without loading and using all the logic of the smtpd daemon. By default, postscreen is no longer in control by the time the greeting banner is sent. If you wish to do anything complicated with deciding whether to accept a message, you need to do it later in the SMTP transaction. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Ignoring postscreen DNSBL disposition by recipient address
On 3/15/2024 3:06 PM, Noel Jones via Postfix-users wrote: > You can move those checks into smtpd restrictions where there can be an allowed sender list proceeding the DNSBL checks. Downside to this approach is no weighting. > Postscreen by design only looks at the IP, and has no mechanism to consider other envelope data. I had some optimism that there would be a mechanism to override the disposition since the envelope recipient is examined as part of the NOQUEUE log result. > I'm somewhat surprised that your (fake) sample singles out zen... Here, spamcop (especially) Ding ding. - Matt On 3/15/2024 1:11 PM, Matt Saladna via Postfix-users wrote: Hello, I'm seeking a workaround for Microsoft's litany of IPs landing on DNSBL. They'd like all mail irrespective of DNSBL status to be delivered, which requires a skip if the sender IP is blacklisted in postscreen. With separation between postscreen and smtpd, postscreen rejects the connection before handing off to smtpd so smtpd_recipient_restrictions isn't triggered. Is there an appropriate workaround that allows postscreen to report DUNNO after DNSBL checks if the recipient matches in a table? Postscreen by design only looks at the IP, and has no mechanism to consider other envelope data. The solution is to not use a DNSBL that routinely blocks wanted mail in postscreen. You can move those checks into smtpd restrictions where there can be an allowed sender list proceeding the DNSBL checks. Sample line: Mar 15 13:51:22 atlas postfix/postscreen[5978]: NOQUEUE: reject: RCPT from [1.2.3.4]:51944: 550 5.7.1 Service unavailable; client [1.2.3.4] blocked using zen.spamhaus.org; from=, to=, proto=ESMTP, helo= Postscreen config: postscreen_dnsbl_action=enforce postscreen_dnsbl_sites=bl.spamcop.net*2 b.barracudacentral.org*2 zen.spamhaus.org=127.0.[0;1;2].[0..254]*2 list.dnswl.org*-2 I'm somewhat surprised that your (fake) sample singles out zen. It's been pretty reliable for me. Here, spamcop (especially) and barracudacentral are much more likely to reject wanted mail. Of course, YMMV... -- Noel Jones ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Ignoring postscreen DNSBL disposition by recipient address
On 3/15/2024 1:11 PM, Matt Saladna via Postfix-users wrote: Hello, I'm seeking a workaround for Microsoft's litany of IPs landing on DNSBL. They'd like all mail irrespective of DNSBL status to be delivered, which requires a skip if the sender IP is blacklisted in postscreen. With separation between postscreen and smtpd, postscreen rejects the connection before handing off to smtpd so smtpd_recipient_restrictions isn't triggered. Is there an appropriate workaround that allows postscreen to report DUNNO after DNSBL checks if the recipient matches in a table? Postscreen by design only looks at the IP, and has no mechanism to consider other envelope data. The solution is to not use a DNSBL that routinely blocks wanted mail in postscreen. You can move those checks into smtpd restrictions where there can be an allowed sender list proceeding the DNSBL checks. Sample line: Mar 15 13:51:22 atlas postfix/postscreen[5978]: NOQUEUE: reject: RCPT from [1.2.3.4]:51944: 550 5.7.1 Service unavailable; client [1.2.3.4] blocked using zen.spamhaus.org; from=, to=, proto=ESMTP, helo= Postscreen config: postscreen_dnsbl_action=enforce postscreen_dnsbl_sites=bl.spamcop.net*2 b.barracudacentral.org*2 zen.spamhaus.org=127.0.[0;1;2].[0..254]*2 list.dnswl.org*-2 I'm somewhat surprised that your (fake) sample singles out zen. It's been pretty reliable for me. Here, spamcop (especially) and barracudacentral are much more likely to reject wanted mail. Of course, YMMV... -- Noel Jones ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
