71 lines
2.7 KiB
Plaintext
71 lines
2.7 KiB
Plaintext
MBOX-Line: From osandov at osandov.com Mon Jan 25 15:15:28 2016
|
|
To: imap-protocol@u.washington.edu
|
|
From: Omar Sandoval <osandov@osandov.com>
|
|
Date: Fri Jun 8 12:34:55 2018
|
|
Subject: [Imap-protocol] Selected mailbox deleted by another client
|
|
Message-ID: <20160125231528.GA21616@mew>
|
|
|
|
Hi,
|
|
|
|
While working on an IMAP client, I seem to have encountered an edge-case
|
|
in the IMAP protocol, and I can't find any clarification elsewhere. In
|
|
particular, I'm talking about the following scenario where two clients
|
|
C1 and C2 are accessing the same server S:
|
|
|
|
C1: A002 SELECT foo
|
|
...
|
|
S: A002 OK [READ-WRITE] foo selected. (Success)
|
|
C2: A002 DELETE foo
|
|
S: A002 OK Success
|
|
C1: A003 UID FETCH 1 ENVELOPE
|
|
S: ???
|
|
|
|
That is, when C2 deletes the mailbox that C1 currently has selected,
|
|
what happens when C1 tries to access that mailbox? There's a previous
|
|
discussion here [1] about what should happen in the case that a client
|
|
attempts to delete the mailbox that it has selected which briefly talks
|
|
about the case I'm asking about here. Here's one proposal from that
|
|
thread:
|
|
|
|
> Or, you can pretend the mailbox is deleted, but still allow all FETCH
|
|
> operations, actually physically deleteing it when the last client
|
|
> leaves the selected state on it. This is similar to the situation of
|
|
> deleting an open file on UNIX, say - the file still exists, but has
|
|
> no name anymore, no applications with it open can still use it, no no
|
|
> new applications can open it.
|
|
|
|
I tried this out on Gmail to see what would happen and got some weird
|
|
results:
|
|
|
|
C1: A003 UID FETCH 1 ENVELOPE
|
|
S: A003 OK Success
|
|
C1: A004 NOOP
|
|
S: A004 OK Success
|
|
C1: A005 UID FETCH 1 ENVELOPE
|
|
S: A005 BAD UID FETCH not allowed now.
|
|
|
|
At first, Gmail seemed to be exhibiting the behavior described in my
|
|
quote. But, inexplicably, after issuing a NOOP, the connection
|
|
apparently left the Selected state and entered the Authenticated state.
|
|
|
|
I dusted off an old Yahoo mail account and got an even weirder result:
|
|
|
|
C1: A003 UID FETCH 1 ENVELOPE
|
|
S: A003 OK UID FETCH completed
|
|
C1: A004 NOOP
|
|
S: A004 NO [SERVERBUG] NOOP Server error - Please try again later
|
|
|
|
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?
|
|
|
|
1: http://mailman13.u.washington.edu/mailman/htdig/imap-protocol/2005-September/000021.html
|
|
2: http://hg.dovecot.org/dovecot-2.1/rev/81a659ab9183
|
|
--
|
|
Omar
|
|
|