Re: Postfix restrictions

[@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 email vs. using alternatives such as SMS will tilt
>>> obviously against email
>> 
>> Sure it will. It hasn't happened yet, and I don't think it will
>> happen (SMS is garbage), but it is still irrelevant to the topic.
> 
> It may be irrelevant to the topic, but your statement characterizes the
> troll perfectly well.

I think you have a problem.

>>> and that's where "most admins" will regret their narrow view. 
>> 
>> How do you figure? You think we run Mailservers because we are
>> emotionally invested in the idea of email as the ONE TRUE INFORMATION
>> EXCHANGE? Nope. We are mail admins because we and our users need
>> email. As soon as that is no longer the case I will gleefully switch
>> to the better thing.
> 
> ... but I have zero tolerance for the arrogant attribution of your
> preconceived notions.

And now I *know* you have a problem.

> My thoughts are far from your wishful dreaming.  All things being
> equal, internet email is less interesting when it is less reliable and
> more spammy, both of which are direct consequences of your myopia.

My myopia is "if you do this, you will be t4chnically correct but you will lose 
mail that you might want. The choice is yours.

Then you attack me.

So guess what? Do what you want. If you do not want advice, DO NOT ASK FOR IT. 
If you do not want to know what the consequences are, DON'T ASK. Iuf you are 
pretending to wonder why something is, but do not


> The question is not "do you want to receive that
> email?"

That is the ONLY question for the vast majority of mail users. They do not give 
a damn about protocols, they want their email.

> The question is "do you want your message delivered reliably
> according to protocol"

Protocols are nice. Getting mail users want is much more important.

But again, do whatever you want. No one else cares. If you have paying 
customers, they will care and if enough mail doesn't arrive, they will leave. 
If you a BOFH with users at your mercy then they can't leave, but when the CEO 
fails to get mail because of your politics, you're getting fired.

Again, your choice.

> By the time "your" users will no longer need you, you may find that the
> competitive landscape has shifted under your feet.  And they may
> gleefully leave you and your baggage behind.  Abandonware.

I've blocked all further mails from you. Do not contact me.





-- 
I think it's the duty of the comedian to find out where the line is
drawn and cross it deliberately.

Re: Postfix restrictions

[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
> > obviously against email
> 
> Sure it will. It hasn't happened yet, and I don't think it will
> happen (SMS is garbage), but it is still irrelevant to the topic.

It may be irrelevant to the topic, but your statement characterizes the
troll perfectly well.

The admins working for the fine companies on the list at the URL below
may be of a different opinion on relevance and on occurence of the
cost/benefit tipping point.

https://en.wikipedia.org/wiki/List_of_mobile_network_operators

Some of them may even opine that your internet email is garbage.

I am personally agnostic regarding garbage...


> > and that's where "most admins" will regret their narrow view. 
> 
> How do you figure? You think we run Mailservers because we are
> emotionally invested in the idea of email as the ONE TRUE INFORMATION
> EXCHANGE? Nope. We are mail admins because we and our users need
> email. As soon as that is no longer the case I will gleefully switch
> to the better thing.

... but I have zero tolerance for the arrogant attribution of your
preconceived notions.

My thoughts are far from your wishful dreaming.  All things being
equal, internet email is less interesting when it is less reliable and
more spammy, both of which are direct consequences of your myopia.  I
care little whether my communication is carried by pigeons, by fax, or
by internet email.  The question is not "do you want to receive that
email?"  The question is "do you want your message delivered reliably
according to protocol" and if email does not cut it, there are
competing protocols that do.

Here is one for you:
https://siarchives.si.edu/history/featured-topics/postcard/postcard-history

By the time "your" users will no longer need you, you may find that the
competitive landscape has shifted under your feet.  And they may
gleefully leave you and your baggage behind.  Abandonware.
 
--
Yuval Levy, JD, MBA, CFA
Ontario-licensed lawyer

Re: Postfix restrictions

[@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 not.

> Making room for degraded configurations is detrimental to the protocol and to 
> the federation of internet email server operators if internet email is ever 
> to mature into a reliable messaging system on par with snailmail.

Yes, you can take a political "this is wrong" stance if you want. Or you can 
get the mail. The choice is yours. Certainly my blocking yahoo serves is a 
political decision.

If you have users, you have less of a choice.

>> The question is, do you want to receive the mail or not? If you do,
>> then don’t use reject_unknown_helo_hostname 
>> 
>> It’s a question only you can answer, but it seems most admins find
>> that this results in too much lost mail.
> 
> The consequence of this narrow framing is that internet email is
> serving the interest of spammers more than the interest of recipients.

Completely irrelevant.

> Spammers pay admins better than recipients, so we get what we pay for. 

I don't know what this means.

> Meanwhile, alternative messaging systems with more rigid controls, some
> of which are proprietary, achieve maturity much faster.

Uh huh. I've been hearing about the death of email for 20 years. I look forward 
to it, but I don't think it's happening in my lifetime.

> Some of them achieve scale as well.  At some point, the cost/benefit analysis 
> of maintaining internet email vs. using alternatives such as SMS will tilt
> obviously against email

Sure it will. It hasn't happened yet, and I don't think it will happen (SMS is 
garbage), but it is still irrelevant to the topic.

> and that's where "most admins" will regret their narrow view. 

How do you figure? You think we run Mailservers because we are emotionally 
invested in the idea of email as the ONE TRUE INFORMATION EXCHANGE? Nope. We 
are mail admins because we and our users need email. As soon as that is no 
longer the case I will gleefully switch to the better thing.





-- 
Disorder is merely the order you were not looking for." Henri Bergson

Re: Postfix restrictions

[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 protocol and to the federation of internet email server
operators if internet email is ever to mature into a reliable messaging
system on par with snailmail.


> The question is, do you want to receive the mail or not? If you do,
> then don’t use reject_unknown_helo_hostname 
> 
> It’s a question only you can answer, but it seems most admins find
> that this results in too much lost mail.

The consequence of this narrow framing is that internet email is
serving the interest of spammers more than the interest of recipients. 
Spammers pay admins better than recipients, so we get what we pay for. 
Meanwhile, alternative messaging systems with more rigid controls, some
of which are proprietary, achieve maturity much faster.  Some of them
achieve scale as well.  At some point, the cost/benefit analysis of
maintaining internet email vs. using alternatives such as SMS will tilt
obviously against email, and that's where "most admins" will regret
their narrow view. 
--
Yuval Levy, JD, MBA, CFA
Ontario-licensed lawyer

Re: Postfix restrictions

[@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 
> configuration?

That’s not the question.

The question is, do you want to receive the mail or not? If you do, then don’t 
use reject_unknown_helo_hostname 

It’s a question only you can answer, but it seems most admins find that this 
results in too much lost mail.


-- 
This magic gin better make us see unicorns that fart rainbows.

Re: Postfix restrictions

[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 years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."

Re: Postfix restrictions

[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 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 no place in 2020's anti-spam.
> 
> On 07.06.20 14:10, Charles Sprickman wrote:
>> I’m going to have thoughts on this next week when I trial it.
>> 
>> RIght now there is no other option for “pausing” spammers until they show up 
>> on my DNSBLs…
>> 
>> I tried postscreen with the after-220 checks that implement a very brief 
>> “greylist”, but it was largely ineffective.
> 
> I don't think greylisting would be more effective than this.  I found
> postscreen more effective (and less problemativ) than postgrey.
> 
> Of course, you need to allow pre-greet checks, where especially pregreet
> text (postscreen_greet_action=enforce) does great job.
> 
> ... and it does not introduce delays.

I’ll just note a few things that I put in my original thread:

- We’ve trialed all the premium lists and observed no huge change
- Even if that did work and a combo of 3-4 paid lists plus free somehow caught 
things, there’s not budget for this, it’s a value-add on connectivity
- The reason I’m looking at greylisting is because the last premium trial we 
ran gave me feedback on the “leaked” spam and it was clear that we simply get 
spam before the hosts are blacklisted (why? 20+ year old domain maybe? 
beginning of the alphabet? I have no idea)
- “Pausing” new senders would resolve a large portion of the leaked spam (see 
above)
- Whitelisting known good senders seems like a reasonable option to avoid 
delays for real mail (and at this point, we have more user feedback on spam 
leaks than delays)
- I’m running the pregreet stuff now, and there does seem to be a small 
improvement, but the short delay is not long enough to get ahead of the delay 
in the host being listed

A new thing I noticed with our problematic spam senders is that while the 
majority do have valid DKIM, they are NOT publishing SPF records. In another 
thread there was talk of simply skipping greylisting on senders with valid SPF 
records, so that may actually be a great compromise in my case.

Charles

> -- 
> 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.
> Remember half the people you know are below average.

Re: Postfix restrictions

[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 any SMTP reply, reject or otherwise, but would like 
> to ensure that that doesn't happen either.


I'll need to check our logs to see what it looks like on ours, its been a while.

But it is certainly *critical* that you have a map in Postfix to prevent it 
appearing in SMTP replies.  I don't think Spamhaus would be too happy with 
people blurting out the "" to the public (or spammers).  ;-)

Re: Postfix restrictions

[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

[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/postfix/rbl_reply_maps.pcre
> > /[a-z0-9]*\.([a-z]*\.dq\.spamhaus\.net)/ $$rbl_code Service unavailable;
> $$rbl_class [$$rbl_what] blocked using ${1}$${rbl_reason?; $$rbl_reason}
> > # cat /etc/postfix/postscreen_dnsbl_reply_map.pcre
> > /[a-z0-9]*\.([a-z]*\.dq\.spamhaus\.net)/ ${1}
>
> ah, thx!
> that seems to work nicely -- for the SMTP reply; doesn't affect the
> dnsblog output (yet; poking around now)
> tho, reading some other examples I've now found in posts -- why the double
> "$$" here?
> reading http://www.postfix.org/pcre_table.5.html I do see ...


This was discussed before:
https://www.mail-archive.com/postfix-users@postfix.org/msg85706.html

Re: Postfix restrictions

[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

[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)/ $$rbl_code Service unavailable; 
> $$rbl_class [$$rbl_what] blocked using ${1}$${rbl_reason?; $$rbl_reason}
> # cat /etc/postfix/postscreen_dnsbl_reply_map.pcre
> /[a-z0-9]*\.([a-z]*\.dq\.spamhaus\.net)/ ${1}

ah, thx!

that seems to work nicely -- for the SMTP reply; doesn't affect the dnsblog 
output (yet; poking around now)

tho, reading some other examples I've now found in posts -- why the double "$$" 
here?

reading

http://www.postfix.org/pcre_table.5.html

I do see the

TEXT SUBSTITUTION
Substitution of substrings (text that  matches  patterns  inside  
"()")from  the  matched  expression into the result string is requested with$1, 
$2, etc.; specify $$ to produce  a  $  character  as  output.

, just not clear if/why it's needed here?

Re: Postfix restrictions

[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/filters the
> "" value from explicit entry in the logs?
>

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)/ $$rbl_code Service unavailable;
$$rbl_class [$$rbl_what] blocked using ${1}$${rbl_reason?; $$rbl_reason}
# cat /etc/postfix/postscreen_dnsbl_reply_map.pcre
/[a-z0-9]*\.([a-z]*\.dq\.spamhaus\.net)/ ${1}

Re: Postfix restrictions

[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],
>  reject_rhsbl_reverse_client 
> .dbl.dq.spamhaus.net=127.0.1.[2;4;5;6],
>  reject_rhsbl_sender 
> .zrd.dq.spamhaus.net=127.0.2.[2..24],
>  reject_rhsbl_helo   
> .zrd.dq.spamhaus.net=127.0.2.[2..24],
>  reject_rhsbl_reverse_client 
> .zrd.dq.spamhaus.net=127.0.2.[2..24],
>  reject_rbl_client   
> .zen.dq.spamhaus.net=127.0.0.[2;3;4..7;10;11]
> smtpd_client_restrictions = reject_rbl_client  
> .zen.dq.spamhaus.net
> postscreen_dnsbl_sites =  
> .zen.dq.spamhaus.net=127.0.0.[2;3;4..7;10;11]

i've switched a postfix install to this^ usage of spamhaus dqs et al.

(hadn't even _noticed_ the dq option since release last year!)

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/filters the 
"" value from explicit entry in the logs?

i haven't yet _seen_ it in any SMTP reply, reject or otherwise, but would like 
to ensure that that doesn't happen either.

Re: Postfix restrictions

[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

[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 
>> nut".
>>
>> It has no place in 2020's anti-spam.

On 07.06.20 14:10, Charles Sprickman wrote:
>I’m going to have thoughts on this next week when I trial it.
>
>RIght now there is no other option for “pausing” spammers until they show 
>up on my DNSBLs…
>
>I tried postscreen with the after-220 checks that implement a very brief 
>“greylist”, but it was largely ineffective.

I don't think greylisting would be more effective than this.  I found
postscreen more effective (and less problemativ) than postgrey.

Of course, you need to allow pre-greet checks, where especially pregreet
text (postscreen_greet_action=enforce) does great job.

... and it does not introduce delays.
-- 
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.
Remember half the people you know are below average.

Re: Postfix restrictions

[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 
>> nut".
>>
>> It has no place in 2020's anti-spam.

On 07.06.20 14:10, Charles Sprickman wrote:
>I’m going to have thoughts on this next week when I trial it.
>
>RIght now there is no other option for “pausing” spammers until they show 
>up on my DNSBLs…
>
>I tried postscreen with the after-220 checks that implement a very brief 
>“greylist”, but it was largely ineffective.

I don't think greylisting would be more effective than this.  I found
postscreen more effective (and less problemativ) than postgrey.

Of course, you need to allow pre-greet checks, where especially pregreet
text (postscreen_greet_action=enforce) does great job.

... and it does not introduce delays.
-- 
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.
Remember half the people you know are below average.

Re: Postfix restrictions

[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 no place in 2020's anti-spam.


On 07.06.20 14:10, Charles Sprickman wrote:

I’m going to have thoughts on this next week when I trial it.

RIght now there is no other option for “pausing” spammers until they show up on 
my DNSBLs…

I tried postscreen with the after-220 checks that implement a very brief 
“greylist”, but it was largely ineffective.


I don't think greylisting would be more effective than this.  I found
postscreen more effective (and less problemativ) than postgrey.

Of course, you need to allow pre-greet checks, where especially pregreet
text (postscreen_greet_action=enforce) does great job.

... and it does not introduce delays.
--
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.
Remember half the people you know are below average.

Re: Postfix restrictions

[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-spam.

I’m going to have thoughts on this next week when I trial it.

RIght now there is no other option for “pausing” spammers until they show up on 
my DNSBLs…

I tried postscreen with the after-220 checks that implement a very brief 
“greylist”, but it was largely ineffective.

Charles

Re: Postfix restrictions

[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 IP
and a perfect DNS. But this hosts still say "EHLO foobar.local"

It's the receivers policy how to handle such connections.
reject_unknown_helo_hostname reject them.

Andreas



It's been my experience that reject_unknown_helo_hostname has more 
false positives than stopping actual spam, and the few spam that 
fail it usually fail other tests.  Use with caution. Rejecting 
invalid or non-FQDN helo names is relatively safe.


It's also been my experience that reject_unknown_client_hostname has 
a large number of false positives, while 
reject_unknown_reverse_client_hostname is relatively safe.


YMMV



  -- Noel Jones

Re: Postfix restrictions

[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 still say "EHLO foobar.local"

It's the receivers policy how to handle such connections.
reject_unknown_helo_hostname reject them.

Andreas

Re: Postfix restrictions

[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
Ontario-licensed lawyer

Re: Postfix restrictions

[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.

Andreas

Re: Postfix restrictions

[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

[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, namely these :

https://www.linuxbabe.com/mail-server/block-email-spam-postfix

https://wiki.centos.org/HowTos/postfix_restrictions


I wonder that two very new documents describe something that has been long
recommended to avoid: postgrey
- watch the thread on https://marc.info/?t=15903688682=1=2

while ignoring one solution that was proposed to replace postgrey and
improve blacklisting: postscreen
(in fact, first page recommends it for iredmail users)

and, of course, neither of those recommend smtp-time spam checking using
e.g.  amavisd-milter, spamass-milter, where both use spamassassin and are
able to reject spam at SMTP level.

some of those recommendations are fine, but you get much more by using two
above described techniques.
--
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.
42.7 percent of all statistics are made up on the spot.

Re: Postfix restrictions

[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 it, you also 
need to use Spamassassin alongside any early-filtering you might be doing with 
Postfix.

This is especially the case if you are a subscriber and you want to make more 
extensive use of their content, as well as new innovations such as the Spamhaus 
HBL which is likely not usable from Postfix.

See:
- 
https://docs.spamhaustech.com/datasets/docs/source/40-real-world-usage/SpamAssassin/000-intro.html
- https://github.com/spamhaus/spamassassin-dqs
- If you are a subscriber, also look at the manuals in the portal

Regarding your Postfix Spamhaus settings, you might want to add it under 
smtpd_client_restrictions and postscreen_dnsbl_sites.  For example (N.B. this 
is a snippet from one of our sites, its not necessarily a Spamhaus recommended 
config, you can look on the subscriber portal for the detail on current 
recommended Postfix configs with Spamhaus) :

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],
reject_rhsbl_reverse_client 
.dbl.dq.spamhaus.net=127.0.1.[2;4;5;6],
reject_rhsbl_sender 
.zrd.dq.spamhaus.net=127.0.2.[2..24],
reject_rhsbl_helo   
.zrd.dq.spamhaus.net=127.0.2.[2..24],
reject_rhsbl_reverse_client 
.zrd.dq.spamhaus.net=127.0.2.[2..24],
reject_rbl_client   
.zen.dq.spamhaus.net=127.0.0.[2;3;4..7;10;11]
smtpd_client_restrictions = reject_rbl_client  .zen.dq.spamhaus.net
postscreen_dnsbl_sites =  
.zen.dq.spamhaus.net=127.0.0.[2;3;4..7;10;11]

Re: Postfix restrictions

[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 adding
> SpamAssassin) while keeping false positives to a minimum.
> 
> Any suggestions ?


I protect my mailing-list addresses with a pair of close-coupled ACLs; accept
the list server, then reject the recipient address (with a polite message to
contact me on-list).

>From my main.cf:-
check_client_access cidr:/etc/postfix/listserver_access.cidr
check_recipient_access hash:/etc/postfix/recipient_access

It catches quite a lot of junk, though I do lose an occasional off-list remark.
However, I can whitelist individual senders elsewhere if I wanted. (Or give them
a different address)

Allen C