Over the last week the Exchange community has learned a bit more about problems with Apple’s Exchange ActiveSync implementation in iOS 6; Microsoft has released a KB article outlining the problem and suggesting some workarounds, and Tony Redmond this morning pointed to a TUAW article that I hadn’t previously seen which asserts that the hijacking problem is a known issue with previous versions of iOS.
Tony’s article is titled “The emerging need for more supervision over ActiveSync implementations.” It’s certainly hard to disagree with that basic premise. Just over 18 months ago, Microsoft launched an Exchange ActiveSync logo certification program with the goal of inducing third parties who sell EAS-compatible devices or software to verify that they properly implement the client side of EAS. A quick check of this page maintained by Microsoft’s legal department shows just over four dozen EAS licensees, but only 3 vendors are listed on the EAS logo page itself. There are several possible explanations, ranging from lack of vendor interest in getting certified to a Microsoft failure to update the contents of the page.
Whatever the reason, I think Tony is right that Microsoft needs to be more proactive in requiring their EAS licensees to perform more robust testing on their clients.
Furthermore, I’m starting to think that the certification and testing program isn’t sufficient in and of itself, which brings me to Postel’s Law.
Some years ago, I worked for a company that made e-mail encryption software. This was during a time when even basic SMTP interoperability between different vendors’ systems was not assured– the Electronic Mail Association had biannual “plugfests” where vendors such as Lotus, Microsoft, and Netscape got together to ensure that their products could exchange SMTP mail properly. Whenever we ran into an interop problem, my boss would cite Postel’s Law:
Be conservative in what you do, be liberal in what you accept from others.
It seems pretty clear that Apple’s iOS EAS implementation has bugs– long-standing ones, if the TUAW article is right– and that Apple has a responsibility to fix them. I am coming to the opinion, though, that the server-side EAS implementation is too lenient about what it accepts. For years Exchange administrators had to suffer through a dance that went something like this:
- A new version of Outlook would ship with a bug that would occasionally corrupt calendar or message items in some interesting way.
- The corrupted items would cause the client to crash; in more severe cases, they could also crash the store process or cause backups, mailbox exports, etc. to fail.
- The Exchange team would release a hotfix to keep that particular flavor of badly formed item from causing such a problem.
- The Outlook team would release a hotfix that would keep that version of Outlook from emitting that particular flavor of corruption.
- In the next release of Exchange, the team would add business logic to reject items with the specific flaws generated by Outlook.
- GOTO 1
Over time, the Exchange business logic got better, as did Outlook’s track record of not creating bad items in the first place. This approach has served Exchange administrators and users pretty well, and it’s clear that the lessons learned from this painful process have been applied in Exchange Web Services. For example, EWS will reject attempts to create calendar items with end dates that come before start dates– something that Outlook used to occasionally do out of sheer perversity.
However, it looks as though, at least in this specific case, EAS doesn’t have business logic in place to catch the modifications that lead to the hijacking behavior. That’s something that Microsoft can fix in three steps.
- First, they can update the EAS spec so that it clearly defines which fields of each data item are to be considered read-only. This gives implementers a fair shot to understand where they may need to change their clients.
- Second, they can update Exchange itself so that it rejects client requests that violate the updated spec.
- Third, they can vigorously “encourage” their major ISV partners to test more aggressively against the updated spec. I have to wonder, for example, how much, if any, testing Apple has done against Exchange 2013…
I’ve been putting the blame on Apple for this problem, and while I don’t think that doing so is unfair or inaccurate, I also believe that the Exchange team can do a better job on the server side of blocking bad client requests, and I hope they’re madly planning how to do so in Exchange 2013 SP1.