Re: [Imap-protocol] UID MOVE and untagged OKs
Bron Gondwana <[email protected]> Thu, 19 Nov 2015 08:30:10 +1100
| Newsgroups | gmane.mail.imap.general |
|---|---|
| Message-ID | <1447882210.1528738.443668657.2E2AAB9D@webmail.messagingengine.com> |
This is a multi-part message in MIME format.
--===============5174842347435744115==
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative; boundary="_----------=_144788221015287380";
charset="utf-8"
This is a multi-part message in MIME format.
--_----------=_144788221015287380
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="ISO-8859-1"
On Wed, Nov 18, 2015, at 14:29, Bron Gondwana wrote:
> 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.
Have heard from someone at Microsoft that they are aware of the problem
- so I guess the message got through to whoever needed to know.
I don't know what their test/deploy cycle looks like - it will be
interesting to see how long until the fix makes it out to production.
Bron.
--
=A0 Bron Gondwana
=A0 [email protected]
=20
=20
--_----------=_144788221015287380
Content-Transfer-Encoding: 7bit
Content-Type: text/html; charset="ISO-8859-1"
<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body><div>On Wed, Nov 18, 2015, at 14:29, Bron Gondwana wrote:<br></div>
<blockquote type="cite"><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>
</blockquote><div> </div>
<div>Have heard from someone at Microsoft that they are aware of the problem - so I guess the message got through to whoever needed to know.<br></div>
<div> </div>
<div>I don't know what their test/deploy cycle looks like - it will be interesting to see how long until the fix makes it out to production.<br></div>
<div> </div>
<div>Bron.<br></div>
<div> </div>
<div>--<br></div>
<div id="sig567075"><div class="signature"> Bron Gondwana<br></div>
<div class="signature"> [email protected]<br></div>
<div class="signature"> </div>
</div>
<div> </div>
</body>
</html>
--_----------=_144788221015287380--
--===============5174842347435744115==
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
--===============5174842347435744115==--