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 | ||
| Duplicate | • aheinecke | T6005 Problem decrypting inline images came up again | ||
| Duplicate | • 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.
Comment Actions
Would it be a workaround idea to double the attachments, so that the original ones would be used as reference for embedded viewing? And the other to be shown?
Comment Actions
A user also report this problem with Microsoft365 and Outlook Versions 2302 and 2208. (Exchange is the latest online-Version.)
Comment Actions
Well maybe we can do this for the small usual "social media" icons that people tend to add in their signatures. But for larger files it would make it even worse that we hit the limitation of Outlook Mail sizes. The problem with touching this issue is that I am rather a slight annoyance 90% of the time, not showing the embedded images in signatures, instead of disastrously hide a real attachment, which for the user feels like "Data loss". But yes it might be time to put this issue back on the Agenda since I know that a lot of customers dislike it and I was always proud that we supported multipart/related encrypted mails.
Comment Actions
I have fixed this as a7349189f3af05822eba4bd17b62482fa2b0747f so I am closing this as a duplicate of T5982 because it is clear to me now that the last remaining and current problem was sending and not receiving such mails and was broken by 9f81ed6561c5f41e50d1a51333c9586a33ed2ef6