[horde] Doubling emails-problem in Outlook 2013

[Michael J Rubinsky]

Quoting Patrick De Zordo <patrick at spamreducer.eu>:

> Yah, of course, see file attached.
> It's 5.2.0-git and Horde_ActiveSync 2.14.2 from some days (I believe  
> 2 or 3) ago.
>
> To clarify:
> ActiveSync protocol should work with this steps I suppose:
> 1) Client asks server to delete a message.
> 2) Client receives MoveItems response with a success code, along  
> with the UID of the new item in the destination folder.
> 3) Client deletes the original item from source folder.
> 4) On the next SYNC request, the client receives the ADD command for  
> the "new" item in the destination folder (trash in this case) and  
> adds the item to the folder.
>
> But, OL is *not* following the standard in that way.
> OL adds an additional step somewhere between 2) and 4) (not able do  
> debug this) where it is copying the message from local source to  
> destination, thus 2 messages..
>
> Am I right with this ideas?

Correct. OL should NOT be moving the email on it's own, just removing  
it from the originating folder once it receives the success response  
from the MOVE command.

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

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


>
> Do you think this could cause any trouble in sync process?

Yes. See above.

> Am 16.05.2014 15:41, schrieb Michael J Rubinsky:
>>
>> Quoting Patrick De Zordo <patrick at spamreducer.eu>:
>>
>>> Hi guys,
>>> [#12945] ActiveSync: Deleting one email in Outlook 2013 results in  
>>> two mails in Outlook 2013 trash folder
>>> indicates a part oft he problem..
>>>
>>> This is "ok" for the clients using Horde as "MS Exchange" Server..
>>> They are not happy about it, but they can work with it..
>>
>> Yeah, it *IS* annoying, but it's a bug/feature of OL, nothing we  
>> can do about it unfortunately.
>>
>>> But the bigger problem is the following behavior:
>>> When a message is moved from the INBOX to a subfolder INBOX.test  
>>> then also there the message is doubled..
>>>
>>> This is more then horrible for users.. They dont know which of the  
>>> 2 messages is the "real" one..
>>>
>>> In addition Oultook says in status line on the bottom "trying to  
>>> connect" + triangle with exclamation mark..
>>> Users are going to be confused and can't understand it.. you know..
>>>
>>> Any hooks/code changes to make in my own GIT fork to workarround?
>>>
>>> Cheers!
>>
>> Can you provide a sync log showing what happens when you move the  
>> message? This sounds similar to another problem that affected  
>> FRAMEWORK_5_1, but not master... Are you running the latest git  
>> master?
>>
>>
>>



-- 
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/20140516/2a688a60/attachment.bin>