[prev in list] [next in list] [prev in thread] [next in thread]
List: imap
Subject: Re: [Imap-protocol] Selected mailbox deleted by another client
From: Jan_Kundrát <jkt () flaska ! net>
Date: 2016-01-25 23:43:06
Message-ID: 4435a78f-3e95-4f3c-9a76-95cdabce95d7 () flaska ! net
[Download RAW message or body]
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/
_______________________________________________
Imap-protocol mailing list
Imap-protocol@u.washington.edu
http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic