MBOX-Line: From jjmckay at comaxis.com Tue Nov 17 16:36:36 2015 To: imap-protocol@u.washington.edu From: Jeff McKay Date: Fri Jun 8 12:34:55 2018 Subject: [Imap-protocol] UID MOVE and untagged OKs In-Reply-To: References: <25069F83-83C9-4130-B0D0-6C4FCC37A292@jabberwocky.com> <564BBF09.7050804@teamaol.com> Message-ID: <564BC814.8080409@comaxis.com> 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 > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: