68 lines
3.1 KiB
Plaintext
68 lines
3.1 KiB
Plaintext
MBOX-Line: From blong at google.com Mon Oct 9 16:30:33 2017
|
|
To: imap-protocol@u.washington.edu
|
|
From: Brandon Long <blong@google.com>
|
|
Date: Fri Jun 8 12:34:55 2018
|
|
Subject: [Imap-protocol] Is server re-use of UID OK?
|
|
In-Reply-To: <d0bd4b95-90bb-4fae-937e-f4ad0c2ebd09@gulbrandsen.priv.no>
|
|
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>
|
|
Message-ID: <CABa8R6ucJXxUp9kAQ+_fDvtEAwmAYtJ6Hmr60J5=SW48SLvmig@mail.gmail.com>
|
|
|
|
On Mon, Oct 9, 2017 at 7:39 AM, Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
|
|
wrote:
|
|
|
|
> Gene Smith writes:
|
|
>
|
|
>> Yes, for other IMAP servers I have tested, if I copy message "A" 10 times
|
|
>> into Inbox I see 10 identical copies of message A in Inbox. For this
|
|
>> openwave server, I see only 1 (and uid fetch 1:* (FLAGS) shows only 1).
|
|
>>
|
|
>
|
|
> Have you tested with gmail?
|
|
|
|
|
|
Since Gmail considers a COPY operation as an "add label" operation, it's
|
|
usually a no-op if the message already has that label, which is what would
|
|
happen in this case.
|
|
|
|
There are cases where Gmail does "reassign UID" on a COPY, ie it bumps the
|
|
UID of a message to the UIDNEXT. It does this if the user is calling COPY
|
|
with a source/target folder that are the same, on the assumption that the
|
|
user is trying to make an actual copy of the message in the same folder.
|
|
Clients doing this tend to be confused if the message isn't the latest UID
|
|
in that case. We also reassign UIDs when messages are moved to/from the
|
|
spam/trash folders, for similar reasons. (Note that APPEND always bumps
|
|
the UID when it detects an attempt to APPEND a duplicate message for
|
|
similar reasons to the COPY to the same folder)
|
|
|
|
Most IMAP flags are also implemented as labels, and so are consistent
|
|
across all "copies" of a message. The exception is \Deleted, so doing
|
|
something like a COPY/Deleted as a MOVE operation without an EXPUNGE and
|
|
then doing it back will leave both "copies" with a \Deleted flag and both
|
|
will be removed with EXPUNGE. That said, the default is for the user to be
|
|
in auto-expunge mode, in which case storing a \Deleted flag will result in
|
|
the message being EXPUNGED (that label removed) at the next sync point.
|
|
|
|
IE, from the given example:
|
|
C: aaa UID COPY 1267 "Mbox"
|
|
S: aaa OK [COPYUID 123456789 1267 1007] UID COPY completed
|
|
C: bbb UID store 1267 +Flags (\Deleted)
|
|
|
|
The UID store is a sync point, so the message will be auto-expunged at this
|
|
point, so the COPY back will get a new UID.
|
|
|
|
You'd need to change the user using the advanced IMAP options to a
|
|
different deletion mode to see the UID maintained.
|
|
|
|
Also, Gmail offers the MOVE extension, so you should really use that
|
|
instead of COPY\Deleted\EXPUNGE.
|
|
|
|
Brandon
|
|
-------------- next part --------------
|
|
An HTML attachment was scrubbed...
|
|
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20171009/ea8f1474/attachment.html>
|