There has been a lot of speculation about the iPhone and its abilities to connect to Microsoft Exchange Server. For instance, Wall Street Journal columnist Walt Mossberg mentions in his June 26 All...
Updated Jul 01, 2019
Version 2.0
Blog Post
This is a very good illustration of security: imap is designed to do email and only email. For calendar syncing, for example, caldav is used instead, in its own separate compartment. Of course, in a well-designed client, this is all seamless to the user.
But behind the scenes, it makes for a very robust and secure design over a kitchen-sink approach. First, it allows each to be the best. Those working on imap can focus on making it solid, secure, and stable as an email protocol only. Those working on caldav can focus on making the calendar syncing be the best it can be, without issues of email support.
Second, it isolates exploits. Suppose, for example, that both calendar-syncing programs had a buffer overflow that would allow for user-level random code execution.
In the case of EAS, this would mean not only calendars would be exposed, but all the email, contacts, tasks, documents, would be also accessible, in the same compromised program. This would be a total disaster.
With webdav+imap, not only would the other services be protected by the access control, but webdav wouldn't even have a clue on where they could be located. So email would be safe. Contacts would be safe. Tasks would be safe. Documents would be safe. Not having all your eggs in one basket is a secure design pattern.
Finally, having limited services reduces the exposed area on average. Recall that Code Red's spread was fueled mostly by computers whose owners were unaware that IIS was running on their machines. Similarly, a calendar exploit allowing administrator-level code execution would likely affect all EAS servers, including those where the users don't use the calendar aspect. Compare this to imap servers, who would mostly be unaffected, because only those needing calendar would turn on caldav.
This is a very good illustration of the dangers of relying on a single source, giving a maginot-line illusion of security.
But behind the scenes, it makes for a very robust and secure design over a kitchen-sink approach. First, it allows each to be the best. Those working on imap can focus on making it solid, secure, and stable as an email protocol only. Those working on caldav can focus on making the calendar syncing be the best it can be, without issues of email support.
Second, it isolates exploits. Suppose, for example, that both calendar-syncing programs had a buffer overflow that would allow for user-level random code execution.
In the case of EAS, this would mean not only calendars would be exposed, but all the email, contacts, tasks, documents, would be also accessible, in the same compromised program. This would be a total disaster.
With webdav+imap, not only would the other services be protected by the access control, but webdav wouldn't even have a clue on where they could be located. So email would be safe. Contacts would be safe. Tasks would be safe. Documents would be safe. Not having all your eggs in one basket is a secure design pattern.
Finally, having limited services reduces the exposed area on average. Recall that Code Red's spread was fueled mostly by computers whose owners were unaware that IIS was running on their machines. Similarly, a calendar exploit allowing administrator-level code execution would likely affect all EAS servers, including those where the users don't use the calendar aspect. Compare this to imap servers, who would mostly be unaffected, because only those needing calendar would turn on caldav.
This is a very good illustration of the dangers of relying on a single source, giving a maginot-line illusion of security.