Microsoft on the IssuesMicrosoft on GovernmentNext at MicrosoftInteroperability @MicrosoftPort25Windows Azure
Posted by Michael BowmanProgram Manager, Office Engineering
Microsoft recognizes that enabling interoperability between products from different vendors is important, particularly with respect to email and calendaring functionality, as it helps our customers stay connected and organized across their favorite services and devices.
Exchange Server 2013 and Microsoft Outlook 2013 support the following core and most commonly adopted email and calendaring standards:
Extensive documentation of this support is publicly available at no charge on MSDN. Microsoft will continue to support these standards in the next versions of Exchange Server and Microsoft Outlook.
To ensure that Microsoft continues to invest in the standards that are most valued by our customers, your feedback is essential. You can tell us what email and calendaring standards you’d like to see in the next versions of Exchange Server and Microsoft Outlook by clicking here or sending email to email@example.com. (Note: please do not include confidential information in your feedback.)
Check back on the blog in 90 days, when we’ll post a general response in this forum. Thank you in advance for your valuable input.
Stay active in Calconnect, for starters (calconnect.org). You had folks there some years ago and then pulled them out. That was a huge mistake.
Ah, I'm told you have people back in Calconnect. That's good. Keep that up and work with them. Work hard with them. Please.
I'd very much like to see Outlook/Exchange update its existing RFC coverage to include their updated RFC counterparts, expansion for common extensions, and additions into new areas such as CalDAV, CardDAV and iSchedule. I will gladly email the address with detailed suggestions.
What's up with the Outlook 2013 usage of XLIST? There seems no way in new client to adjust folder locations it uses XLIST to establish them. If your IMAP server doesn't support this extension????? Would be great if this command had a formal RFC and were established in many mail-store software but it is not the case.
In Exchange 2013 SMTP recipient filtering is done AFTER data which causes pointless traffic and unnecessary load..
Mail to "Unknown users" should be rejected after Rcpt to:
Outlook 2013's IMAP implementation was a major step backward. Not allowing the user to specify folder locations and instead relying on the XLIST command (which is not supported by our IMAP server software and never will be) has meant that we've had to take Outlook 2013 off the list of supportable clients for users of our legacy IMAP service. The bigger "wish list" item though for us is the ability for end-users to schedule meetings (ie. check "free/busy" info) between people that use different email services, most specifically Exchange/O365/or Outlook.com and GMail. On our campus most staff are using Exchange but many faculty most students are electing to use GMail. Scheduling is therefore a nightmare (students prefer GMail at an over 80% rate) and we frequently have to result to Doodle Polls. However even scheduling Exchange to Exchange across organizational boundaries (for example between people on our campus and people working at Microsoft) is a nightmare. Playing nice with all those calendaring standards that might solve this issue is a HUGE HUGE need for our university. If you don't do it, you are just pushing people to GMail because they are currently "winning" the battle among our younger users. If we all have to use just one thing, it will be GMail, not Exchange and Outlook.
If Microsoft is really interested in "[...] interoperability between products from different vendors [...]", please make the new Exchange version run on one or two of the most widely used Linux distro's.
My detailed email submission has been sent. Enjoy. :)
Please take into consideration to follow the SHOULD recommendation of RFC 2060 when dealing with IMAP COPY.
For a more detailled explanation of what I'm trying to say, please have a look at social.technet.microsoft.com/.../e8122c0c-7abd-4d1d-957b-cec5f5a7167f
Regarding my previous comment concerning IMAP COPY, please don't mind me mentioning RFC 2060, I was of course referring to the more recent revision RFC 3501 and other newer RFCs.
Having read Benjamin's link, I must concur. That behavior in Outlook 2013 is *not* expected and *not* an acceptable outcome.
My site inserts custom X- headers on the MTA routes. These headers indicate spam and malware scanning, as well as results of some business rule decisions. They are valuable information and not something we consider OK to be removed.
[I've sent this as email, of course.]
I'll never be truly happy until Exchange stops using proprietary extensions and protocols that aren't absolutely essential. So, full IMAP, CalDAV and CardDAV, please. And then work on your awful clients, to support those also. Perhaps then you would find yourself less at Google's mercy. And you would interoperate with every single vendors' client and server products.
BTW, I wanted to develop an ActiveSync implementation that was Open Source and a front-end to existing servers. If I had, it would have saved you the trouble. I got no reply from your licensing folk. Push is perhaps not essential to some people, but for those of us who want it being dependant on Exchange just to get the ActiveSync protocol is an absurd mockery of interoperability. And, in any case, Google have taken the lead in dropping it. Apple users (I'm one) are most affected, but I don't imagine Apple will be too bothered about fixing that, since they have their own proprietary nonsense for iCloud. And of course Exchange still gets the benefit of push, making your true devotion to interoperability a matter of ethics rather than business sense.
I would also be happier (but this isn't strictly required) if you brought your suggestions before the IETF. I don't mind if you don't do this so long as access to the specifications are completely free; this way the market, rather than technical merit, will decide which protocols are better, but they're still open to implementers.
Thanks for all of the Exchange and Outlook standards feedback! Check back on the blog in three months, when we’ll post a summary response. Really appreciate your valuable input! – Michael
Will never again buy Outlook if it doesn't incorporate caldav and carddav!
Just a friendly reminder, it's been three months. Has the formal response been published?