IMAP mailbox is read-only: why delete or EXPUNGE appears to succeed but nothing disappears

Read the mailbox selection result

When an IMAP mailbox is selected, the server tells the client whether access is read-write or read-only. RFC 9051 defines READ-WRITE and READ-ONLY response codes and makes EXAMINE explicitly read-only. A cleanup worker should record this result as part of session state. If the mailbox is read-only, do not continue into a deletion workflow and later report success merely because the connection itself stayed healthy.

Understand the two-step deletion model

Traditional IMAP deletion is usually a flag-and-expunge process. A message is marked with the \Deleted flag, then EXPUNGE permanently removes messages carrying that flag. If the selected mailbox does not allow those state changes, one or both operations will fail or have no effect. Libraries can hide protocol details behind methods such as deleteMessages or closeBox, so read their semantics and log the underlying response when cleanup behaves unexpectedly.

Do not confuse deleting a message with deleting a mailbox

IMAP has a DELETE command for removing an entire mailbox and separate message commands such as STORE, MOVE, and EXPUNGE. The similar words can create dangerous abstractions. A maintenance function named deleteFolder or delBox is not a substitute for removing messages inside INBOX. Keep message cleanup and mailbox lifecycle in different code paths, require explicit mailbox names, and test against a disposable account before giving automation delete permissions.

Prefer move-to-folder when retention matters

For bounce notices or processed auto-replies, permanently deleting immediately can make incident reconstruction harder. If the provider supports MOVE and the mailbox is writable, consider moving handled messages to an archive or processed folder first. This preserves evidence while keeping INBOX small. The folder itself must be discovered rather than hard-coded because providers and languages label Trash, Deleted Items, and Junk differently. Cleanup policy should follow the value of the messages, not merely convenience.

Handle permission changes as a state transition

A mailbox can become effectively read-only because of permission changes, shared mailbox settings, token scopes, or provider behavior. If a worker that was previously able to write suddenly receives READ-ONLY, surface it as an incident. Do not repeatedly retry EXPUNGE on every polling cycle. Repeated mutation attempts add noise and can hide the real access problem. Continue read-only processing only if that behavior is safe for your application and follow-up cancellation does not depend on moving or flagging messages.

Use UNSELECT when you need to leave without expunging

RFC 9051 defines UNSELECT as a way to leave the selected state without permanently removing messages, unlike CLOSE which can expunge deleted messages when the mailbox is writable. For automation that sometimes marks messages during inspection, choosing the correct session-ending command matters. If you are unsure whether deletion flags are present, a conservative path can prevent accidental cleanup while debugging. Library defaults should be reviewed rather than assumed.

Verify the result after a destructive operation

After any delete or move action, query by UID to confirm the expected message is no longer in the source mailbox or is present in the destination. Do not treat a successful function return as the entire QA. IMAP responses can be asynchronous and libraries may auto-expunge on close depending on configuration. Verification makes bulk cleanup safer and gives you a concrete failure point when provider semantics differ.

Create a read-only test mode

A useful safety feature is a mode that opens mailboxes with EXAMINE, runs all classification and candidate selection, but never mutates state. It can print or store which UIDs would be moved or deleted. After reviewing the sample, enable write mode in a test mailbox and confirm behavior before production. This is especially valuable for new cleanup logic because an error in reply classification can destroy the evidence you need to fix the classifier.

Fail closed when mailbox permissions are weaker than your workflow expects

IMAP SELECT can open a mailbox read-write, while EXAMINE is explicitly read-only; servers can also indicate a selected mailbox is read-only because of permissions. A cleanup worker should inspect that state before issuing STORE/EXPUNGE operations. If the mailbox is read-only, reading and correlating replies can continue, but mutation jobs should stop with a clear permission error rather than pretending the delete succeeded. This matters when a provider changes delegated access or when an account is intentionally converted to read-only during an incident.

Separate “processed” from “physically removed.” Your application can record that a reply has been correlated to an outbound thread even when it cannot modify flags or move the message. If retention policy later permits deletion, a write-enabled maintenance job can act from that processing record. When deletion is allowed, remember that IMAP’s `\Deleted` flag and EXPUNGE are distinct operations; closing behavior also matters, and UNSELECT exists for leaving a mailbox without expunging messages. For destructive tests, use a dedicated mailbox with known sample messages and verify server state after each command. The goal is to ensure a permissions surprise never causes the reply detector to lose business state merely because a housekeeping action failed.

Expose capability failures to the operator

A read-only condition should appear in health reporting before it becomes a cleanup backlog. Record the mailbox name, account, selected access mode, attempted operation, and server response. If the account was supposed to have write access, alert on the first transition rather than retrying EXPUNGE in a tight loop. If read-only access is intentional, disable mutation jobs for that mailbox and keep reply ingestion healthy. This distinction prevents a housekeeping permission problem from being misdiagnosed as an IMAP connectivity outage and gives the operator a precise permission change to investigate.

Field checklist

• Capture READ-WRITE or READ-ONLY immediately after mailbox selection.
• Keep message deletion separate from mailbox DELETE operations.
• Verify library auto-expunge behavior before bulk cleanup.
• Prefer archive/move when messages have diagnostic value.
• Stop repeated destructive retries if access changes to read-only.
• Test cleanup first with EXAMINE/read-only dry run.