Does it decrypt then?

This is not the first report I have gotten about mailstore problems. My suspicion here is that the mail is opened read only or somehow got the wrong properties from mailstore.

FWIW, a log of the decryption process will always show the sender's key because a message is usually also encrypted to that one (--encrypt-to).

Done in master

I think that this chnage is useful enough to be backported to 2.2. Done that.

You can test it now out using GnuPG master: Just add --include-key-block and you can then verify using an empty keyring. Currently --auto-key-retrieve is not needed but we need to think on how we can enable or disable this during verification.

This is now implemented

ftr, here is the thread I had in mind but couldn't recall above. @aheinecke is that your thinking, or a more pgp/mime bound mechanism as @dkg assumed?

@wiktor-k, "just extend the spec" doesn't necessarily work with existing clients, which might be surprised to find unexpected packets in the signature section of an e-mail. It seems more likely to me that they'd be able to handle (meaning: ignore) an unknown subpacket (as long as it's well-formed) than to handle additional packets. But all of these surmises require testing with existing clients, of course. Has anyone done any of that testing?

This is a nice idea and although it overlaps with Autocrypt it has other uses too: for example verification of signed files that can be vastly simplified (just get the file and the signature, no key fetching needed, downside: the key attached to the signature could be stale).

Ah, thanks for pointing out the subpacket option (i guess it could be hashed or unhashed). i don't think any of the subpackets currently defined in RFC4880 supports this use case -- but i guess you could mint a new one, or use a notation.

Werner said that it's possible in OpenPGP to also put the pubkey into the signature. (...) The nice advantage is that this will also work for files.

Hi @aheinecke, thanks for thinking about this, and thanks for tagging me here too. I'm definitely interested.

For the split OpenPGP / SMIME it's not intended to only work for BCC, its just the same mechanism I use internally.

I think this is a great feature to have. Thanks for working on it, @aheinecke .

The idea of the implementation is that BCC recpients will get a mail with no other recipients. Because Exchange / Outlook handles the sending we can't do it more low level. We use the "Protected-headers" scheme to transfer the original To / CC headers.

I renamed the ticket so that others don't think we generally don't support Office2019 because I use it myself and it works for me.

Thank you for the detailed report.

I remember that I tested inline content-disposition handling in Outlook without GpgOL and try to do the same handling as Outlook would handle them. But then at the very least It should be shown as an attachment and not hidden.

I've just tested this with GpgOL 2.4.6~beta3 as well, and while the i see the same issue :( (though the legacy display part is not shown, thanks to your fix of T4796).

Thanks! taking screenshots is definitely tedious. I just redid the screenshots for all the sample pgp/mime messages with GpgOL 2.4.6-beta3, and i can confirm that it looks like you've resolved the matter.

That means that the GnuPG Backend does not work. I do not think that the office update is the reason, me and others use GpgOL with the most recent versions of Office Pro Plus without issue.
Have you possibly modified you gnupg config files? If there is a bad value in there it would result in such an error.

It can force it on the outbound. https://support.symantec.com/us/en/article.tech164655.html
It also allow SIMME pass-through. https://support.symantec.com/us/en/article.tech166867.html

An updated build is available here: https://files.gpg4win.org/Beta/gpgol/2.4.6-beta3/

thanks for the fix, @aheinecke ! can you post screenshots of the changes? or do you have a nightly build i could test?

I have checked the eMail header of the eMail from Sender X in the Exchange mailbox of User A and I see Sender X is using Mozilla Thunderbird and I tested it with Thunderbird also, but it works for me.
I cannot provide all details of the eMail from Sender X because it's a customer of another customer, but I have replaced the IP addresses and other private information in the eMail header and this is the result:

thanks for the report. This is definitely a sore spot and we need to look at it again. I did some experiments a while a go trying to fix this issue but so far I was unable to get to stable results so for now this is a known issue.
I'm a bit suprised that the workaround with not having the mail open does not work for you.

Is this about any special version of Symantec? As far as I knew Symantec Endpoint Security Desktop (or whatever they call it nowadays) supports reading PGP/MIME and even sending it if forced.

This again,...
That error always occurs when the Exchange Server is unhappy with the structure of our PGP/MIME Mails. It has nothing to do with S/MIME, that is only because Exchange only knows about S/MIME, so our PGP/MIME Mails also claim to be S/MIME mails.

Display now looks good to me in all cases. We still keep the subject when a reply / forward is done, but that is the same as before. To do this properly I would have to actually do the protected headers sending,.. as then I could automatically flag such a message to be sent with protected headers. But that would be a new feature and I rather work on properly doing BCC sending as the next privacy enhancing feature.

The base64 for the version is not needed. I rebuilt and did a test for that. I was testing with Outlook 2016 to Outlook.com to another exchange server. One of the servers in the chain is converting the mime parts to base64.
The MAPI headers in gpgol are causing the auto-decryption of Symantec to stop checking for the MIME attachments. On internal emails the MAPI format is retained and that causes an issue with the symantec client. When they leave the exchange server the base MIME format is what is sent and that works with the Symantec client.

Using base64 encoding for a fixed format part in us-ascii is not a good idea because in practise many PGP/MIME decoders won't be able to detect and then decyrypt such a message.

note that it *does* sometimes hide the legacy display part, for some messages, including unfortunately-complex -- that's good! -- but maybe this points to some internal inconsistency:

This is fixed now.

Thanks for examination.
Providing an 'untouched .msg' seems to be complicate because OL receives several encrypted mails all day long, so GpgOl must be activated for common use. Additional: To avoid this issue, .txt mode has been deactivated, .html is allowed without downloading foreign items or pictures.

Thanks for the report but I cannot reproduce the issue :-/. In multipart alternative mails GpgOL takes the text part if text mode is set in Outlook.

Fixed

We now have a decent error message for this.

I think this is now resolved.

I think we can fix it by removing the smime attachment from OOM, because we still have it in MAPI, we just never cared that it was also in OOM (where only our decrypted attachments belong) because it was hidden.

Still unresolved...

I have the same effect if I send a signed text-only or HTML email using Outlook 365 and our Exchange 365 and if I view the mail on Outlook on Android. The mail shows no contents only the file. If I view the mail using Outlook 365 on my PC or Windows 10 Mail it looks fine.
If I address it also to my Microsoft account and my Gmail account (using all adresses in the TO: field of the same mail) the email looks normal in the Gmail Android app and (!) in Outlook for Android.
So the same mail - both in the same Outlook for Android app - looks correct in my Microsoft account inbox but only shows the file in my Exchange inbox - in the same Outlook App. Weird… Nokia 7 plus, Android 9, newest patch level (September 2019) and no updates in Google Play Store.
BTW: In Exchange 365 I configured the message flow, default remote domain (there is no other) to never to use Rich Text, always and only HTML.

Today a new signed message from BSI Buerger CERT was received. The PGP signature could be verified by first opening of the document. As I opened the file some hours later again, it failed, as I opened it a third time (shortly after the second time), the signature was verified. Outlook was not closed between the second and third opening. Signature verification appears unstable.

There is no reason for apologies :-). As far as I know this all is open source, freeware and you don't get paid for this, right? So, I simply also try to add my contribution by most precise error reports to help to find the error and am grateful if it will be solved one day in the future :-).