Block spam at smtp time, but then still forward to users spam box
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
Re: Block spam at smtp time, but then still forward to users spam box
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)
Re: Block spam at smtp time, but then still forward to users spam box
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
Re: Block spam at smtp time, but then still forward to users spam box
On 20 May 2019, at 01:42, Brent Clark 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.
Re: Block spam at smtp time, but then still forward to users spam box
> 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 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.
