MBOX-Line: From brong at fastmail.fm  Mon Jan 25 15:41:35 2016
To: imap-protocol@u.washington.edu
From: Bron Gondwana <brong@fastmail.fm>
Date: Fri Jun  8 12:34:55 2018
Subject: [Imap-protocol] Selected mailbox deleted by another client
In-Reply-To: <20160125231528.GA21616@mew>
References: <20160125231528.GA21616@mew>
Message-ID: <1453765295.487330.502398698.1C26076F@webmail.messagingengine.com>

On Tue, Jan 26, 2016, at 10:15, Omar Sandoval wrote:
> I haven't actually tried it, but Dovecot apparently disconnects the
> client [2].
> 
> So, what's the correct behavior here? I'm a fan of the behavior I quoted
> above, and the Dovecot behavior also seems sane. Gmail's behavior seems
> utterly incorrect, however. NOOP is definitely not supposed to change
> the connection state, so this appears to be a bug. Any thoughts?

Cyrus has a switch called 'disconnect_on_vanished_mailbox' which gives
the same behaviour as Dovecot.  It defaults to off, but my testing just now
showed an immediate disconnect without even running the NOOP when I
ran the command, so I'll be investigating that (and adding a test case to
our testing framework)

Thanks for bringing this up :)

What Cyrus is supposed to do is to issue an EXPUNGE for every existing
message (or a VANISHED if QRESYNC is turned on) and then a NO in
response to the command.  You would remain "selected" though.

I guess you could return:

<tag> NO [CLOSED] Mailbox no longer exists

If QRESYNC is enabled...

https://tools.ietf.org/html/rfc5162#section-3.7

Another possible thing (and what Cyrus IMAP used to do for a little while
in the 2.4 series when I added long-lived index locks) is to say
"NO Mailbox is locked" to the session which tries to delete an open
mailbox.  This was bad because the situation actually occurs quite often
in practice that someone's phone or desktop is sitting there with a mailbox
open for hours or days just NOOPing away.

Bron.

-- 
  Bron Gondwana
  brong@fastmail.fm