40 lines
1.4 KiB
Plaintext
40 lines
1.4 KiB
Plaintext
MBOX-Line: From jkt at flaska.net Mon Jan 25 15:43:06 2016
|
|
To: imap-protocol@u.washington.edu
|
|
From: =?iso-8859-1?Q?Jan_Kundr=E1t?= <jkt@flaska.net>
|
|
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: <4435a78f-3e95-4f3c-9a76-95cdabce95d7@flaska.net>
|
|
|
|
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/
|
|
|