MBOX-Line: From tss at iki.fi  Tue Jun 15 10:37:23 2010
To: imap-protocol@u.washington.edu
From: Timo Sirainen <tss@iki.fi>
Date: Fri Jun  8 12:34:44 2018
Subject: [Imap-protocol] MOVE is a pipeline
In-Reply-To: <306561054.4215.1276619210367.JavaMail.root@dogfood.zimbra.com>
References: <306561054.4215.1276619210367.JavaMail.root@dogfood.zimbra.com>
Message-ID: <1276623443.2916.36.camel@kurkku.sapo.corppt.com>

On Tue, 2010-06-15 at 09:26 -0700, Dan Karp wrote:
> > > Would it be unreasonable to state that the only untagged EXPUNGE
> > > responses from a MOVE command may be those directly resulting from
> > > the MOVE? (UID MOVE, like UID FETCH, would have no such
> > > constraints.)
> > 
> > That requires an amendment to RFC 3501 7.4.1.
> 
> Good form would be to amend it in any case.  MOVE would definitely
> fall into the category of commands for which EXPUNGEs from other
> sources would cause loss of synchronization, and thus it needs to
> be added to the list in 7.4.1.

The problem isn't only EXPUNGEs, but all untagged replies that refer to
messages (assuming MOVE doesn't send EXPUNGEs/MOVED replies to note when
the sequences change).

Oh, now I started also thinking about NOTIFY+QRESYNC combination where
you can tell it to send VANISHED replies at any time. If MOVE is sending
EXPUNGE/VANISHED replies and if client cares about which ones of those
were from MOVE, it couldn't really know since a VANISHED reply might
have been sent to client just before the server received MOVE command.


