Re: [Imap-protocol] UID MOVE and untagged OKs
Brandon Long <[email protected]> Tue, 17 Nov 2015 16:06:39 -0800
| Newsgroups | gmane.mail.imap.general |
|---|---|
| Message-ID | <CABa8R6tSWdWpSc2Xxfp+tWVk=GGRHYsdX-YmGXPVoAGCBBdPQw@mail.gmail.com> |
--===============2579149968377457255== Content-Type: multipart/alternative; boundary=001a1140fb3ea8c5d60524c56a65 --001a1140fb3ea8c5d60524c56a65 Content-Type: text/plain; charset=UTF-8 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 <[email protected]> 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 >> [email protected] >> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol >> > > _______________________________________________ > Imap-protocol mailing list > [email protected] > http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol > --001a1140fb3ea8c5d60524c56a65 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Or his client is eating the '* ' in some fashion, = it would be good for someone with an account to verify the bad behavior.<di= v><br></div><div>They obviously think they're sending the right respons= e, let's not assume that they are sending the wrong one.</div><div><br>= </div><div>Brandon</div></div><div class=3D"gmail_extra"><br><div class=3D"= gmail_quote">On Tue, Nov 17, 2015 at 3:58 PM, Stu Brandt <span dir=3D"ltr">= <<a href=3D"mailto:[email protected]" target=3D"_blank">stuart.b= [email protected]</a>></span> wrote:<br><blockquote class=3D"gmail_quote= " style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">D= avid -<br> <br> My read matches yours. Their 2nd line is neither a tagged or untagged respo= nse, rfc6851 section 3.3 has a specific example covering COPYUID in the res= ponse, and rfc6851 section 4.3 seems pretty clear when it says to send the = COPYUID response code in an untagged OK.<br> <br> - Stuart<div class=3D"HOEnZb"><div class=3D"h5"><br> <br> On 11/17/15 6:11 PM, David Shaw wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Hello,<br> <br> I'm currently beating my head against a problem with a particular serve= r implementation.=C2=A0 The problem, as best I can work out from the outsid= e, is in UID MOVE.<br> <br> My understanding from RFC-6851 is that a UID MOVE transaction should look s= omething like this (cut and paste from the RFC):<br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 C: a UID MOVE 42:69 foo<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 S: * OK [COPYUID 432432 42:69 1202:1229]<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 S: * 22 EXPUNGE<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 S: (more expunges)<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 S: a OK Done<br> <br> The relevant piece of this for my question is that the COPYUID response is = in an untagged OK.=C2=A0 Again, from the RFC: "Servers implementing UI= DPLUS are also advised to send the COPYUID response code in an untagged OK = before sending EXPUNGE or moved responses."<br> <br> This seems straightforward.<br> <br> The server I'm having a problem (<a href=3D"http://outlook.office365.co= m" rel=3D"noreferrer" target=3D"_blank">outlook.office365.com</a>) with has= a UID MOVE transaction like this (actual transaction captured from my clie= nt):<br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 C: 14 UID MOVE 7599 "Deleted Items"<b= r> =C2=A0 =C2=A0 =C2=A0 =C2=A0 S:=C2=A0 [COPYUID 12 7599 4788]<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 S:=C2=A0 * 373 EXPUNGE<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 S:=C2=A0 * 372 EXISTS<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 S:=C2=A0 14 OK MOVE completed.<br> <br> The concern is with the second line (the COPYUID response).=C2=A0 There is = no untagged OK / "* OK" there, which seems incorrect to me and pe= rhaps more significantly, seems to cause the Apple iOS mail program to thro= w an error every time a message is moved from folder to folder (which of co= urse includes the "delete this message" function).<br> <br> I've spent (literally) weeks trying to get Microsoft Office365 support = to acknowledge the problem, without success.=C2=A0 The most recent response= insists that they are following the RFC, and in fact quoted the "Serv= ers implementing UIDPLUS are also advised to send the COPYUID response code= in an untagged OK before sending EXPUNGE or moved responses." line fr= om RFC-6851 as what they are doing.<br> <br> Could the experts on this list help me understand what is going on here?=C2= =A0 I have no particular need to be "right" - I just want to be a= ble to delete messages without getting errors every single time.<br> <br> Thanks,<br> <br> David<br> <br> _______________________________________________<br> Imap-protocol mailing list<br> <a href=3D"mailto:[email protected]" target=3D"_blank">Imap-pr= [email protected]</a><br> <a href=3D"http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol= " rel=3D"noreferrer" target=3D"_blank">http://mailman13.u.washington.edu/ma= ilman/listinfo/imap-protocol</a><br> </blockquote> <br> _______________________________________________<br> Imap-protocol mailing list<br> <a href=3D"mailto:[email protected]" target=3D"_blank">Imap-pr= [email protected]</a><br> <a href=3D"http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol= " rel=3D"noreferrer" target=3D"_blank">http://mailman13.u.washington.edu/ma= ilman/listinfo/imap-protocol</a><br> </div></div></blockquote></div><br></div> --001a1140fb3ea8c5d60524c56a65-- --===============2579149968377457255== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Imap-protocol mailing list [email protected] http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol --===============2579149968377457255==--