This is excellent, frankly. Lately I haven't been super keen on Thunderbird's move away from plugins (seriously, different colored accounts should be trivially easy and apparently no.)
But given the garbage pile experience that is "Outlook on the Web" (and the fact that I have been forced into it at work) -- yeah, if this works that'll be an easy donation.
Apparently EWS which makes sense. ActiveSync is for mobile and EWS is newer compared to MAPI (which is an API technically), although there is a protocol that maps this to RPC for the Exchange case.
Are you sure it's not Microsoft Graph? (did you find this in the docs somewhere?) The end of life of EWS has been set in stone for 2026[0] (although it's been implied EoL for a few years) seems futile to invest in an expiring service.
What's the difference between an API and a protocol? From my understanding, if a developer publishes an API or a protocol spec, I can use that to retrieve data from their server either way
API is documentation for MAPI.DLL in this case. It is useless under non-windows system and requires this DLL, which is, effectively, Outlook backed.
Network protocol between MAPI.DLL and Exchange server newer was published (but partially revers-engineered).
And I've participated in project which uses MAPI.DLL, it was buggy as hell, and we delayed product release for whole year (!), trying to workaround all bugs. It was complete disaster and failed product too late to market.
I would expect an API is a set of things one could call, and a protocol is the sequence of things that one must, should, or can do in order to be in compliance with what the other party in the protocol is expecting to happen
HTTP is a protocol because one cannot just socket.write whatever bytes they want and have any good outcome, whereas socket.write is an API that is available in a hypothetical library
Yep, I was using MAPI as shorthand for both RPC MAPI (which was traditionally used inside corp networks, where port 35 would be open) and RPC-over-HTTP.
There's also a JSON-based web services API that is, as far as I know, unpublished (which OWA and I think the "next gen" Outlook uses).
It‘s not totally separate from MAPI because it inherits a large amount of the legacy baggage. A compliant implementation will need a very similar object model, in particular most of the properties, streams and encapsulated formats are also transported through EWS.
I wonder how it deals with things like MAPI (which still forms internals of Outlook and Exchange) not actually supporting HTML email[1] despite having a message for it (and Outlook being infamous for pushing HTML email in minds of many)
[1] If you include a HTML Email message part in a MAPI store, the MS MAPI library explodes and declares the store unreadable. You have to wrap HTML in RTF and include it in RTF message part... ¯ \ _ ಠ _ ಠ _ / ¯
Yeah! Currently, I am paying for ExQuilla because my university does not provide e-mail access via IMAP. They literally told me that IMAP is too old and Exchange is "the future" sigh.
IMAP is indeed old, but the question is, what implication of it being old they see as critical. If they worry about things needing to be encrypted better, then they could have PGP set up. It is quite common to have a more secure message exchange via a not secure channel in many protocols, so I don't see a big problem.
Usually when someone claims some proprietary MS owned product is the future, they are either sorely uninformed, MS fanboy, or their income depends on sticking with proprietary tech. None of which one would want at a public institution, and least of all in institutions of the education system.
I still remember, when some admin at some educational place I went to wrote messages to everyone on the whole system to warn them about MS office document macros. But of course people did not get it and then some malware spread over many people's systems, because they ran the code. And this happened multiple times within a year or so and even after I had graduated, but still received e-mail, it happened again. So funny to watch that story play out over and over again.
Have you, perhaps, not run a mail server? The limitation of SMTP/IMAP is that they're built with the assumption the connecting party can be trusted and acting in good faith (like many of the original protocols).
You can implement TCP rate limits on top, but that doesn't work when botnets and spammers (likely using "crowdsourced VPNs") rarely use the same IP twice. Further if you're running robust mail infrastructure (backup/fallback mail exchanges) communicating these limits/ reputations is left up to the operator (not supported by protocols, rarely supported by servers). I don't think MAPI/OWA/EWS is better, at all, especially not against open mail standards, but SMTP & IMAP don't cut it either. On a new server, it only takes a few hours before someone connects over IMAP and starts testing passwords against accounts (faster if the server is assigned to the MX or A of an existing domain, and valid emails might be known from hacks/cracks/dumps/leaks/people posting their email in their profile).
> they are either sorely uninformed, MS fanboy, or their income depends on sticking with proprietary tech
Or lazy. Or understaffed. Needless to say, other universities do support IMAP and apparently it worked just fine. Anyway, I sent an angry e-mail and moved on with my life :)
Before you all get too excited, please remember that Exchange admins can control which clients are allowed to connect to their service, and Microsoft actively advises them to shut out everything but recent versions of Microsoft clients.
Source: me, at almost all of my jobs, after being told to lock people out for using third party clients.
Too bad they spent time to Microsoft's proprietary protocol and not to suppoert open protocols better.
Native Sieve editor would be nice.
Or really good feature: store per-folder settings (like reply-to, sorting direction, view mode, etc) on IMAP server. There is per-folder key-value storage on IMAP server, and it is supported at least by dovecot server. Now I need to configure all my 100+ folders with 5 identities and different column settings on each new Thunderbird installation. It is SUXXXX.
If I need Exchange protocol I will use Outlook. Thank you.
Or at least decent text editor, which allows to have one physical line per paragraph in plain-text messages but wrap these long lines visually to size of the editor window. As simple as that.
Or good quoting engine. Does somebody remember FIDO's editor GoldEd? It made perfect multi-level quotes int most complex situations without problem, re-wrap and re-format lines to fit it in 80 columns (without breaking quotes in process!), it was real pleasure to read long threads because you always know who wrote what. And if you see broken quotes in echoarea you know, it is from usenet user, received via gateway with their shitty news clients.
Thunderbird is still shitty in this regard, 30 years later.
What does it have with it being proprietary? They are doing it because tons and tons of people who would actually use a full email client also use Exchange, for reasons that are usually beyond the users control. You'd rather have them support something that much less people use or need for... reasons? Remember, this is an email client. Supporting or not a certain protocol won't make email servers support said protocol, not in any meaningful way at least. It would just make the email client (again, more of a niche nowadays) more irrelevant.
Exchange is not email server. It is groupware server. Thunderbird will not support all features of Exchange, ever, as it requires much more than e-mail (and even calendar) support.
And, yes, Exchange supports IMAP for people who want to use it as bad and feature-limited email server ;-)
I want Thunderbird to be best e-mail client, not mediocre groupware client.
I don’t think it’s that it required Rust, as that the people who wanted to implement that feature wanted to use Rust, and that motivated the Thunderbird gang to do the needful to make that an option.
When you installed Windows 95, you would get an icon on your desktop: The Microsoft Network. It was the villainous attempt to control the Internet from the start. Gladly, it never thrived.
So then came Internet Explorer, which after decades of spreading evil via non-standard behavior, annoying popups and malware, is finally gone.
Now it's the turn for Exchange to be erased from the collective memory of humankind.
I've long struggled with this. Another HN user pointed out that it could actually be Windows Defender causing the issue. I disabled it for Thunderbird, and things are now running much better. Hopefully this will work for you too!
I use Linux and I’ll know I will be crucified for saying it… but Outlook’s base UI is just better and I might reconsider TB when I can make it look even remotely like Outlook.
It’s not big things. It’s spacing, fonts, choice of pictograms and their locations. Some is opinion, and some is just functionally better.
In fact, I stand by that if I were them, I would be pushing as hard as possible for an Outlook Theme for people just coming in or back. Office 365 is too common to ignore - considering the native Exchange support post here.
I want Thunderbird to look like Thunderbird, not Outlook. There's nothing superior about Outlook. When Microsoft made the ridiculous decision to stuck the search text box in the Title Bar, it was clear they have no clue any more what they're doing. Then Thunderbird recently followed suit. Dumb and dumber. At least TB lets us fix it. Now they're focusing on Exchange support when the best email servers on the planet have nothing to do with Microsoft? Dumb and dumber redux. Time to look for a new email client on the Linux Desktop.
I get your sentiment, and while some may disagree (most of this is subjective, anyway), there will be many who agree with most of your points here. However:
> Now they're focusing on Exchange support when the best email servers on the planet have nothing to do with Microsoft?
People don't want Exchange because they like Exchange. For people who like Microsoft, the very last thing they care about is that their email client communicates with their server over Exchange.
This feature is for the unfortunate Linux fans, like you, who are stuck with a job that requires them to interact with a Microsoft server. That's not dumb, that's a smart move on the TB side (well, lucky, perhaps, that people are willing to work on it, more than being smart) to allow users to use TB in the first place. If you don't use Exchange you won't mind the support (barring perhaps reduced development elsewhere), but it will let many people use TB where they otherwise _could not_ without plugins.
>now, I don't see many places using Exchange switching to Thunderbird,
Because you couldn’t.
There was a TB extension “OWL” but it wasn’t good enough for me, still lacked things like the contact cards with data from your Active Directory install, and other default Outlook features.
So the point for me is now you could take that path - maybe.
> It’s not big things. It’s spacing, fonts, choice of pictograms and their locations. Some is opinion, and some is just functionally better.
Thunderbird had a great looking (in my opinion) proposed new UI from the designer for the Supernova project, but it never actually shipped in 115 which was a real shame. I'd say they got about half-way there when they cut the release.
But given the garbage pile experience that is "Outlook on the Web" (and the fact that I have been forced into it at work) -- yeah, if this works that'll be an easy donation.