Re: [Imap-protocol] UID MOVE and untagged OKs
Bron Gondwana <[email protected]> Wed, 18 Nov 2015 14:29:43 +1100
| Newsgroups | gmane.mail.imap.general |
|---|---|
| Message-ID | <1447817383.3655600.442841513.22BFE21F@webmail.messagingengine.com> |
This is a multi-part message in MIME format.
--===============7448777058972725077==
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative; boundary="_----------=_144781738436556002";
charset="utf-8"
This is a multi-part message in MIME format.
--_----------=_144781738436556002
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="ISO-8859-1"
On Wed, Nov 18, 2015, at 11:36, Jeff McKay 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.
I can also confirm this - sorry about the few hour delay, dentist
appointment in the middle of all this.
I've bought myself an O365 account and tested it just to see it for
myself, this is with openssl s_client
. FETCH 1:* UID
* 1 FETCH (UID 8)
. OK FETCH completed.
. MOVE 1 Extra [COPYUID 78 8 1]
* 1 EXPUNGE
* 0 EXISTS
. OK MOVE completed.
> >
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.
Likewise, and I deal in cludges for crappy clients as well.=A0 At least I
had already done the work to make EXPUNGE on a mailbox with no \Deleted
messages be cheap, because there's a popular client in the wild which
does an IDLE/EXPUNGE loop now, and it's hammering people running older
versions of the Cyrus IMAPd server which had expensive EXPUNGE.
I still rate Yahoo's IMAP server returning a DIFFERENT RFC822.SIZE for
the same message moved to a different mailbox, despite neither of them
matching the actual byte count on the RFC822 itself as one of the most
impressive things I've worked around recently.=A0 The really is
approximately nothing you can rely on being actually right when talking
to an arbitrary server, it's all heuristics.
(certainly older versions of Cyrus had serious issues with reliable
CONDSTORE, and I bet there are some poky corners of URLAUTH and other
rarely-loved bits that aren't perfect)
> I guess David is writing some kind
of add-in for iOS Mail where he can't do that.=A0 I would think
though that
>
the Apple folks could get Microsoft to see the light.
It's all a matter of getting the right people, and the bigger the org,
the harder it is to get in contact with them.=A0 We're really lucky to
have people like Brandon here so we can bypass having to find someone
who actually does front-line gmail support and then escalate past them
to someone who can actually fix things!
Bron.
> 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 <[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.=A0 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.=A0 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:=A0 [COPYUID 12 7599 4788]
>>>>
S:=A0 * 373 EXPUNGE
>>>>
S:=A0 * 372 EXISTS
>>>>
S:=A0 14 OK MOVE completed.
>>>>
>>>>
The concern is with the second line (the COPYUID
response).=A0 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.=A0 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?=A0 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
>>
>>
>>
>> _______________________________________________
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
--
=A0 Bron Gondwana
=A0 [email protected]
=20
=20
--_----------=_144781738436556002
Content-Transfer-Encoding: 7bit
Content-Type: text/html; charset="ISO-8859-1"
<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body><div> </div>
<div> </div>
<div> </div>
<div>On Wed, Nov 18, 2015, at 11:36, Jeff McKay wrote:<br></div>
<blockquote type="cite"><div>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.<br></div>
</blockquote><div> </div>
<div>I can also confirm this - sorry about the few hour delay, dentist appointment in the middle of all this.<br></div>
<div> </div>
<div>I've bought myself an O365 account and tested it just to see it for myself, this is with openssl s_client<br></div>
<div> </div>
<div>. FETCH 1:* UID<br></div>
<div>* 1 FETCH (UID 8)<br></div>
<div>. OK FETCH completed.<br></div>
<div>. MOVE 1 Extra<br></div>
<div>[COPYUID 78 8 1]<br></div>
<div>* 1 EXPUNGE<br></div>
<div>* 0 EXISTS<br></div>
<div>. OK MOVE completed.<br></div>
<div> </div>
<blockquote type="cite"><div>>
My<br></div>
<div>
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<br></div>
<div>
deal with crappy imap servers. <br></div>
</blockquote><div> </div>
<div>Likewise, and I deal in cludges for crappy clients as well. At least I had already done the work to make EXPUNGE on a mailbox with no \Deleted messages be cheap, because there's a popular client in the wild which does an IDLE/EXPUNGE loop now, and it's hammering people running older versions of the Cyrus IMAPd server which had expensive EXPUNGE.<br></div>
<div> </div>
<div>I still rate Yahoo's IMAP server returning a DIFFERENT RFC822.SIZE for the same message moved to a different mailbox, despite neither of them matching the actual byte count on the RFC822 itself as one of the most impressive things I've worked around recently. The really is approximately nothing you can rely on being actually right when talking to an arbitrary server, it's all heuristics.<br></div>
<div> </div>
<div>(certainly older versions of Cyrus had serious issues with reliable CONDSTORE, and I bet there are some poky corners of URLAUTH and other rarely-loved bits that aren't perfect)<br></div>
<div> </div>
<blockquote type="cite"><div>I guess David is writing some kind
of add-in for iOS Mail where he can't do that. I would think though
that<br></div>
<div>
the Apple folks could get Microsoft to see the light.<br></div>
</blockquote><div> </div>
<div>It's all a matter of getting the right people, and the bigger the org, the harder it is to get in contact with them. We're really lucky to have people like Brandon here so we can bypass having to find someone who actually does front-line gmail support and then escalate past them to someone who can actually fix things!<br></div>
<div> </div>
<div>Bron.<br></div>
<div> </div>
<blockquote type="cite"><div>On 11/17/2015 4:06 PM, Brandon Long
wrote:<br></div>
<blockquote type="cite" cite="mid:CABa8R6tSWdWpSc2Xxfp+tWVk=GGRHYsdX-YmGXPVoAGCBBdPQw@mail.gmail.com"><div dir="ltr"><div>Or his client is eating the '* ' in some fashion,
it would be good for someone with an account to verify the bad
behavior.<br></div>
<div> </div>
<div>They obviously think they're sending the right response,
let's not assume that they are sending the wrong one.<br></div>
<div> </div>
<div>Brandon<br></div>
</div>
<div><div> </div>
<div><div>On Tue, Nov 17, 2015 at 3:58 PM, Stu
Brandt <span dir="ltr"><<a href="mailto:[email protected]">[email protected]</a>></span>
wrote:<br></div>
<blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204, 204, 204);padding-left:1ex;"><div>David -<br></div>
<div> </div>
<div>
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.<br></div>
<div> </div>
<div>
- Stuart<br></div>
<div><div><div> </div>
<div> </div>
<div>
On 11/17/15 6:11 PM, David Shaw wrote:<br></div>
<blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204, 204, 204);padding-left:1ex;"><div>Hello,<br></div>
<div> </div>
<div>
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.<br></div>
<div> </div>
<div>
My understanding from RFC-6851 is that a UID MOVE
transaction should look something like this (cut and
paste from the RFC):<br></div>
<div> </div>
<div>
C: a UID MOVE 42:69 foo<br></div>
<div>
S: * OK [COPYUID 432432 42:69 1202:1229]<br></div>
<div>
S: * 22 EXPUNGE<br></div>
<div>
S: (more expunges)<br></div>
<div>
S: a OK Done<br></div>
<div> </div>
<div>
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."<br></div>
<div> </div>
<div>
This seems straightforward.<br></div>
<div> </div>
<div>
The server I'm having a problem (<a href="http://outlook.office365.com">outlook.office365.com</a>) with has
a UID MOVE transaction like this (actual transaction
captured from my client):<br></div>
<div> </div>
<div>
C: 14 UID MOVE 7599 "Deleted Items"<br></div>
<div>
S: [COPYUID 12 7599 4788]<br></div>
<div>
S: * 373 EXPUNGE<br></div>
<div>
S: * 372 EXISTS<br></div>
<div>
S: 14 OK MOVE completed.<br></div>
<div> </div>
<div>
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).<br></div>
<div> </div>
<div>
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.<br></div>
<div> </div>
<div>
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.<br></div>
<div> </div>
<div>
Thanks,<br></div>
<div> </div>
<div>
David<br></div>
<div> </div>
<div>
_______________________________________________<br></div>
<div>
Imap-protocol mailing list<br></div>
<div> <a href="mailto:[email protected]">[email protected]</a><br></div>
<div> <a href="http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol">http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol</a><br></div>
</blockquote><div> </div>
<div>
_______________________________________________<br></div>
<div>
Imap-protocol mailing list<br></div>
<div> <a href="mailto:[email protected]">[email protected]</a><br></div>
<div> <a href="http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol">http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol</a><br></div>
</div>
</div>
</blockquote></div>
<div> </div>
</div>
<div> </div>
<div> </div>
<pre>_______________________________________________
Imap-protocol mailing list
<a href="mailto:[email protected]">[email protected]</a> <a href="http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol">http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol</a><br></pre></blockquote><div> </div>
<div><u>_______________________________________________</u><br></div>
<div>Imap-protocol mailing list<br></div>
<div><a href="mailto:[email protected]">[email protected]</a><br></div>
<div><a href="http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol">http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol</a><br></div>
</blockquote><div> </div>
<div id="sig567075"><div class="signature">--<br></div>
<div class="signature"> Bron Gondwana<br></div>
<div class="signature"> [email protected]<br></div>
<div class="signature"> </div>
</div>
<div> </div>
</body>
</html>
--_----------=_144781738436556002--
--===============7448777058972725077==
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
--===============7448777058972725077==--