[Dovecot] Multiple Concurrent IMAP Connections For Same User

[Ed W]

On 06/03/2011 14:51, Stephen Usher wrote:
> Actually it doesn't matter what the second client is (it can be another
> copy of TB3), the important thing is that TB3 doesn't notice the change
> underneath it. (The programmers seem to assume that it will have
> exclusive access to the mailbox from what I can see.) The real mailbox
> does change correctly, TB3's idea of what the mailbox holds does not and
> it fails to check its consistency with respect to the server.
> 
> Obviously there's a difference in behaviour for some reason when TB3
> interacts with Cyrus IMAP as it seems not to have a problem with that
> IMAP server. It's almost as if TB3 expects to be informed when there has
> been a deletion. (TB3 will notice other status changes such as a message
> being read etc.)

I may just be having the same issue as you and it's been persistent for
a while.  I believe that it's possibly a bug related to IDLE in Dovecot
(unproven and unsupported claim...)

Do you also get the same effect with read and unread marks?

We have three users here, all logging in from different local machines,
which then go through a NAT (so to Dovecot they look the same IP), and
all three machines log into the same account with the same credentials
(ie shared inbox).  We observe that generally the inbox view looks the
same on all machines and I haven't noticed any deletes not syncing
across instantly, but definitely there exists a set of circumstances
where the read/unread marks are not synced correctly.  I haven't nailed
down the specifics but I believe it might occur when one TB client isn't
focused on the shared inbox (background IDLE connection) and it might
occur only after some mins have passed in that state (nat timeout?) and
it might not occur if CONDSTORE is disabled on TB3...

Do you have a common NAT in your situation?  Could there be a NAT
timeout/IDLE permutation causing the effect you see?

Note that I can fix the sync issue by simply clicking back into the
shared inbox, toggling the state a few times and we are back in again?

My best hunch is that there is some shared code in Dovecot to send IDLE
updates every so often and it's hashed on username and IP (I think?), so
if we have two users behind nat, one using the connection regularly and
the other idle, I wonder if the nat is allowed to timeout on the idle
machine?  Definitely feels like CONDSTOR is part of the problem, but
this would fit because each side of the link would disagree on last update?

Just an idea..

Ed W