Page MenuHome GnuPG

Embedded images are seen as attachments after encrypting and decrypting
Open, NormalPublic

Description

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.

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

Event Timeline

aheinecke triaged this task as Normal priority.
aheinecke added a subscriber: aheinecke.

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.

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.

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.

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?

A user also report this problem with Microsoft365 and Outlook Versions 2302 and 2208. (Exchange is the latest online-Version.)

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?

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.