> we have 15 people hired and working on the project
Honest question: What are these people actually doing? I haven't seen new features since a long time, but Thunderbird seems to have reorganized one year ago (https://blog.thunderbird.net/2020/01/thunderbirds-new-home/), so they probably plan something big, like a rewrite of the software?
I've noticed that many of the linux repos are not up to date. If you're using those, you probably need to install it directly from the website to get the latest version and see the updates.
The major features that have come out lately that I've noticed are first-party calendar integration and first-party GPG support. There was a calendar integration but I always found it to be a bit funny and hard to get working all of the way. I never had problems with Enigmail, however.
Both features work much more solidly as an included part of Thunderbird. There are other, smaller features that have come in like having e-mail addresses in the To/CC/BCC lines be places into ovals to show them as a distinct, drag-able element.
The Thunderbird codebase is old and is full of a ton of features, transforming it in a way that is true to its past and moves towards a better future is going to take time but it is coming along. Sure, some of the major features were available as plug-ins but they're much more solid now that they're built-in.
> I've noticed that many of the linux repos are not up to date
This is very tricky.
Thunderbird keeps breaking addons compatibility (as an end user, I don't care if this is justified or not), by supporting main versions for short times (v68 was released less than two years ago).
An O/S like LTS Ubuntu, which has a 4+ years support cycles, is systematically forced to break TB compatibility during each cycle, which is contrary to the O/S versioning guidelines (which typically freeze the program versions, with the exception of security upgrades, e.g. web browsers).
As a side effect, addons, which give TB a significant value (I'd argue that they give its only value - even Google Calendar is not natively supported) slowly disappear.
Thunderbird is essentially systematically and forcefully breaking versioning and compatibility. I believe something's broken in the team/company.
Given the resources available, I don't think they can make the product better and maintain compatibility for long. Given the previous decade+ of minimal enhancement to the point where it's now just the tiniest fraction of email users, standing still is a guaranteed death sentence.
I figure the easy (though actually hard) answer is to try to collect commonly used add-ons in one central place and update those there, the same way that TypeScript can always keep moving as a language while centrally publishing new versions of types with backwards compatibility to older language APIs.
Alternatively, and not so good, the other answer is to maintain shims or back-ported APIs for some duration as downloadable add-ons that extensions could use. You could add existing extensions to a giant test-suite that ensures common extensions don't break.
You could combine all these approaches, of course. Personally, I'd push to have common community add-ons maintained centrally though, such that if they change an API and it's a relatively easy fix, project maintainers could automate a "code-mod" or fix to rename and use the new API, or shim support for the old API? It's not easy, exactly, it requires taking ownership of a community to such an extent that you can ship API changes as useful codemods to help automate community porting efforts.
That said, I've often found that even if plugin APIs don't change, requirements to list compatible API versions in plugin manifests can make it hard to use new plugins until app authors can get around to updating the manifest to a new version and ensure compatibility for their extension. It might be interesting if app or extension stores could run tests to confirm if a plugin is compatible or not and if not, maybe suggestions could be made to point projects to new APIs and porting guides, if not outright automated PRs for fixes?
> Knowing that following the proper migration strategy is not easy, we created two wrapper APIs which do not require all of these changes. Using these APIs, you can quickly get your add-on running in Thunderbird 78 again, but you will not get the benefits of a MailExtension. The idea behind this is to make add-ons compatible with the current ESR as quickly and easily as possible, so users can continue to work with their beloved add-ons.
Per se, this would be a sensible move. However, in the bigger picture, the plan starts to show its pointy-hairedness:
> While the Thunderbird team plans to add more APIs with upcoming releases, the current set of APIs will not be sufficient to port most add-ons. To work around this limitation, add-ons can introduce their own, additional APIs as so-called Experiments [...] [which] are expected to require updates for each new version of Thunderbird.
In other words, the TB team, for unspecified reasons (it's not clear if they were really forced to move to MailExtensions), has broken compatibility with the previous versions of the addons, and provided half-baked APIs which are expected to break again in the future.
Other mind-numbing pointy-hairedness:
> [...] If you follow this strategy, you will end up with a future-proof MailExtension that will require substantially less maintenance work for future versions of Thunderbird.
They're saying in a single sentence that updated addons won't require changes in the future (being "future-proof") _and_ that they will require them.
===
All in all, I have the strong suspicion that Thunderbird is very incompetently developed/maintained, but I'd be very happy to be proven wrong (with technical arguments).
First-party GPG support would be so nice to have some decades ago. By now seems everyone admitted defeat. Companies standardized on email as notification system for "you got a message in the actually secure medium". Humans standardized on using some inherently safe (but usually not open) communicator. Who is there still wanting secure email?
This question (and the one above right now) are good points. GPG isn't really a killer feature right now. I likewise haven't needed secure e-mail in a while. I just happened to notice it when it migrated stuff over. I stopped using my Yubikey with gpg a while back.
All of that said - I'm replying to this message and not the other because there is one use for secure e-mail that may make a difference: DeltaChat. Deltachat uses autocrypt which includes your public key in headers. With autocrypt in place, Thunderbird can still read DeltaChat messages.
I'm not sure if DeltaChat will ever take off in large numbers but it seems like a decent option for secure chat/IM.
It does, and the benefit is that anyone with an email address can already be approached via Deltachat, because all it does is send and receive email through the Autocrypt protocol, which gracefully degrades with clients that don't support it.
> Companies standardized on email as notification system for "you got a message in the actually secure medium".
This is so ridiculous. I have to log in to a dozen different sites to download documents. And those sites are 2FA secured, so I have no means to automate. Of course these companies never heared of (REST) APIs. - This is such a step backwards.
That's an extra thing they could get wrong. Seeing how some banks cannot deal with copy-pasting my legal name correctly, I prefer to not give them anything else out of the ordinary.
I still haven't been able to get the new GPG integration working with my Yubikey, that whole path seems not super well-supported yet. And Enigmail doesn't run on more recent versions of Thunderbird.
I haven't had to work with encrypted email for a little bit, but I think the next time I do it'll push me to another email client if I still haven't gotten this working.
Right, even with that I haven't gotten it working. I'm sure I'm doing something wrong, but the failure modes don't make it particularly clear what the problem is.
Depending on what you mean there are a couple of extensions which help: Conversations [1] and ThreadVis [2].
Thunderbird is slowly becoming less dated, but I'm not sure Gmail's UI is necessarily what email client designers should be aspiring to. The former lead designer of Gmail (and Inbox) hated it so much that he has put hundreds of hours into maintaining personal modifications. Now that's he's trying to turn it into a business, the marketing site is a bit more original and there's fewer strongly worded criticisms but I'm sure you can read between the lines [3].
There are many things planned, especially moving to "web based technologies" for the client as a longer term initiative. The roadmap also has some work on JMAP support, which I hope picks up on mail servers too. One thing I'd love to see, which probably won't be on the roadmap, is native integration with Exchange and Exchange calendaring. I know there are some extensions for this, but none of those have actually worked well for me.
A move to anything similar to Electron is gonna be the same to me as the project dying. In either case, I'll no longer use it. That's a shame.
[EDIT] "but it's already XUL!" right but XUL-based GUI programs can run great on machines without enough memory to use Slack or VSCode without hitting swap, even if those were the only programs open. My source for this: I've been using XUL apps since the days when machines with 128MB of system memory were pretty damn high-end. They were kinda heavy back then, but basically fine. They're straight-up lightweight by today's standards.
> I've been using XUL apps since the days when machines with 128MB of system memory were pretty damn high-end. They were kinda heavy back then, but basically fine. They're straight-up lightweight by today's standards.
Right, but even XUL has grown quite a bit since those days - not to mention that it's pretty much dead at this point. Still, something other than "yet another desktop app built around some descendant of KHTML" would be nice.
There are basically four ways this could go:
1. Thunderbird spearheads a Gecko-based alternative to Electron (following Firefox in deprecating XUL)
2. Thunderbird throws in with the various XUL-preserving Firefox forks to maintain XUL as a Gecko-based alternative to Electron (since the Firefox folks don't seem to have any interest in doing so)
3. Thunderbird switches to some native-widgeted toolkit like Qt or GTK
4. Thunderbird switches to Electron
These are in order of my preference. Option 1 also thankfully seems to be Thunderbird's current direction, though it'd be nice if it could spearhead the necessary documentation and niceties for other applications to use Gecko in desktop apps.
Actually, the Thunderbird team throwing its weight behind Kmail/Contact, a client plagued by UX papercuts and a less than stable foundation (akonadi), but otherwise pleasant to use and portable sounds like an awesome idea!
Flutter is native as much as drawing on a canvas is native. While you could argue that Win32 technically ends up drawing on a canvas at the end, they still expose native widgets. Flutter just straight up draws on said canvas.
Thunderbird already needs HTML and CSS for rendering emails, and needs JS for XUL anyways, right? So Thunderbird already needs HTML, CSS, and JS engines at any given time. Where will the memory bloat come from by moving to using HTML, CSS, and JS for the UI?
It's the culture of Electron and NodeJS/NPM and their programming style. Switching to Electron wouldn't require adopting those, but the practices associated with the "modern JS" crowd are almost certain to end up infecting the way that Thunderbird is developed just like it has infected essentially everything about the way anyone does JS these days.
“Web-based technologies” doesn’t necessarily mean something like electron. Firefox used the same language and has largely completed their migration away from XUL. You can see details in the roadmap here: https://docs.google.com/document/d/1ORqed8SW_7fPnPdjfz42RoGf...
I definitely don't consider Firefox's resource use (battery, CPU, memory) something to aim for. Pre 2.0 Firefox? Hell yes, it was part of what got everyone on it in the first place. After 2.0, when it started to bloat rapidly for unclear reasons? Not so much.
I remember trying out Firefox for the first time (it was v2.0) and it would take well over 5 minutes before it would even display a window on my computer (regularly, not just the first ever launch). I would have to check Task Manager to make sure that it did start.
IE6, on the other hand, would be usable in less than 10 seconds from launch. Granted, it probably got preloaded by Windows, but even Windows took less than 5 minutes.
1) Yes, I know, that's how long Firefox has been going down the wrong path, performance-wise. They've only recently seemed to kinda start addressing that ("now we're as good as Chrome, finally!" OK but Chrome is also bad, so....)
2) I'd prefer software just, you know, not be bad. Safari, for all its problems, demonstrates that there's nothing inherent in a modern desktop web browser that requires it to be grossly inconsiderate of your system resources.
I understand your points but please don't argue for good software and use Safari as a good example. Safari is the new internet explorer, it requires its own workarounds, it doesn't support some standards because Apple doesn't want it, and you must buy a Mac to debug it.
The context was how good Safari is for end users when it comes to resource use, not how good Safari is for developers when it comes to developing for it. These two aren't very related and developers tend to view things HEAVILY biased through their own experience as developers (which is why Electron is so popular).
The point is that Firefox 2 became too bloated for its time and it never felt like it got debloated after that even things progressed.
I remember these days clearly because Firefox 1 was very fast and it displaced Mozilla (what was later called "Mozilla Suite") as the main browser for the Mozilla Foundation exactly because of that performance benefit. However Firefox 2 not only ended up becoming much slower but Mozilla Suite actually became faster and ended up being faster than Firefox despite providing not only a browser, but also a mail client, news client, WYSIWYG editor, IRC client, etc - ie an integrated "internet client".
At the time i liked Mozilla more than Firefox so i was bitter about it and how it was eventually abandoned by Mozilla Foundation (it became Seamonkey, sure, but that is another story).
I'm still unsure why certain websites result in browser processes using up substantial resources in terms of CPU time or system memory. I typically will search for "Web Content" processes in top and kill the ones that are taking more than a certain percent of resident memory or using more than 20% CPU time just to keep the computer usable.
That's not a problem I recall encountering in the days of Firefox 2.0.
Firefox 2 had other issues. You don't remember that a website could freeze the whole browser and that it didn't have any thread or process separation between tabs?
I do remember the days where there was no thread or process separation, but, at least for the set of websites I would frequent back in those days, it rarely happened. And, even then, it didn't render the computer unusable due to constant swapping due to insufficient memory.
I think you should really consider to upgrade your hardware if a website can make your computer unusable. I agree it shouldn't be the case but that's how it is.
It really only happens with certain websites, like Facebook. If I leave a browser tab open overnight, then it can get to that point where I see a browser tab taking 50% of the resident memory,
I guess it's too much to ask companies not to implement websites that leak memory.
I used Mozilla (the original) on my Pentium MMX with 128MB of RAM and i remember it being so slow i could literally watch the widgets draw themselves one after another whenever i opened a dialog window.
Oh yeah, Mozilla was heavier than IE, which was heavier than Phoenix/Firebird/pre-2.0-Firefox. Plus FF had a popup blocker built in, which was huge in a way that's hard to appreciate these days. Very quick to start, pages (at least seemed to) load faster, no more popups which were like 99% of ad-annoyances on the web in those days, and tabbed browsing, all free and open-source with no ads in the browser itself (see: Opera). That's what sold it, originally.
While that's true, I've noticed that my installation of Thunderbird has recently started allocating anywhere from 30 to 40% of resident memory (%mem column in top), and it takes a very long time to switch tasks to or from Thunderbird. It's an older laptop with 6 GB of RAM, but I don't recall encountering issues like this on much older machines with just megabytes of system memory.
I have used Thunderbird for many years now, but it's starting to give me some problems, so I'm thinking about finding something else. E.g. it always shows the last folder opened as the windows title when switching between tasks, and filters are not always working as they should. Are there any good alternatives?
There are a number out there that I've heard of but never tried. Years ago, I used to use Seamonkey (which was a continuation of the Mozilla application suite and was the predecessor of Firefox and Thunderbird). I might try it again just to use the mail client :).
why evenn care about JMAP. better support EWS/ActiveSync. JMAP is still in such an early stage and no matter if proprietary or not, there is still no protocol out there that does the same things than EWS/ActiveSync.
That seems like a lot of duplicated effort when Davmail exists. I'd much prefer to see them supporting a decent new protocol than throwing resources at chasing legacy use cases like EWS that's not going to be used by a significant portion of their target market anyways.
I don't mean this to be dismissive, I mean that EWS is a massive moving target that will require a significant allocation of resources that would, IMO, be better spent on other things.
They are just mirroring Firefox's (and thus Gecko's) own deprecation of XUL in favour of (X)HTML. Firefox's top level windows are now (X)HTML with XUL elements, and XUL specific elements and code paths are gradually being replaced with standard HTML elements or custom elements.
Given that the general public has largely moved on to web interfaces or mobile apps for email access, do we really need to render HTML emails in Thunderbird? I have mine set to display messages as plain text.
As a technical user, how often is the HTML content actually useful to the content of the message? For some anecdata, I'm a heavy user of Mutt, and I get my HTML mails piped through w3m --dump for display.. I might have to invoke a web browser on the content once every few months?
If they could finally make Faceted Search configurable to show a list of results and make that list matching your normal view settings (e.g. not threaded) that would be awesome. It is really a drag that it is always 5 clicks to get a view where the search results are comprehensible.
This is not a SaaS; this is an application built and distributed to more than 20 million people on their own machines, with different hardware, operating systems, installed software, different filesystems, upgrades, behind firewalls or weird networking, interacting with email providers and their particularities...
Well, at first I thought the same. But honestly I don't really care if features are being added as long as they don't break too much. A few years, ago I switched to Thunderbird from Kmail because the KDE people constantly managed to break Kmail.
I still use KDE as a desktop environment and while I think Kmail looks better, Thunderbird just works so much better (e.g. faster, better RSS integration, better search results) that I am quite happy that I switched.
Since thunderbird tracks the firefox codebase and firefox moved to webextensions that broke a lot of thunderbird extensions too. They mitigated the fallout.
E.g. the virtual identities extension now is a first party feature.
I'm using the beta version and the changes are actually useful and, relatively, plenty.
The one thing I'm currently looking forward the most is multi-process support, planned for Thunderbird 91, IIRC; It should relieve the hangs I sometimes get (having >50 GiB mails locally has its tolls, but oh well LKML, QEMU, ... archives and such are just nice to have around for me).
I still use Claws Mail because I have never been able to figure out how to set Thunderbird to display emails with a consistent font size.
I've changed the advanced settings and set a minimum font size, and it has no effect. You can zoom in when you're looking at an email, but the results are inconsistent from email to email.
With Claws Mail I get the same font size every time.
If anyone knows how to set this up properly, I'd give Thunderbird a try again.
What I want most out of Thunderbird is a self hostable web application that I can run on my own servers, and access as TLS1.3 in a browser, as a modern webmail app as competition for Rainloop and Roundcube.
I realize this would probably require a complete re-write.
The closest I can do to that now is a much more cumbersome solution involving something like a bare bones xfce4 desktop environment, the Linux thunderbird client, and VNC-over-SSH or apache guacamole.
I used Thunderbird as a work email client around 2012-2013 era. It was decent, but a little sluggish for my taste. I attributed it to my weak office PC at the time.
Thinking they've done some interesting updates since then, I tried it again recently, in February 2021.
I was disappointed to find a sluggish client with worse UI than it had 8 years ago, defeating the entire purpose of having a desktop email client on a powerful machine. Maybe it was some default settings or whatnot, but I didn't feel like digging around to fix it and there was no advantage in using it over the default Gmail web client. RAM usage was not light either. It all seemed like some weird poor UI wrapper around an Electron instance that just loads the Gmail client.
I ended up going back to Opera Mail - a lightweight desktop email client from 2016, that unfortunately isn't getting updated anymore.
Not sure what the use case is for that type of software anymore. It didn't feel like a real desktop client.
1. Why is there no Thunderbird for Android? It's the only project that I trust with my emails on my phone.
2. What do Android users use as an email client on their phones?
I current cannot access email on my phone. Maybe it is better this way, security wise. But if Thunderbird was available for Android I might consider using it.
I have been using FairEmail for a month now. It's privacy centric and has loooooots of features. It is ad-free. It does not open stuff that may be used to track you by default. It can do GPG and so much more. It is developped by a single and very responsive developper for now. I liked it so much I bought the premium version to support his work but paid features are quite niche and you won't click on something only to find out that you need the paid version.
https://email.faircode.eu/
I used to use Aqua Mail when I had a slow phone which could not run Gmail that well.
Now a days Gmail app is good enough. If I use third party clients, the email search does not work as good as Gmail. So there really isn't any option.
Absolutely. I'm really glad that the Thunderbird project is healthy and alive. The ecosystem very much needs a solid open source email client to compete with commercial alternatives - particularly the cloud providers with their cloud vendor lock-in. Re-writing Thunderbird in a more accessible framework (JavaScript) will doubtless help more contributors to work on the codebase.
> Implementing a better vertical layout by exploring the possibility of not using the <tree> XUL element and relying on a highly scalable and equally performant HTML component.
Hey, does that mean we can have two lines per mail in the mail column :) ?
Otherwise, I am not convinced by matrix integration. Unless it's a deep one and creates new scenarios impossible with two standalone applications.
It already is written in KavaScript for large parts. However Firefox/Gecko deprecated the XUL UI system, which is used by Thunderbird, so they have to swap the UI toolkit to something else.
Without question: Thunderbird (short: TB) may or may not be have its problems. But its very secure and last a long time.
I use this Client since 2000 (on Windows) and due to problems with my computer in the beginning, i use it the PortableApp.com Version of TB more than 10 years.
My Mail-Archive (only important mails) is beginning in the year 2000, the whole TB-folder has a size of 1.33 GB.
TL;DR; I use TB and TB Portable over 20 years and have an actual folder size of 1.33 GB. No unsolvable problems in this time. I make heavy use of the RSS-Reader, too.
Therefore i use uBlock Origin for TB.
Can someone recommend a thunderbird alternative on Linux that supports Microsoft Exchanges account? My company uses Exchange without imap. I can connect with apple mail on Mac, but yet need to find a mail client on linux. Thanks!
I think that financial and technical status are essentially divorced. Good that they're getting money, but on the technical side, it's a rambling disaster.
TB has had the embarrassing Mork backend for ages (took around 14 years to fix; it's not in the released version yet). And the codebase is so tangled that nobody has been able to convert the email writing window into a tab. One window!
Even ignoring the above, the addons compatibility keeps breaking. AFAIK that's a necessity, but as an end-user, the result is an increased alienation from the product.
Ultimately, Thunderbird without addons is an unremarkable product.
> And the codebase is so tangled that nobody has been able to convert the email writing window into a tab. One window!
Switching between windows is easy using alt-tab. Switching tabs requires one to do something like ctrl-pgup/pgdown or alt-number if you know the tab number. Personally, I think using alt-tab is a lot easier to switch between the compose and overview windows.
Thunderbird got mothballed for a few years as Mozilla no longer saw it as a priority so it was only receiving small fixes and patches in the ESR channel. After a long process of pushing from some motivated developers it recently was de-coupled from Mozilla in order to allow it to live or die by it's own communities initiative.
Since it's spin-off it's been developed at breakneck speeds to desperately bring it up to par with modern Firefox (they share back-end technologies) in order to make it's development more sustainable and predictable. Unfortunately this has been a strain on add-on developers like myself. I was maintain the lookout TNEF parsing plugin however due to the pace of the changes and an increase in lack of time I'm now only putting out small fires
There are still multiple bugs involving loss or corruption of email. (the one I've got open in another tab is 13 years old) Why does anyone actually use this program?
Do you know of an email program without bugs? TB has been working well for me for many years, and apparently for a good number of other people as well.
I'm sure it has issues - heck, I've even filed bugs against it personally - but your comment doesn't at all resonate with my experience as a user.
I haven't used TB for a while, but it has corrupted my local inbox once, and on two other occasions deleted e-mail from the server before confirming it was on disk, causing recent e-mails to be lost. This was all over 10 years ago, so perhaps it's better now.
Did they move? When I installed Thunderbird on my Windows 10 machine recently, I noted that Maildir was available as an option, and switched to it. But it seemed like mbox was still the default, and certain behavior seems to be glitchy on Maildir. (I get frequent notifications about compaction of mailboxes, despite the fact that Maildir cannot be, and does not need to be, compacted.)
I've used Thunderbird with IMAP for literally at least a decade and have email back to 1998-ish. Haven't lost anything, occasionally had to rebuild Thunderbird's local cache.
Much easier to backup if your email is in one place and running even a local IMAP server is better than storing it in an email client.
> Much easier to backup if your email is in one place and running even a local IMAP server is better than storing it in an email client.
The 13-year old bug I linked to involves IMAP mail handling, I believe. I haven't dug too deeply into these bugs because, honestly... I'd like to be able to use Thunderbird for a couple of things, but mail handling doesn't need to be very screwed up for me to avoid the program. A 13 year old bug involving data loss is enough to make me avoid the program, even if it would not appear to effect my use case.
> Haven't lost anything
I guess I can understand how others might view it as "just email." I won't argue with the implied "I've never lost data to this program so it must never happen" argument, but I wonder how you know you've never lost anything. I feel like I'm capable of not noticing a data loss bug involving email, or not noticing until I need something and it is not there.
Honest question: What are these people actually doing? I haven't seen new features since a long time, but Thunderbird seems to have reorganized one year ago (https://blog.thunderbird.net/2020/01/thunderbirds-new-home/), so they probably plan something big, like a rewrite of the software?