[horde] Doubling emails-problem in Outlook 2013

[Michael J Rubinsky]

Quoting Michael J Rubinsky <mrubinsk at horde.org>:

> Quoting Michael J Rubinsky <mrubinsk at horde.org>:
>
>> Quoting Patrick De Zordo <patrick at spamreducer.eu>:
>>
>>> Am 16.05.2014 16:13, schrieb Michael J Rubinsky:
>>>>> Could it be possible (theoretical) to make some "if" or "case"  
>>>>> instruction into the code to check if it is an OL client
>>>>> and in case to omit the ADD command for the "new" item in the  
>>>>> destination folder?
>>>>
>>>> Theoretically, sure. But that is NOT something we are going to do  
>>>> in our code. There are already WAY too many workarounds in the  
>>>> code for misbehaving clients that cause severe issues when they  
>>>> are not worked around. This issue is an obvious bug in OL and an  
>>>> annoyance for the users, but not something that would prevent the  
>>>> client from working or something that would bring down the server  
>>>> due to tons of SYNC loops.
>>>>
>>>
>>> So what is MS Exchange server doing in this case?
>>> Are they using some workarround probably, since there ActiveSync  
>>> is working on OL and also in mobile clients.
>>
>> First of all, OL does NOT connect using ActiveSync to a true  
>> exchange server. That is explicitly not allowed by OL. It connects  
>> using the traditional RPC/MAPI interface it always has. As far as  
>> mobile clients go, I have 3 different Windows mobile clients that  
>> all behave correctly when connected to Horde. Also, I'm not 100%  
>> sure about this one since it was a while since I tested it, but I  
>> believe the Email client in Windows 8 also worked correctly.
>>
>>>>> The UID would not change in Outlook (so OL would have the old  
>>>>> UID and the IMAP-Horde backend would have a new UID);
>>>>> but it should not matter since Outlook "think" the self copied  
>>>>> message is the moved message?
>>>>
>>>> This would mean that the client state is now inconsistent. The  
>>>> ActiveSync server thinks an email with the new UID is on the  
>>>> client (which, by the way would match the UID of the actual email  
>>>> on the IMAP server). This now no longer matches the actual state  
>>>> of the client. Any server side change to the email (like actually  
>>>> deleting it from the IMAP server) will now NEVER make it to the  
>>>> client since the UIDs are no longer the same. Likewise, no change  
>>>> to the email on the client side (like, for instance trying to  
>>>> move it back to the INBOX) will ever be accepted by the server.
>>>
>>> Agree, but what could you do for the "normal" moving of messages?
>>
>> My comments were aimed at the issue of deleting messages since  
>> that's the only issue I have verified. I have not noticed any  
>> issues moving email from one folder to another in OL.
>>
>>
>>> Our human clients (not OL ;-) ) are moving emails forwards and  
>>> backwards and sort them with local rules, etc..
>>> So they are making a lot of trouble in their messageboxes after  
>>> some days.. I think you can understand this is a severe problem..
>>
>> As I said, I have only seen this when deleting messages, not when  
>> explicitly moving them. I will have to look at your log when I have  
>> time and see if I can deduce what is going on for you. Regardless,  
>> I'm not going to stop sending correct wbxml responses to commands  
>> because a client doesn't know it's own protocol.
>
> Actually, I see this now when I move some email messages, but not  
> all the time. Regardless, the WBXML that is being returned from the  
> MOVEITEMS command is 100% correct. This is absolutely a OL  
> bug/feature.

...and I will eat these words now.

While the WBXML response to the MOVEITEMS correct is correct, OL also  
requires a DELETE command be sent to the ORIGINAL mailbox to manually  
remove the original item. Even though in the UI, the message is moved  
to the new mailbox, OL apparently still thinks it's in the original  
mailbox and will remove the "duplicate" entry once it receives this  
delete command.

Both issues (duplicates when deleting or moving) should be fixed with  
this commit.

-- 
mike
The Horde Project
http://www.horde.org
https://www.facebook.com/hordeproject
https://www.twitter.com/hordeproject
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5869 bytes
Desc: S/MIME Signature
URL: <http://lists.horde.org/archives/horde/attachments/20140519/67a49733/attachment.bin>