Page MenuHome GnuPG
Create Task
Maniphest T5493

Attachment1.pgp not offered for saving in an email from Symantec Encryption Desktop (PGP)
Closed, WontfixPublic
Actions

Description

Some attachments are not shown in GpgOL and thus cannot be saved on disc.

A user reports that encrypted emails from several senders
from Symantec Desktop (version unknown) have two attachments,
but only one is shown. The result is that image data from and HTML mail is missing.

Email arrive via Exchange and are looked at from Outlook 2013.

Here is some debugging output showing that there are two attachments:

==============
20:40:21/3484/mapihelp.cpp:mapi_create_attach_table: message has 3 attachments
20:40:21/3484/DBG_OOM/mapihelp.cpp:mapi_create_attach_table:2595 AddRef on 00000243ae6f4be8
20:40:21/3484/DBG_OOM/mapihelp.cpp:mapi_create_attach_table:2595 AddRef on 00000243ae6f4e68
20:40:21/3484/DBG_OOM/mapihelp.cpp:mapi_create_attach_table:2595 AddRef on 00000243ae6f4fa8
20:40:21/3484/mapihelp.cpp:mapi_create_attach_table: attachment info:
20:40:21/3484/ 529093 mt=0 fname=`Attachment1.pgp' ct=`image/png' ct_parms=`(null)' method:1
20:40:21/3484/ 529125 mt=0 fname=`PGPexch.htm.pgp' ct=`(null)' ct_parms=`(null)' method:1
20:40:21/3484/ 531173 mt=4 fname=`GpgOL_original_OpenPGP_message.txt' ct=`(null)' ct_parms=`(null)' method:1
==============

With a different email client (transport SMTP) I could see both attachments, could decrypt them and once replacing the embedded Windows link in the HTML file
src="cid:image001.png@01D7624C.32C3FAA0"
with
src="./Attachment1"
I can see the HTML with the image.

Problem seen with Gpg4win 3.1.16 and 3.1.14.

For completeness: Symantec can be configured to use the recommended standard OpenPGP/MIME which is the real solution for this problem, because opening additional attachments, especially with potentially active contents like HTML maybe a security risk.

On the other hand, it is important that GpgOL offers all attachments that there are on the message. And some senders are external and cannot be influcenced.

Details

External Link
https://wald.intevation.org/forum/forum.php?thread_id=2331&forum_id=21&group_id=11
Version
2.5.0

Event Timeline

bernhard created this task.Jun 17 2021, 3:41 PM
bernhard updated the task description. (Show Details)Jun 17 2021, 3:45 PM
• aheinecke closed this task as Wontfix.Jan 10 2022, 9:30 AM

I am tending towards wontfix. The reason is here that the sender attempts to send HTML with inline pgp. Which is not supported. Then that HTML apparently tries to be mutlipart/related which is not supported for inline PGP. Then it would require us to correct a wrongly sent content type of the inline attachment so that outlook does not interpret it as a png. And in that Format it could even be that Attachment1.pgp is not encrypted but instead png data, as the content type indicates.

What happens here is that after decryption the mail looks to outlook like an html mail that references a png, so the attachment itself is hidden by outlook as it thinks it is displaying the png. But instead it cannot interpret the Attachment1.pgp.

This is unsupported in so many ways and clearly wrong that I do not want to complicate the code and risk regressions for proper mails by trying to handle this. It is better that a reciever asks the sender to encrypt the attachment as a file and send it this way.