217 lines
7.4 KiB
Plaintext
217 lines
7.4 KiB
Plaintext
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>
|