Received a report about this per mail. While Encrypted mails or sent mails are ok. Received signed mails are opened with GpgOL even if the S/MIME support is disabled.
Description
Details
- Version
- 3.1.0
Revisions and Commits
rW Gpg4win | |||
rW17a1b4fa4f85 Add patch for GpgOL to fix T3935 | |||
rO GpgOL | |||
rO2426ff7d1a5d Fix content-type detection for headerless mails |
Status | Assigned | Task | ||
---|---|---|---|---|
Resolved | • aheinecke | T3935 GpgOL: S/MIME signed mails opened with GpgOL even if S/MIME is disabled | ||
Resolved | • aheinecke | T4264 Gpg4win 3.1.6 | ||
Resolved | • werner | T4289 GnuPG 2.1.12 release |
Event Timeline
Two more reports in the Gpg4win forums. Still can't reproduce it. I've asked for debug output.
I'm not sure if it's exactly the same case, but:
- S/MIME signed and encrypted message is ignored by GpgOL (which is good). Message class is: mapi_change_message_class: checking message class `IPM.Note.SMIME'
- S/MIME signed only (not encrypted) message is processed by GpgOL. Message class: mapi_change_message_class: checking message class `IPM.Note.GpgOL.MultipartSigned'
09:43:50/8848/gpgoladdin.cpp:OnConnection: this is GpgOL 2.2.0 09:43:50/8848/gpgoladdin.cpp:OnConnection: using GPGME 1.11.2-beta58 09:43:50/8848/gpgoladdin.cpp:OnConnection: in Outlook 16.0.0.10325 ... 09:43:51/8848/storing option `enableSmime' value=`0' 09:43:51/8848/storing option `encryptDefault' value=`0' 09:43:51/8848/storing option `signDefault' value=`0' 09:43:51/8848/storing option `logFile' value=`C:\Users\...\Desktop\GpgOL.log' 09:43:51/8848/storing option `gitCommit' value=`0x0' 09:43:51/8848/storing option `formsRevision' value=`335' 09:43:51/8848/storing option `announceNumber' value=`0' 09:43:51/8848/storing option `inlinePGP' value=`0' 09:43:51/8848/storing option `autoresolve' value=`0' 09:43:51/8848/storing option `replyCrypt' value=`1' 09:43:51/8848/storing option `smimeHtmlWarnShown' value=`0'
I've tried again with different Versions to rerproduce this issue and I can't reproduce it.
IPM.Note.GpgOL.MultipartSigned means that GpgOL already had looked at that mail before and modified it. Only after switching away from that mail and then looking at it again would it be handled again by Outlook. GpgOL needs a chance to "revert" it's changes to S/MIME Mails that were made when S/MIME was enabled so that Outlook handles them again.
Did you have S/MIME enabled in the past?
I have additionally the problem, that signed and encrypted S/MIMI messages are handled by GPGOL even if S/MIME support is disabled.
Steps to reproduce:
- Use Mailbox on computer A with installed S/MIME Certificates and without installed gnuPG
- Switch to computer B (with installed gnuPG but without installed User Certificate - No S/MIME support enabled in GPGOL)
- Open Outlook and connect to Mail Account
- Install User Certificate through Outlook
- GPGOL is still trying to decrypt the mails
Computer A
- Windows 7, Outlook 2016
Computer B
- Windows 2012R2, Outlook 2016, GPG4win 3.1.2
Thanks for the details. I tried to reproduce it but again for me it works. Still I give this high priority as this can be a blocker in deploying GpgOL and we should fix it for the next release.
Are you looking at the same Mailbox on both computers? E.g. are you looking at the mail in the "Sent" mail folder. Or are you sending from Computer A to a different mail account on Computer B?
Are you using an exchange connection on both computers?
Does it help if you unselect the mail and select it again?
I only have test S/MIME certificates for IMAP servers I'll get some for my outlook.com accounts which I use for exchange testing. With GpgOL sent mails from / to the outlook.com account work though. If I send to myself and disable S/MIME after sending Outlook tries to decrypt the mail in the INBOX.
I'm looking at my personal Inbox on both computers.
I received the encrypted mails, before I connected computer B with my Account
And yes, I'm using an exchange connection.
No, it does not help to unselect the mail. The error occurs with several Mails.
I'm trying to get you the logs from GPGOL.