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.

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.

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 https://efail.de/

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

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

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.