[horde] Outlook Debugging Day

Mon May 26 13:41:40 UTC 2014

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

>> -----Ursprüngliche Nachricht-----
>> Von: Michael J Rubinsky [mailto:mrubinsk at horde.org]
>> Gesendet: Montag, 26. Mai 2014 03:07
>> An: Patrick De Zordo
>> Betreff: Re: AW: Re: Outlook Debugging Day
>>
>>
>> Quoting Patrick De Zordo <patrick at spamreducer.eu>:
>>
>> > Ok,
>> > if you need a running ActiveSync Server for debugging, as promised,
>> > just give me half an hour to do the server install in datacenter for
>> > ya.
>> >
>> > Here ya!
>> > You are welcome!
>>
>> My proof of concept failed. This was not the issue. The only  
>> possibility left is
>> that OL has a flawed implementation of the MOVEITEMS command. Really
>> nothing else I can do about it at this point.
>
> Not good news, I'm really disappointed.

So am I, after spending days and days of my own time tracking this down.

> Have you debug'ed on a "running" ActiveSync server?

What do you mean by a "running" ActiveSync server? ActiveSync is the  
protocol. Horde IS an ActiveSync server. Do you mean Exchange  
(Exchange won't connect to OL2013 using ActiveSync) or do you mean the  
proprietary/commercial SmarterMail product with the commercial  
ActiveSync add-on you pointed out earlier?

> What is he doing to "correct" the strange behavior of OL?

I have no idea. If you are talking about SmarterMail, I didn't install  
it, haven't tested it. My guess is that the ADD command isn't sent to  
OL clients, though that doesn't completely explain why my tests  
initially worked on my test server.  If you provide me with either a  
wiretrace of a session on SmarterMail where you don't see this  
behavior, or non-SSL access to a running SmarterMail server with EAS  
enabled along with a test account on that server where I can receive  
email, I'll do a quick test and trace myself - but see below.

I am intimately familiar with the EAS protocol specification. I have  
also read, re-read, and then read again the published Microsoft  
specification for the commands involved in this issue over the last 2  
weeks. Horde is following the specification EXACTLY. This is what the  
specification says MUST happen:

1) User deletes an email.
2) Client sends a MOVEITEMS request to the server with the source  
folder id, message UID, and destination folder id.
3) Server executes the move. On success, the client receives a SUCCESS  
status code, along with the new UID of the message in the destination  
folder.
4) On the next SYNC request, the client is sent an ADD command for the  
destination folder for the moved message. This message may have a new  
UID. The client is sent a REMOVE command for the message moved out of  
the source folder.

That's it. Nowhere does it say that the server shouldn't send an ADD  
command, or that the client should move the item on it's own.

During my latest tests, I discovered that if the email is deleted via  
another client (which only shows one copy of the email), BOTH copies  
are deleted from OL. This leads me to believe that what OL is doing is  
moving the message on it's own, then when it receives the SUCCESS  
status and new UID, it simply assigns this UID to the message it moved  
on it's own, instead of waiting for (or ignoring) the ADD command with  
the same UID. This is absolutely a violation of the protocol, as  
currently published.

Even if we were to work around this for only OL2013 (which is a  
horrible, horrible hack), it would require a fair amount of work since:

1) The places that we generate the server delta has no idea about the  
client. I.e., we can't ignore a change at this stage of the code.

2) Even if stuff is refactored to allow for (1) we would need to  
change the information that is stored when items are moved via a  
MOVEITEMS command to include a MESSAGE-ID (though that isn't always  
guaranteed to be there) and probably the destination folder id/message  
UID combination. Otherwise we would have no idea what message we  
should ignore.

3) Also, what happens if/when Microsoft fixes this? That will require  
yet another hack to not only sniff out OL, but to sniff the version as  
well.

This is not something that I'm going to do on my own time. If this is  
really important to your organization you could consider sponsoring  
the work.

For what it's worth, OL2013 is the ONLY client that I have ever seen  
that does this, including other Microsoft clients, like Windows Mail  
and Windows Phone/Mobile.

-- 
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/20140526/6e71bf8d/attachment.bin>