On the IMAP mail server side (RHEL9 with Cyrus IMAP 3.4.7), the customer have observed an issue where emails moved to the Trash folder by multiple IMAP client applications (MUAs) are not physically deleted from the server, even after users perform actions such as "Empty Trash." Specifically, the message files under each user's Trash folder (e.g., ./user/*/Trash) remain undeleted.

Since the Trash appears empty from the MUA's perspective, it seems there is an inconsistency between the actual message files on the server and the metadata (presumably index information) referenced by the MUAs.

Then I have asked the customer to run ipurge command to delete messages, this command could search the old messages, and only delete the messages
meta data not the physical mail file.

1. sudo -u cyrus ipurge -f -d 30 user/*/Trash

IN my test environment, I tried to reproduce this issue the messages cannot be physically removed in my cyrus-imapd server too. The below is the result:

1. telnet localhost 143
   Trying ::1...
   Connected to localhost.
   Escape character is '^]'.

• OK [CAPABILITY IMAP4rev1 LITERAL+ ID ENABLE STARTTLS AUTH=PLAIN AUTH=LOGIN AUTH=CRAM-MD5 AUTH=DIGEST-MD5 AUTH=NTLM AUTH=GSSAPI SASL-IR] node-0.mengyirhel9u4.lab.xxx.redhat.com Cyrus IMAP 3.4.8-1.el9 Fedora server ready
  1 LOGIN test redaht
  1 OK [CAPABILITY IMAP4rev1 LITERAL+ ID ENABLE ACL ANNOTATE-EXPERIMENT-1 BINARY CATENATE CHILDREN CONDSTORE CREATE-SPECIAL-USE ESEARCH ESORT LIST-EXTENDED LIST-MYRIGHTS LIST-STATUS MAILBOX-REFERRALS METADATA MOVE MULTIAPPEND NAMESPACE OBJECTID QRESYNC QUOTA RIGHTS=kxten SAVEDATE SEARCH=FUZZY SORT SORT=DISPLAY SPECIAL-USE STATUS=SIZE THREAD=ORDEREDSUBJECT THREAD=REFERENCES UIDPLUS UNSELECT URLAUTH URLAUTH=BINARY WITHIN DIGEST=SHA1 LIST-METADATA NO_ATOMIC_RENAME PREVIEW=FUZZY SCAN SORT=MODSEQ SORT=UID THREAD=REFS X-CREATEDMODSEQ X-REPLICATION XLIST XMOVE LOGINDISABLED XCONVERSATIONS COMPRESS=DEFLATE X-QUOTA=STORAGE X-QUOTA=MESSAGE X-QUOTA=X-ANNOTATION-STORAGE X-QUOTA=X-NUM-FOLDERS IDLE] User logged in SESSIONID=<cyrus-1744767180-22675-1-14533567385598052441>
  1 LIST "" "*"
• LIST (\HasNoChildren) "/" INBOX
• LIST (\HasNoChildren) "/" INBOX.Trash
  1 OK Completed (0.000 secs 2 calls)
  1 SELECT INBOX.Trash
• OK [CLOSED] Ok
• 1 EXISTS
• 0 RECENT
• FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
• OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen \*)] Ok
• OK [UNSEEN 1] Ok
• OK [UIDVALIDITY 1744765265] Ok
• OK [UIDNEXT 2] Ok
• OK [HIGHESTMODSEQ 4] Ok
• OK [URLMECH INTERNAL] Ok
• OK [ANNOTATIONS 65536] Ok
  11 OK [READ-WRITE] Completed
  . store 1 flags Deleted <--- Set \Deleted flag to this test mail
• FLAGS (\Answered \Flagged \Draft \Deleted \Seen Deleted)
• OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen Deleted \*)] Ok
• 1 FETCH (FLAGS (Deleted))　　　<-- Confirmed flag is set
  . OK Completed
  . expunge　　　　<--- Attempt to delete. But No message deleted.
  . OK Completed
  11 SELECT INBOX.Trash
• OK [CLOSED] Ok
• 1 EXISTS
• 0 RECENT
• FLAGS (\Answered \Flagged \Draft \Deleted \Seen Deleted)
• OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen Deleted \*)] Ok
• OK [UNSEEN 1] Ok
• OK [UIDVALIDITY 1744765265] Ok
• OK [UIDNEXT 2] Ok
• OK [HIGHESTMODSEQ 5] Ok
• OK [URLMECH INTERNAL] Ok
• OK [ANNOTATIONS 65536] Ok
  11 OK [READ-WRITE] Completed

Actual result: The mail messages can be deleted by ipurge command or deleted in telnet.

NOW the physical files of emails cannot be completely deleted, causing the customer's disk capacity to be almost exhausted. The customer urgently needs a method to delete the physical files of emails. Can you provide a method to delete emails before fixing this bug?

Since customer has addressed their concern on this which is impacting their daily operation and is requesting an urgent update from Red Hat, could you please have a look at this?

Thank you
Mengyi