THEAD CLOSED: (was: Postfix restrictions)

2020-06-09 Thread Viktor Dukhovni
On Wed, Jun 10, 2020 at 12:00:21AM -0600, @lbutlr wrote: > > It may be irrelevant to the topic, but your statement characterizes the > > troll perfectly well. > > I think you have a problem. This thread has outlived its use by. No followups please. -- Viktor.

Re: Postfix restrictions

2020-06-09 Thread @lbutlr
> On 09 Jun 2020, at 23:29, yuv wrote: > > On Tue, 2020-06-09 at 01:16 -0600, @lbutlr wrote: >>> On 08 Jun 2020, at 16:21, yuv wrote: >>> >>> Some of [the alternatives to internet email] will achieve scale as >>> well. At some point, the cost/benefit analysis of maintaining >>> internet ema

Re: Postfix restrictions

2020-06-09 Thread yuv
On Tue, 2020-06-09 at 01:16 -0600, @lbutlr wrote: > > On 08 Jun 2020, at 16:21, yuv wrote: > > > > Some of [the alternatives to internet email] will achieve scale as > > well. At some point, the cost/benefit analysis of maintaining > > internet email vs. using alternatives such as SMS will tilt

Re: Postfix restrictions

2020-06-09 Thread @lbutlr
> On 08 Jun 2020, at 16:21, yuv wrote: > > On Sun, 2020-06-07 at 20:36 -0600, @lbutlr wrote: >> On 07 Jun 2020, at 06:38, yuv wrote: >>> Is there a valid reason for a sender not to fix something so >>> essential as DNS configuration? >> >> That’s not the question. > > Oh, yes it is. Really

Re: Postfix restrictions

2020-06-08 Thread yuv
On Sun, 2020-06-07 at 20:36 -0600, @lbutlr wrote: > On 07 Jun 2020, at 06:38, yuv wrote: > > Is there a valid reason for a sender not to fix something so > > essential as DNS configuration? > > That’s not the question. Oh, yes it is. Making room for degraded configurations is detrimental to the

Re: Postfix restrictions

2020-06-08 Thread @lbutlr
On 07 Jun 2020, at 06:38, yuv wrote: > On Sun, 2020-06-07 at 14:22 +0200, A. Schulze wrote: >> using "reject_unknown_helo_hostname" may trigger some false >> positives. Not every sender have such perfect setups. > Is there a valid reason for a sender not to fix something so essential as DNS > co

Re: Postfix restrictions

2020-06-08 Thread Jaroslaw Rafa
Dnia 8.06.2020 o godz. 14:31:32 Charles Sprickman pisze: > > > Please avoid private copies of mail, thank you. > > Odd, no idea why the reply-to didn’t fire instead... Because it isn't there? :) This list doesn't set Reply-To. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million y

Re: Postfix restrictions

2020-06-08 Thread Charles Sprickman
> On Jun 8, 2020, at 3:08 AM, Matus UHLAR - fantomas wrote: > > Please avoid private copies of mail, thank you. Odd, no idea why the reply-to didn’t fire instead... > I wonder that two very new documents describe something that has been long recommended to avoid: postgrey > >>> On

Re: Postfix restrictions

2020-06-08 Thread Laura Smith
> Jun 8 06:49:08 mx postfix/dnsblog[21103]: addr 151.20.170.84 listed by domain > .zen.dq.spamhaus.net as 127.0.0.10 > > with the "" clearly displayed. > > have you a setting/map in postfix that simply prevents/filters the > "" value from explicit entry in the logs? > > i haven't yetseen it in

Re: Postfix restrictions

2020-06-08 Thread PGNet Dev
On 6/8/20 8:37 AM, Dominic Raferd wrote: > This was discussed before: > https://www.mail-archive.com/postfix-users@postfix.org/msg85706.html thx! i had similarly "interpreted the text 'specify $$ to produce a $ character as output' as meaning that $$ would produce a hard-coded dollar sign"

Re: Postfix restrictions

2020-06-08 Thread Dominic Raferd
On Mon, 8 Jun 2020 at 16:11, PGNet Dev wrote: > On 6/8/20 7:12 AM, Dominic Raferd wrote: > > main.cf : > > > > rbl_reply_maps = pcre:/etc/postfix/rbl_reply_maps.pcre > > postscreen_dnsbl_reply_map = > pcre:/etc/postfix/postscreen_dnsbl_reply_map.pcre > > > > > > # cat /etc/postf

Re: Postfix restrictions

2020-06-08 Thread n5d9xq3ti233xiyif2vp
> RIght now there is no other option for “pausing” spammers until they show > up on my DNSBLs… > We're finding the Spamhaus paid lists do a good job of fresh spammers (IIRC HBL and ZRD).

Re: Postfix restrictions

2020-06-08 Thread PGNet Dev
On 6/8/20 7:12 AM, Dominic Raferd wrote: > main.cf : > > rbl_reply_maps = pcre:/etc/postfix/rbl_reply_maps.pcre > postscreen_dnsbl_reply_map = pcre:/etc/postfix/postscreen_dnsbl_reply_map.pcre > > > # cat /etc/postfix/rbl_reply_maps.pcre > /[a-z0-9]*\.([a-z]*\.dq\.spamhaus\.net)/

Re: Postfix restrictions

2020-06-08 Thread Dominic Raferd
On Mon, 8 Jun 2020 at 15:07, PGNet Dev wrote: > > in my logs, i see, e.g. > Jun 8 06:49:08 mx postfix/dnsblog[21103]: addr 151.20.170.84 > listed by domain .zen.dq.spamhaus.net as 127.0.0.10 > > with the "" clearly displayed. > > have you a setting/map in postfix that simply prevents/fil

Re: Postfix restrictions

2020-06-08 Thread PGNet Dev
On 6/7/20 4:23 AM, Laura Smith wrote: > smtpd_recipient_restrictions = > permit_mynetworks,${indexed}custom_reject,reject_unauth_destination, > reject_rhsbl_sender > .dbl.dq.spamhaus.net=127.0.1.[2;4;5;6], > reject_rhsbl_helo > .dbl.dq.spamhaus.net=127.0.1.[2;4;5;6],

Re: Postfix restrictions

2020-06-08 Thread Laura Smith
> RIght now there is no other option for “pausing” spammers until they show up > on my DNSBLs… > We're finding the Spamhaus paid lists do a good job of fresh spammers (IIRC HBL and ZRD).

Re: Postfix restrictions

2020-06-08 Thread uhlar
Please avoid private copies of mail, thank you. >>> I wonder that two very new documents describe something that has been long >>> recommended to avoid: postgrey >> On Jun 7, 2020, at 8:03 AM, Laura Smith >> wrote: >> I agree. Greylisting is a primitive, last century "sledgehammer to crack a

Re: Postfix restrictions

2020-06-08 Thread uhlar
Please avoid private copies of mail, thank you. >>> I wonder that two very new documents describe something that has been long >>> recommended to avoid: postgrey >> On Jun 7, 2020, at 8:03 AM, Laura Smith >> wrote: >> I agree. Greylisting is a primitive, last century "sledgehammer to crack a

Re: Postfix restrictions

2020-06-08 Thread Matus UHLAR - fantomas
Please avoid private copies of mail, thank you. I wonder that two very new documents describe something that has been long recommended to avoid: postgrey On Jun 7, 2020, at 8:03 AM, Laura Smith wrote: I agree. Greylisting is a primitive, last century "sledgehammer to crack a nut". It has

Re: Postfix restrictions

2020-06-07 Thread Charles Sprickman
> On Jun 7, 2020, at 8:03 AM, Laura Smith > wrote: > > >> I wonder that two very new documents describe something that has been long >> recommended to avoid: postgrey > > I agree. Greylisting is a primitive, last century "sledgehammer to crack a > nut". > > It has no place in 2020's anti-

Re: Postfix restrictions

2020-06-07 Thread Noel Jones
On 6/7/2020 9:01 AM, A. Schulze wrote: Am 07.06.20 um 14:38 schrieb yuv: Is there a valid reason for a sender not to fix something so essential as DNS configuration? no valid reason but reality. There are so many sendings hosts named "foobar.local". Via NAT they are visible with a public I

Re: Postfix restrictions

2020-06-07 Thread A. Schulze
Am 07.06.20 um 14:38 schrieb yuv: > Is there a valid reason for a sender not to fix something so essential > as DNS configuration? no valid reason but reality. There are so many sendings hosts named "foobar.local". Via NAT they are visible with a public IP and a perfect DNS. But this hosts st

Re: Postfix restrictions

2020-06-07 Thread yuv
On Sun, 2020-06-07 at 14:22 +0200, A. Schulze wrote: > using "reject_unknown_helo_hostname" may trigger some false > positives. Not every sender have such perfect setups. Is there a valid reason for a sender not to fix something so essential as DNS configuration? -- Yuval Levy, JD, MBA, CFA Ontar

Re: Postfix restrictions

2020-06-07 Thread A. Schulze
Am 07.06.20 um 11:51 schrieb Nicolas Kovacs: using "reject_unknown_helo_hostname" may trigger some false positives. Not every sender have such perfect setups. You may use "warn_if_reject reject_unknown_helo_hostname" for some time and check if loosing such traffic is acceptable for you. Andr

Re: Postfix restrictions

2020-06-07 Thread Laura Smith
> I wonder that two very new documents describe something that has been long > recommended to avoid: postgrey I agree. Greylisting is a primitive, last century "sledgehammer to crack a nut". It has no place in 2020's anti-spam.

Re: Postfix restrictions

2020-06-07 Thread Matus UHLAR - fantomas
On 07.06.20 11:51, Nicolas Kovacs wrote: I'm currently fine-tuning my mail server (Postfix and Dovecot on CentOS 7). SPF, DKIM and DMARC work fine, now I'd like to limit the spam tsunami. Besides the official Postfix documentation, I've read a few articles about Postfix spam restrictions, namel

Re: Postfix restrictions

2020-06-07 Thread Laura Smith
> reject_rhsbl_helo dbl.spamhaus.org, > reject_rhsbl_reverse_client dbl.spamhaus.org, > reject_rhsbl_sender dbl.spamhaus.org, > reject_rbl_client zen.spamhaus.org > --8< > Bear in mind that whilst Spamhaus is great, to get the most out of i

Re: Postfix restrictions

2020-06-07 Thread Allen Coates
On 07/06/2020 10:51, Nicolas Kovacs wrote: > Before committing this configuration to my main server, I thought I'd share > this configuration on the list. Maybe the Postfix gurus among you have the odd > comment to make. > > My aim is simply to eliminate as much spam as possible (that is, before

Postfix restrictions

2020-06-07 Thread Nicolas Kovacs
Hi, I'm currently fine-tuning my mail server (Postfix and Dovecot on CentOS 7). SPF, DKIM and DMARC work fine, now I'd like to limit the spam tsunami. Besides the official Postfix documentation, I've read a few articles about Postfix spam restrictions, namely these : https://www.linuxbabe.com/m

order of milter check and postfix restrictions

2008-08-09 Thread Anton Yuzhaninov
It seems to be, that order of restrictions described here: http://archives.neohapsis.com/archives/postfix/2007-08/0663.html not true for postfix 2.5.2 - smtpd_end_of_data_restrictions checked before milter_end_of_data_macros Is it true, or I mistaken? -- Anton Yuzhaninov