wasm-demo/demo/ermis-f/imap-protocol/cur/1600094992.22572.mbox:2,S

126 lines
5.0 KiB
Plaintext

MBOX-Line: From jjmckay at comaxis.com Tue Nov 17 16:36:36 2015
To: imap-protocol@u.washington.edu
From: Jeff McKay <jjmckay@comaxis.com>
Date: Fri Jun 8 12:34:55 2018
Subject: [Imap-protocol] UID MOVE and untagged OKs
In-Reply-To: <CABa8R6tSWdWpSc2Xxfp+tWVk=GGRHYsdX-YmGXPVoAGCBBdPQw@mail.gmail.com>
References: <25069F83-83C9-4130-B0D0-6C4FCC37A292@jabberwocky.com>
<564BBF09.7050804@teamaol.com>
<CABa8R6tSWdWpSc2Xxfp+tWVk=GGRHYsdX-YmGXPVoAGCBBdPQw@mail.gmail.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 <stuart.brandt@teamaol.com
> <mailto: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
> <http://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
> <mailto:Imap-protocol@u.washington.edu>
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
>
>
> _______________________________________________
> Imap-protocol mailing list
> Imap-protocol@u.washington.edu <mailto: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: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20151117/2ea60d97/attachment.html>