Bringing Exchange Support to Thunderbird(blog.thunderbird.net)
blog.thunderbird.net
Bringing Exchange Support to Thunderbird
https://blog.thunderbird.net/2024/04/adventures-in-rust-bringing-exchange-support-to-thunderbird/
148 comments
why implementing ews when it is already deprecated and will be removed in two years? https://techcommunity.microsoft.com/t5/exchange-team-blog/re...
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.
Smashing.
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.
Whatever you are smoking, I want some.
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.
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.
"Nope, they will just bite the bullet and rewrite everything to use Graph API instead."
LOL, no I won't.
LOL, no I won't.
As Sean Burke puts it on the related bug on Bugzilla (https://bugzilla.mozilla.org/show_bug.cgi?id=1847846#c2):
> 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.
> 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.
>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.
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'd widen that to "I don't want to use outlook" which includes Linux installs but also all thunderbird windows users, I'd think.
"my work uses exchange on-prem" is pretty large though, especially in headcount (enterprises).
I don't know of any published numbers about specific user count (would be very interested to see them), but in terms of deployments it's gone from more than half on prem in 2018 to ~16% in 2023. Of that 16%, I wonder how many users are both willing and able to use an alternate client?
Of the organizations that have Exchange Server on premises, I'd bet the lions share are hybrid, with regular user mailboxes in the cloud, using the server(s) for application relays, etc.
I'm a Thunderbird-on-Windows-in-VM-on-Mac user for one on-prem and one web-but-can't-access-on-non-managed-windows-endpoint VM account.
And yet it's exactly the situation I'm in. I use evolution on Ubuntu through a horizon virtual desktop, purely for better exchange support. I switched from thunderbird on windows to outlook on windows when I started having a lot more meetings to coordinate, and then evolution when a virtual desktop solution was rolled out and Linux was an option for desktops at work again. Quite a few other people in my department that just use thunderbird on Linux because they can't stand outlook or using the web version would happily have better outlook support.
Perhaps there is an audience here and it just doesn't match your own experiences.
Perhaps there is an audience here and it just doesn't match your own experiences.
Does evolution calendar work seamlessly with Exchange? I used Thunderbird with the Exchange addon for three years and email and contacts worked without any problems, but calendar was bad. I could see my calendar but couldn't edit it from Thunderbird.
Not seamlessly. It seems to work but is half-broken. Id does not properly pair invitations, updates and RSVPs from emails with auto-created items (by the Exchange server) and you end up with duplicates and mess. At leas that was my experience when I used this setup. Then moved to evolution for email and web outlook exclusively for calendar.
Now I am on windows partly for lack of proper Outlook and Teams on linux (sad).
I’m not sure what you are talking about. When did I say where I was in that venn?
I am Linux Desktop and hate outlook web.
I am the target user, and the post about Rust and using EWS gives me almost no confidence in this.
And I’m more aware that my case isn’t popular, and targeting on-premise is even less so.
I am Linux Desktop and hate outlook web.
I am the target user, and the post about Rust and using EWS gives me almost no confidence in this.
And I’m more aware that my case isn’t popular, and targeting on-premise is even less so.
Email solutions are company-wide, and companies are big.
Tons of companies use exchange on-prem either for historical reasons or legal reasons (e.g. they can't store email in the cloud - yes, this is very much a thing).
Beyond a certain size, companies inevitably have to support teams on different OSes. You have to let the accounting and finance guys use Windows (they'll die without Excel), you have to let the creatives use OSX or they'll throw a fit, and you have to let some in house IT teams use Linux.
But they all have to use the same email platform, and if it's on-prem exchange, the Linux guys are in a tough spot.
Tons of companies use exchange on-prem either for historical reasons or legal reasons (e.g. they can't store email in the cloud - yes, this is very much a thing).
Beyond a certain size, companies inevitably have to support teams on different OSes. You have to let the accounting and finance guys use Windows (they'll die without Excel), you have to let the creatives use OSX or they'll throw a fit, and you have to let some in house IT teams use Linux.
But they all have to use the same email platform, and if it's on-prem exchange, the Linux guys are in a tough spot.
> I think they’re making a mistake using EWS
In 2024.
Should they did it in 2012 the people would actually use it. For now - yes, anyone needing a thick mail client for Exchnage but not Outlook has figured their workarounds years ago.
In 2024.
Should they did it in 2012 the people would actually use it. For now - yes, anyone needing a thick mail client for Exchnage but not Outlook has figured their workarounds years ago.
Can't up-to-date on-premises installs have Graph API enabled?
Because you basically have no other realistic choice for the time being when dealing with crap such as Exchange.
Em Client (www.emclient.com) has supported Exchange for a while I think
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
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
Not everyone is using Exchange Online.
only like vast majority, yes, i know
We'll see how long that remains the case when Microsoft can't keep the Chinese government out of its cloud.
100%, but they are still not really interested in onpremises exchange, at least the latest version is 2019 which is no longer in mainline support, only security with no new version announced
these days it looks like every email is a teams message anyways, so unless they also release onpremise teams server, i don't see a future of exchange very bright
maybe everyone will move to google workspace in the future?
these days it looks like every email is a teams message anyways, so unless they also release onpremise teams server, i don't see a future of exchange very bright
maybe everyone will move to google workspace in the future?
Teams will crater in popularity once it's no longer bundled with Office 365. Nobody uses Teams because it's good, they use it because it was free with stuff they already had.
2019 is technically still receiving feature updates because of the delay of the new Exchange on-prem, though however that transition takes place will be wild.
2019 is technically still receiving feature updates because of the delay of the new Exchange on-prem, though however that transition takes place will be wild.
I don't think we will be able to get rid of teams that easily
1) it's a PITA to migrate teams accounts between tenants not mentioning migrating stuff off teams to another solution
2) companies use teams as "shared folders" in respective channels
3) copilot which enterprises even pay extra for
> Teams will crater in popularity once it's no longer bundled with Office 365. Nobody uses Teams because it's good, they use it because it was free with stuff they already had.
And what if the unbundling doesn't affect the price? Don't confuse MSFT making mediocre products with them being commercially stupid.
And what if the unbundling doesn't affect the price? Don't confuse MSFT making mediocre products with them being commercially stupid.
Working for a non-tech company, I can tell you that most love Teams. It was a godsend during Covid, people haven’t really seen anything else, and in all honesty it does what it’s supposed to do
You think outsourced point-and-click administrators of company on-prem servers could do better?
A valid point - you can't match Microsoft's resources and in-house expertise.
But you are probably a much less appealing target. Also, you might be willing to lock it down more than Microsoft, which has to please all those millions of customers and wants to admin it at the lowest cost possible - including possibly minimizing support calls by using permissive settings - and not with the most security possible.
But you are probably a much less appealing target. Also, you might be willing to lock it down more than Microsoft, which has to please all those millions of customers and wants to admin it at the lowest cost possible - including possibly minimizing support calls by using permissive settings - and not with the most security possible.
Indeed, one of my favorite inconvenient truths is that geo-blocking remains one of the most effective, and essentially free attack surface reductions you can make.
If all your staff are in a country, there's no reason for your internal tools to be accessible from any other country. If all of your customers are in a country, there's no reason for any of your web presence to be accessible from any other country.
If all your staff are in a country, there's no reason for your internal tools to be accessible from any other country. If all of your customers are in a country, there's no reason for any of your web presence to be accessible from any other country.
Yes. Managing Exchange is not that hard. Having everyone's eggs in one basket though is just dumb.
Not that hard for you. I think, you’re overestimating the average employee. At my current company, the maintainers absolutely don’t have a clue how it works, and they are completely unusable when there is a problem with it. They don’t know even the basic things, they just blindly follow transcripts from Microsoft, like telecallers.
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 imagine most of the work they accomplished here will be key in adding JMAP support in the future as well.
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.
If you're using Windows, in my experience Thunderbird is essentially unusable until you add a Windows Defender exclusion for your Thunderbird profile.
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
> There is experimental maildir support (one file for each email) which is friendlier for AVs
One (whatever big) file is always way more 'friendlier' for the AV than a bazillion of files. Especially on NTFS and on Win32.
No, don't try maildir on the Windows.
One (whatever big) file is always way more 'friendlier' for the AV than a bazillion of files. Especially on NTFS and on Win32.
No, don't try maildir on the Windows.
> One (whatever big) file is always way more 'friendlier' for the AV than a bazillion of files.
Defender will scan the entire file on opening if it's been modified. So for an mbox file, any update to the mbox (e.g. adding a message or marking one as read) will lead Defender to block reading until it's scanned it in full again.
While maildir will increase the baseline costs because opening files in windows is expensive, it will drastically reduce AV overhead, because the AV has a lot less data to scan, and it will only scan files which have been modified.
Defender will scan the entire file on opening if it's been modified. So for an mbox file, any update to the mbox (e.g. adding a message or marking one as read) will lead Defender to block reading until it's scanned it in full again.
While maildir will increase the baseline costs because opening files in windows is expensive, it will drastically reduce AV overhead, because the AV has a lot less data to scan, and it will only scan files which have been modified.
> Defender will scan the entire file on opening if it's been modified
In that case it would delete the whole mailbox for EICAR. Sound plausible, but I have a WinSvr2022 machine without WinDefender (or any other AV) and Thunderbird there is slow as molasses.
But sure, if adding the path to the exclusions alleviate the problem then it's Defender causing issues.
> because opening files in windows is expensive
Yes, this is the reason I would generally advise against that. Also it mess up NTFS fragmentation bad and while nowadays it's less of an issue for a laptop with oh so fast NVMe drive in it, it's still a problem (especially if you later need to move that folder with a bazillion files in it).
In that case it would delete the whole mailbox for EICAR. Sound plausible, but I have a WinSvr2022 machine without WinDefender (or any other AV) and Thunderbird there is slow as molasses.
But sure, if adding the path to the exclusions alleviate the problem then it's Defender causing issues.
> because opening files in windows is expensive
Yes, this is the reason I would generally advise against that. Also it mess up NTFS fragmentation bad and while nowadays it's less of an issue for a laptop with oh so fast NVMe drive in it, it's still a problem (especially if you later need to move that folder with a bazillion files in it).
> No, don't try maildir on the Windows.
Why, exactly? I have switched to maildir as soon as it was available as experimental feature, and performance gains when compared to mbox were enormous, especially during bulk operations. Switching folders takes <0.1s, with ~100k messages per folder, on Windows 7 64-bit.
Why, exactly? I have switched to maildir as soon as it was available as experimental feature, and performance gains when compared to mbox were enormous, especially during bulk operations. Switching folders takes <0.1s, with ~100k messages per folder, on Windows 7 64-bit.
The logic is probably as discussed above. Opening files is relatively expensive on Windows, so intuitively, maildir should be worse in terms of performance. I believe there's also some filesystem reasons to prefer avoiding lots of small files but that's beyond my pay-grade.
The reason maildir is faster despite this is the antivirus factor.
The fastest solution is adding an exception so that Defender doesn't scan your Thunderbird email, however that has the trade off that your antivirus isn't able to scan your email.
The reason maildir is faster despite this is the antivirus factor.
The fastest solution is adding an exception so that Defender doesn't scan your Thunderbird email, however that has the trade off that your antivirus isn't able to scan your email.
Check other comments.
And while switching folders, which is the major part of UX anyway, is fast, because TB only scans a handful of messages in the view[0], what about other operations which would need to scan the entire mailbox, like searching for something?
[0] why even it does that? beats me, but clearly it does, otherwise you wouldn't see the speed improvement
And while switching folders, which is the major part of UX anyway, is fast, because TB only scans a handful of messages in the view[0], what about other operations which would need to scan the entire mailbox, like searching for something?
[0] why even it does that? beats me, but clearly it does, otherwise you wouldn't see the speed improvement
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.
The folder it's installed in, or the folder it keeps my mail in? Or both?
(Also: what is the realistic security impact of this? As long as I don't do anything stupid, is it negligible?)
(Also: what is the realistic security impact of this? As long as I don't do anything stupid, is it negligible?)
As I understand it, before you open a (potentially dangerous) attachment in another app, it would be saved to your Temp or Downloads folder, where Defender would still have access.
A carefully crafted email (or PDF attachment) that exploits vulnerabilities within Thunderbird's HTML or image rendering (or its PDF.js sandbox) might still pose a risk, but probably less so than any random web page that you open in Firefox, where JS (which should be disabled in Thunderbird by default) is the primary attack vector.
Also, note that there is a setting called "Allow antivirus clients to quarantine individual incoming messages". With this enabled, "Thunderbird first stores each incoming message in a temporary file in the system temp folder" (where Defender would have access). "If the new message file still exists after being scanned by the antivirus software, then it is moved to your Thunderbird Inbox folder file." [1] If this is implemented correctly, it should only impact performance when receiving new emails.
[1] https://support.mozilla.org/en-US/kb/privacy-panel-settings-...
A carefully crafted email (or PDF attachment) that exploits vulnerabilities within Thunderbird's HTML or image rendering (or its PDF.js sandbox) might still pose a risk, but probably less so than any random web page that you open in Firefox, where JS (which should be disabled in Thunderbird by default) is the primary attack vector.
Also, note that there is a setting called "Allow antivirus clients to quarantine individual incoming messages". With this enabled, "Thunderbird first stores each incoming message in a temporary file in the system temp folder" (where Defender would have access). "If the new message file still exists after being scanned by the antivirus software, then it is moved to your Thunderbird Inbox folder file." [1] If this is implemented correctly, it should only impact performance when receiving new emails.
[1] https://support.mozilla.org/en-US/kb/privacy-panel-settings-...
Where the email is stored.
I'd say there is little impact as when a malicious email ends on disk, it was processed and the potential damage has been done already. I trust the server-side filtering and thunderbird security more than file-access protection in defender
In response to both comments: I turned on "Allow antivirus clients to quarantine individual incoming messages" and then added an exception for the folder where Thunderbird is keeping my mail, and it's now noticeably snappier—not instant, but opening my archives folder (~35,000 messages) was previously anywhere from a couple seconds to a couple dozen of seconds, and is now probably a little under a second.
I am. Huh. I guess I'm going back to trying Thunderbird, thanks! I hope that was the issue, because the interface is just much better.
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.
[1] https://github.com/Ericsson/exchangecalendar
[1] https://github.com/Ericsson/exchangecalendar
I used TbSync [0] with the ActiveSync [1] extension. That got me both mail and calendar, does that not work for you?
[0] https://addons.thunderbird.net/en-us/thunderbird/addon/tbsyn...
[1] https://addons.thunderbird.net/en-us/thunderbird/addon/eas-4...
[0] https://addons.thunderbird.net/en-us/thunderbird/addon/tbsyn...
[1] https://addons.thunderbird.net/en-us/thunderbird/addon/eas-4...
Will give try it a try. Mail works fine via IMAP for me. I always had problems handling outlook invites, team calendars and other peoples availabilities correctly, why I went back to outlook.
Hate Exchange but glad they are doing this. Now maybe I can successfully send plaintext mail on Exchange when confined to Windows.
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.
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.
Most clients allow you to pick which font your plain text email is rendered in.
Plain text gives the recipient control over how the content is rendered - as opposed to HTML which forces your choices on the reader.
Plain text gives the recipient control over how the content is rendered - as opposed to HTML which forces your choices on the reader.
Readers don't know this. They just know your e-mails always look weird and quote other e-mails weirdly.
I say this as a daily mutt user.
I say this as a daily mutt user.
Let illiterates wonder, one day they might set out to find out the reason and learn something on the way.
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.
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.
Employees have no choice when it comes to their corporate email provider, and this is not a hill to die on for 99.99999% of them.
On the other hand, being able to use Thunderbird as a client is a net win and a pragmatic move.
On the other hand, being able to use Thunderbird as a client is a net win and a pragmatic move.
The sad fact is: Most employees aren’t able or allowed to install an alternative email client. And most employees don’t care.
Years ago I worked for a place used exhange and third party tools were heavily discouraged but not banned. Web access wasn’t supported either so we were almost forced to have to use Outlook on a Windows machine. But I found DAVmail[0] allowed me to use the apps I wanted without being locked in and without mail clients supporting it directly. Nice to see more options here. Hopefully those of us who do care can continue to make the choices to use the tools we like.
[0] https://davmail.sourceforge.net/
[0] https://davmail.sourceforge.net/
Although, I would assume of those that can run what they want and do care they are already aware of and possibly use Thunderbird.
Not every initiative has to just be about new users. Sometimes it's important to retain the ones you have. Making Thunderbird more useful and viable for those that use it already isn't a bad thing.
Not every initiative has to just be about new users. Sometimes it's important to retain the ones you have. Making Thunderbird more useful and viable for those that use it already isn't a bad thing.
> every megacorp's
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.
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 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.
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.
What makes you say the protocol is different for each provider?
I maintain a proxy that transparently adds support for OAuth 2.0 support to IMAP/POP/SMTP clients (https://github.com/simonrob/email-oauth2-proxy), and for normal use it doesn’t need to know anything about which service it is connecting to. Apart from advanced features such as CCG or ROPCG which are mostly O365 only, what is different?
I maintain a proxy that transparently adds support for OAuth 2.0 support to IMAP/POP/SMTP clients (https://github.com/simonrob/email-oauth2-proxy), and for normal use it doesn’t need to know anything about which service it is connecting to. Apart from advanced features such as CCG or ROPCG which are mostly O365 only, what is different?
It's also cheaper per head than Google's business offering so it makes sense even for small business.
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?
Submitted earlier the same with full title but didn't get any traction: https://news.ycombinator.com/item?id=40095870
What are you talking about, fam? Exchange support for Thunderbird is the entire second half of the article.
> Exchange support for Thunderbird is the entire second half of the article.
Sure, for Thunderbird developers. Regular users don't care about any of that, if they even understand what it says.
Sure, for Thunderbird developers. Regular users don't care about any of that, if they even understand what it says.
[deleted]
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, 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?
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 neither had to do that with a custom email.
I entered the email addy and the password and Thunderbird congigured the account automatically.
Snd that was a few years ago.
I entered the email addy and the password and Thunderbird congigured the account automatically.
Snd that was a few years ago.
Mozilla keeps a centralised database with configuration for common providers. The ones you mention are likely in that database.
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!
I'm over the moon about it now!
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 :(
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.
We had the same issue however I took a different path; I got the company to dump exchange and sharepoint. Things were happier from then on.
> There was also no paid maintainership from about 2012 — when Mozilla divested and transferred ownership of Thunderbird to its community — until 2017, when Thunderbird rejoined the Mozilla Foundation.
What a scandal this was. A prime example of Mozilla's backwards priorities.
What a scandal this was. A prime example of Mozilla's backwards priorities.
I disagree. The world moved to web/mobile app based mail. You’re allowed to not be happy about that (I’m not over the moon about it) but it’s the truth. It wasn’t worth Mozilla funding it.
Please include PST file import out of the box so that folks can seamlessly switch away from their Outlook installs without having to fiddle with Outlook itself. There is a free project for reading PST files, all it needs is integrating into the suite.
PST export using the Exchange module for PowerShell has been a thing since Exchange 2010, see "New-MailboxExportRequest": https://learn.microsoft.com/en-us/powershell/module/exchange...
EDIT: Oh, nvm - it's on-prem only - huh... that's asinine.
EDIT: Oh, nvm - it's on-prem only - huh... that's asinine.
PSTs can be exported from Exchange Online via eDiscovery, although I'm curious why you'd want to, since it will only include whatever's in the mailbox anyway, which can presumably be accessed directly from the cloud when the mail client signs in.
What's the use case with PST import in Thunderbird? Outlook clients with an IMAP/POP3 mailbox storing a local archive of mail that's since been deleted from the server? This can be uploaded to the Exchange Online mailbox through Outlook which would be more resilient and less brittle than a local PST. What scenario am I missing?
What's the use case with PST import in Thunderbird? Outlook clients with an IMAP/POP3 mailbox storing a local archive of mail that's since been deleted from the server? This can be uploaded to the Exchange Online mailbox through Outlook which would be more resilient and less brittle than a local PST. What scenario am I missing?
Just noting that mail exported through ediscovery doesn't look like you'd expect - mail data is several folders deep. It's fine to say "just a few more clicks" but having inbox not be in an inbox folder is jarring breaks any idea of automated imports.
the docs might be misleading - New-MailboxImportRequest is "only supported on-prem", but it's used by the PST import UI and works just fine with EXO
This will be nice; I've been stuck using OWL for this purpose (which I think is the main extension; IDK if there's anything else.)
Anything that doesn’t work well that you’ve seen with the Owl extension?
At some point I somehow got logged out and then was unable to use the OWA login inside TB, because it required some silly JS to run. That meant Owl could no longer fetch e-mail. I contacted them about it, but they did not care and basically shrugged and did not give any advice.
At some point I was able to switch to using OAuth to get my e-mail, without Owl.
TB is slow overall, mainly due to Defender. OWL also totally Broke last year when TB updated on a point release, fixed by OWL in days.
We're desperately in need of SMTP/2 + IMAP5 or something
IMAPv4r2 came out relatively recently, in 2021: https://datatracker.ietf.org/doc/rfc9051/
(The big differences are IMAPv4r2 mandates a lot of necessary new features, like UID or UTF-8 support, and actually deprecated silly old stuff like MUTF7 mailbox names.)
(The big differences are IMAPv4r2 mandates a lot of necessary new features, like UID or UTF-8 support, and actually deprecated silly old stuff like MUTF7 mailbox names.)
Does it support 2FA yet?
nobody supports 2fa on every mail request, that's just silly.
Even MS's MFA is nothing more than a token that gets stored locally ( aka, a password ) and which can be stolen and be used elsewhere ( like a password! ) by hackers.
https://mrd0x.com/stealing-tokens-from-office-applications/
Even MS's MFA is nothing more than a token that gets stored locally ( aka, a password ) and which can be stolen and be used elsewhere ( like a password! ) by hackers.
https://mrd0x.com/stealing-tokens-from-office-applications/
Anyone know what that application is that's being used in that screenshot to search memory for strings?
https://mrd0x.com/static/e0e177157e8596c60273e12d4b3bd695/4e...
https://mrd0x.com/static/e0e177157e8596c60273e12d4b3bd695/4e...
Bit rusty on MICROS~1 but I think it could be WinDbg.
It would be good to make Thunderbird a proper competitor to Gnome's Evolution when it comes to EWS.
Is thunderbird search on par with gmail's search?
It's not bad - their time range narrowing graph thingy is really good, and I can normally find what I need. My main complaint is that my outlook calendars don't show up, so I can't search them for events.
My biggest complaint is that there is a hardcoded result limit. And it searches for that whole limit, then renders the result. So if you have a lot of messages you can't use the date range thing to refine the results. And if you want one of the recent ones you still need to wait for the UI to lock up and return all of the results.
The results themselves are good enough.
The results themselves are good enough.
It is the worst search I have ever used in any product.
I'd say that's an exaggeration but it's not great. It would really help if you could default search queries to the 'show results as a list' and quickfilter view, but for some reason that's not an option.
https://support.mozilla.org/en-US/questions/1401708
https://support.mozilla.org/en-US/questions/1401708
Sadly, I have the same experience. It's one of the minus points of using Thunderbird, alongside the lack of the feature for shipping my configurations (e.g. filters) across machines.
It is truly horrid. I routinely have to go into the web client to search
It returns exact matches in chronological order, which is generally good enough.
I've been using thunderbird in exchange places for years. Yeah, it's shit, but that's exchange. I just try to limit my exposure. But I can see "invites" and that kind of stuff. What am I missing?
Imagine if IMAP was slightly better and had a standard for calendar and contact objects.
Who the fuck cares? Exchange is dead. Office 365 is where its at. Move on Thunderbird team.
Office 365 is dead too.
No it's still around: https://lazyadmin.nl/office-365/microsoft-365-e3-vs-office-3...
And it probably will be until Microsoft stops selling lifetime windows licenses because the biggest point of M365 is windows as a service. Even if you buy the other components like Intune and entra ID separately you're still way cheaper off with lifetime windows licenses. Which is what we do at work.
And it probably will be until Microsoft stops selling lifetime windows licenses because the biggest point of M365 is windows as a service. Even if you buy the other components like Intune and entra ID separately you're still way cheaper off with lifetime windows licenses. Which is what we do at work.
> it’s no surprise that there’s demand among Thunderbird users to support Exchange.
Uh, I'm surprised. How many people actually love thunderbird? And to the extend it justified the development.
Uh, I'm surprised. How many people actually love thunderbird? And to the extend it justified the development.
Enough to raise >6m in donations in 2022: https://blog.thunderbird.net/2023/05/thunderbird-is-thriving...
> How many people actually love thunderbird?
I love Thunderbird and give them money every month. Name another good open source mail client.
I love Thunderbird and give them money every month. Name another good open source mail client.
Are you suggesting that no development is justified? I think we can expect that for any email client, there will be demand for one of the most popular email servers, and one that is required for most corporate use.
Thunderbird is paramount to my workflow and has been for over a decade. If I did not have thunderbird I would be upset.
That said, loving a software requires a paradigm shift for me. I can't fathom loving something that is not alive. I do enjoy it, however.
That said, loving a software requires a paradigm shift for me. I can't fathom loving something that is not alive. I do enjoy it, however.
Do you have a use case you'd prefer they put their resources into implementing?
Oh, Microsoft Exchange. I was thinking crypto support.
This post gives me extremely little hope.
One one hand… ok, let’s say it’s an engineering post written by devs for devs. OKAY, talk about Rust if you like. Devs might be more interested in the cause than the effect.
On the other hand… is this written for devs? Seems written for users. And I for one don’t give one half of one shit what language you use as a customer. It’s a post about Exchange, I don’t want to hear about new fangled language. I don’t pay you use a specific language, I pay you to deliver a specific feature… now obviously I don’t pay them in anything but time, donation, and reputation. But I think the point applies.
No one but Rust Evangelicals care about doing something over in Rust. There isn’t a single end feature that you can deliver in Rust but not C.
It reads to me like the developers are nerding out on a detail while being slightly uncommitted to the thing they “are paid to make”.
I have to agree with the other users that MS has already set an EOL on the feature that TB is planning to use. So… woohoo Rust?
One one hand… ok, let’s say it’s an engineering post written by devs for devs. OKAY, talk about Rust if you like. Devs might be more interested in the cause than the effect.
On the other hand… is this written for devs? Seems written for users. And I for one don’t give one half of one shit what language you use as a customer. It’s a post about Exchange, I don’t want to hear about new fangled language. I don’t pay you use a specific language, I pay you to deliver a specific feature… now obviously I don’t pay them in anything but time, donation, and reputation. But I think the point applies.
No one but Rust Evangelicals care about doing something over in Rust. There isn’t a single end feature that you can deliver in Rust but not C.
It reads to me like the developers are nerding out on a detail while being slightly uncommitted to the thing they “are paid to make”.
I have to agree with the other users that MS has already set an EOL on the feature that TB is planning to use. So… woohoo Rust?
> There isn’t a single end feature that you can deliver in Rust but not C.
There are! Namely, when it’s open source with volunteer-ish developers, who cannot be arsed to not use Rust, as it’s simply that much more pleasant to be spending your time with.
So in some sense, it’s either done in Rust because the implementers want to for one reason or another, or just not at all, as no one can be forced.
There are! Namely, when it’s open source with volunteer-ish developers, who cannot be arsed to not use Rust, as it’s simply that much more pleasant to be spending your time with.
So in some sense, it’s either done in Rust because the implementers want to for one reason or another, or just not at all, as no one can be forced.
That isn’t even remotely a counter to what I said.
There is not end feature you can do in Rust that you cannot do in C. End of story.
Cool, it’s popular among enthusiasts. That’s fine.
There is not end feature you can do in Rust that you cannot do in C. End of story.
Cool, it’s popular among enthusiasts. That’s fine.
> There is not end feature you can do in Rust that you cannot do in C.
Sure, but you could create the whole thing in brainfuck if you really wanted to.
Having something be nice to work with or extend is genuinely a feature
Sure, but you could create the whole thing in brainfuck if you really wanted to.
Having something be nice to work with or extend is genuinely a feature
Right. So talking to you users about a feature, then spending the who time talking about Rust… tells me you have devs needing out and don’t actually care about the feature.
Which they are telling you in multiple ways by talking about on-prem, EWS, Rust.
Kind of like that was what my post was about.
Which they are telling you in multiple ways by talking about on-prem, EWS, Rust.
Kind of like that was what my post was about.
Not to speak negative on you, most likely you have many years with C/C++, but I've been wanting to learn c++ for a long time. I learned the language but getting into a project or parsing through old code I'm still not getting into it.
But having picked up a rust book. Maaan. It's so nice. Just the ways it goes about so many things are so inline with the concepts I've already been incorporating into my code for the past 4 years or so. Just really brings a lot of things together into such a nice package.
Not to say that you should inherently like rust yourself, it's fine to be indifferent. Either way, heh. .... So... woohoo Rust?
But having picked up a rust book. Maaan. It's so nice. Just the ways it goes about so many things are so inline with the concepts I've already been incorporating into my code for the past 4 years or so. Just really brings a lot of things together into such a nice package.
Not to say that you should inherently like rust yourself, it's fine to be indifferent. Either way, heh. .... So... woohoo Rust?
While it's all software that compiles down to assembly in the end, there's a lot of code that is monstrously difficult to do in C, especially at scale, but relatively straightforward to do in Rust with 1-5% of the dev time. There are also many skilled developers who would simply refuse to do a project like this in C, but would be happy to do it in Rust.
As a simple example, writing portable I/O code can be a huge burden in C, but has been abstracted away through libraries like mio in Rust.
As a simple example, writing portable I/O code can be a huge burden in C, but has been abstracted away through libraries like mio in Rust.
Code compiles down to machine code. Not assembly. If I give you assembly and disassembly, you’ll prefer the former.
Ok. You find it difficult to do things in C. Understood. I believe the topic is of end features, bit maintenance or abstraction.
Ok. You find it difficult to do things in C. Understood. I believe the topic is of end features, bit maintenance or abstraction.
[deleted]
> No one but Rust Evangelicals care about doing something over in Rust. There isn’t a single end feature that you can deliver in Rust but not C.
Strictly speaking, no. But there are many ways that the quality of life of writing code is so much higher in Rust than C. A non-exhaustive stuff of just the things I've done in my most recent project:
* String handling. C's idiomatic string interface (i.e., null-terminated strings) is a dumpster fire of an interface that makes security vulnerabilities far more likely. And the set of string functions in the C standard library are a joke.
* For that matter, memory management. Sure, I can write malloc and free manually, and have to manually remember whenever I get a pointer whether or not I'm responsible for freeing it, or if the pointer is only valid until the next function call, or stuff like that. But scale that to 100KLOC, and the ability of programmers to remember all of those details turns out to shockingly poor. Meanwhile, in Rust, it's a compiler error if you get it wrong, rather than being a crash or worse.
* Asynchronous programming. Rust has built-in coroutine support; C does not.
* Better idiomatic error handling. Handling an error in Rust is very often just a single ? character. No more chance of gotofail!
* Newtypes, which are a godsend if you want to implement a parse-don't-validate strategy.
* Better threading support. Rust has a much richer standard library for writing multithreaded applications, and it provides much better compiler support for it (Send and Sync traits are absolute godsends for annotating what can and can't be used from multiple threads). And if you go out into common crates... rayon is a better way to do embarrassingly parallel code than OpenMP is, especially if you want to do fancy stuff like non-trivial reductions. (Side note: the first successful attempt at a multithreaded HTML rendering engine was written in Rust, and that's not for a lack of trying with C++ code. That is how much of a godsend Rust ends up being.)
I am by no means a member of the Rewrite-it-in-Rust brigade; I'm pretty sober about the costs of rewrites and the benefits you'd get from such a thing. However, I will say that Rust is generally a superior option than C/C++ if you're doing parsing code (which means you're dealing with untrusted input that you really want to be sure isn't going to go haywire on unexpected input). And for email protocols, where you deal with a lot of mixed binary and text in the same stream, Rust's string handling support is in a sweet spot, especially compared to most other safe VM languages which have different types for binary strings and text strings.
Also, knowing enough of the Thunderbird internals to know what code already does need to be rewritten, I'm fairly confident of where I can sensibly propose that things ought to be written in Rust in lieu of C++ or JS.
Strictly speaking, no. But there are many ways that the quality of life of writing code is so much higher in Rust than C. A non-exhaustive stuff of just the things I've done in my most recent project:
* String handling. C's idiomatic string interface (i.e., null-terminated strings) is a dumpster fire of an interface that makes security vulnerabilities far more likely. And the set of string functions in the C standard library are a joke.
* For that matter, memory management. Sure, I can write malloc and free manually, and have to manually remember whenever I get a pointer whether or not I'm responsible for freeing it, or if the pointer is only valid until the next function call, or stuff like that. But scale that to 100KLOC, and the ability of programmers to remember all of those details turns out to shockingly poor. Meanwhile, in Rust, it's a compiler error if you get it wrong, rather than being a crash or worse.
* Asynchronous programming. Rust has built-in coroutine support; C does not.
* Better idiomatic error handling. Handling an error in Rust is very often just a single ? character. No more chance of gotofail!
* Newtypes, which are a godsend if you want to implement a parse-don't-validate strategy.
* Better threading support. Rust has a much richer standard library for writing multithreaded applications, and it provides much better compiler support for it (Send and Sync traits are absolute godsends for annotating what can and can't be used from multiple threads). And if you go out into common crates... rayon is a better way to do embarrassingly parallel code than OpenMP is, especially if you want to do fancy stuff like non-trivial reductions. (Side note: the first successful attempt at a multithreaded HTML rendering engine was written in Rust, and that's not for a lack of trying with C++ code. That is how much of a godsend Rust ends up being.)
I am by no means a member of the Rewrite-it-in-Rust brigade; I'm pretty sober about the costs of rewrites and the benefits you'd get from such a thing. However, I will say that Rust is generally a superior option than C/C++ if you're doing parsing code (which means you're dealing with untrusted input that you really want to be sure isn't going to go haywire on unexpected input). And for email protocols, where you deal with a lot of mixed binary and text in the same stream, Rust's string handling support is in a sweet spot, especially compared to most other safe VM languages which have different types for binary strings and text strings.
Also, knowing enough of the Thunderbird internals to know what code already does need to be rewritten, I'm fairly confident of where I can sensibly propose that things ought to be written in Rust in lieu of C++ or JS.
This is good news and I'm looking forward to Thunderbird natively supporting XChange. But everything I read about it triggers my inner voice: „Do a parallel rewrite of the whole damn 20 year old codebase in Rust! It’s faster, cheaper and cleaner. Do it right now. Don’t discuss it in mailing lists. Take 12 competent software developers and let them rebuild everything.“
Faster and cheaper to write an email client from scratch? Including HTML rendering? Are you sure?
No. Leave the html rendering to Firefox.
Edit: As it has already been handled by Thunderbird in the past.
Edit: As it has already been handled by Thunderbird in the past.
Actually leave html rendering to Servo https://servo.org/