[horde] Doubling emails-problem in Outlook 2013

[Michael J Rubinsky]

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.


-- 
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/e5ec2478/attachment-0001.bin>