Enough is enough with Thunderbird

Exactly. Well said, @antonis. Every time I hear the phrase “make it more modern,” I just assume it to mean “remove a lot of useful settings, or bury them under endless sub-menus, reduce font contrast to pale gray on even paler gray, and inject a lot of blank space around everything… you know… make it look nice for phone screens.”

Although I do understand the developers’ reasoning for rebuilding the code. What would have been nice is if they could have made the new layout a setting that users could enable themselves, to “check out the new look,” or disable to keep the UI as it was. But maybe it wasn’t possible to keep everything as it was, given the new code. :man_shrugging:

They did say they were going to try to approximate the former look and functionality, so I don’t know how some of those jarring design changes made it into the mix. :grimacing:


By the way, another annoyance: I have dark theme enabled, but when I launch Thunderbird, it first displays as bright white before quickly switching to black.


OK, as an exercise, I updated one of my other machines and followed the list of changes I made (see above) to make sure it was complete. I adjusted or added some edits to that list, so check them out if you’re interested.


That wouldn’t surprise me at all - particularly as at V1.0 of a rewrite. Achieving compatibility with a former look may be something that is only arrived at over time i.e. incrementally over the next 3 years.

I still look forward to

an adaptable and extremely customizable user interface

Within limits that should keep everybody happy - but it is an objective over 3 years.

In principle, this is a good thing i.e. Thunderbird will still work on the desktop/laptop but it will work better than it currently does on a touchscreen tablet and better than it currently does on a smartphone. (They also observe that they want to make Thunderbird fully compatible with current accessibility technology, which was probably not such a requirement, or even a possibility, back in the stone age when Thunderbird started.)

I’m pretty confident that Rome won’t be built in a day. :wink:

I’m not disagreeing with that claim but where specifically did they say that?

It is perhaps implied by “extremely customizable”.


I probably gleaned that from a separate blog post of theirs; in the comments, Jason Evangelho replied to a commenter’s concerns (“…I hope it can be made to look as much like the current version as possible…”) with this:

Jason Evangelho wrote on July 13, 2023 at 18:08

You’ll be relieved to know that 115 still mostly defaults to the layout and presentation you’re used to from version 102. It takes a few toggles and changes to get the “Supernova” look. And we did this because we understand some of our users have been used to that general paradigm for the last 20 years.

We also have no plans to retire the “legacy” views, although the defaults may change in the future.

EDIT: Fixed the link, which was not for the blog post I mentioned.


Two classical “Mail User Agents” (MUAs) to compare feature- and license-wise would be Sylpheed or Claws Mail.


Thunderbird Januay 2024 update: Thunderbird Monthly Development Digest: January 2024

Thunderbird 2024 roadmap: Roadmap - Thunderbird

Thunderbird for Android 2024 roadmap: Android Roadmap - Thunderbird

1 Like

Using Claws mail myself, I also convinced my wife to switch from Thunderbird to Claws.
She is very pleased with it.


Any highlights for us? :wink:

1 Like

Implementing Rust.
(Is that good or bad?)

Thunderbird for Android and K9 Mail (which is based on Thunderbird code) will co-exist. :+1:

1 Like

Search for “phosh” produced no results. :frowning:

A very good thing, I would say.
Rust, like Go is a memory safe language (unlike C, java) An enormous progress - so many bugs due to memory unsafe programming languages like C (which the entire Linux ecosystem is built on)
It remains to be seen what they mean by “implementing”? Which part of TB would be rusted? Obviously not the entire code - this would be herculean work. And the problem here, is that if you have some part of the Rust code that depends on any C library - well, nothing is memory safe anymore…


At the risk of starting a my-programming-language-is-better-than-yours war :wink: … to the best of my knowledge, Java is memory safe. (There is no “free” at all in Java - so there are no use-after-free errors, no double-free errors - and all memory is type safe - and all array accesses are checked … . So large classes of programming errors are simply not possible, as compared with languages like C.)

If you look more at the report it seems like what they mean is: They have changed Thunderbird so that Rust code can be integrated within Thunderbird and they did that in order to have safe support for Microsoft Exchange-related protocols. But I don’t really know the details (and Exchange support is not needed by me).


Java is memory safe. U.S. and International Partners Issue Recommendations to Secure Software Products Through Memory Safety > National Security Agency/Central Security Service > Press Release View

Recommended memory safe programming languages mentioned in the CSI include C#, Go, Java, Python, Rust, and Swift.

For details about these recommendations see https://media.defense.gov/2023/Dec/06/2003352724/-1/-1/0/THE-CASE-FOR-MEMORY-SAFE-ROADMAPS-TLP-CLEAR.PDF

Also, I should note that Kotlin (a Java alternative that is used by many/most Android devs) is also memory-safe. Here is the cloc decomposition for K9-Mail / Thunderbird-android from GitHub - thunderbird/thunderbird-android: K-9 Mail – Open Source Email App for Android . You’ll note that in terms of actual code (Kotlin and Java), the project is written in memory safe languages.

Language                     files          blank        comment           code
Kotlin                        1472          18752           3038         102035
XML                            830           1639           3913          67019
Java                           346           9939           6903          44367
SVG                             72             27             46           6541
Gradle                          66            331             18           1609
YAML                            23            187             77           1541
JSON                            23              0              0            948
Markdown                        24            264              0            674
TOML                             1              4             13            256
Bourne Shell                     7             66            136            204
DOS Batch                        1             21              2             69
ProGuard                         2             19             29             35
SUM:                          2867          31249          14175         225298
1 Like

My understanding is that if you want to write an app to run under Android then it must be memory safe because it must fall under an even broader kind of safety i.e. that it respects the restraints of its environment and cannot escape from the environment - which would be much harder to enforce if the programming language is not memory safe. (It is the same under iOS but the approved or encouraged programming languages are, I think, different ones.)

1 Like

Maybe. Certainly Java and/or Kotlin are preferred. That said, applications are allowed to have native C/C++ libraries … which weakens/defeats the memory-safe advantages (Add C and C++ code to your project  |  Android Studio  |  Android Developers). I think the main aspect of application safety in regard to memory is enforced by the OS ( https://source.android.com/docs/security/features ) — each app is run under a unique UID and is effectively isolated with resource availability managed via SELinux MACs …


My bad here, I guess!
Some intox from Tamago unikernels on USB Armory devices, which I love and use for different security purposes. I picked up from these guys that Go was memory safe and java, C# and Python were not. But I didn’t check those assertions…

…of absolutely no use to me, Thanks God!


Here is the comparison list I was mentioning earlier, pseudo-Wirecutter-style:


  • English
  • Free tier without third-party invitation requirements and/or a trial period
  • No advertisements
  • No email address and/or phone number requirements for signup and/or service usage



I’m using Posteo and I’m very pleased with them.
You can even pay in cash, if that’s what you are looking for.

1 Like

I made the list into a wiki post, so others may choose to maintain it if they want to. Past this point, I am likely to self-host my own email server in spite of its various challenges, but I will strive to reduce its maintenance as much as possible while prioritizing security and privacy.