104 lines
5.4 KiB
Plaintext
104 lines
5.4 KiB
Plaintext
MBOX-Line: From dshaw at jabberwocky.com Tue Nov 17 19:32:33 2015
|
|
To: imap-protocol@u.washington.edu
|
|
From: David Shaw <dshaw@jabberwocky.com>
|
|
Date: Fri Jun 8 12:34:55 2018
|
|
Subject: [Imap-protocol] UID MOVE and untagged OKs
|
|
In-Reply-To: <564BC814.8080409@comaxis.com>
|
|
References: <25069F83-83C9-4130-B0D0-6C4FCC37A292@jabberwocky.com>
|
|
<564BBF09.7050804@teamaol.com>
|
|
<CABa8R6tSWdWpSc2Xxfp+tWVk=GGRHYsdX-YmGXPVoAGCBBdPQw@mail.gmail.com>
|
|
<564BC814.8080409@comaxis.com>
|
|
Message-ID: <6AE55419-5337-4B1C-9AB5-F69FD47868D8@jabberwocky.com>
|
|
|
|
Thanks everyone for the responses.
|
|
|
|
Just to clarify - this isn't involving an add-in or extension for iOS Mail. If I had some control over the code, I could possibly put in some sort of Microsoft compatibility mode, but unfortunately this is just plain old iOS Mail as shipped by Apple (and I don't work there).
|
|
|
|
I actually first suspected this was an iOS bug because the problem started immediately when iOS 9.0 was released, but it turned out that iOS 8.x didn't support UID MOVE at all (using UID COPY, etc, instead), so it never even saw the incorrect server behavior. Once iOS 9 started supporting UID MOVE, the Office365 problem became visible.
|
|
|
|
I've pretty much hit a brick wall attempting to get Microsoft to even acknowledge the bug. I'm pleased I'm not the only person who sees a problem here.
|
|
|
|
David
|
|
|
|
> On Nov 17, 2015, at 7:36 PM, Jeff McKay <jjmckay@comaxis.com> wrote:
|
|
>
|
|
> I just tried it and I would agree with David that O365 is indeed behaving as he described - no untagged OK in response to UID MOVE. My
|
|
> only point, in response to Bron, is that as as developer at a company that wants to make actual sales, I do sometimes have to put in kludges to
|
|
> deal with crappy imap servers. I guess David is writing some kind of add-in for iOS Mail where he can't do that. I would think though that
|
|
> the Apple folks could get Microsoft to see the light.
|
|
>
|
|
> On 11/17/2015 4:06 PM, Brandon Long wrote:
|
|
>> 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
|
|
>>
|
|
>>
|
|
>>
|
|
>> _______________________________________________
|
|
>> 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
|
|
|
|
|