Spam filter with action "Err 550"


Would be of huge benefit in the fight against spam, to have a third option "Reject with err 550" in DA spam filter (user/email/filters).
At the moment we can only drop or forward to spambox, but both these options, to the eye of the spammer are a confirmation that the spam has been correctly delivered. On the contrary, a reject 550 (NB: not a bounce) would be much better in the long run because:
1) the spammer acknowledges the waste of time (and probably money).
2) his box gets full of errors and probably he wastes time cleaning.
3) The sender SMTP wastes more time while the recipient SMTP spends basically the same time of a drop and much less than using the spambox.
4) But most of all, because of the 3 points above, the spammer will be quite happy to remove such recipient from his DB.


Activity Newest / Oldest



Gmail's method is the best of all. Gmail rejects spam with 5xx if it's obviously spam, or greylists it with 4xx if it's probably spam, or accepts it and puts in the spam folder if there is some doubt, or accepts and delivers normally if it's clearly not spam. Because Gmail's spam filter is very accurate, there are no user-accessible settings, other than marking individual email messages as spam or not spam.

If we are discussing what settings should be available to the user, then we are admitting that our spam filter is noticeably less accurate than Gmail's spam filter.

The way that rspamd works, its configuration roughly mirrors what Gmail does. I.e., it can be configured to specify thresholds at which various actions will occur depending on spam level. E.g.:

level ≤ A : deliver normally.
A LT level ≤ B : greylist with 4xx
B LT level : reject with 5xx

(Note: LT stands for the less-than character, which if used literally triggers a website bug.)

The OP's feature request is essentially asking for these settings to be made user-accessible. Which is a fine idea, but the down side is that it increases load on the server to accept spam when the user chooses poor settings.

So I think ideally:

- Anything that is clearly spam should always be greylisted or, at a higher threshold, be rejected. User gets no choice.

- Below these thresholds, let the user decide.

The result would be that the user only gets to decide when the email might or might not be spam, but does not get to decide what to do with anything that is spam with a high degree of certainty.




Miguel Ângelo

We would love this feature as well. Please vote guys!

  • R