For a long time I've enjoyed the fact that IMAP devices (e.g. iPhone) and Zimbra did an excellent job dealing with offline scenarios, so changes that were made on the device while they could not connect to the Zimbra server were quickly resolved the moment the connection was re-established. You could move messages to different folders, flag them, delete them, etc. and once the IMAP connection was reestablished all these updates would get applied to the messages in the Zimbra store.
Yesterday, I ran into an odd scenario that sent me down a rabbit hole uncovering a nasty IMAP sync bug in Zimbra 8.8.8 Patch 5. In that version, once the IMAP connection to the Zimbra has been re-established, the messages you touched totally disappear. In the Web Client they are nowhere to be found anymore, not even in Trash. On the IMAP device where the changed were made the message header still exists, but when you try to read the message the email client on the device hangs for a while and ultimately complains that the message cannot be downloaded from the server.
After a lot of research I discovered that [bug]all affected messages have the BITMASK_DELETED bit (128) set in on the flags field of mail_item table (of mboxgroup#)[/bug]. When this happens the message is effectively gone: the IMAP client can no longer access it, and the message completely disappears from the web client. (No longer visible in any folder, including Trash, and cannot be found anymore using Search.) The messages appear to be left in whatever folder they were originally at; the folder_id field does not change to that of Trash.
When I manually update the flags field and unset the BITMASK_DELETED bit, the message re-appears in the web client. The IMAP client unfortunately remains stuck in a "LOADING" phase when you try to view the message, even after restarting both the email client and the Zimbra server. Edit: additionally moving the message to the folder where the IMAP client thinks the message should be seems to make it accessible again.
This leaves me with a number of questions:
- Is anyone else seeing this behavior as well?
- If yes, was this a recent change or did I simply not notice in the last couple of months?
- What purpose does the BITMASK_DELETE flag serve? Normally deleted messages get moved to Trash, where they get purged after 30 days, but this is a seemingly weird state where the message is "deleted", even though it's not. Is this part of the message retention logic?
- Would the message get purged for real at some point? How long would that take?
- Is there an official method to recover these types of messages that does not require the use of the mysql client?
System configuration being used:
- Zimbra 8.8.8 Patch 5 for RHEL 7, Open Source Edition.
- Using the standard built-in IMAP server (not the new stand-alone one)
- nio_imap_enabled = true
I'd appreciate hearing if others are seeing this as well, and if this is perhaps a known (recent) bug or one that I need to submit