3 ms·

> Turns out there aren’t a lot of email clients for Linux users that work with Exchange / Office 365 Has Linux on the desktop really fallen so far in the last

> Turns out there aren’t a lot of email clients for Linux users that work with Exchange / Office 365 Has Linux on the desktop really fallen so far in the last years? When did the decay really set in? How does open source friendly Microsoft not see Linux email clients support falling behind at least as a problem in MS documenting its APIs, if not an opportunity to participate in the major open source clients and influence and attract developers?

pidg 8y ago
Office 365 comes with a very good web verison of Outlook, which supports more modern features than most email clients do (such as Office 365 Groups). I suspect it doesn't bother them hugely that desktop client support is falling behind on any platform. edited to add: Oddly I can't find much marketing by Microsoft of the browser Outlook, otherwise I'd link it here, but I'd say it's about 85-90% feature complete compared with the desktop client.
- kevkav 8y ago
  I do agree that the Outlook web app is good and is getting better all the time. Personally though (and I think a lot of people would agree), I like to have a standalone email client that doesn't constantly get lost in tab clutter.
  - jrockway 8y ago
    Having used webmail for about 7 years (I used Gnus before), the tab clutter problem is easy to avoid. Right click the tab, select "Pin tab", and you're done.
megaman22 8y ago
I'm not sure it's worth building an email client that works with Exchange/Office 365 on Linux, when you can use the web interface. Particularly as much of a PITA that trying to use EWS is, and how different it is for on-premise vs Office 365 usage. It's currently a toss-up whether it's even worth trying to use Outlook on Windows desktops, as much of a buggy, hogging, piece of garbage it is.
livebsd 8y ago
If you need an _email_ client, implementing support for the exchange protocol is probably the least of your concerns. Even if the exchange protocol was open, I wouldn't implement support for a specific vendor knowing there are protocols which are more commonly used. Microsoft could instead start by improving their implementation of IMAP in exchange, which is one of the most horrid and buggy implementations of IMAP I've ever seen. This is also true for their IMAP endpoint at office365.com. But it's clear where they stand: outlook is the ultimate corporate lock-in, and it's not due to email by itself.
jcranmer 8y ago
As someone who was worked on an email client before: IMAP and the raw message/rfc822 format is already a quite complex format to handle. Most open-source software starts by building their logic around these formats. Exchange is a completely different model, everything from how you communicate with the server, how you store the bits on disk or in memory, or even the logical structure of messages. On top of this, it adds several features that don't really have a parallel in the standard RFCs. For most people working on email clients, it is far easier to tell users "enable IMAP on your Exchange server" than to actually implement the full top-to-bottom stack you need to get things working. Even then, given the likelihood of bugs and missing features, it's hard to justify making the switch from Exchange to $ALTERNATIVE, and if you didn't need those missing features, well go back to enabling IMAP and use that instead. The APIs that MS uses for Exchange are largely public at this point. Even the mapping between MAPI messages and message/rfc822 that Outlook does is released in one of the documents.

pidg 8y ago

Office 365 comes with a very good web verison of Outlook, which supports more modern features than most email clients do (such as Office 365 Groups). I suspect it doesn't bother them hugely that desktop client support is falling behind on any platform. edited to add: Oddly I can't find much marketing by Microsoft of the browser Outlook, otherwise I'd link it here, but I'd say it's about 85-90% feature complete compared with the desktop client.

kevkav 8y ago
I do agree that the Outlook web app is good and is getting better all the time. Personally though (and I think a lot of people would agree), I like to have a standalone email client that doesn't constantly get lost in tab clutter.
- jrockway 8y ago
  Having used webmail for about 7 years (I used Gnus before), the tab clutter problem is easy to avoid. Right click the tab, select "Pin tab", and you're done.

megaman22 8y ago

I'm not sure it's worth building an email client that works with Exchange/Office 365 on Linux, when you can use the web interface. Particularly as much of a PITA that trying to use EWS is, and how different it is for on-premise vs Office 365 usage. It's currently a toss-up whether it's even worth trying to use Outlook on Windows desktops, as much of a buggy, hogging, piece of garbage it is.

livebsd 8y ago

If you need an _email_ client, implementing support for the exchange protocol is probably the least of your concerns. Even if the exchange protocol was open, I wouldn't implement support for a specific vendor knowing there are protocols which are more commonly used. Microsoft could instead start by improving their implementation of IMAP in exchange, which is one of the most horrid and buggy implementations of IMAP I've ever seen. This is also true for their IMAP endpoint at office365.com. But it's clear where they stand: outlook is the ultimate corporate lock-in, and it's not due to email by itself.

jcranmer 8y ago

As someone who was worked on an email client before: IMAP and the raw message/rfc822 format is already a quite complex format to handle. Most open-source software starts by building their logic around these formats. Exchange is a completely different model, everything from how you communicate with the server, how you store the bits on disk or in memory, or even the logical structure of messages. On top of this, it adds several features that don't really have a parallel in the standard RFCs. For most people working on email clients, it is far easier to tell users "enable IMAP on your Exchange server" than to actually implement the full top-to-bottom stack you need to get things working. Even then, given the likelihood of bugs and missing features, it's hard to justify making the switch from Exchange to $ALTERNATIVE, and if you didn't need those missing features, well go back to enabling IMAP and use that instead. The APIs that MS uses for Exchange are largely public at this point. Even the mapping between MAPI messages and message/rfc822 that Outlook does is released in one of the documents.