MBOX-Line: From brong at fastmail.fm  Tue Nov 17 19:29:43 2015
To: imap-protocol@u.washington.edu
From: Bron Gondwana <brong@fastmail.fm>
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: <1447817383.3655600.442841513.22BFE21F@webmail.messagingengine.com>




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.? 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.? 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.? 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.? 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 <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

--
? Bron Gondwana
? brong@fastmail.fm
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20151118/f9e5cdd4/attachment.html>
