39 lines
2.0 KiB
Plaintext
39 lines
2.0 KiB
Plaintext
MBOX-Line: From davew at hireahit.com Mon Oct 9 14:32:32 2017
|
|
To: imap-protocol@u.washington.edu
|
|
From: Dave Warren <davew@hireahit.com>
|
|
Date: Fri Jun 8 12:34:55 2018
|
|
Subject: [Imap-protocol] Is server re-use of UID OK?
|
|
In-Reply-To: <5dff705c-130c-ac73-fae4-b5ba1b9b0cc2@chartertn.net>
|
|
References: <38137c2b-f1f1-2bed-e22f-2aea7fa50ac3@chartertn.net>
|
|
<CAByav=gBnVkLg+4z90ewBvKRVtOrEQ7XESfirEQ1dyx=Sb0MXw@mail.gmail.com>
|
|
<abb75221-a38a-3317-86a2-98a8340e55d3@chartertn.net>
|
|
<CAByav=gfGNd2KHyx8kb9GQ-XEfs3L0LzqJuQGJRwDXg9x9mdMA@mail.gmail.com>
|
|
<1a206274-8bce-f789-4dc9-638ed20e9372@chartertn.net>
|
|
<d0bd4b95-90bb-4fae-937e-f4ad0c2ebd09@gulbrandsen.priv.no>
|
|
<5dff705c-130c-ac73-fae4-b5ba1b9b0cc2@chartertn.net>
|
|
Message-ID: <1611d170-ea34-1adf-8cd6-090e571cf12c@hireahit.com>
|
|
|
|
On 2017-10-09 14:41, Gene Smith wrote:
|
|
> Yes, in the mbox where the message was deleted, its UID is still present
|
|
> but with the \deleted flag set. The same message but with a different
|
|
> UID is in Trash. When I try to copy it back to the original mbox from
|
|
> Trash, the server indicates that it is copying it to the original UID
|
|
> (not >= UIDNEXT). The main problem I see is that this copy doesn't clear
|
|
> the \deleted flag for the UID in the original folder so the message
|
|
> remain invisible in the client.
|
|
|
|
I think it might reduce confusion if we stop saying "Message was
|
|
deleted". "Deleted" doesn't have a clear definition in this context
|
|
because it isn't really a thing in IMAP (although it is how IMAP clients
|
|
present multiple different behaviours to users). At the protocol level,
|
|
you can set the \Deleted flag or you can EXPUNGE.
|
|
|
|
Since a \Deleted flag can be trivially removed, there is no "reuse" of a
|
|
UID, the UID was still being reused and the COPY was just returning an
|
|
accurate (if unusual) result. Expunging and then reusing the UID
|
|
(assuming an unchanged UIDVALIDITY) would be a very significant problem
|
|
with regards to clients maintaining the validity of their caches, but
|
|
simply changing a flag is perfectly valid.
|
|
|
|
|