Might there be a relation to T7842? But I would have thought that then all signed messages would be unaffected.

Marcus suggestion: offer the HTML mail content as attachment.

Not a good idea. Because then the user will open it with the browser and the browser loads all kind of additional data including drive-by malware. If HTML *mail* is shown by a MUA no links should be followed to keep information and the fact that it was read confidential.

I would suggest to show the HTML in raw form. This way the user notice that there is something. Maybe with a header explaining that for security reasons HTML are not rendered.

Der HTML Body wird als text/plain Anhang angehängt wobei alle <> durch {} ersetzt werden.

Name des Anhangs "HTML_email_content.txt".
Der Anhang erhält am Anfang die Zeile:

HTML Attachment as Text for security all <,> were replaced with {,}.

Ok, I think, my tests above might be not valid, as new mails behave differently.
Some comment about what is to be expected would be nice, the last comment T7843: GpgOL: Empty OpenPGP mails with "Read as plain" activated is probably outdated.

The current state seems to be:

• When a new mail is opened for the first time, the GpgOL Decrypted plain text attachment is displayed
  
• When reopened, the plaintext converted content is displayed nicely in the normal mail body (the same way as for smime mails)
  

@mmontkowski Is this expected?

I assume, it's due to the difference in the mail structure (as displayed in outlook web):

• GpgOL Decrypted plain text always displayed (old mail):

• GpgOL Decrypted plain text not displayed (new mail; plaintext displayed in body instead, which is way better than the formerly proposed fix):

New issue for a partially unresponsive interface on mails with many/big mail attachments: T8356: GpgOL: Outlook might end up in an unresponsive state in read only mode for old mails