On 20 May 2019, at 3:42, Brent Clark wrote:
Good day Guys
Just want to check with the community.
My colleague has proposed that at smtp time, if a mail is deemed as
spam, the server issues a reject code, but then to too accept the mail
and forward the mail the user for incase its a false positive.
Note that this is a flagrantly non-standard behavior. In my opinion, it
is also likely to result in far more trouble than it will be worth and
may be a career-limiting choice for any mail admin who advocates for it
or implements it without the enthusiastic support of anyone in the
organization likely to seek a scapegoat for an email disaster. In short:
I think it's a horrible idea.
With that warning given: there is exactly one way to do this. You would
need to postpone all decisions about whether a message is acceptable to
the "end of DATA" stage (after your server has made affirmative
responses to EHLO, MAIL, one or more RCPT, and the initial DATA
commands.) At that point the server would send a '554' response to the
sender (indicating rejection) but in fact sequester the mail for further
investigation.
The way to do this with Postfix would be with a milter program like
MIMEDefang that can make arbitrary filtering and disposition decisions
at end-of-DATA time. The milter would need to implement a quarantine of
some form and support a reject-but-quarantine behavior (as MIMEDefang
does.) Of course, after you've told the sender that you don't want that
message, you have a message in quarantine that you need to make a more
careful (presumably human) decision about. This is a system you would
need to design, implement, and staff.
His logic is that, that the spammer does not build up a database.
Of what exactly?
Presumably you won't do this with all mail, because the last thing you
want is to make legitimate senders of legitimate mail believe that
everything they send is being rejected. No matter how you make that cut,
spammers will be able, in principle, to determine something about why
you accept vs. why you reject, even if some of your rejections are not
real.
Currently what we do is, if the score is between 5 and 15, just accept
and move the spam to the users SPAM box. Above 15 we out right block.
Hmmm... That sounds like you're using SpamAssassin. Many sites use its
scores that way. I personally prefer a much narrower range for
"delivered likely spam" but that's a site-specific issue. If you have a
substantial amount of legitimate mail ending up in the 5-15 range, you
may have a serious problem with your SpamAssassin config.
What evidence do you have that spammers are using your current behavior
in support of evading filtering?
I am on the fence on this one, hence the reason to pick the
communities brain.
As I made clear up front, I think it's a practice which would cause more
trouble than it could possibly be worth. Even with the shift of spam
towards extortion and compromise and away from simple advertisement, a
piece of wanted mail rejected is still about an order of magnitude worse
than a piece of spam accidentally delivered. By shifting your practice
from overtly accepting borderline mail (while delivering it to a spam
box) to rejecting it (while presumably either delivering it to a spam
box or to a human judge) you would lose most of the harm mitigation you
are getting by having the spam box, while it is unclear whether you
gain anything at all.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
