Block spam at smtp time, but then still forward to users spam box

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Block spam at smtp time, but then still forward to users spam box

Brent Clark-4
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.

His logic is that, that the spammer does not build up a database.

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.

I am on the fence on this one, hence the reason to pick the communities
brain.

If anyone can share any thoughts or concerns, please can you share.

Many thanks
Brent
Reply | Threaded
Open this post in threaded view
|

Re: Block spam at smtp time, but then still forward to users spam box

Bill Cole-3
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
[hidden email] or [hidden email]
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Reply | Threaded
Open this post in threaded view
|

Re: Block spam at smtp time, but then still forward to users spam box

Noel Jones-2
In reply to this post by Brent Clark-4
On 5/20/2019 2:42 AM, 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.

This is not possible with the built-in postfix restrictions such as
check_*_access, or postfix rbl lookups.

This is possible for a milter or content_filter.  For example, using
amavisd-new, you can set it to reject+quarantine spam, which might
be useful for analysis.  Not sure how useful it would be to actually
deliver the spam... keeping it out of the user's mailbox is kinda
the whole point.

If you have more than a very small number of high-scoring false
positives, you should adjust your scoring.

>
> His logic is that, that the spammer does not build up a database.

His logic is flawed.

 From the spammer's point of view, there's no difference in
"reject+keep" and just "reject".

This also sounds like advice from 15+ years ago. I've heard the
"spammer database" argument (again just last week!) as an excuse to
discard all spam, and even to discard mail to unknown recipients --
both of which might have once been OK, but are now very bad
ideas[1][2]. Spammers and spam-fighting evolves. Best practice these
days is to reject unwanted mail.


>
> 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.
>
> I am on the fence on this one, hence the reason to pick the
> communities brain.
>
> If anyone can share any thoughts or concerns, please can you share.

Get off the fence and back to safety.  This is a bad idea, at least
the deliver to users part of it. Keeping for analysis is OK, but
maybe more trouble than it's worth.

If you're getting more than a tiny tiny amount of false positives
that score 15 or more, you should adjust the offending scores.


[1] Domains that accept (and possibly discard) all mail seem to be
abused by spammers-for-hire, which use them to inflate their
"guaranteed delivery" stats. This wastes your bandwidth and
processing power even if you never actually see the message.  So
reject everything you don't want.
[2] The spammers already have your user list, harvested from hacked
web sites and stolen address books, then shared or sold. Dictionary
attacks are far less popular than they once were.




   -- Noel Jones
Reply | Threaded
Open this post in threaded view
|

Re: Block spam at smtp time, but then still forward to users spam box

@lbutlr
In reply to this post by Brent Clark-4
On 20 May 2019, at 01:42, Brent Clark <[hidden email]> wrote:
> 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.

The odds of a mail scoring over 10.0 on SpamAssassin being legit are so low as to be meaningless, so that's a silly reason to implement a completely non-standard email chain that is likely to only anger your users with even more spam to sort through.

> His logic is that, that the spammer does not build up a database.

The days of that are long past. Spammers simply buy lists of billions of emails. They do not care about delivery at all.

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

I'd say 15 is far too high and including that much spam probably trains your users to never even bother looking at the spam folder, but that's fine.

> I am on the fence on this one, hence the reason to pick the communities brain.

I would never do this. My rule is very simple, anything we accept gets delivered to the user. Anything we reject gets rejected during the SMTP transaction. If it is LEGITIMATE mail, the sender will see the rejection.

--
And east is east and west is west and if you take cranberries and stew
them like applesauce they taste much more like prunes than rhubarb does.


Reply | Threaded
Open this post in threaded view
|

Re: Block spam at smtp time, but then still forward to users spam box

Thilo Molitor
> I would never do this. My rule is very simple, anything we accept gets
> delivered to the user. Anything we reject gets rejected during the SMTP
> transaction. If it is LEGITIMATE mail, the sender will see the rejection.
This simple rule ensures a timely notification of the sender if something is
wrong and I implement it like this, too.

@Brent:
If your users never (or very seldom) look into the spam folder or periodically
clear it without manually sorting it, all legitimate mail in the spam folder
will get lost without sender and recipient ever noticing.
If no spam folder is used but rejects, the sender will get notified and can try
to reach the recipient via some other communication channel.

At least in germany this has legal implications, too.
See for example this presenation (in german, sorry folks):
https://www.heinlein-support.de/vortrag/spam-quarantaene-und-tagging-der-grosse-irrtum



Am Montag, 20. Mai 2019, 12:53:34 CEST schrieb @lbutlr:

> On 20 May 2019, at 01:42, Brent Clark <[hidden email]> wrote:
> > 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.
> The odds of a mail scoring over 10.0 on SpamAssassin being legit are so low
> as to be meaningless, so that's a silly reason to implement a completely
> non-standard email chain that is likely to only anger your users with even
> more spam to sort through.
> > His logic is that, that the spammer does not build up a database.
>
> The days of that are long past. Spammers simply buy lists of billions of
> emails. They do not care about delivery at all.
> > 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.
> I'd say 15 is far too high and including that much spam probably trains your
> users to never even bother looking at the spam folder, but that's fine.
> > I am on the fence on this one, hence the reason to pick the communities
> > brain.
> I would never do this. My rule is very simple, anything we accept gets
> delivered to the user. Anything we reject gets rejected during the SMTP
> transaction. If it is LEGITIMATE mail, the sender will see the rejection.