wasm-demo/demo/ermis-f/imap-protocol/cur/1600094986.22566.mbox:2,S

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/