When you encrypt an e-mail with a html-body which has embedded images, this images are seen as normal attachments after decryption on the receiver side. After an analysis of the received e-mail I could see, that all Contentid - tags of the image describing mime-parts are blank after decryption. They were filled before encryption. So it is clear that GpgOL has just deleted them.
Description
Description
Details
Details
- Version
- GpgOL 2.5.0 ; Microsoft® Outlook® für Microsoft 365 MSO (Version 2110 Build 16.0.14527.20270) 64 Bit; Windows 10 pro Version 2004
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Resolved | aheinecke | T2861 GpgOL: Problem decrypting inline image | ||
| Resolved | aheinecke | T4161 GpgOL: Attachments might be hidden in some cases | ||
| Open | aheinecke | T6005 Problem decrypting inline images came up again | ||
| Open | aheinecke | T5709 Embedded images are seen as attachments after encrypting and decrypting |
Event Timeline
Comment Actions
Yes. Sorry about that. We had multiple issues where attachments were hidden and not shown as attachments because they had a content-id but that content-id was not referenced in a way that outlook shows.
So the decision was to always show all attachments because the usability loss is less bad then accidentally hiding an attachment the user requires. We will not fully change that because we cannot be 100% sure if an attachment can be accessed when we let outlook hide it and hiding an attachment feels to users like data loss.
Still I keep this issue open because I have noticed a different issue that the references in the mail body do not work anymore and at least for the most used case of embedding images as part of a mail in the text we should improve the behavior there. We had a better handling in previous versions.
Comment Actions
As far as I understand the problem, all content-ids are lost during processing of an email.
This process happens during the signing/encryption of an email.
Would it be possible, to move the deletion of content-ids only to the decryption of a message and add an (experimental) option to not do this (standard could be the same behaviour as currently)?
That way one could send an email with a content-id (no parsing necessary, trust the mail software you're currently using to do the right thing - fingers crossed) and use the content-id on decryption. If that doesn't work, set the experimental flag (manually) to "delete content-id = yes" and decrypt the message again, to gain access to the "lost" images.
Comment Actions
Other options would be
- to display a warning if there are inline images in the email.
- an option not to automatically sign emails if they contain an inline image.
The current behaviour of sending an email and then noticing that an image is no longer displayed inline is imo improvable.