• Hi, Pleskians! We are running a UX testing of our upcoming product intended for server management and monitoring.
    We would like to invite you to have a call with us and have some fun checking our prototype. The agenda is pretty simple - we bring new design and some scenarios that you need to walk through and succeed. We will be watching and taking insights for further development of the design.
    If you would like to participate, please use this link to book a meeting. We will sent the link to the clickable prototype at the meeting.
  • Our UX team believes in the in the power of direct feedback and would like to invite you to participate in interviews, tests, and surveys.
    To stay in the loop and never miss an opportunity to share your thoughts, please subscribe to our UX research program. If you were previously part of the Plesk UX research program, please re-subscribe to continue receiving our invitations.
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.

Forwarded to devs Plesk Email Security spam email deleted are treated as ham

oskar.szafraniec

New Pleskian
Username:

TITLE

Plesk Email Security spam email deleted are treated as ham

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE

Debian 9.13
Plesk 18.0.44

PROBLEM DESCRIPTION

I noticed that when some users delete emails from Spam folder (moved to Trash) sa-learn --ham is fired on it. Change in es-report-ham.sieve listed below solves the problem. Can someone from Plesk Team check it? After some updates (i think from Plesk Email Security ext) I have to change this by hand. I think this can happen when a mailbox value is not Trash but INBOX.Trash.

STEPS TO REPRODUCE

Delete email from Spam folder, so it is moved to Trash.

ACTUAL RESULT

sa-learn --ham process is fired so the email is treaded as HAM

EXPECTED RESULT

Email should be just moved without starting sa-learn process

ANY ADDITIONAL INFORMATION

Below chenge fixes it in my case.

# diff es-report-ham.sieve.org es-report-ham.sieve 7c7 < if string "${mailbox}" "Trash" { --- > if string :matches "${mailbox}" "*Trash" {

YOUR EXPECTATIONS FROM PLESK SERVICE TEAM

Confirm bug
 
Thank you for reporting. In case you need to contact support on this issue, please provide the internal ID [PPS-13846].
 
Thank you for reporting. In case you need to contact support on this issue, please provide the internal ID [PPS-13846].
This bug is still not corrected. Every time there is an update I need to change this line of code. I think my change is not breaking your solution but adds support for other configurations that holds subfolders in IMAP with a "dot" at the begining.

Any change to make this change global? Do you see anything wrong in my solution?
 
You're proposed solution seems fine. Unfortunately the issue is still in our backlog. As not many users seem to affected it received low priority. Did you ever open a support ticket about this issue? If so do you know the ticket ID?
 
No, I did not. Only here as advised in Issue - Plesk Email Security spam email deleted are treated as ham

It can be that some users don't see a problem with it as they are unaware of it. Diffrent separators are common with dovecot used in Plesk and are described here: Namespaces — Dovecot documentation

Maybe there is a solution to "drop" the dot from mail dirs?

In our system Maildirs look like this:
Code:
info/Maildir# ls -al
total 61
drwx------ 8 popuser popuser 21500 Aug  2  2022 .
drwx------ 3 popuser popuser 21500 Aug  2  2022 ..
drwx------ 2 popuser popuser     1 Aug  2  2022 cur
-rw------- 1 popuser popuser    54 Aug  2  2022 dovecot-uidlist
drwx------ 5 popuser popuser  5200 Aug  2  2022 .Drafts
-rw------- 1 popuser popuser     0 Aug  2  2022 maildirfolder
drwx------ 2 popuser popuser     1 Aug  2  2022 new
drwx------ 5 popuser popuser  5400 Aug  2  2022 .Spam
drwx------ 2 popuser popuser     1 Aug  2  2022 tmp
drwx------ 5 popuser popuser  5500 Aug  2  2022 .Trash
 
Hey, @oskar.szafraniec. The case is no longer in the backlog, it is currently in the queue. However, I still cannot provide any ETA on when a fix will be delivered. What Kaspar mentioned in his last reply is still true. There aren't many users affected and the priority is not considerably high. I forwarded your suggestion to our dev team. Apologies for the delay addressing your message.
 
Back
Top