88 lines
4.0 KiB
Plaintext
88 lines
4.0 KiB
Plaintext
MBOX-Line: From gds at chartertn.net Mon Oct 9 13:41:24 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: <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: <5dff705c-130c-ac73-fae4-b5ba1b9b0cc2@chartertn.net>
|
|
|
|
On 10/9/17 10:39 AM, Arnt Gulbrandsen 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?
|
|
|
|
Just tried gmail and and if I copy a message multiple times there
|
|
remains only one copy of the message in the destination folder. I
|
|
haven't looked at the imap transactions to to see what is actually
|
|
happening.
|
|
|
|
With imap.outlook.com it does allow multiple duplicate messages to be
|
|
copied in so I assume it is assigning new and higher UID to each duplicate.
|
|
|
|
imap.yahoo seems different. When I copy in a duplicate, at the
|
|
destination folder that message seems to disappear in my client for
|
|
about 1/2 second or so and then come back. I did look at the imap
|
|
transaction for yahoo to see what is happening. Yahoo is assigning a new
|
|
and higher UID each time the duplicate message is copied to a
|
|
destination but it seems to be silently expunging the previous UID for
|
|
the message. I see nothing being "stored", such as \deleted, to the
|
|
message's previous UID and I see no expunge responses. As multiple
|
|
duplicate copies occur, the gap between the highest UID and the next to
|
|
highest UID grows (based on uid fetch 1, *).
|
|
|
|
Zimbra and mDaemon allow multiple duplicates to be copied in like
|
|
outlook. Haven't looked at transaction details.
|
|
|
|
>
|
|
> The server doesn't seem to reuse a UID, if I understand you correctly.
|
|
> The message has a UID before the COPY command and nothing changes. The
|
|
> UID is in continuous use for a particular message, so there's no reuse
|
|
> going on, and the ban on reuse does not apply.
|
|
|
|
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.
|
|
|
|
>
|
|
> Can you find out whether flags apply to the message or to references?
|
|
> Ie. if you copy a message into two mailboxes and set flag "foobar" on
|
|
> the message in one mailbox, does the flag appear on the message in the
|
|
> other mailbox?
|
|
|
|
Actually, this is what happens when I delete a message from openwave
|
|
server. In the original folder the message's UID gets marked with
|
|
\deleted flag and the message is not expunged. In the Trash folder where
|
|
the client copies it on delete, the \deleted flag is *not* set. So the
|
|
exact same message resides in two folders with differing flags.
|
|
|
|
As an additional test on openwave, I copied a message from Inbox to two
|
|
different folders. In one folder I set several attributes (Important,
|
|
Starred, Junk, Unread). In the other folder these flags don't appear for
|
|
the exact same message. I then copied the this highly-flagged message
|
|
back to Inbox attempting to overwrite the original. These attributes did
|
|
not appear in the original message in Inbox.
|
|
|
|
>
|
|
> Arnt
|
|
>
|
|
> _______________________________________________
|
|
> Imap-protocol mailing list
|
|
> Imap-protocol@u.washington.edu
|
|
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
|
|
|
|
|