I think that greylisting gets a different kind of approach.
Error 4.x.x is a temporary reject during delivery to Postfix. If it’s legitimate message, the MTA will try again in a correct time.
The greylisting should be bypassed when :
the message comes from an already know legitimate server as assured by SPF
I think you are right @stephdl : we should simply not bounce mails « back » to spammers, at least not those with a very high score.
Maybe that’s a postfix job but it has to rely on rspamd to decide wether a mail is spam or not.
By the way : It just came to my mind that that issue (spam mails bounced) already plagued me in the past : I use a smarthost that decides from time to time that I’m a spammer because I send too many non delivery notifications for spammers ! Read my post I wrote at that time on this board : Postfix sending non-deliveries notifications because of spam?
I just ended up disabling rspamd, as it sent almost everything to spam folder probable as well as reject. It blocked online bill pay alerts, newsletters, you know, important emails. I just need to figure out how to get rspamd to learn from good emails it has marked as spam. I tried allowing the sender in the web gui but that did not work.
I agree. But also I can’t totally rely on that every backscatter source will try again the delivery.
Get into a Blacklist is a matter of time. Therefore, during backscatter firetime i am not sure than all the spam sources will manage the delivery according to RFC and best practices for email servers.
I think (and maybe i’m wrong ) that SPF could ease at least 30% of backscatter sources. So, still not absolute weapon but… maybe another little brick into the “keep the thrash out of servers” wall.
NethServer does not bounce emails.
NethServer does not create backscatter.
To fight backscatter received by NethServer (sent by other mail servers) you need to know which mail servers can send email for your domain and discard messages not sent by them, or you will lose legitimate bounces. This can not be done automatically.
Reading the mail headers again, I believe that in that case you’re right : my user is actually victim of a backscatter mail, and therefore nethserver isn’t the culprit here. I misinterpreted the non delivery notification.
I see. I thought that a 554 could generate backscatter but it looks like it is actually not the case.
However, I’m positive that still there is a case where nethserver answers back to spammer, which triggers the anti spam policy of my smarthost. I’ll report back next time it happens.
The recipients are obviously not connected in any way to our business. MAILER-DAEMON indicates that it is our server that tries to answer them some delivery report… for a mail we never sent.
How do you interpret this ? Personally I interpret this as the result of a backscatter attack involving our server.