Reappearing emails - IMAP trace

[Ron Cleven]

>> >
>> >A few days back, I sent an overview of this problem, but received no responses.   Since then, I have run dozens of traces to isolate the problem, difficult because there are timing issues involved.  I have finally nailed it down.  If this is not the proper place to report such bugs or if someone knows that this bug has been fixed, please let me know.  As I noted in my earlier post, we have been running Dovecot 2.2.10 with a pair of CentOS 7 boxes with replications for the past year.  We have been quite happy with the performance and reliability.
>> >
>> >Recently we received a report that emails could reappear in the INBOX after being deleted.  After running a pile of traces, I determined that the problem was strangely related to replications.  For the purposes of this discussion, I will refer to the two symmetric replicating servers as A and B.  Further, let us assume that during "normal" operation, all the emails are delivered to A via SMTP and are replicated to B.  Under those assumptions, if the IMAP user connects to A (where the messages were originally delivered), there is no problem, at least no problem I was able to find.  The problem I am describing only arises if the IMAP user connects to B.  Connecting to B has never presented any other problems that I am aware of.
>> >
>> >The test for which I have provided the trace starts with a test mailbox containing only 3 unread messages in the INBOX.  Moving 1 of the unread messages to Trash is all that is needed to reproduce the problem.  Remember this is ONLY a problem if the IMAP sessions do not connect to the server to which the messages were originally delivered.  Also, I found that there is a timing window.  The critical IMAP commands are:
>> >
>> >   UID STORE xxx +FLAGS.SILENT (\Seen)
>> >   UID MOVE xxx Trash
>> >
>> >If you introduce a large enough delay (I arbitrarily chose 5 seconds) between those two commands, there is no problem. Presumably this has to do with the two boxes syncing up some critical data structure.
> What mailbox format do you use? Are you able to reproduce this by running doveadm sync commands manually instead of letting replication do it? For example:
>
>   - doveadm sync -s "" -d -u user at domain > state
>   - Run the UID STORE & UID MOVE
>   - doveadm sync -s "`cat state`" -d -u user at domain
>
> There have been some fixes, especially recentlyhttps://github.com/dovecot/core/commit/950a6e61d6c2dac961ce031bdd8b2895bc32b827  sounds a bit similar although I don't really see how it would apply here. Would be a good idea to try anyway with v2.2.22.rc1 (which seems to be stable enough that I'll make v2.2.22 release soon).
>
> Anyway, I attempted a few times to reproduce it with your test but wasn't able to.
I was out when you were kind enough to reply.  To answer your question, 
we are using Maildir format.  The trace I provided was based upon IMAP 
interactions with Roundcube (though the problem was reproducable with 
several mail clients).  I left in a few more steps to make the trace 
look less contrived.  However, I reduced it further to just a couple of 
connection sessions.  What I found in that exercise that was not 
apparent to me in my prior posting was that the "STATUS INBOX" command 
that ultimately reveals the problem (it shows the message reappearing) 
only becomes "wrong" when it is done in a subsequent session.  That is, 
even if I inject an artificially large delay after the "UID STORE" / 
"UID MOVE" commands before the "STATUS INBOX" command in the same 
session, that result is never "wrong".  But, as soon as I open a 
subsequent IMAP session, the "STATUS INBOX" command then shows the 
problematic results.  I have never dug into the Dovecot code base, but I 
assume this relates to how the session data is cached and how the 
replications update it.  None of this is relevant if the problem has 
already been fixed, so I will endeavor to set up a couple of test boxes 
with the current version to verify.  The link you provided does look 
quite hopeful. Thanks so much.