Bringing Exchange Support to Thunderbird
blog.thunderbird.net
blog.thunderbird.net
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.
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.
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?
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.
And what if the unbundling doesn't affect the price? Don't confuse MSFT making mediocre products with them being commercially stupid.
> 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.
Perhaps there is an audience here and it just doesn't match your own experiences.
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.
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.
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 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
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.
LOL, no I won't.
(Also: what is the realistic security impact of this? As long as I don't do anything stupid, is it negligible?)
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-...
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.
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 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.
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
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.
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).
[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.
I say this as a daily mutt user.
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.
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.
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.
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?
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 :(
What a scandal this was. A prime example of Mozilla's backwards priorities.
EDIT: Oh, nvm - it's on-prem only - huh... that's asinine.
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?
JMAP calendar, contacts, sharing and sieve scripts aren't finalized yet.
(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.)
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/static/e0e177157e8596c60273e12d4b3bd695/4e...
The results themselves are good enough.
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.
Uh, I'm surprised. How many people actually love thunderbird? And to the extend it justified the development.
I love Thunderbird and give them money every month. Name another good open source mail client.
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.
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 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 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.
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
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.
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.
Ok. You find it difficult to do things in C. Understood. I believe the topic is of end features, bit maintenance or abstraction.
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.
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?
Edit: As it has already been handled by Thunderbird in the past.