Office 2016 is used as e-mail client and GpgOL 2.3.3. is installed. Two e-mail accounts were set up, from different provider. In the first installed account, GpgOL 2.3.3 works fine. The second account does not recognize a PGP signature. The signature can be found as attachment, but no signature verfication happens in Office.
Description
Description
Details
Details
- Version
- 2.3.3
Related Objects
Related Objects
Event Timeline
Comment Actions
Are you sure that it is related to accounts and not to the mail? E.g. if you copy that mail from the second account to the first account, is it verified then?
GpgOL is pretty Account agnostic and I have about 10 accounts in my main Outlook 2016 development environment. The only thing I can think of is that mabye the second account is online IMAP or has some read / write permission differences.
Comment Actions
I am quite sure! Because, (1) I opened both mails on another computer were Thunderbird is installed. Both signatures can be verified on both accounts with Thunderbird. Both mails were sent out with PGP signature by HPI Identity Leak Checker Team, so the signature generally works fine. (2) If I save the key which is as asc file in the attachment (in the account which does not work) on computer and perform then a check of the signature, I receive a input / output error in Kleopatra. I will make some screenshots, and I´ll send it by mail to you.
Comment Actions
Screenshots were sent by e-mail to you. Thunderbird and Outlook screenshots are different.
Comment Actions
Did you get the screenshots from Thunderbird (works fine in both accounts) and Outlook (failure in one account)? If not, please provide e-mail address.
Comment Actions
Hi,
yes I got the screenshot but they sadly did not tell me much. I don't have a good idea right now why it does not work for that one account.
Maybe a debug log could shed more light on this. If you would enable debugging in the GpgOL (ideally with data debugging enabled) and send me a log opening the mail that is not verified it might help.
Thanks,
Andre
Comment Actions
According to the log GpgOL is not notified by Outlook that a mail is read. So it does nothing.
Are you sure that there is nothing special about this account ? No addin that is only enabled for this account e.g.? How is this account configured? Is it IMAP? Exchange? Something else, like Google App sync or so?
Comment Actions
This account is IMAP, nothing special, I´ll send a screenshot from the add-ins by e-mail.
Comment Actions
Ah! I see it now. I've looked at the screenshots again and noticed that Enigmail writes for the posteo message. "Part of the messaage is signed" and shows it as encrypted, while for t-online it is the full message that is signed and not encrypted.
In outlook the mail to posteo has the small lock icon in the upper right corner indicating that this is an encrypted S/MIME mail.
Is it possible that you have enabled inbound S/MIME encryption in posteo? ( https://posteo.de/en/help/how-do-i-activate-inbound-encryption-with-my-public-pgp-key )
That would fully explain it as GpgOL does not support PGP mails wrapped in S/MIME encryption.
Comment Actions
On think should be mentioned. Both accounts are IMAP, but the Posteo account has one particular feature. All inbound traffic from their server to my client (receiving e-mails) is encrypted with my own public S/MIME certificate (they call it "Eingangsverschlüsselung") so all non-encrypted e-mail will be treated between Posteo server and my client as S/MIME end-to -end encrypted e-mails. This is not the case with the t-online account (there it is just TLS encrypted). However, I believe a PGP signature verification should happen after S/MIME decryption on the client.
Comment Actions
@JW-D Sorry but that is a Wontfix. We had a similar task: T4115
The reasons we won't handle PGP inside of S/MIME:
- GpgOL only shows a single crypto state for a Mail. E.g. We don't support partially signed messages or stuff like a PGP Inline message inside of a PGP/MIME message, which would basically be the same as this here.
- It is much more simple and so less error prone then a full mime parser.
- This makes us robust against a large number of attacks on the mime parsing and display.
- It is also due to the limitiations we have creating "non fakable" GUI elements inside Outlook.
- When S/MIME is handled by Outlook itself we would also have to parse the output of Outlooks S/MIME handling. I'm not even sure that this is fully possible.
You could also infinetly wrap S/MIME inside of OpenPGP inside of S/MIME inside of OpenPGP etc. ;-) That is very hard to display and handle securely.