Closed Bug 1730383 Opened 3 years ago Closed 2 years ago

TB 78.14.0 and TB 91.1.0 does not recognize OpenPGP-encrypted messages or cannot decrypt them


(MailNews Core :: Security: OpenPGP, defect)



(Not tracked)



(Reporter: norbert.adam, Unassigned)



(1 file)

Attached file Encrypted Email.eml

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0

Steps to reproduce:

Frequently received an encrypted message that was encrypted by the encryption provider "Totemo".

Actual results:

OpenPGP sign not given in the header field of the preview window. No text in the preview window, Two attachments: 1. "Encrypted part of the message.eml", 2. "Sender_name.asc"

Expected results:

Message should be recognized as OpenPGP message, corresponding sign ("OpenPGP") should be shown in the header of the preview window and also message text should be shon in preview window.

Component: Security → Security: OpenPGP
Product: Thunderbird → MailNews Core
Summary: TB 78.14.0 and TB 91.1.0 (64 bit) does not recognize OpenPGP-encrypted messages or cannot decrypt them → TB 78.14.0 and TB 91.1.0 does not recognize OpenPGP-encrypted messages or cannot decrypt them

Previous versions of TB + Enigmail were able to recognize that kind of OpenPGP messages, decrypt it correctly and show the content of the message.

The attached .eml-file is an example of a problematic OpenPGP encrypted message that show the problems, if one tries to open it in TB 78 or 91.
So, an insider should be probably able to see what of the totemo-created code causes the problems, when analyzing and comparing it to code created by TB.

By the way, when I use my K-9 email-client on my android mobile phone it is able to recognize and decrypt the totemo created OpenPGP messages, like the one I attached in the example file, correctly.

Notice: From the OpenPGP point of view encrypted message and key have correct structure, so issue should be elsewhere, like MIME headers or so on.

Good to know, but what does this mean to receivers of such a totemo mail? Will you ore someone else within TB work on this problem?

I work on RNP library, not TB, so just re-checked whether OpenPGP data from the message is correctly parsed by RNP. I think TB developers will get to this report soon.

Closed: 2 years ago
Flags: needinfo?(kaie)
Resolution: --- → FIXED
Resolution: FIXED → ---

Thunderbird will only decrypt a message if the outermost MIME layer is the encryption layer.

This limitation was introduced as one aspect of mitigating the attack vectors described in the EFAIL vulnerability reports, see

The attached message doesn't follow this requirement, and therefore Thunderbird ignores the nested encryption layer.

Flags: needinfo?(kaie)

Marking as invalid, because not automatically decrypting this message is the intended behavior.

Closed: 2 years ago2 years ago
Resolution: --- → INVALID

As a result, you should at least give the receiver of such a message the chance to decrypt it on its own responsibility. If for example the sender is known by the receiver, just simply not decrypting it is not a good option.

Can you open the attachment to view the decrypted message?

No. The attachment has always only the size of a 174 bytes, whereas the original attachment can have 1.539 KB for example. The attachment is in the form of an .eml file. The name of the file ist "Verschlüsselter Teil der Nachricht.eml". The "ü" in "Verschlüsselt" is replaced by a romb with a question mark in it.

What I can do is:

  1. Open the source of the message.
  2. Copy the decrypted message between --- BEGIN PGP MESSAGE --- and --- END PGP MESSAGE --- including the delimiters
  3. Decrypt the message for the example with Cleopatra.
    That works, but that should be done by Thunderbird.

So what? Will someone implement a "decrypt on your own responsibility" solution, because not all clients have implemented the same standard, especially the standard thunderbird has.

Let's track the request to "decrypt nested part" in bug 1746579.

You need to log in before you can comment on or make changes to this bug.