1931550 - Optionally allow viewing remote content in encrypted emails, after showing approriate warnings to the user

Status: NEW

(MailNews Core :: Security: OpenPGP, enhancement)

Description

[u764152]

Attachment: xx.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36

Steps to reproduce:

As of version 128.4.3esr, it is no longer possible to display external content in emails if they are encrypted.

The “Options” button is no longer available there and exceptions can therefore no longer be added.

Addresses that are already allowed also no longer work and no images or similar are downloaded.

Actual results:

No external content can be displayed at all. Whether in exception or not.

Expected results:

After downgrading to 128.4.2esr, everything works as usual again.

Every encrypted mail has the “Options” button again to add it to the exceptions. Every address in these exceptions works again and external content is displayed.

Comment 1

[Magnus Melin [:mkmelin]]

This is per design - it's not safe. Changed in bug 1925929. See CVE-2024-11159.

Comment 2

[u764152]

And when will this workaround be properly corrected?

It can't be that I can no longer see any external mail content, not even if I explicitly allow it!

Thunderbird would therefore be useless for people who use inbound encryption!

Comment 3

[u764152]

Oh, so the thread has now been closed...

So does this really mean that I have to look for new mail software after all these years?
Such a “feature” is a disaster!

Anyone who automatically encrypts their incoming mails can no longer use Thunderbird.

Very stupid decision!

Comment 4

[Magnus Melin [:mkmelin]]

Sorry but it's essentially not possible to have encrypted emails with remote content that would not risk leaking plain text to an attacker.

Comment 5

[u764152]

That may be true, but that's exactly what the exceptions were intended for...
Anyone who puts addresses in exceptions is taking this risk, if you want to call it a risk. That's enough to ensure that mails from third parties do not display any external content.
Only mails from exceptions would have the risk. And of course spoofing, but there is always a residual risk with everything in the universe.

I use inbound encryption with PGP inline. This means that 100% of incoming mails are stored in encrypted form.
For a few days now, I have not been able to see 100% of these mails properly.

I am now testing the eM Client, which a few years ago only had PGP and no inline PGP, now it has both and has been working quite well for 5 minutes.

Comment 6

[Kai Engert [:KaiE:]]

Magnus is right that it's by design.
It has been working like that for S/MIME messages for years, and I hadn't seen complaints about that behavior in the past.

Nevertheless, even if the new behavior for OpenPGP is the safe default, I can understand that some users might want to override.
We could consider to allow it with proper warning.
I think we can reopen this bug to investigate what we could offer.

In the meantime, here is a manual workaround that you could use, if you aren't worried about exposing details from the message.
If you aren't, you probably don't worry about having an unencrypted copy on your computer.

I haven't tried, but I think you could use th feature to create a decrypted copy.

Create a folder "decrypted" in your local folders.
Go to the message you want to allow.
Right click it, select "Organize", then "Create decrypted copy in", and select your "decrypted" local folder.
Afterwards, go to that folder, select the message.
Because it is no longer encrypted, Thunderbird should offer you to optionally view the remote content.

Comment 7

[Ed]

See also https://new.reddit.com/r/Thunderbird/comments/1gtn3oo/remote_content_with_openpgp_on_thunderbird/.

Comment 8

[secunis]

Hello,

I would like to express my concerns about the recent decision to completely block remote content in encrypted emails (starting with Thunderbird 128.4.3esr), without providing users the option to manually allow it.

Previously, Thunderbird handled this in a balanced way: remote content was blocked by default, but users could explicitly allow it for trusted senders. This functionality was essential for many, especially those relying on PGP-encrypted emails. The removal of this feature has introduced significant usability challenges without delivering a proportional security benefit.

Why this is problematic:

1. Encryption integrity remains intact:
   Remote content does not compromise the encryption itself if implemented securely. Risks are limited to metadata such as IP addresses or tracking content—known weaknesses that were already sufficiently addressed by the previous blocking policy. Moreover, there is no evidence suggesting that remote content would compromise the encrypted email contents. In this case, the security concerns might be overstated.
2. Users lose control:
   Removing the ability to make an informed decision takes away user agency. This feels like overreach, disregarding the fact that many users are willing to accept certain risks in exceptional cases.
3. Impractical decision:
   Many companies and services—including large providers—use external content such as logos or images in emails, even in security-critical notifications like password resets. Completely blocking such content makes Thunderbird impractical in many real-world scenarios.
4. The proposed workaround is cumbersome:
   Users are advised to create a decrypted copy of the email and move it to a local folder to view external content. This approach is neither intuitive nor user-friendly, contradicting the fundamental idea that Thunderbird should be a practical and easy-to-use email client.

Privacy should support usability:
Thunderbird stands for privacy and data protection. For this very reason, Thunderbird should not hinder users who highly value privacy and actively use PGP encryption. The current decision restricts and discourages these users instead of empowering them. This course of action is more likely to alienate existing users than to attract new ones.

Access to the original bug:
It would also be helpful to gain access to the original bug report to better understand the exact risks. This would allow for a more informed assessment of whether this measure is genuinely necessary or if alternative solutions are viable.

Suggestion:
I kindly request that this decision be reconsidered and an option introduced to allow users to consciously enable remote content in encrypted emails—ideally with a clear warning. Such functionality would strike a balance between security and usability while meeting the needs of the user base.

Thank you for your work and for considering this feedback.

Comment 9

[Magnus Melin [:mkmelin]]

I think you misunderstood: this isn't about bundling other privacy concerns. Remote content compromises the actual encryption itself: with remote content in the message the plaintext can be compromised. This is from Efail (we had only fixed it for S/MIME earlier, in bug 1411592)

Comment 10

[secunis]

Thank you for clarifying!

I understand the concern regarding potential vulnerabilities like Efail. From my understanding, however, the Efail attack primarily exploited issues with how email clients processed encrypted messages, particularly when handling mixed-content scenarios. A properly implemented PGP system should avoid such pitfalls.

This raises the question: isn’t this more about ensuring secure implementation rather than removing functionality entirely? Remote content itself doesn’t compromise the encryption algorithm (e.g., PGP), as the plaintext remains protected until decrypted by the client. The risk lies in how the client processes the message after decryption.

A few considerations:

• If remote content is handled securely (e.g., through sandboxing or blocking external scripts), the encrypted content remains protected.
• Risks like metadata exposure or tracking pixels are well-understood and were already mitigated effectively by Thunderbird’s previous default blocking policy.

By completely removing the user’s ability to manually allow remote content, Thunderbird restricts functionality for informed users who rely on it, without necessarily addressing the core issue. Wouldn’t it be more effective to implement additional safeguards for handling decrypted messages, rather than blanket restrictions?

I would appreciate further clarification on how this specific change better addresses Efail-related risks compared to the existing mitigation measures.

Comment 11

[Kai Engert [:KaiE:]]

Should we consider to allow users to "load anyway", I think we should:

• Treat the override separate from other override configurations. If the user generally allows remote content, I'd require a manual override for each individual message anyway.
• Even if the user has allowed general overrides for a specific server, I'd not automatically use that override for encrypted messages.
• The warning should clearly say that allowing the viewing/loading of remote content might leak the contents of the encrypted email to the Internet

In other words, every encrypted message would always require a manual click to confirm the remote content warning.
Would that be acceptable usability and sufficient protection?

Comment 12

[Kai Engert [:KaiE:]]

There isn't really interesting information in bug 1925929, I've opened it.

Comment 13

[secunis]

Thank you for the explanation and the suggestions.

I would like to emphasize that the vulnerabilities highlighted by EFAIL are certainly serious and should not be underestimated. However, they primarily affect the implementation in email clients and not the fundamental encryption mechanisms of PGP or S/MIME. This distinction is essential when considering the removal of functionality in Thunderbird.

Key Points from EFAIL:
1. CBC/CFB Gadget Attack:
This attack exploits vulnerabilities in the specifications of PGP and S/MIME by manipulating encrypted data to create exfiltration channels. Modern OpenPGP implementations with Modification Detection Codes (MDC) can effectively prevent such attacks—provided clients handle invalid MDCs correctly and do not display manipulated plaintext.

2. Direct Exfiltration:
This attack relies on insecure processing of MIME and HTML content in email clients, where separate parts of the message are combined in ways that expose plaintext. While this is a serious vulnerability, it is an implementation issue. It could be addressed through stricter MIME validation and secure handling of active HTML content.

3. Existing Mitigations:
The EFAIL documentation recommends disabling HTML rendering or using sandboxed environments for decryption. Thunderbird’s previous approach—blocking external content by default but allowing users to manually enable it for trusted senders—was already a good compromise to mitigate these risks.

On the Proposed Changes:
The idea of requiring a manual click with a clear warning for encrypted emails sounds like a reasonable compromise between security and usability. I agree that:

• Every encrypted message should require manual confirmation, regardless of global or server-specific overrides.
• The warning should clearly and explicitly state that loading external content could result in a potential leak of plaintext to the internet.
• This approach would allow users to make informed decisions while maintaining high-security standards.

Suggestions for Alternative Security Measures:
If this approach is pursued, it could be enhanced with additional measures, such as:

• Stricter MIME validation and more secure processing of HTML content.
• Sandboxing of external content to isolate potential attacks.
• An option to allow external content only temporarily or for a single session, without saving permanent exceptions.

Why the Previous Solution Was Optimal:
I would still like to emphasize that Thunderbird’s previous solution—with the ability to manually allow external content or configure general exceptions in the settings—was ideal for many users. It offered security through default blocking without unnecessarily limiting usability.

Thunderbird should continue to stand for privacy and security while also giving users the flexibility to make informed decisions. Completely removing this functionality may otherwise lead many users to seek alternatives.

Comment 14

[Magnus Melin [:mkmelin]]

(In reply to secunis from comment #13)

I would like to emphasize that the vulnerabilities highlighted by EFAIL are certainly serious and should not be underestimated. However, they primarily affect the implementation in email clients and not the fundamental encryption mechanisms of PGP or S/MIME.

Blocking is almost the only thing a client can do. The mechanism essentially breaks when loading remote content. See bug 1419417 as well.

Comment 15

[secunis]

I understand that blocking remote content is currently seen as one of the most effective measures to mitigate the risks described in EFAIL. However, I firmly believe that Thunderbird’s approach prior to version 128.4.3 struck the right balance between security and usability.

Before version 128.4.3, Thunderbird offered the following essential features, which I believe should absolutely be retained:

Default blocking of remote content: This already provided a high level of protection against tracking and potential security risks.
Manual approval option: Users could consciously decide whether to load remote content for a specific message.
Exception lists: It was possible to whitelist trusted senders, which is critical for many experienced users.

These features allowed users to make informed decisions while maintaining security for all emails. The removal of these options in the current implementation significantly restricts usability, particularly for users who rely on PGP in their workflows.

Regarding EFAIL:
The EFAIL issue demonstrates that the vulnerabilities primarily stem from insecure implementations in email clients, not the encryption itself. Thunderbird’s previous approach had already effectively mitigated these risks:

CBC/CFB Gadget Attacks: These can be reliably prevented with correctly implemented Modification Detection Codes (MDC).
Direct Exfiltration: This risk could be addressed through stricter MIME validation and secure processing of HTML content, without compromising usability.

Proposal:
Rather than completely removing the functionality, Thunderbird should retain the proven options from previous versions and enhance them with additional safeguards, such as:

Stricter MIME and HTML validation to minimize exfiltration risks.
Sandboxing remote content to securely isolate potential attack vectors.
Clear warnings to communicate risks to users, enabling them to make informed decisions.

The previous options—default blocking, manual approval, and exception lists—are already a well-balanced solution. They should not be removed but complemented with appropriate security mechanisms to maintain usability and flexibility.

Thank you for allowing this discussion. I hope this perspective will be taken into consideration for future developments.

Comment 16

[Magnus Melin [:mkmelin]]

(In reply to secunis from comment #15)

The EFAIL issue demonstrates that the vulnerabilities primarily stem from insecure implementations in email clients, not the encryption itself. Thunderbird’s previous approach had already effectively mitigated these risks:

For the decryption oracle exploit, there's really not much more than blocking that the client can do to keep the content safe.

I don't think the previous remote content blocking (for general privacy) was enough. For anyone not familiar with the details above, it's very unexpected that loading remote could reveal the encrypted content. So to allow override loading anyway would need its own warning etc.

Comment 17

[secunis]

I understand that the current implementation aims to minimize the risks posed by exploits such as the Decryption Oracle Exploit and EFAIL. However, I believe that Thunderbird's previous approach—prior to version 128.4.3—already struck a good balance between security and usability.

Why the Previous Approach Was Better:

**Default Blocking: ** Thunderbird already blocked remote content by default, ensuring a high level of security. This was the right foundation.
Manual Approval: Users could consciously decide whether and for which specific messages remote content should be loaded. This flexibility was essential for many experienced users who regularly use PGP in their workflows.
Dropdown Menu Options: The ability to load content for a single session or permanently for trusted senders proved to be extremely practical in real-world scenarios.
Settings Option: Under "Privacy & Security," users could decide—prior to version 128.4.3—whether to generally allow or block remote content. This feature was user-friendly and allowed users to tailor their security preferences to their needs (see attached screenshot). This functionality should not be removed, as it provided security and flexibility for many users.

Problems with the Current Implementation:
As shown in the attached screenshots, the complete blocking of remote content results in highly distorted and unreadable emails. This is particularly problematic for business emails, which typically include external content such as logos or interactive elements. In 90% of cases, these types of emails contain such content, and the current behavior significantly reduces usability.

Additional Perspectives:

The current implementation not only removes the ability to consciously approve remote content but also introduces a substantial loss of flexibility for all users. There are numerous alternatives that could ensure higher security without sacrificing usability. These include:

Detailed Warnings: Instead of removing the functionality entirely, a clearly worded warning could highlight the potential risks, such as:
"Loading external content may expose you to tracking or data leaks. Do you still want to proceed?"

Enhanced Protective Measures: Security precautions could be complemented with stricter MIME validations or sandbox mechanisms to further reduce potential attack vectors.

Retaining Previous Options: Thunderbird could continue blocking remote content by default while retaining the well-established manual override options available prior to version 128.4.3.

Technically Sound Solutions: Instead of completely removing the ability to approve remote content, Thunderbird could implement a combination of better technical implementation, stricter standards, and clearer warnings. These approaches demonstrate that eliminating the manual approval feature is neither the only nor the best solution.

Focus on Usability:
Business users and individuals who frequently handle encrypted emails may migrate to alternatives like eM Client or Betterbird due to these restrictions. Thunderbird should not create the impression that security must always come at the expense of usability—especially when practical alternatives exist.

Conclusion:
From my perspective, Thunderbird’s previous approach was optimal, as it balanced security and flexibility equally. The complete removal of the manual approval feature represents a significant step backward in usability without providing a proportionate increase in security. A clear warning and additional protective measures could further enhance security without stripping experienced users of their control over their messages.

Comment 18

[secunis]

Attachment: xxx

Comment 19

[secunis]

Attachment: xxxx

Comment 20

[secunis]

Is Blocking Remote Content the Only Solution to Address EFAIL?
After analyzing the EFAIL website and its contents, including technical details and graphics, it is clear that blocking remote content is not the only possible measure to mitigate the vulnerabilities described in EFAIL. Alternative approaches exist that can provide effective security without significantly compromising usability.

Why Blocking Alone Is Not Necessarily Essential
The vulnerabilities outlined in EFAIL, such as the Decryption Oracle Exploit and Direct Exfiltration, primarily rely on:

Manipulated Messages: Attackers modify encrypted messages (MIME or HTML) to exfiltrate plaintext through external channels.
Weaknesses in Processing: The issues stem from insecure implementations in email clients, not from the encryption algorithms themselves (PGP/S/MIME).

Therefore, the focus should be on making email clients more robust against such attacks, rather than removing user control altogether.

Alternative Measures to Mitigate EFAIL Risks

Stricter MIME Validation:

A more rigorous check of MIME structures could prevent manipulated messages from being processed correctly.
For instance, email clients could ensure that separate MIME parts cannot be combined in ways that expose plaintext.

Secure HTML Processing:

Rendering HTML content should occur in an isolated sandbox environment.
External content could be loaded in a controlled environment to ensure that plaintext data is not embedded in URLs (as seen in direct exfiltration).

Modification Detection Codes (MDC):

Modern OpenPGP implementations use MDC to detect tampering with encrypted text. Thunderbird could strictly validate MDCs and warn users when manipulations are detected.

Detailed Warnings for Users:

Instead of fully blocking content, Thunderbird could display clear warnings such as: “Loading external content might cause tracking or data leaks. The message could be manipulated. Do you still want to proceed?”
Such warnings would empower users to make informed decisions without concealing security risks.

Isolated Decryption:

Plaintext could be decrypted in a separate environment where external content remains disabled until explicitly allowed by the user.

Temporary Allowance Options:

External content could be allowed temporarily for a single session without saving permanent exceptions.

Why Full Blocking Is Problematic

Completely blocking remote content does not address the root causes of the EFAIL vulnerabilities but rather reduces their symptoms. If an email client is securely implemented, the described attacks can be mitigated through the following steps:

Rejecting the processing of manipulated messages.
Proper implementation of security protocols like MDC.
Minimizing attack vectors through validation and isolation.

Full blocking, however, severely impacts usability, especially for users who regularly work with encrypted emails. As demonstrated on the EFAIL website, the primary focus is on technical weaknesses in implementation, not fundamental principles like the display of remote content.

Conclusion

Completely blocking remote content in Thunderbird is not the only solution and may be seen as an overreaction to the EFAIL issue. Instead, targeted improvements in implementation, such as those described above, would be a more effective way to ensure both security and usability. Thunderbird could retain its previous approach – default blocking with manual overrides – while enhancing it with additional security mechanisms, ensuring users retain control without compromising safety.

Comment 21

[u764152]

If it is important that technically inexperienced users are better protected, how about an add-on?

Without an add-on you can no longer load external content with PGP and with an add-on (must be installed with several clicks) external loading works.

Comment 22

[survivor.swinger969]

I'm a Flatpak Thunderbird user who was unaware that the "show remote content" feature was dependent on not using encrypted emails. It would be helpful if there were in-app explanations of why this feature is dangerous with a link to a webpage with more info on just why this is an issue because I don't quite understand it despite using other encrypted messaging tools already. I'd also like to have the option for temporarily and permanently making exceptions again for trusted third-parties.

Comment 24

[secunis]

I have tested various versions of Thunderbird to investigate the issue with external content in encrypted emails:

115.6.2: No issues; everything works as expected. However, an update to 128.4.4 introduces problems.
128.4.4: The problem with external content persists.
133.0b5: The issue with external content remains unresolved.
132.0.0: Works flawlessly, but updating to 132.0.1 causes the same problem.

This clearly shows that the change was deliberately introduced and not due to a general security deficiency in older versions. It emphasizes my opinion that strictly blocking external content and removing the manual approval option is not the optimal solution. Earlier versions demonstrate that security and usability can coexist without imposing such severe limitations on users.

Comment 25

[Magnus Melin [:mkmelin]]

Older versions were simply insecure. Hence the security fix.

Comment 26

[secunis]

Once again!

EFAIL highlights vulnerabilities in how email clients process encrypted messages, not in the encryption technology itself (e.g., PGP or S/MIME). The encryption algorithms remain secure and intact as long as the message is not decrypted. The issues arise due to manipulated encrypted messages and insecure implementations in email clients.

How Does an EFAIL Attack Work?

1. Manipulated Message:
An attacker intercepts an encrypted email, modifies it, and injects malicious elements, such as HTML tags that reference external content (e.g., images or URLs).
2. Decryption by the Client:
The email client decrypts the manipulated content and combines it with other parts of the message—potentially triggering the loading of external content.
3. Exfiltration of Plaintext:
The decrypted plaintext is leaked through external references (e.g., URLs) embedded in the message. This occurs because the client processes and combines the manipulated components without sufficient validation or safeguards.

Why Full Blocking of External Content Is Not Optimal

1. Root Problem Remains:
Blocking external content addresses a symptom, not the root cause.
The real issue lies in the insecure handling of manipulated messages by the client.
A secure client should detect and block such manipulations before decrypting the message or loading external content.
Modern PGP implementations include safeguards like Modification Detection Codes (MDC) to ensure that messages haven’t been tampered with.
2. Unnecessary Usability Restrictions:
Completely blocking external content and removing manual override options penalizes all users—even those who understand the risks and follow secure workflows.
3. Alternative, More Effective Measures:

Stricter Validation: Email clients should validate MIME structures and HTML content to detect and prevent manipulations.
Isolated Rendering: External content rendering (e.g., HTML) should occur in a sandbox, ensuring plaintext is never unintentionally combined with external communications.
Warnings and Temporary Approvals: Instead of removing functionality, the client could provide detailed warnings about potential risks and allow users to temporarily approve external content when needed.

Conclusion: The Solution Lies in Implementation, Not Restriction
EFAIL makes it clear that the root of the problem is not external content loading but insecure email client implementations. The full blocking of external content, as introduced in Thunderbird 128.4.3, addresses a symptom but results in unnecessary restrictions and significantly reduces user flexibility.

The focus should be on** robust implementation** that detects and prevents manipulations while maintaining user options for approving external content. This could be complemented with additional safeguards like sandboxing and clear warnings.

Final Note
I am an IT-Security Specialist and Analyst, and if this explanation doesn’t clarify the issue, I truly don’t know what else could make it clearer. EFAIL is not a justification for removing user control entirely—it’s a call for smarter, more secure implementations.

Comment 27

[Magnus Melin [:mkmelin]]

Please read up on the full context before commenting - especially bug 1419417. The only way I know of to make it secure for remote content, is to block.

(That said, yes we could re-allow unblocking, with new appropriate explanations where the user would allow allow that third parties may then be able to see the plain text of the message.)

Comment 28

[secunis]

Thunderbird should promote both privacy and user-friendliness, not just through a blanket blocking of external content, but with smart solutions that combine security and flexibility. A rigid "one-size-fits-all" blocking approach contradicts the philosophy of a user-centric email client and unnecessarily restricts experienced users. There needs to be a balance between protective mechanisms and deliberate user control.

Thunderbird is widely regarded as a trusted email client, particularly due to its support for PGP-encrypted mailboxes. Users who highly value security and encryption rely on these functionalities. However, with the current strategy of indiscriminately blocking external content, Thunderbird is shooting itself in the foot. It risks alienating the very users who depend on a secure yet user-friendly handling of PGP-encrypted messages.

It seems as though the developers are adhering to a very conservative approach, favoring blocking as a "one-size-fits-all" solution. This stance appears to stem from viewing security in isolation, without adequately considering the broader impact on usability and user adoption.

Comment 29

[secunis]

Thunderbird should promote both privacy and user-friendliness, not just through a blanket blocking of external content, but with smart solutions that combine security and flexibility. A rigid "one-size-fits-all" blocking approach contradicts the philosophy of a user-centric email client and unnecessarily restricts experienced users. There needs to be a balance between protective mechanisms and deliberate user control.

Thunderbird is widely regarded as a trusted email client, particularly due to its support for PGP-encrypted mailboxes. Users who highly value security and encryption rely on these functionalities. However, with the current strategy of indiscriminately blocking external content, Thunderbird is shooting itself in the foot. It risks alienating the very users who depend on a secure yet user-friendly handling of PGP-encrypted messages.

It seems as though the developers are adhering to a very conservative approach, favoring blocking as a "one-size-fits-all" solution. This stance appears to stem from viewing security in isolation, without adequately considering the broader impact on usability and user adoption.

Before making such drastic decisions, it would be prudent to thoroughly read and understand what true security entails in conjunction with efficiency. Security should not come at the cost of usability, but rather work in harmony to provide a seamless and safe experience for all users.

Comment 30

[Magnus Melin [:mkmelin]]

If you read the linked bugs, you'd understand that this isn't about privacy, but about not leaking the actual plaintext.

Comment 31

[secunis]

The risks associated with EFAIL attacks primarily arise from:

**Insecure combination of MIME parts: **When encrypted and unencrypted parts of a message are not sufficiently isolated, attackers can exploit these structural vulnerabilities by manipulating the MIME structure.

**CSS leaking: **If an unencrypted part contains CSS that is applied to the encrypted part, confidential content could be manipulated or concealed, potentially leading to unintentional disclosure.

The core issues, therefore, lie in the internal processing and the lack of separation between message elements. While external content may play a role in exfiltration, the primary focus should be on internal vulnerabilities rather than solely on blocking external content.

Instead of providing clear, comprehensible explanations or solutions, much remains vague and inadequately communicated. I am offering well-founded solutions, demonstrating how MIME isolation and the prevention of CSS leaking can address the real dangers at their root—without an unnecessary focus on external content, which only distracts from the actual problem.

Comment 32

[Magnus Melin [:mkmelin]]

That is besides the point as we cannot isolate the parts in such a way. Ideally we could, but we can't. It's a large long term project to do so.

Comment 33

[u764152]

Is there still discussion here? Ok lol let's be honest, this is about a basic function that is now gone. Security or not, a basic function(!) is no longer available.

It's a sad thing about Thunderbird as I've been a user from the very beginning. But I will never give in to such socialist commands.
Just like the “vaccination” of which I don't have a single one in me!!!

Force is a no-go.

Only socialists want to educate people according to their own ideas. I'm so sick of it!

Comment 34

[:glob ✱]

(In reply to Shadow from comment #33)

This is a polite reminder that Bugzilla is our professional working environment as well as our issue tracker. I encourage you to review our Community Participation and Bugzilla Etiquette guidelines; comments that help move issues towards a resolution are always welcome. Comments that add nothing more than demands that a resolution occur, however, are not.

Comment 35

[Magnus Melin [:mkmelin]]

Just to re-iterate: yes I think will fix this bug to allow viewing after appropriate warning - but that's not by backing out the fix.

Comment 36

[secunis]

I am curious to see when and how the implementation will take place—or how it has been implemented. Fortunately, there are alternatives available nowadays.

Comment 37

[Eddy]

(In reply to Shadow from comment #33)

Is there still discussion here? Ok lol let's be honest, this is about a basic function that is now gone. Security or not, a basic function(!) is no longer available.

It's a sad thing about Thunderbird as I've been a user from the very beginning. But I will never give in to such socialist commands.
Just like the “vaccination” of which I don't have a single one in me!!!

Force is a no-go.

Only socialists want to educate people according to their own ideas. I'm so sick of it!

As much as I can understand your problem and have the same problem and annoyance, but you definitely need professional help regarding your paranoia of an ominous socialist-bolshevik-communist... world conspiracy. Hm, somehow that reminds me of something.
By the way: In a socialist world, such companies as Alphabet, Amazon, Microsoft, Meta, etc. with such immense power and planned obsoloscence would not exist.
But what am I telling the politically uneducated, who are springing up like mushrooms these days.
I wish you good health and that you always have enough money for it.

And about the problem itself: Even if I deactivate GPG, I cannot view external content.

Comment 38

[u764152]

(In reply to Eddy from comment #37)

(In reply to Shadow from comment #33)

Is there still discussion here? Ok lol let's be honest, this is about a basic function that is now gone. Security or not, a basic function(!) is no longer available.

It's a sad thing about Thunderbird as I've been a user from the very beginning. But I will never give in to such socialist commands.
Just like the “vaccination” of which I don't have a single one in me!!!

Force is a no-go.

Only socialists want to educate people according to their own ideas. I'm so sick of it!

As much as I can understand your problem and have the same problem and annoyance, but you definitely need professional help regarding your paranoia of an ominous socialist-bolshevik-communist... world conspiracy.
Fuck yourself

By the way: In a socialist world, such companies as Alphabet, Amazon, Microsoft, Meta, etc. with such immense power and planned obsoloscence would not exist.
You simply don't understand anything about politics. Amazon and its kind are involved themselves... They are part of the whole thing.

Comment 39

[Magnus Melin [:mkmelin]]

Bugzilla isn't the place for political discussions or disputes - and the topic obviously has absolute zero to do with this bug. Read https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

Comment 40

[secunis]

As I have mentioned before, Thunderbird demonstrates a fundamental issue in handling vulnerabilities: instead of addressing the root causes – such as the insecure combination of MIME parts and the risks posed by CSS leaking – it merely blocks external content. This does not solve the problem but only circumvents it superficially, leaving the internal weaknesses unaddressed.

In addition, there is a lack of clear communication: rather than explaining to users in a direct and understandable way what steps are being taken or what solutions are in progress, references are often made to other bugs or technical details. This neither creates transparency nor fosters trust, especially considering the responsibility that a client like Thunderbird carries.

Instead of simple blocking, real solutions are needed, such as the separation of MIME parts and the prevention of CSS leaking. Only then can the actual security risks be addressed in the long term – rather than resorting to measures that merely treat the symptoms.

That’s why I’m curious to see when and how the implementation will take place – or how it has already been implemented. Fortunately, there are plenty of alternatives available today.

Comment 41

[betterbird.project+18]

(In reply to Magnus Melin [:mkmelin] from comment #32)

That is besides the point as we cannot isolate the parts in such a way. Ideally we could, but we can't. It's a large long term project to do so.

Seems like this has been on the cards since 1999, going by bug 1297653 comment 44. Maybe it's time to start thinking about it since not sandboxing MIME parts has security implications. Bug 1151366 was also a mayor overhaul.

Comment 43

[DaFluff]

I'm afraid that this is one of these bug tickets that remain open for years.

Therefore, I would like to remind everyone that there are different reasons/use cases for using encrypted emails. Not everyone needs to defend against EFAIL attacks, as this attack is often not worth the effort (there is almost no value if you can read any of my order confirmation emails or registration confirmations). I'm much more concerned about email tracking and data leakage from my email provider. Therefore, I encrypt every email in my mailbox.

The current solution doesn't work for users like me because we can't read newsletters anymore, order confirmation emails look awkward, and basically any other email that is sent by any company is difficult to read. This change made Thunderbird very uncomfortable to use for users like me. You're essentially forcing us to disable the encryption of our inbox. (The workaround is to store emails decrypted, which, theoretically, opens new security concerns/threads.)

I'm really hoping that this issue can be resolved soon in a way that works for everyone. I understand the risk of EFAIL and want to be able to make the decision myself for every email - just like it was in the past! Newsletters don't need such a level of security.

Thank you for your kind understanding.

Comment 44

[Freedom]

Betterbird has fixed this bug introduced by Thunderbird developers:

https://github.com/Betterbird/thunderbird-patches/issues/376

Very unfortunate users are forced to switch because the upstream developers don't care.

Comment 45

[Eddy]

Betterbird didn't really do it satisfactorily either.
This is because you always have to give permission separately for each new email.
This means that you have to confirm each new email from the same sender again.

Certainly better than Mozilla's obsessive, preachy behavior with Thunderbird, but not really good either.

Comment 46

[Simon Friedberger [:simonf]]

For the use cases by DaFluff (encrypting mails himself) and Eddy (trusting senders) it is necessary to have an option "always allow this key" and "always allow this sender". Just in case we want to have this kind of granularity.

Comment 48

[DaFluff]

(In reply to Simon Friedberger (:simonf) from comment #46)

For the use cases by DaFluff (encrypting mails himself) and Eddy (trusting senders) it is necessary to have an option "always allow this key" and "always allow this sender". Just in case we want to have this kind of granularity.

Since I was mentioned: I would not use "always allow this key", because in my case, I would then also unlock spam and fishing mails, which I don't want to. The options we had before were perfect for my use case (trust sender, domain(s), or only this email).

I would appreciate it if we could at least have a temporary fix (like the one from comment #11). Thunderbird feels broken to me and users like myself without a solution. Plus, it adds another hurdle for Thunderbird users to start using encrypted emails.

Thanks for reading.

Comment 51

[steffen.hoyer]

I completely understand the focus on security. Really! This was the reason I switched to a paid email provider that offers the option of server-side encrypting incoming emails with my PGP key. This keeps my emails secure, even when stored on my provider's servers. Great!
I'm a tech-savvy user, otherwise I wouldn't have started using PGP in the first place. But as a long-time Thunderbird user, I'm outraged.
How is it possible that, even after years of studying computer science, I'm not able to display my internet provider's invoices properly in Thunderbird?

Until this problem is resolved, I have only three options:

• I'll go back to using MS Outlook (and accept tracking, but hope my PiHole filters it out)
• I'll disable PGP (which isn't a great option considering the original goal of increased security and privacy)
• I'll have to install an outdated version of Thunderbird and disable automatic updates (Is this really intended? I highly doubt it)

Therefore, my urgent request: Please allow technically savvy users to once again have control over their own data and settings and do not treat us like immature children. Give us an option to enable the reloading of external content again, even if this only applies temporarily for a single email.
The constant bug reports linked here clearly show that users expect a different behavior from their Thunderbird client.

Comment 52

[Seth]

(In reply to steffen.hoyer from comment #51)

…
even if this only applies temporarily for a single email.
…

A workaround for the issue that satisfies this had already been provided by Kai Engert [:KaiE:]. We have a similar setup (my mail provider automatically encrypts emails as it arrives or as I save them), so I can vouch the following works in these circumstances.

1. Right-click the email you want remote content for.
2. Hover over Organize.
3. Hover over Create Decrypted Copy In….
4. Select a mailbox that will not automatically encrypt the email. (I personally choose Local Folders → Trash.)
5. Read the email. 🎉

Note: If you wish to forward an email with remote content intact, you will also need to do the steps above, then forward the email via the decrypted copy you created. Otherwise, remote content won't be accessible to recipients you forward to either.

Comment 53

[Kai Engert [:KaiE:]]

We should investigate whether the theory in bug 1994709 is correct.
(Iff it's correct, we could undo the change that caused this behavior.)

Comment 54

[DaFluff]

Just made my annual donation to Thunderbird and wanted to send belated birthday wishes to this bug. 🎂 Especially after noticing that Thunderbird's own thank-you email contains external images that won't load after decryption – and there's no "view online" link either (which becomes more common in general).

I know, encrypted email is still a niche, but it would be wonderful if this could be squeezed onto the radar sometime soon. I can barely remember what pretty emails look like... 🫣

Happy holidays and a great new year to the whole team! 🎄