53 lines
2.3 KiB
Plaintext
53 lines
2.3 KiB
Plaintext
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>
|