[Imap-protocol] Selected mailbox deleted by another client

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
_______________________________________________
Imap-protocol mailing list
[email protected]
http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol