mailing list archives

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

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

On Tuesday, 26 January 2016 00:15:28 CET, Omar Sandoval wrote:
> 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:

There's also an RFC which outlines some possibilities, see 
https://tools.ietf.org/html/rfc2180#section-3 .

> 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.

Sounds like NO would be better reply (even for the A003), indeed.

Cheers,
Jan

-- 
Trojit?, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

On 2016-01-25 15:41, Bron Gondwana wrote:
> 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.

 From a user perspective, this is probably the least desired 
possibility, although it certainly would avoid any further complications :)

Another possibility would be to block any further attempt to SELECT, or 
add messages into the mailbox and queue the delete for the next time the 
lock is released. I know of one server that does this in certain 
circumstances, and it seems minimally harmful from a end-user and client 
perspective.

-- 
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren