[horde] Outlook Debugging Day

[Michael J Rubinsky]

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 15:42
>> An: Patrick De Zordo; horde at lists.horde.org
>> Betreff: Re: AW: AW: Re: Outlook Debugging Day
>>
>>
>> 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?
>>
>
> With "running" (note the parenthesis), I mean a ActiveSync capable  
> software implementation with another software
> which is able to deal with OL (for example SmarterMail, and lot of others).

You say "Lot of others". What others? The 2 others I know of do not  
work around this.


>> > 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.
>>
>
> Oh ya! That's what I try to offer to you since days.. :-)
> Probably it's a language problem, since natively I speak German and  
> Italian.. English is just a "old school" version.. ;-)

Ok. Send me the connection details and I'll look at it this week, to  
see what the protocol conversation looks like.


>> 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:
>>
>
> Would be horrible, right.. but every request done to Microsoft was  
> just not answered.
> There are some entries in their own knowledgebase/MSDN like the following
> http://social.msdn.microsoft.com/Forums/en-US/a132b78f-7c30-469e-bd87-a5c1a6015eee/outlook-2013-active-sync-bug-move-message-serverid-compare?forum=os_exchangeprotocols
> which basically isn't replied.. I suppose they KNOW there is a  
> problem.. but won't confirm this.. (this is normal for M$.. used  
> their products for years, every request is ignored or answered with  
> some "blah blah" just to fill up the MSDN database..)

Yes, I know, but since when is Microsoft's inability/lack of desire to  
fix THEIR bugs, Horde's problem?

>> 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.
>>
>
> Probably it's just some "simple hack", at least for you since you  
> know your product in "every code line"..

No, that's what I'm saying. We are not going to include any kind of  
ugly, "simple" hack in our released code. If it can be worked around,  
it will have to be done in a somewhat elegant way - and (2) from above  
is the minimum that would be required to do this. If it were "simple",  
it would have already been fixed.

>> 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.
>>
>
> I think it will not be done in next months, then they will give out  
> the next OL release and "probably" they fix this then..

My point isn't about WHEN, or IF it will be fixed. My point is that  
any workaround for Microsoft's bug that we introduce into our code  
base adds to our future maintenance costs because it's something that  
will have to be maintained and worked around AGAIN, if/when it is  
fixed my Microsoft.

>> 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.
>>
>
> Sponsoring would be nice, but correct me if I'm wrong, you know lot,
> really lot products on the market use OL with the respective API to  
> send and receive emails, for now OL is THE groupware solution used  
> in Business work.

OL2013 is the first (and so far only) version that supports EAS.

> Since M$ has changed their licensing model to something very  
> expensive Server + Exchange (no Small Business Version anymore) and  
> in alternative the very insecure Office365
> for working in the cloud (our documents are transferred over the  
> world, coming in an out from servers to servers..), there is no more  
> a valuable solution for SMB clients.
> So what possibilities are on market?
> - buying some product on market which has yearly fees that are more  
> or less same expensive to M$
> - using open source software (Openchange (SoGO) or Horde?)
>
> Others (in a stable state!!)? Don't think so.
>
> Complete compatibility to OL (for the moment 2013) would boost Horde..

Horde is FOSS. Horde's goals are to work with accepted open standards.  
Granted, that becomes a gray area with something like EAS where it  
seems that different clients seem to use their own interpretation of  
such a standard.

Improving Horde's (already huge) market share is always nice, agreed.  
However, as with most FOSS, development of Horde is not most of our  
developers' jobs, at least not anything we rely on for income. It's  
something most of us do for fun, for the love of coding, or for things  
that we have a personal need for. Like most people, I have limited  
free time. Sponsoring work is both an incentive for working on things  
that I have no desire to do for myself, and it allows me to take take  
time away from other income-producing jobs to spend the time working  
on something that otherwise wouldn't get done, and it also helps  
support Horde development by supporting Horde LLC. After all, we don't  
receive any more income for more market share.


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