Your Input Needed: Exchange Server and Outlook Standards
Posted by Michael Bowman
Program 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:
- IMAP (Internet Message Access Protocol - RFC 3501): IMAP allows a client to access and manipulate electronic mail messages on a server. This protocol allows Exchange users to access their email across a broad range of IMAP clients and enables Outlook users to access email on IMAP servers.
- POP3 (Post Office Protocol version 3 - RFC 1939): POP3 is a broadly adopted standard for webmail service providers. Outlook uses the POP3 protocol to retrieve messages from the server. The POP3 service for Microsoft Exchange Server is used by clients that implement the POP3 protocol to store and retrieve messages on the server.
- iCalendar (RFC 2445, RFC 2446, RFC 2447): This common format facilitates the open exchange of calendaring and scheduling information across the Internet. iCalendar is supported by both Outlook and Exchange and enables syncing and publishing of calendar items across supported services and servers, regardless of platform.
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 emailstand@microsoft.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.
Comments
Anonymous
January 01, 2003
Will never again buy Outlook if it doesn't incorporate caldav and carddav!Anonymous
January 01, 2003
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! – MichaelAnonymous
May 31, 2013
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.Anonymous
May 31, 2013
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.Anonymous
May 31, 2013
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.Anonymous
May 31, 2013
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.Anonymous
May 31, 2013
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:Anonymous
May 31, 2013
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.Anonymous
June 01, 2013
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.Anonymous
June 01, 2013
My detailed email submission has been sent. Enjoy. :)Anonymous
June 04, 2013
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 Thank you.Anonymous
June 04, 2013
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.Anonymous
June 04, 2013
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.Anonymous
June 05, 2013
[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. Cheers, SabahattinAnonymous
September 09, 2013
Just a friendly reminder, it's been three months. Has the formal response been published?Anonymous
November 07, 2013
Thanks to all who provided input regarding support of the core and most commonly adopted email and calendaring standards in Microsoft Exchange Server and Outlook. The feedback confirmed the following plan of standards support in the next versions of Microsoft Exchange Server and Outlook:IMAP: Internet Message Access Protocol version 4.1 (RFC 3501)
POP3: Post Office Protocol version 3 (RFC 1939)
iCalendar: Internet iCalendar Protocol (RFC 5545), the iCalendar Transport-Independent Interoperability Protocol (RFC 5546), and the iCalendar Message-Based Interoperability Protocol (RFC 2447). Again, we appreciate all the responses and if you have additional feedback on Microsoft Exchange Server and Outlook standards support, please visit the Microsoft Office feedback page here:feedback.office.microsoft.com/default.aspx
Anonymous
February 25, 2014
Hello,
Now that Exchange 2013 SP1 is out, and revives the Edge Transport role, does that mean that AlexB's comment about SMTP recipient filtering (upthread) is "fixed"?
Thank you,
Andrew