The encryption system should be saying "BAD MESSAGE" to the client and instead it is saying "Here's the message and some malware".

I disagree. The encryption system should not know about HTML, and these messages are "BAD MESSAGE"s even if they are unencrypted. That clearly points at the mail client, not the encryption layer.

Both things are problems. The encryption system should definitely be communicating that the message was tampered with...

Well, again, the encryption system will. Or at least it can. (Apparently you can encrypt without signing? WTF use is that? But let's assume signatures are used.) The MIME structure of email is the problem here. It isn't OpenPGP's problem to solve, which we know because there is literally no way for them to solve it. No conceivable (sensible[1]) update to OpenPGP could fix the problem, so it can't be their responsibility.

[1]: I mean, yeah, they could ship something that hacks the Thunderbird process and gets the rest of the email, but that's just crazy talk. Nothing that has a sensible API that fits with what Thunderbird is doing now can solve the problem.

> Apparently you can encrypt without signing? WTF use is that?

Sending a message without identifying the author, for example.

Which can be achieved with authenticated encryption by generating a new key and deleting it afterwards

Is there a standard for this? It seems like if you tried to do it by hand, the receiver's UI would present this in a scary/confusing way. I'm imagining instead some sort of "Alan Smithee" User ID which the UI interprets as "deliberately anonymous/disavowable".

One of the attacks injects content into the encrypted messages.

It really also just shouldn't support unauthenticated encryption at all. And with authenticated encryption I mean something like chacha20-poly1305 or AES-GCM that gives you authentication on small chunks so it can give the "BAD MESSAGE" output when decrypting from a pipe.