EWS is the only realistic way for "not Outlook" to work - MAPI is not exactly an open API.
When EWS goes away so will rather a lot of customers, probably not enough to dent the bottom line (initially).
Then it becomes apparent that all email is equal and Exchange online becomes a footnote in history. Microsoft used to do email and then they shat the bed. All a bit embarrassing on the surface but not really.
Running email systems is a right old pain when all you really desire is data (and metadata) to mine and flog on to other data fetishists. Email is generally rather static and rather large in storage terms but it can yield gold from personal exchanges.
Ideally you get someone else to take the pain (AWS, Google and co - yes they get to mine but they bear the costs too) but ensure the marks use Outlook (and they do).
Then you change Outlook (loving the new Electron version) to store all credentials in your cloud. You use those creds to mine data within email held on other people's clouds. They front the cost of storage.
Exchange Online isn't going anywhere and I doubt deprecating EWS is going to matter because where are those customers going to go? GMail where they would have to completely change how they do business and use their APIs instead? Nope, they will just bite the bullet and rewrite everything to use Graph API instead.
As for Microsoft wanting EMail Data for mining vs not hosting, check out the MSFT revenue. It's not in Advertising space that's for sure.
> At present, EWS is our best way to enable support for both Exchange Online and on-premise installations.
> Graph API has been considered and may be considered again in future, but it currently provides narrower support than EWS and lacks some functionality for desktop applications. Even with the announcement that EWS support will be removed for Exchange Online, it's still valuable in the short term for enabling access for a wide userbase and in the long term for supporting users using on-premise installations.
The venn of “my work uses exchange on-prem”, “I use Linux desktop and can’t use outlook”, “I am aware of and would use exchange on Thunderbird” is pretty damn small.
I think they’re making a mistake using EWS and planning on targeting on-prem with the same or more weight than online.
As a linux user, it's more like either die by the web version or migrate the company to another mail solution. And yes, I know evolution does ews as well, but i got tired of sync issues and having to switch from deb to flatpack because of it and other annoyances over the years.
I mostly gave up on email anyway and switched to a better solution - teams (at least until July after which the deb package of v1 should stop working and v2 doesn't work for me in firefox - can't unmute myself in calls) /s
Strategically this makes sense if the goal is just to get people to use Thunderbird, but ideologically JMAP support would be a lot nicer in my opinion.
I recently tried Thunderbird instead of Outlook. It had the same issue as FF did before the quantum update: It's too damn slow. Switching between different folders with hundreds or thousands of mails has noticable delays, while in Outlook it's essentially instant.
This is very likely because Thunderbird uses mbox files, so one big text file per mail folder. There is experimental maildir support (one file for each email) which is friendlier for AVs: https://support.mozilla.org/en-US/kb/maildir-thunderbird
This. Took me some time until I figured this out. I would definitely not discover this if I was a new user, but I migrated my profile from linux where everything was fast (with the same mailbox) so I was suspicious.
I have exactly the opposite experience. Using outlook for mail is such a pain to me. Particularly the search experience does not work (I use expressionsearchNG for thunderbird) . For calendars it is just the opposite so that I am currently running it side by side. One problem is I think the iCal bridge to the outlook server we have to use at work. The announcement unfortunately cannot change anything here. I used the EWS addon maintained by Ericson [1] for a while. But Mozilla I guess drove many Plugin developers away by breaking the interface rapidly. Now they are putting some stuff into the core again. I am not really sure if that is a good strategy. They should rather IMHO work on a stable interface.
Yeah, and have your email appear significantly worse on a bunch of email clients all in the name of tech purism / nostalgia for ‘the old days’.
After I saw how usual it was for plain text email to be rendered in a fixed-width font, instead or something more sane, there’s no way I could justify doing it just because “HTML email is an abomination” or whatever.
I am most against HTML email for security and privacy reasons. Plain text (or hell even RTF) are simply safer. Also, most HTML email is used for marketing, which we don’t need to be making easier/better. Really Markdown email would be a happy medium, anything but whatever non-standard abominations Outlook/Exchange inject (don’t get me started on .eml files).
>in the entire 20 year lifetime of the Thunderbird project, no one has added support for a new mail protocol before.
Technically true but also every megacorp's OAuth2 out-of-band authentication implementation needs it's own special configuration (read workaround) per email client and Thunderbird has collected quite a few. These are not normal mail protocols: they're over HTTPS not IMAP or POP3 or SMTP.
This proclamation "no one has added support for a new mail protocol" is a good thing and this change is not good. Supporting proprietary setups is pragmatic and understandable but it's not good. This is only going to briefly mitigate the problems of email splintering into dozens of per-corporation variations while encouraging people to be okay with them in the long run.
I was talking about proprietary OAuth2 authentication protocol implementations in that statement. Like how the Thunderbird OAuth2 protocol for gmail is incompatible with the one for yahoo email, and so on. Which is different from normal protocols like imap/pop3 where the implementations are compatible across companies.
I was not speaking in the context of exchange but in the more general sense of new HTTPS based protocol flavors being added to Thunderbird regularly.
Not sure why the headline was changed. This is an article about Rust programming. "Bringing Exchange Support to Thunderbird" implies it's about Thunderbird and it's support for Exchange - something you won't learn from the article.
Based on the first paragraph of the article which focuses on Exchange rather than language, I'd say the feature itself is more important than the implementation, and that's also what most users care about.
I dunno. I've been using Thunderbird for years with exchange - first onprem and now O365. I might've missed it in the article or misremember the difficulty of setting it up (low), but errrrr.... it just works?
I guess support for proprietary specifications is useful, but I really wish Mozilla would prioritise implementing standards like auto-discovery of email submission (SMTP) servers (rfc6186, 2011).
Currently, users have to manually provide hostname and port of their SMTP server, which is likely fine for those of us on this website, but not at all friendly for the other 99.9% of the human population.
The amount of effort require to implement all of Exchange is also probably orders of magnitude more than discovery of submission servers via DNS/SRV. I really don't get Mozilla's priorities.
> Currently, users have to manually provide hostname and port of their SMTP server
i don't think I had to do that when I added my Hotmail, Google, or Yahoo accounts to Thunderbird. I just used my email address at each of them. Are these treated as special cases?
Wow! 20 years or so ago, I remember working in IT and only a few of us ran Linux in otherwise fully Microsoft shops. Exchange was always one of these things that it was tough to find a good client for. We would have been over the moon!
Using anything Microsoft on Linux is really painful, and they appear to be in the process of deprecating the web version of Teams if you're not specifically using Edge :(
Afaik Teams never worked on Firefox. MS' engineering is incapable or unwilling to use standard APIs or compatibility layers to implement a tool that works on all modern browsers, while competitors in voice and video chat have this for a long time already.
Readit News
When EWS goes away so will rather a lot of customers, probably not enough to dent the bottom line (initially).
Then it becomes apparent that all email is equal and Exchange online becomes a footnote in history. Microsoft used to do email and then they shat the bed. All a bit embarrassing on the surface but not really.
Running email systems is a right old pain when all you really desire is data (and metadata) to mine and flog on to other data fetishists. Email is generally rather static and rather large in storage terms but it can yield gold from personal exchanges.
Ideally you get someone else to take the pain (AWS, Google and co - yes they get to mine but they bear the costs too) but ensure the marks use Outlook (and they do).
Then you change Outlook (loving the new Electron version) to store all credentials in your cloud. You use those creds to mine data within email held on other people's clouds. They front the cost of storage.
Smashing.
Exchange Online isn't going anywhere and I doubt deprecating EWS is going to matter because where are those customers going to go? GMail where they would have to completely change how they do business and use their APIs instead? Nope, they will just bite the bullet and rewrite everything to use Graph API instead.
As for Microsoft wanting EMail Data for mining vs not hosting, check out the MSFT revenue. It's not in Advertising space that's for sure.
Dead Comment
> At present, EWS is our best way to enable support for both Exchange Online and on-premise installations.
> Graph API has been considered and may be considered again in future, but it currently provides narrower support than EWS and lacks some functionality for desktop applications. Even with the announcement that EWS support will be removed for Exchange Online, it's still valuable in the short term for enabling access for a wide userbase and in the long term for supporting users using on-premise installations.
But really tho…
The venn of “my work uses exchange on-prem”, “I use Linux desktop and can’t use outlook”, “I am aware of and would use exchange on Thunderbird” is pretty damn small.
I think they’re making a mistake using EWS and planning on targeting on-prem with the same or more weight than online.
I mostly gave up on email anyway and switched to a better solution - teams (at least until July after which the deb package of v1 should stop working and v2 doesn't work for me in firefox - can't unmute myself in calls) /s
(Also: what is the realistic security impact of this? As long as I don't do anything stupid, is it negligible?)
[1] https://github.com/Ericsson/exchangecalendar
[0] https://addons.thunderbird.net/en-us/thunderbird/addon/tbsyn...
[1] https://addons.thunderbird.net/en-us/thunderbird/addon/eas-4...
After I saw how usual it was for plain text email to be rendered in a fixed-width font, instead or something more sane, there’s no way I could justify doing it just because “HTML email is an abomination” or whatever.
Plain text gives the recipient control over how the content is rendered - as opposed to HTML which forces your choices on the reader.
Technically true but also every megacorp's OAuth2 out-of-band authentication implementation needs it's own special configuration (read workaround) per email client and Thunderbird has collected quite a few. These are not normal mail protocols: they're over HTTPS not IMAP or POP3 or SMTP.
This proclamation "no one has added support for a new mail protocol" is a good thing and this change is not good. Supporting proprietary setups is pragmatic and understandable but it's not good. This is only going to briefly mitigate the problems of email splintering into dozens of per-corporation variations while encouraging people to be okay with them in the long run.
On the other hand, being able to use Thunderbird as a client is a net win and a pragmatic move.
It's not just one of every megacorp, it's by far the most commonly used email in business, Microsoft's Exchange and especially Exchange online.
I was not speaking in the context of exchange but in the more general sense of new HTTPS based protocol flavors being added to Thunderbird regularly.
Sure, for Thunderbird developers. Regular users don't care about any of that, if they even understand what it says.
Currently, users have to manually provide hostname and port of their SMTP server, which is likely fine for those of us on this website, but not at all friendly for the other 99.9% of the human population.
The amount of effort require to implement all of Exchange is also probably orders of magnitude more than discovery of submission servers via DNS/SRV. I really don't get Mozilla's priorities.
i don't think I had to do that when I added my Hotmail, Google, or Yahoo accounts to Thunderbird. I just used my email address at each of them. Are these treated as special cases?
I entered the email addy and the password and Thunderbird congigured the account automatically.
Snd that was a few years ago.
Using anything Microsoft on Linux is really painful, and they appear to be in the process of deprecating the web version of Teams if you're not specifically using Edge :(