100 lines
3.7 KiB
Plaintext
100 lines
3.7 KiB
Plaintext
MBOX-Line: From blong at google.com Tue Nov 17 16:06:39 2015
|
|
To: imap-protocol@u.washington.edu
|
|
From: Brandon Long <blong@google.com>
|
|
Date: Fri Jun 8 12:34:55 2018
|
|
Subject: [Imap-protocol] UID MOVE and untagged OKs
|
|
In-Reply-To: <564BBF09.7050804@teamaol.com>
|
|
References: <25069F83-83C9-4130-B0D0-6C4FCC37A292@jabberwocky.com>
|
|
<564BBF09.7050804@teamaol.com>
|
|
Message-ID: <CABa8R6tSWdWpSc2Xxfp+tWVk=GGRHYsdX-YmGXPVoAGCBBdPQw@mail.gmail.com>
|
|
|
|
Or his client is eating the '* ' in some fashion, it would be good for
|
|
someone with an account to verify the bad behavior.
|
|
|
|
They obviously think they're sending the right response, let's not assume
|
|
that they are sending the wrong one.
|
|
|
|
Brandon
|
|
|
|
On Tue, Nov 17, 2015 at 3:58 PM, Stu Brandt <stuart.brandt@teamaol.com>
|
|
wrote:
|
|
|
|
> David -
|
|
>
|
|
> My read matches yours. Their 2nd line is neither a tagged or untagged
|
|
> response, rfc6851 section 3.3 has a specific example covering COPYUID in
|
|
> the response, and rfc6851 section 4.3 seems pretty clear when it says to
|
|
> send the COPYUID response code in an untagged OK.
|
|
>
|
|
> - Stuart
|
|
>
|
|
>
|
|
> On 11/17/15 6:11 PM, David Shaw wrote:
|
|
>
|
|
>> Hello,
|
|
>>
|
|
>> I'm currently beating my head against a problem with a particular server
|
|
>> implementation. The problem, as best I can work out from the outside, is
|
|
>> in UID MOVE.
|
|
>>
|
|
>> My understanding from RFC-6851 is that a UID MOVE transaction should look
|
|
>> something like this (cut and paste from the RFC):
|
|
>>
|
|
>> C: a UID MOVE 42:69 foo
|
|
>> S: * OK [COPYUID 432432 42:69 1202:1229]
|
|
>> S: * 22 EXPUNGE
|
|
>> S: (more expunges)
|
|
>> S: a OK Done
|
|
>>
|
|
>> The relevant piece of this for my question is that the COPYUID response
|
|
>> is in an untagged OK. Again, from the RFC: "Servers implementing UIDPLUS
|
|
>> are also advised to send the COPYUID response code in an untagged OK before
|
|
>> sending EXPUNGE or moved responses."
|
|
>>
|
|
>> This seems straightforward.
|
|
>>
|
|
>> The server I'm having a problem (outlook.office365.com) with has a UID
|
|
>> MOVE transaction like this (actual transaction captured from my client):
|
|
>>
|
|
>> C: 14 UID MOVE 7599 "Deleted Items"
|
|
>> S: [COPYUID 12 7599 4788]
|
|
>> S: * 373 EXPUNGE
|
|
>> S: * 372 EXISTS
|
|
>> S: 14 OK MOVE completed.
|
|
>>
|
|
>> The concern is with the second line (the COPYUID response). There is no
|
|
>> untagged OK / "* OK" there, which seems incorrect to me and perhaps more
|
|
>> significantly, seems to cause the Apple iOS mail program to throw an error
|
|
>> every time a message is moved from folder to folder (which of course
|
|
>> includes the "delete this message" function).
|
|
>>
|
|
>> I've spent (literally) weeks trying to get Microsoft Office365 support to
|
|
>> acknowledge the problem, without success. The most recent response insists
|
|
>> that they are following the RFC, and in fact quoted the "Servers
|
|
>> implementing UIDPLUS are also advised to send the COPYUID response code in
|
|
>> an untagged OK before sending EXPUNGE or moved responses." line from
|
|
>> RFC-6851 as what they are doing.
|
|
>>
|
|
>> Could the experts on this list help me understand what is going on here?
|
|
>> I have no particular need to be "right" - I just want to be able to delete
|
|
>> messages without getting errors every single time.
|
|
>>
|
|
>> Thanks,
|
|
>>
|
|
>> David
|
|
>>
|
|
>> _______________________________________________
|
|
>> Imap-protocol mailing list
|
|
>> Imap-protocol@u.washington.edu
|
|
>> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
|
|
>>
|
|
>
|
|
> _______________________________________________
|
|
> Imap-protocol mailing list
|
|
> 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/20151117/bad4d19a/attachment.html>
|