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).
Wed, Mar 25
Fri, Mar 20
Done in master
Tue, Mar 17
Sat, Mar 14
I think that this chnage is useful enough to be backported to 2.2. Done that.
Fri, Mar 13
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.
Wed, Mar 11
This is now implemented
Tue, Mar 10
@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.
Mon, Mar 9
Hi @aheinecke, thanks for thinking about this, and thanks for tagging me here too. I'm definitely interested.
Mar 4 2020
Feb 27 2020
For the split OpenPGP / SMIME it's not intended to only work for BCC, its just the same mechanism I use internally.
Feb 26 2020
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.
Feb 6 2020
Feb 5 2020
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.
Feb 4 2020
Jan 31 2020
Jan 30 2020
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.
Jan 28 2020
Jan 27 2020
Jan 17 2020
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/
Jan 16 2020
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.
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.
Jan 14 2020
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.
Jan 13 2020
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.
Jan 12 2020
Jan 10 2020
Jan 8 2020
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:
Dec 30 2019
Dec 26 2019
Dec 24 2019
Dec 20 2019
This is fixed now.
Dec 19 2019
Dec 18 2019
Dec 17 2019
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.
Dec 16 2019
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.
We now have a decent error message for this.