125 lines
5.6 KiB
Plaintext
125 lines
5.6 KiB
Plaintext
MBOX-Line: From bill.shannon at ymail.com Mon May 25 23:31:45 2015
|
|
To: imap-protocol@u.washington.edu
|
|
From: Bill Shannon <bill.shannon@ymail.com>
|
|
Date: Fri Jun 8 12:34:55 2018
|
|
Subject: [Imap-protocol] COPYUID message order
|
|
In-Reply-To: <CABa8R6s6FQaj6tJRfkiZp+U1ybUeKsOYNb96BrFyiP4=WGavUA@mail.gmail.com>
|
|
References: <555FBFD2.1030800@ymail.com> <CABa8R6tpd-2GPoSTX0_d8wnROvQpm4_zmMxconJDPPud3NNdww@mail.gmail.com> <555FD141.1060300@ymail.com> <B992E8DF-EF7F-4C29-9869-41C8B4728D2D@isode.com>
|
|
<CABa8R6s6FQaj6tJRfkiZp+U1ybUeKsOYNb96BrFyiP4=WGavUA@mail.gmail.com>
|
|
Message-ID: <55641351.8030608@ymail.com>
|
|
|
|
I'd like to be able to report the status of each message that was requested to
|
|
be copied. If one of the messages was not copied for some reason, and so is
|
|
left out of the returned list of source UIDs, how do I figure out which one that
|
|
was? Without a complete map from sequence number to UID, it seems that the
|
|
COPYUID response code for the simple COPY command may not be sufficient.
|
|
|
|
|
|
Brandon Long wrote on 05/23/2015 12:30 PM:
|
|
>
|
|
> I don't think you can guarantee that all of the messages you asked to be
|
|
> copied were, for example one of them may have been expunged by a different client.
|
|
>
|
|
> Not sure what the need to match the requested UIDs vs the source UIDs
|
|
> returned, but they may not match.
|
|
>
|
|
> Brandon
|
|
>
|
|
> On May 23, 2015 3:52 AM, "Alexey Melnikov" <alexey.melnikov@isode.com
|
|
> <mailto:alexey.melnikov@isode.com>> wrote:
|
|
>
|
|
> Hi Bill,
|
|
>
|
|
> On 23 May 2015, at 02:00, Bill Shannon <bill.shannon@ymail.com
|
|
> <mailto:bill.shannon@ymail.com>> wrote:
|
|
>
|
|
>> I *so* wish there were compatibility tests for servers, rather than "it
|
|
>> didn't break any clients so it must be good enough". :-)
|
|
>>
|
|
>> Ok, how about this. If I sort the original message numbers, and sort the
|
|
>> returned source and destination UIDs, the result will be one-to-one,
|
|
>> right? The first message number will correspond to the first source UID,
|
|
>> which will correspond to the first destination UID, right? And all three
|
|
>> sets will have exactly the same cardinality?
|
|
>
|
|
> Yes. I don't think it really matters in which order messages are copied,
|
|
> as long as the matching UIDs are returned correctly.
|
|
>
|
|
>>
|
|
>> Brandon Long wrote on 05/22/2015 05:17 PM:
|
|
>>> At least for Gmail, we always re-order the given set into sequence order
|
|
>>> (which is the same as uid order) before doing any operation. So, the
|
|
>>> source UIDs in COPYUID are in the order in which they were copied.
|
|
>>>
|
|
>>> Since a COPY in Gmail is the equivalent of adding a label to a message,
|
|
>>> the message may already have that label, so it may already be in the
|
|
>>> recipient mailbox. We always return the destination UIDs in the order
|
|
>>> which matches the source UID order, so in your example, source UID 1 is
|
|
>>> destination UID 2, and source UID 2 is destination UID 1.
|
|
>>>
|
|
>>> When APPEND'ing a duplicate message, we update the UID assigned to the
|
|
>>> original to be the newest UID in the mailbox (and that's returned with
|
|
>>> APPENDUID), since we found clients typically assumed that was the case
|
|
>>> and could get confused.
|
|
>>>
|
|
>>> We could have done this with COPY, I guess, but we didn't see any client
|
|
>>> issues in testing, so we left it this way since the performance is better.
|
|
>>>
|
|
>>> Brandon
|
|
>>>
|
|
>>> On Fri, May 22, 2015 at 4:46 PM, Bill Shannon <bill.shannon@ymail.com
|
|
>>> <mailto:bill.shannon@ymail.com>> wrote:
|
|
>>>
|
|
>>> I'm unclear on the requirements around the COPY command and the COPYUID
|
|
>>> response code.
|
|
>>>
|
|
>>> Is there any guarantee that the order of messages in the COPY command is
|
|
>>> the order they'll appear in the destination mailbox? Or are they
|
|
>>> allowed to appear in any arbitrary order in the destination mailbox?
|
|
>>> (After any existing messages, of course.)
|
|
>>>
|
|
>>> RFC 4315 says of the COPYUID response:
|
|
>>>
|
|
>>> The source UID set is in the order the message(s) were copied; the
|
|
>>> destination UID set corresponds to the source UID set and is in
|
|
>>> the same order.
|
|
>>>
|
|
>>> Exactly what order is that? Is it the order in which the messages were
|
|
>>> mentioned in the COPY command? Is it the order they actually appear in
|
|
>>> the destination mailbox (assuming it can be different)? Or is it in
|
|
>>> some other undefined order?
|
|
>>>
|
|
>>> With Gmail I'm getting
|
|
>>>
|
|
>>> A1 COPY 1:2 dest
|
|
>>> A1 OK [COPYUID 123456 1:2 2,1]
|
|
>>>
|
|
>>> and
|
|
>>>
|
|
>>> A1 COPY 2,1 dest
|
|
>>> A1 OK [COPYUID 123456 1:2 2,1]
|
|
>>>
|
|
>>> The order of the source UIDs is unrelated to the order the messages
|
|
>>> are mentioned in the COPY command and unrelated to the order they
|
|
>>> appear in the destination mailbox.
|
|
>>>
|
|
>>> If I don't know the UIDs of the source messages, is there any way to
|
|
>>> determine which message was copied to which UID in the destination
|
|
>>> mailbox?
|
|
>>> _______________________________________________
|
|
>>> Imap-protocol mailing list
|
|
>>> Imap-protocol@u.washington.edu <mailto:Imap-protocol@u.washington.edu>
|
|
>>> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
|
|
>>>
|
|
>>>
|
|
>>
|
|
>> _______________________________________________
|
|
>> Imap-protocol mailing list
|
|
>> Imap-protocol@u.washington.edu <mailto:Imap-protocol@u.washington.edu>
|
|
>> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
|
|
>
|
|
|
|
-------------- next part --------------
|
|
An HTML attachment was scrubbed...
|
|
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20150525/9a8de554/attachment.html>
|