75 lines
3.0 KiB
Plaintext
75 lines
3.0 KiB
Plaintext
MBOX-Line: From gds at chartertn.net Mon Oct 9 15:59:53 2017
|
|
To: imap-protocol@u.washington.edu
|
|
From: Gene Smith <gds@chartertn.net>
|
|
Date: Fri Jun 8 12:34:55 2018
|
|
Subject: [Imap-protocol] Is server re-use of UID OK?
|
|
In-Reply-To: <1611d170-ea34-1adf-8cd6-090e571cf12c@hireahit.com>
|
|
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>
|
|
<1611d170-ea34-1adf-8cd6-090e571cf12c@hireahit.com>
|
|
Message-ID: <2e246450-3dca-0522-6cb5-72016def70a9@chartertn.net>
|
|
|
|
On 10/9/17 5:32 PM, Dave Warren wrote:
|
|
>
|
|
> 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.
|
|
|
|
OK, s/Message was deleted/Message was deleted in the client program/ :)
|
|
|
|
>
|
|
> 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.
|
|
|
|
Openwave has no problem if the copy destination mbox is first expunged
|
|
or if the original UID now having the \deleted flag is expunged with
|
|
"uid expunge <uid>" since openwave has UIDPLUS capability. In that case
|
|
the server copies to a new UID >= UIDNEXT with \deleted not set so the
|
|
copied-in message is visible in the client program.
|
|
|
|
So I think if there is a bug in the openwave server it because it
|
|
somewhat violates this requirement for the COPY command from rfc 3501:
|
|
|
|
"The COPY command copies the specified message(s) to the end of the
|
|
specified destination mailbox. The flags and internal date of the
|
|
message(s) SHOULD be preserved, and the Recent flag SHOULD be set,
|
|
in the copy."
|
|
|
|
1.The copy does not always copy messages to the "end" of specified
|
|
destination mbox. (I don't see an explicit definition for "end" in the
|
|
rfc but I am sure it means at UID >=UIDNEXT or at the next greater
|
|
sequence number.)
|
|
|
|
2.When it does a copy to an existing and unexpunged UID not at the "end"
|
|
it does not preserve the flag states from the source mbox/UID. Also, the
|
|
Recent flag is not set. Of course, this is a SHOULD requirement so maybe
|
|
there are valid reasons for not doing these that I'm not aware of.
|
|
|
|
-gene
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
>
|
|
> _______________________________________________
|
|
> Imap-protocol mailing list
|
|
> Imap-protocol@u.washington.edu
|
|
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
|
|
|
|
|