[Bug] I still receive letters from addresses marked as Spam

[tprudentova]

0.12.0, tested on Android, Safari, Firefox, Opera; mail.stg.lin-saas.com

1. Select a letter, mark it as Spam
2. Receive a letter from the sender of the letter marked as Spam
3. The letters still arrive to Inbox and not to Spam

Expectation: if I marked an address as Spam, the letters arrive to the Spam folder; I see the Spam banner

Screen.Recording.2024-08-13.at.17.52.26.mov

[hoangdat]

Hi @Arsnael ,
what happens if an email address which was marked as spam previously send us another emails?

[Arsnael]

Depends how TMail was configured with rspamd on TWP (not gonna check now I'm busy on customer deployment).

It's a learning process, a mail is scored by rspamd on different criterias as spam or not, not only on the sender as well, so maybe it would need a bit more to learn. And maybe the rspamd listener aint used, cron jobs are for daily spam and reports and maybe need to wait or something is wrong in the setup. Would need to check if per user spam report has been enabled or not on twp.

I wouldn't call that a bug though...

[quantranhong1999]

As Rene said, the spam learning on the backend side is a process e.g. spam learning only triggers having 20 spam messages for example. Of course, we could lower the threshold, but a small learning set is not efficient enough (be careful with false negative).

I would not consider it a bug either. If the user needs to avoid receiving mail from an address, I think the frontend side could support a button to automatically create an email rule that moves the mails to Spam if the address matched.

[hoangdat]

• when mark as spam, tmail should mark the sender as spammer too (use email-rule for this)
  Cc: @Bobpodvalnyi

[chibenwa]

We need to review helm chart settings ?

[hoangdat]

We need to review helm chart settings ?

@Arsnael can you take a look?

[Arsnael]

As said earlier, it's not as simple as "I mark an email as spam so from now on it always gets rejected!"

It's a machine learning process. When you mark a mail as spam, it's not only about the sender address, but a lot of components. If you mark as spam multiple times though emails coming from the same sender, eventually the spam detection algorithm might take that into account. It will degrade the scoring until it's degraded enough to be immediately recognized as a spam.

Also note that on TWP we didn't turn per user Bayes algorithm, so it's general. Maybe we should, but then you would need to have personally marked as spam a certain number of emails after turning it on to start being effective.

Except for that, I don't understand what else you expect from us here honestly :)

[hoangdat]

[quantranhong1999]

I think the frontend side could support a button to automatically create an email rule that moves the mails to Spam if the address matched. as I proposed above - maybe is what you want?

[hoangdat]

Desc:

• Mark as spam will show a dialog to indicate that: mail will be move to spam, and this sender will be marked as spammer.
• Name of email rule, which is created to move email from this spammer to Spam folder

@dieptran88 please help us.

[chibenwa]

STOP

For your infomation per user bayes DBs were NOT applied on imap.linagora.com. Which means that per user feedback on the platform was innefective.

We need to connect onto RSpamD URL for each deployment and validate several users are reported onto the wecome URI

So as a starter the It do not work statement is based on an incomplete deployment: THUS this do not mean that the product needs to evolve.

Also I do not like much the proposed alternatives:

• Mark as spam will show a dialog to indicate that: mail will be move to spam, and this sender will be marked as spammer.

Careful of not overloading the UI / adding clicks! Spam management should be as transparent and as painless as possible.

Sender marked as spammer is technically already done by RSpamd but in a much more clever fashion.

Name of email rule, which is created to move email from this spammer to Spam folder

Email rules may not be the greatest tool we have to be honnest.

Given N rule in an account evaluating the rules is O(N) for each incoming emails. This is because such rules are very generic thus we do bot build indexes in order to ease their evaluation,,,

This means our solution should keep this N in a reasonable size. Rule count should not excess saay 100 rule...

If spammer creates a rule then I can see this going to well over 10.000 rules on an executive account: we will get perf issues.

Also the valuable rules I created for sorting my important emails will be lost in the noise of the antispam rules... So not only we nuke the perfs but we'd also nuke the UX

Finally a good chunk of spams use always a different sender (to bypass anti-spam!). The approach of block the sender would be mostly inneffective.

I do not deny the need for a blocklist to just stop receiving emails from some users but IMO this would be a distinct feature and we could for instance leverage the Apache James blocklist capabilities which are likely to be much much more suited to the job.

IMO the topic deserves a workshop of its own.