[horde] Doubling emails-problem in Outlook 2013
Michael J Rubinsky
mrubinsk at horde.org
Mon May 19 18:28:08 UTC 2014
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>
More information about the horde
mailing list