Backstory:

GnuPG is a program, not a library, and attempts to use it as one involve parsing its stdout (e.g. using GPGME)

Thunderbird renders untrusted HTML content and therefore is subject to a steady stream of CVEs and must stay absolutely up-to-date with Gecko

Gecko scaled back XUL and extension support, and WebExtensions are not sufficient to allow an Enigmail extension to run an installed binary.

> WebExtensions are not sufficient to allow an Enigmail extension to run an installed binary

I don't know about the situation in thunderbird, but in firefox this isn't entirely true. It is possible to communicate with a native executable using a JSON protocol over IPC, if that native executable is registered using a manifest file (See https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...). so it would be possible to use a wrapper executable that communicates with the extension using native messaging, and invokes gpg as needed. However, as I understand it, the native executable would need to be installed out-of-band (meaning it isn't part of the extension bundle itself).

Instead of trying to reimplement GPG, they could have added the necessary APIs to WebExtensions.

Not directly related, but maybe Thunderbird shouldn't use Gecko to render emails. A smaller renderer with limited features may be sufficient and more secure.

Or... disable any JS runtime in a webview/iframe for the message. I get using an HTML rendering engine, I don't get ever enabling JS.

Worst offense was when Outlook (and Express) used the IE rendering engine with JS in "local" (unrestricted) trust mode. Melissa/ILoveYou etc...

That's about the bare minimum. Does any modern client not do that? But I think an HTML renderer that doesn't even have support for Javascript, audio and video tags, perhaps parts of CSS, etc. has a smaller attack surface.

Automatic playing of audio or video, and no eval support in css would also be a good idea.

> Thunderbird renders untrusted HTML content and therefore is subject to a steady stream of CVEs and must stay absolutely up-to-date with Gecko

Thunderbird will prompt the user to decide whether they want to render remote content. I'm not sure if that's the default setting, but that's how it's worked for me for many years over multiple installations.

That's just for images. There could still be exploits in the HTML itself executing locally.

Is this the case if you have Thunderbird set to view message body as plain text?

Which version of HTML is used for email? No javascript for instance right? Possible to make a reduced parser for which it is easier to verify correctness?

Thunderbird renders HTML using the same rendering engine as Firefox, although the email doesn't use the HTML5 doctype (so it's quirks mode), and several features are disabled (e.g., JS, frames).

There's been a couple of working groups that have attempted to standardize HTML support in email, but they don't get very far on account of having almost no representation from anyone who actually works on email clients (on account of most of the interest being email marketers who want to complain about HTML support).

The actual support for HTML is probably these days mostly HTML5 (in terms of the actual parsing algorithm), with several elements unsupported, and the CSS support being very spotty. Many MUAs are using whitelists of elements to support (don't expect <video> to make it through, and especially not <iframe>), and scrubbing CSS themselves with whitelists. In effect, this means that virtually everything added in HTML5 probably won't work, so the support is more akin to HTML4 in that regard. Infamously, Outlook uses the same HTML rendering engine as Word, which is (was?) based on the IE 5.5 rendering engine.

There is no standard HTML version for email, the same way there is no standard HTML version for a website. The contents can reasonably be anything.

Follow up question: What parts of html do you need implement to render 99% of emails decently accurately?

For a very long time, the limit was Outlook on Windows, which used the Word 2003 parser. So, whatever was supported by Word 2003.

But, more recently, mail campaigns have instead targeted Gmail, so "whatever Gmail renders" (this is not everything a browser renders, but is close). It's not feasible to implement a subset for this and do parallel CVE fixes.

Unfortunately Outlook has a pretty big market share in corporate world and if you're serious about your emails, you still have to support it.

It's worse than IE6. And to help your sanity, use mjml.

Or just don't send weird shit in emails.

Email html rendering is a giant pile of steaming dino dung. No matter how you implement it, you will absolutely break emails.

Thunderbird has simplified html viewer, no css etc, works pretty well.

Right, but then Thunderbird regularly prompts you to update to 78.x, and I’ve almost clicked ok several times already. I assume there’s probably a setting one can toggle in the config editor to turn off the prompt, but there should really be an option in the UI.

When this type of stuff starts happening, I take it as a sign that the software has reached "critical mass", is now in a runaway cycle of increasing abuse of its users, and migrate away as quickly as possible.

Thunderbird, years ago for me.

If a human acts abusive towards me, it is logical to end the relationship, even if it is years old.

I am a tolerant person, so once or twice I may accept excuses and justifications, but after that, it's time to distance myself.

I don't see why it should be any different from software. If I feel like I am dependent on it and "can't" move away, all the more reason to prioritize finding alternatives.

It is irrelevant whether the causes are incompetence, malice, or "accidental", the result is all the same, and I cannot allow it.

There is still, somehow, nothing I've found that's better than Thunderbird for an open source desktop GUI email client. Little choice but to allow it for many users like myself.

Worse still - even many of the proprietary ones now rely on 3rd party servers for "cloud" features, or are bloated and ugly electron apps.

KMail is pretty great IME.

Sounds like a pretty reasonable personal choice to me, I don’t know why you’re being downvoted without any explanatory comments.

There's not much in the email clients landscape; almost nothing in Linux, actually. I suppose that this is because nowadays almost all the users read email from web clients.

For me TB just works (especially because I'm locked at the ESR version, 68), however, I've never been extremly happy of it.

"I know I shouldn't stay with them, but they are a good person, and even if they beat me, I just don't know if there are any better options out there."

No offense intended, that's what your comment sounds like.

If you start looking, I bet you will find some options.

There is a variety of desktop mail clients, but the vast majority (of cross platform _and_ open source) is small-ish unkown-ish programs. The plugin system is in my opionion important (like for browsers) functionality, so popularity of a client is a significant factor, in order to have plugins available.

Evolution is possibly the only valid competitor, however, it's not cross-platform as Thunderbird.

I did start looking, and I didn’t find anything’ better. It seems most of the people who cared about local mail clients moved to either:

- online services, which are way worse Re: auto-updates, they do not even ask.

- mail clients with limited HTML support, which are not usable with many online stores I want to use.

Which mail client are you using?