Where to place spamhaus tests
I have recently begun getting blocks from dbl.spamhaus.org for "valid" email. I thought a single instance was an aberration but in all I've seen half a dozen emails blocked - a large number for my small system. The original setup was... smtpd_helo_restrictions = ... reject_rhsbl_helo dbl.spamhaus.org smtpd_sender_restrictions = ... reject_rhsbl_sender dbl.spamhaus.org smtpd_recipient_restrictions = ... reject_rbl_client zen.spamhaus.org reject_rhsbl_client dbl.spamhaus.org I have now disabled the dbl.spamhaus tests but left in place the zen.spamhaus one. The mail server is an old one, running almost untouched for several years. The positioning of the spamhaus tests has not changed in some time until now. I am setting up a new server with postfix, spamassassin, dovecot etc but it has yet to receive any real mail. I am concerned that adding spamhaus tests to postfix on the new server may be detrimental even though, until now, I have seen no adverse reaction. Spamhaus has a page for setting up postfix and recommends... smtpd_recipient_restrictions = ... reject_rbl_client zen.spamhaus.org=127.0.0.[2..11] reject_rhsbl_sender dbl.spamhaus.org=127.0.1.[2..99] reject_rhsbl_helo dbl.spamhaus.org=127.0.1.[2..99] reject_rhsbl_reverse_client dbl.spamhaus.org=127.0.1.[2..99] warn_if_reject reject_rbl_client zen.spamhaus.org=127.255.255.[1..255] Is this a realistic setup? Should there be more, fewer or repositioned tests? I am prepared to dump them all and rely on spamassassin but I'd prefer to remove spam/viruses as early as feasible.
Re: Where to place spamhaus tests
On 03.08.22 10:39, Linkcheck wrote: I have recently begun getting blocks from dbl.spamhaus.org for "valid" email. I thought a single instance was an aberration but in all I've seen half a dozen emails blocked - a large number for my small system. The original setup was... smtpd_helo_restrictions = ... reject_rhsbl_helo dbl.spamhaus.org smtpd_sender_restrictions = ... reject_rhsbl_sender dbl.spamhaus.org smtpd_recipient_restrictions = ... reject_rbl_client zen.spamhaus.org reject_rhsbl_client dbl.spamhaus.org I have now disabled the dbl.spamhaus tests but left in place the zen.spamhaus one. The mail server is an old one, running almost untouched for several years. The positioning of the spamhaus tests has not changed in some time until now. I am setting up a new server with postfix, spamassassin, dovecot etc but it has yet to receive any real mail. I am concerned that adding spamhaus tests to postfix on the new server may be detrimental even though, until now, I have seen no adverse reaction. Spamhaus has a page for setting up postfix and recommends... smtpd_recipient_restrictions = ... reject_rbl_client zen.spamhaus.org=127.0.0.[2..11] reject_rhsbl_sender dbl.spamhaus.org=127.0.1.[2..99] reject_rhsbl_helo dbl.spamhaus.org=127.0.1.[2..99] reject_rhsbl_reverse_client dbl.spamhaus.org=127.0.1.[2..99] warn_if_reject reject_rbl_client zen.spamhaus.org=127.255.255.[1..255] Is this a realistic setup? Should there be more, fewer or repositioned tests? I have moved towards postscreen a long time ago. postscreen supports multiple scored blocklists and/or allowlists, block clients from configured score and with pregreet test helps with blocking many bots and can even replace greylisting protection. http://www.postfix.org/POSTSCREEN_README.html -- 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. Posli tento mail 100 svojim znamim - nech vidia aky si idiot Send this email to 100 your friends - let them see what an idiot you are
postfix/postscreen with proxy protocol?
I reconfigured one of my VPS to use the proxy protocol instead of NAT to forward external traffic to my postfix (postscreen). I have set up nginx to forward the TCP stream to port 10025 using proxy_protocol v1 (afaik v2 is not yet supported by nginx), and when connecting I am getting back the response “421 4.3.2 No system resources” and the log message haproxy/postscreen[903]: warning: haproxy read: unsupported protocol type: PROXY TCP6 2a00:f48:1003:3489::1 2a03:4000:6:1487:83b:12ff:fe79:c546 52700 25\r\n. I changed nginx to accept ipv4 only and succeeded. Then in https://github.com/vdukhovni/postfix/blob/7240584ca17cdc3ea313bb72180ee265f01eb2b1/postfix/src/global/haproxy_srvr.c it looks like tcp6 support is compiled conditionally. Is there a good reason for that? My understanding is, that the proxied protocol is entirely independent of the protocols available locally. Thanks, Joachim
Re: Where to place spamhaus tests
On 03.08.22 14:59, Matus UHLAR - fantomas wrote: I have moved towards postscreen a long time ago. postscreen supports multiple scored blocklists and/or allowlists, block clients from configured score and with pregreet test helps with blocking many bots and can even replace greylisting protection. http://www.postfix.org/POSTSCREEN_README.html I forgot to add that postscreen does NOT process e-mail sender nor recipient, only senders IP address. Thus, it's not effective about dbl.spamhaus that is used in rhsbl* checks. However, it's great for replacing reject_rbl_client at SMTP level. false positives at rhsbl level are to be fixed with local allow lists or using permit_rhswl_client. zen.spamhaus.org is quite safe to use and it's not to be replaced, but improved by using dbl.spamhaus.org. On 03.08.22 10:39, Linkcheck wrote: I have recently begun getting blocks from dbl.spamhaus.org for "valid" email. I thought a single instance was an aberration but in all I've seen half a dozen emails blocked - a large number for my small system. The original setup was... smtpd_helo_restrictions = ... reject_rhsbl_helo dbl.spamhaus.org smtpd_sender_restrictions = ... reject_rhsbl_sender dbl.spamhaus.org smtpd_recipient_restrictions = ... reject_rbl_client zen.spamhaus.org reject_rhsbl_client dbl.spamhaus.org I have now disabled the dbl.spamhaus tests but left in place the zen.spamhaus one. The mail server is an old one, running almost untouched for several years. The positioning of the spamhaus tests has not changed in some time until now. I am setting up a new server with postfix, spamassassin, dovecot etc but it has yet to receive any real mail. I am concerned that adding spamhaus tests to postfix on the new server may be detrimental even though, until now, I have seen no adverse reaction. Spamhaus has a page for setting up postfix and recommends... smtpd_recipient_restrictions = ... reject_rbl_client zen.spamhaus.org=127.0.0.[2..11] reject_rhsbl_sender dbl.spamhaus.org=127.0.1.[2..99] reject_rhsbl_helo dbl.spamhaus.org=127.0.1.[2..99] reject_rhsbl_reverse_client dbl.spamhaus.org=127.0.1.[2..99] warn_if_reject reject_rbl_client zen.spamhaus.org=127.255.255.[1..255] Is this a realistic setup? Should there be more, fewer or repositioned tests? -- 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. 99 percent of lawyers give the rest a bad name.
Re: Where to place spamhaus tests
Thank you, Matus. I have considered pstscreen in the past but decided it was an extra layer of complexity I could manage without. I also find zen.spamhaus reliable but is the spamhaus suggestion for postfix a) good and b) all that is needed? For example, is dbl.spamhaus, as they suggest, a good idea for Sender, Helo and Reverse_Client or will it contribute more unwanted blocks? It appears to be dangerous in my current situation.
Re: Where to place spamhaus tests
On Wed, Aug 03, 2022 at 10:39:04AM +0100, Linkcheck wrote: > Spamhaus has a page for setting up postfix and recommends... > > smtpd_recipient_restrictions = >... >reject_rbl_client zen.spamhaus.org=127.0.0.[2..11] >reject_rhsbl_sender dbl.spamhaus.org=127.0.1.[2..99] >reject_rhsbl_helo dbl.spamhaus.org=127.0.1.[2..99] >reject_rhsbl_reverse_client dbl.spamhaus.org=127.0.1.[2..99] >warn_if_reject reject_rbl_client zen.spamhaus.org=127.255.255.[1..255] > > > Is this a realistic setup? Should there be more, fewer or repositioned > tests? Looks sensible. I'd keep these. -- Viktor.
Re: postfix/postscreen with proxy protocol?
On Wed, Aug 03, 2022 at 03:11:33PM +0200, Joachim Lindenberg wrote: > I reconfigured one of my VPS to use the proxy protocol instead of NAT > to forward external traffic to my postfix (postscreen). I have set up > nginx to forward the TCP stream to port 10025 using proxy_protocol v1 > (afaik v2 is not yet supported by nginx), and when connecting I am > getting back the response “421 4.3.2 No system resources” and the log > message > > haproxy/postscreen[903]: warning: haproxy read: unsupported protocol type: > PROXY TCP6 2a00:f48:1003:3489::1 2a03:4000:6:1487:83b:12ff:fe79:c546 52700 > 25\r\n. This happens when either: - AF_INET6 is not defined in your system headers - Your kernel has no IPv6 support - Your "inet_protocols" parameter setting does not include "ipv6" Most likely you have "inet_protocols = ipv4", which is not sufficient to handle proxied IPv6 connections. > Then in > https://github.com/vdukhovni/postfix/blob/7240584ca17cdc3ea313bb72180ee265f01eb2b1/postfix/src/global/haproxy_srvr.c > it looks like tcp6 support is compiled conditionally. Only to the extent of requiring the system headers to define "AF_INET6", which should not be an issue on any non-ancient system. > My understanding is, that the proxied protocol is entirely independent > of the protocols available locally. Postfix still needs to be able to parse the address, attempt to resolve it to a hostname, ... -- Viktor.
Re: Where to place spamhaus tests
On 8/3/22 10:24, Linkcheck wrote: Thank you, Matus. I have considered pstscreen in the past but decided it was an extra layer of complexity I could manage without. I also find zen.spamhaus reliable but is the spamhaus suggestion for postfix a) good and b) all that is needed? For example, is dbl.spamhaus, as they suggest, a good idea for Sender, Helo and Reverse_Client or will it contribute more unwanted blocks? It appears to be dangerous in my current situation. One quick comment: If you run rspamd, do not put RBL tests in postscreen, configure them in rspamd instead, or rspamd will not see the RBL failures and will be unable to learn from them. -- Phil Stracchino Babylon Communications ph...@caerllewys.net p...@co.ordinate.org Landline: +1.603.293.8485 Mobile: +1.603.998.6958
Re: Where to place spamhaus tests
On 03/08/2022 3:35 pm, Viktor Dukhovni wrote: Looks sensible. I'd keep these. Despite previously blocking valid emails with dbl? I notice that the spamhaus solution places all the tests into the smtpd_recipient_restrictions section, whereas I had them in different sections plus an extra one - reject_rhsbl_client - in smtpd_recipient_restrictions. Will this make a difference? I always understood it didn't matter which section tests were in as they were all processed at an appropriate time. Or perhaps I misread/misremembered that?
Re: Where to place spamhaus tests
On Wed, Aug 03, 2022 at 04:51:04PM +0100, Linkcheck wrote: > On 03/08/2022 3:35 pm, Viktor Dukhovni wrote: > > Looks sensible. I'd keep these. > > Despite previously blocking valid emails with dbl? YMMV. My comment was mostly on detailed syntax and placement, which of the lists you want to use is up to you. Personally, I use only the IP RBL (zen). I'm willing to accept a modest amount of spam, because my mail client does a good job of classifying the ones that get through. -- Viktor.
AW: postfix/postscreen with proxy protocol?
Hello Viktor, thanks for looking into it. I do have inet_protocols=ipv4 in main.cf, everything else should support ipv6 as mailcow in general does support ipv6, but due my NAT setup I decided not to support ipv6 so far, and also I don´t believe ipv4 will go away soon for smtp in general. Moving to proxy protocol would allow me to support ipv6 inbound (relevant for submission if at all), but for sure I will not change my internal network to ipv6. Nevertheless, I really don´t see any dependencies here that cannot be resolved. Parsing is text processing and data structures, not relying on kernel support or settings. DNS reverse lookups of ipv6 addresses can be done via ipv4. If you want to support smooth transitions, please do away with exceptions like this one. And at the minimum I think it is important to have this transparent for anyone falling into the same trap. Took me some time to come up with an idea what´s going wrong. Thanks, Joachim -Ursprüngliche Nachricht- Von: owner-postfix-us...@postfix.org <> Im Auftrag von Viktor Dukhovni Gesendet: Mittwoch, 3. August 2022 17:04 An: postfix-users@postfix.org Betreff: Re: postfix/postscreen with proxy protocol? On Wed, Aug 03, 2022 at 03:11:33PM +0200, Joachim Lindenberg wrote: > I reconfigured one of my VPS to use the proxy protocol instead of NAT > to forward external traffic to my postfix (postscreen). I have set up > nginx to forward the TCP stream to port 10025 using proxy_protocol v1 > (afaik v2 is not yet supported by nginx), and when connecting I am > getting back the response “421 4.3.2 No system resources” and the log > message > > haproxy/postscreen[903]: warning: haproxy read: unsupported protocol type: > PROXY TCP6 2a00:f48:1003:3489::1 2a03:4000:6:1487:83b:12ff:fe79:c546 52700 > 25\r\n. This happens when either: - AF_INET6 is not defined in your system headers - Your kernel has no IPv6 support - Your "inet_protocols" parameter setting does not include "ipv6" Most likely you have "inet_protocols = ipv4", which is not sufficient to handle proxied IPv6 connections. > Then in > https://github.com/vdukhovni/postfix/blob/7240584ca17cdc3ea313bb72180e > e265f01eb2b1/postfix/src/global/haproxy_srvr.c > it looks like tcp6 support is compiled conditionally. Only to the extent of requiring the system headers to define "AF_INET6", which should not be an issue on any non-ancient system. > My understanding is, that the proxied protocol is entirely independent > of the protocols available locally. Postfix still needs to be able to parse the address, attempt to resolve it to a hostname, ... -- Viktor.
Re: AW: postfix/postscreen with proxy protocol?
On Wed, Aug 03, 2022 at 10:39:17PM +0200, Joachim Lindenberg wrote: > I do have inet_protocols=ipv4 in main.cf, everything else should > support ipv6 as mailcow in general does support ipv6, but due my NAT > setup I decided not to support ipv6 so far, and also I don´t believe > ipv4 will go away soon for smtp in general. Moving to proxy protocol > would allow me to support ipv6 inbound (relevant for submission if at > all), but for sure I will not change my internal network to ipv6. > Nevertheless, I really don´t see any dependencies here that cannot be > resolved. Parsing is text processing and data structures, not relying > on kernel support or settings. DNS reverse lookups of ipv6 addresses > can be done via ipv4. If you want to support smooth transitions, > please do away with exceptions like this one. Postfix presently does not support IPv6 address processing when inet_protocols = ipv4. This restriction could perhaps be lifted in the HAPROXY code, but this would require some analysis... -- Viktor.
Re: AW: postfix/postscreen with proxy protocol?
Viktor Dukhovni: > On Wed, Aug 03, 2022 at 10:39:17PM +0200, Joachim Lindenberg wrote: > > > I do have inet_protocols=ipv4 in main.cf, everything else should > > support ipv6 as mailcow in general does support ipv6, but due my NAT > > setup I decided not to support ipv6 so far, and also I don?t believe > > ipv4 will go away soon for smtp in general. Moving to proxy protocol > > would allow me to support ipv6 inbound (relevant for submission if at > > all), but for sure I will not change my internal network to ipv6. > > Nevertheless, I really don?t see any dependencies here that cannot be > > resolved. Parsing is text processing and data structures, not relying > > on kernel support or settings. DNS reverse lookups of ipv6 addresses > > can be done via ipv4. If you want to support smooth transitions, > > please do away with exceptions like this one. > > Postfix presently does not support IPv6 address processing when > inet_protocols = ipv4. > > This restriction could perhaps be lifted in the HAPROXY code, but this > would require some analysis... Absolutely not. Postfix infrastructure code will have to handle IPv6 address formats for logging, for relay access control, in email addresses with an address literal (required by RFC) and so on. It does not matter that the address is received by proxy. Wietse
