MBOX-Line: From tjs at psaux.com  Sun Oct  8 18:40:26 2017
To: imap-protocol@u.washington.edu
From: Tim Showalter <tjs@psaux.com>
Date: Fri Jun  8 12:34:55 2018
Subject: [Imap-protocol] Is server re-use of UID OK?
In-Reply-To: <abb75221-a38a-3317-86a2-98a8340e55d3@chartertn.net>
References: <38137c2b-f1f1-2bed-e22f-2aea7fa50ac3@chartertn.net>
	<CAByav=gBnVkLg+4z90ewBvKRVtOrEQ7XESfirEQ1dyx=Sb0MXw@mail.gmail.com>
	<abb75221-a38a-3317-86a2-98a8340e55d3@chartertn.net>
Message-ID: <CAByav=gfGNd2KHyx8kb9GQ-XEfs3L0LzqJuQGJRwDXg9x9mdMA@mail.gmail.com>

On Sun, Oct 8, 2017 at 3:26 PM, Gene Smith <gds@chartertn.net> wrote:
>
>     C: aaa UID COPY 1267 "Mbox"
>>     S: aaa OK [COPYUID 123456789 1267 1007] UID COPY completed
>>     C: bbb UID store 1267 +Flags (\Deleted)
>>
>>     C: ccc UID COPY 1007 "Inbox"
>>     S: ccc OK [COPYUID 987654321 1007 1267] UID COPY completed
>>     C: ddd UID store 1007 +Flags (\Deleted)
>
>
I think the server is thinking, "its the same message I am copying back to
> Inbox (how does it knows? Same Message-ID or maybe checksum?) so I don't
> have to do anything." If the server had at least reset the \deleted flag on
> message at UID 1267 in Inbox I think it would be OK. The rfc says COPY must
> preserve the flags. It also says messages added to a mailbox must have UID
> >= UIDNEXT. But if the server is copying in a message that is already
> present but just flagged as \deleted, maybe RFC doesn't say you can't
> COPYUID to the original UID which is < UIDNEXT? But I think the server
> should reset \deleted at the destination.
>

Recovering a used UID is never permitted*. If there is no EXPUNGE, there
should be two copies of the message in Inbox in this example. (Setting
\Deleted is reversible.)

The design of the specification is concerned with what happens when a
separate client connects before and after this exchange. Because UIDNEXT
has not been used correctly, clients that have cached state wouldn't see
changes to the mailbox correctly.

I guess the server might have an optimization (aka hack) for this, but it
doesn't appear to be properly protocol compliant.

* unless the UIDVALIDITY is reset, which trashes everyone's caches anyway.

Tim
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20171008/831bdddd/attachment.html>
