GpgOL interpretes some encrypted messages as unencrypted and skips decryption entirely
Open, Needs TriagePublic

Description

Some messages that are encrypted are not recognized as encrypted by GpgOL and users are not able to use GPGOL to decrypt them.
The messages in question are:
Content-type: multipart/mixed;
Content-Type: application/pgp-encrypted

In gpgol.log I can see trace:
05:18:23/4528/mapihelp.cpp:mapi_change_message_class: checking message class `IPM.Note'
05:18:23/4528/TRACE/mapihelp.cpp:change_message_class_ipm_note:1123 enter
05:18:23/4528/TRACE/mapihelp.cpp:mapi_get_message_content_type:3216 enter
05:18:23/4528/TRACE/mapihelp.cpp:mapi_get_header:534 enter
05:18:23/4528/TRACE/oomhelp.cpp:get_object_name:83 enter
05:18:23/4528/TRACE/oomhelp.cpp:get_object_name:123: return
05:18:23/4528/oomhelp.cpp:gpgol_openProperty: OpenProperty on 000001d7e4902cf8 prop 7d001e result 000001d7e49030f0
05:18:23/4528/DBG_MEM/mapihelp.cpp:mapi_get_header:564: Object: 000001d7e49030f0 released ref: 0
05:18:23/4528/TRACE/mapihelp.cpp:mapi_get_header:565: return
05:18:23/4528/TRACE/mapihelp.cpp:parse_header_data:3162 enter
05:18:23/4528/TRACE/mapihelp.cpp:parse_header_data:3203: return
05:18:23/4528/TRACE/mapihelp.cpp:mapi_get_message_content_type:3337: return
05:18:23/4528/mapihelp.cpp:change_message_class_ipm_note: content type is 'multipart/mixed'
05:18:23/4528/TRACE/mapihelp.cpp:get_msgcls_from_pgp_lines:728 enter
05:18:23/4528/TRACE/mapihelp.cpp:mapi_get_body_as_stream:575 enter
05:18:23/4528/TRACE/mapihelp.cpp:get_internetcharsetbody_tag:268 enter
05:18:23/4528/TRACE/mapihelp.cpp:get_internetcharsetbody_tag:301: return
05:18:23/4528/oomhelp.cpp:gpgol_openProperty: OpenProperty failed hr=0x8004010f MAPI_E_NOT_FOUND
05:18:23/4528/mapihelp.cpp:mapi_get_body_as_stream: OpenProperty tag=84680102 failed: hr=0x8004010f
05:18:23/4528/TRACE/oomhelp.cpp:get_object_name:83 enter
05:18:23/4528/TRACE/oomhelp.cpp:get_object_name:123: return
05:18:23/4528/oomhelp.cpp:gpgol_openProperty: OpenProperty on 000001d7e4902cf8 prop 1000001e result 000001d7e49031f0
05:18:23/4528/TRACE/mapihelp.cpp:mapi_get_body_as_stream:613: return
05:18:23/4528/DBG_MEM/mapihelp.cpp:get_msgcls_from_pgp_lines:799: Object: 000001d7e49031f0 released ref: 0
05:18:23/4528/TRACE/mapihelp.cpp:get_msgcls_from_pgp_lines:848: return
05:18:23/4528/TRACE/mapihelp.cpp:change_message_class_ipm_note:1193: return
05:18:23/4528/TRACE/mapihelp.cpp:string_to_type:1445 enter
05:18:23/4528/TRACE/mapihelp.cpp:string_to_type:1448: return
05:18:23/4528/mapihelp.cpp:mapi_change_message_class Message is not a crypto message or already in the right class.


I can send mail raw message or headers for analysis in private conversation.

Kind request for your analysis,
Best regards,
Iwona Zielinska

Details

Version
2.4.4, 2.4.5, 2.4.6, 2.4.6.beta68
iwona.zielinska changed the edit policy from "All Users" to "iwona.zielinska (Iwona Zielinska)".
werner added a subscriber: werner.Jul 2 2020, 2:06 PM

Hi,
could you please change the edit policy back to all users so that I can change the status of this task?

thanks for the report and the details. It is very clear what happens here:

05:18:23/4528/mapihelp.cpp:change_message_class_ipm_note: content type is 'multipart/mixed'

is the underlying Problem. The mail is not a top level crypto Mail but instead multipart/mixed.

Which means the MIME tree looks like

  • multipart/mixed
    • multipart/encrypted;
      • application/pgp-encrypted
      • application/octet-stream
    • some other part

Where instead it should only be:

  • multipart/encrypted;
    • application/pgp-encrypted
    • application/octet-stream

My suspicion is that some Software modifies your message in transit. For example to add an Image "Scanned by $Virus Software" to the mail. That breaks the MIME Structure and to GpgOL it no longer looks like an encrypted mail, but rather as a Mail that has an encrypted mail as an attachment and some other attachment.

A more complex MIME Parser for GpgOL that could handle this is something we would like to have but even Outlook itself does not support such a case in its built-in encryption support. And it is quite difficult to decide what to show the user in such a case. In your case the additional attachment could probably be ignored, but that might not be the case for other users and other attachments.

iwona.zielinska changed the edit policy from "iwona.zielinska (Iwona Zielinska)" to "All Users".Jul 2 2020, 2:12 PM

Thanks,
I edited the task and now you can edit it too.

I must add context to this story:
we haxe a,b,...y,z accounts. So far they were hosted on O365 exchange.
Couple of these accounts have been migrated to on-prem exchange last week. Only the accounts on-prem cannot read encrypted emails from accounts in cloud o365.
they can decrypt mails from other migrated accounts.
oh - I checked headers of archive mails - before it was always :
multipart/mixed
multipart/encrypted;
application/pgp-encrypted
and GpgOL was handling well.
Now I see only :
multipart/mixed
in header.

Best regards,
Iwona Zielinska

Dear gnupg developers.
I have contacted the Microsoft to get their analysis as well.
A Case #:20812681 has been registered. Where Microsoft stated that third party developers of plugins like GpgOL have their channels and should contact Microsoft directly in cases like this. Further analysis has been denied to me.

It is sad to see the gpg email encryption, ( probably the most secure way to exchange messages endpoint to endpoint there is to date ) to go slowly out of business because it is simply not supported by giants.
Best regards,
Iwona