Hey @pkoevesdi, Gpg4win Version 3.0.1 was just released. Can you may download and install it and check if this issue still exists?

Version 3.0.1 just hitted. @madjari - may you can check if the various bugfixes in that version fixed your issue as well?

With the Release of Gpg4win 3.0.1 the Error doesn't appear anymore while testing with Windows 10 (64bit) with Outlook 2016 and Windows 7 (64bit) with Outlook 2010.

rO13950a985228 Works around this problem by launching Kleopatra in the background when Outlook is started.
This should both speed up the first operation and work around this issue. In my opinion it's better to waste some resources in the background if Kleo is not needed then to create a bad user experience if encryption does not work and results in a hang of outlook.

I could not reproduce it again on Friday. Did some code staring to find the issue but failed. Everything looks Ok.

Forgot to mention this bug in the commit addressing this. ( 278893850ed926d4646929ee97576a8d09fd4998 )

Thanks for your reports.
I can finally reproduce this on a new Test VM which I gave little resources. Most of the time it does not work. Sometimes it works. Looks like a timing issue, on my main development VM which is fairly quick it always works. I'll work on it.

I am connected via IMAP. Sometimes Outlook also crashes when I handle a message that is in a local inbox not directly associated with an account. It may be relevant that I have two IMAP accounts configured that run on different key pairs and all messages are shifted to a local inbox on arrival.

This was only for multipart/alternative HTML mails which was a fairly recent feature for GpgOL.
The encoding for html mails was handled incorrectly as it took the encoding of the text/plain part and not the text/html part. Fixed now.

Indeed. Thanks for your report I can reproduce this. Funny how this was missed through all the Beta's and pre release testing.

How are you connected to your server? I mean IMAP, or Exchange MAPI or is it a Hotmai / Outlook.com account?

I resolve this. If it is not displayed anymore it means that outlook should handle it.

Tested with Gpg4win-3.0.0-beta17 with GpgOL-2.0.2-beta8 on Windows 10 (64bit) with Outlook 2016.

I enabled the error and did the following with Gpg4win-3.0.0-beta17 with GpgOL-2.0.2-beta8 on Windows 7 (64bit) with Outlook 2010

In T3442#105339, @aheinecke wrote:

In T3442#104402, @JochenSaalfeld wrote:

1. Mails encrypted with S/MIME are stored with "No Data" in the sent EMail folder, but arrive properly at the recipients (you will recieve a readable copy, if you add yourself to the list of recipients). This Issue breaks the GpgOL Plugin after some time which is leading to the described Problem.

Fixed with 474cc15d8e331c9def298dbbfe3b99e6c8cf8035

Versions Used: Gpg4win-3.0.0-beta17 with GpgOL-2.0.2-beta8 on Windows 10 (64bit) with Outlook 2016.

@tstreibl thanks for helping with your feedback!
Please note that this issue (T3442) still has the status "testing", because we want to perform some more tests before declaring it resolved. :)

In T3442#105466, @tstreibl wrote:

Starting Outlook still bring up the "Fehler in der Benutzeroberfläche von XML von "GpgOL .....Unbekannte Office.Steuerelemente-ID: TabComposerTool" Message Box.

Sorry for my inpatience...but it's a little bit hard to understand why the above, very simple test procedure obviously isn't reproducible on your systems.

Starting Outlook still bring up the "Fehler in der Benutzeroberfläche von XML von "GpgOL .....Unbekannte Office.Steuerelemente-ID: TabComposerTool" Message Box.

tested your new .dll. Created a new email. Choosed "sign". Pasted an email adress from outlook address book into the "an" field. Outlook crashs. Took me 2 seconds to test. What the hell are you testing?

Thank you very much. Both the signed only and the encrypted mail are fully valid for me (checked on the IMAP server and with kmail) and don't contain any references to gpgolXXX.dat. This means they were correctly converted to valid PGP/MIME Mails.

Dear Andre

This means that the MAPI to MIME conversion did not happen.

Jochen could you please test this on one of our test VM's again and resolve this then?

A new binary for GpgOL can be found under: http://files.gpg4win.org/Beta/gpgol/2.0.2-beta8/ or for http://files.gpg4win.org/Beta/gpgol/2.0.2-beta8_x64/

@aheinecke Regarding closing: I'd say that we should have a test on this one and then close it for only the refocussed "send-folder problem".
Can you provide an updated gpgol.dll drop in replacement?
Some of the users in the forum may be willing to test as well.

In T3442#104402, @JochenSaalfeld wrote:

1. Mails encrypted with S/MIME are stored with "No Data" in the sent EMail folder, but arrive properly at the recipients (you will recieve a readable copy, if you add yourself to the list of recipients). This Issue breaks the GpgOL Plugin after some time which is leading to the described Problem.

Jochen can you please confirm that this works reliable for you too?

This indeed is a mixup of the protocol detection and likely a regression from a fix for exchange support. (On Exchange emails from exchange to exchange look the same as sent mails as both don't go through the MIME conversion)

This error looks like an element might be referenced that is not available in Outlook 2010. In that case the problem should be reproducible for users that have Developer Options -> Show Add-In Errors enabled.

When receiving an S/MIME mail that is encrypted, the successful log looks like:

Comparing the gpgol.log files in the case of OpenPGP decryption (successful) and S/MIME decryption in send folder (failing).

Here is the link to the wald report by John Mrkva:
https://wald.intevation.org/forum/forum.php?thread_id=1785&forum_id=21&group_id=11

Same here: I can confirm the bug. I can move an email, if i unselect it before an then use its context menu to move it.
This behaviour is already mentioned in the readme:
c:\Program Files (x86)\Gpg4win\share\gpg4win\README.en.txt

Yesterday I could reproduce that emails in the "send" folder cannot be decrypted anymore.

This week I'm trying to make progress with this issue.

Confirmed, this is the exact same problem!

I tried to melt it down to a specific beta release with which it isn't possible anymore to decrypt send emails.

Since this is a bug that is related to two different parts of the gpg4win package, this bug now only cares about the GpgOL Issue, that GpgOL crashes and cant decrypt messages from the sent folder that are encrypted with S/MIME. All File Based Issues are belonging to Kleopatra are documentet in the KDE Phabricator (https://phabricator.kde.org/T7310).

1. Mails encrypted with S/MIME are stored with "No Data" in the sent EMail folder, but arrive properly at the recipients (you will recieve a readable copy, if you add yourself to the list of recipients). This Issue breaks the GpgOL Plugin after some time which is leading to the described Problem.

2. Files that are Signed and Encrypted to a S/MIME Certificate is broken. When you select a file and encrypt and sign it to a recipient, only a detached signature will be created and the Encrpyted file is missing. (Very similar to Issue 1, but file based).

https://phabricator.kde.org/D8368

There is just another person experiencing the same problem with an Exchange based account on Win10pro x64, Outlook 2016 x86.

I don't have access to this description. I used official, newest releases. I searched for this issue on the web, on the gpg4win page but did not find a solution. Is there any accessible information?

So far we could recreate the following issues:

There are more Logfiles:

Are those mails sent by GpgOL with Outlook or recieved? Can you explain your complete Workflow and state what software was used in it?

Can you relate to the issue described in the GPG4win Forums?

You could try to use NO-MIME (or PGP/INLINE) instead of the OpenPGP/MIME standard. You can change the way of packaging your encrypted content in the GpgOL Addin Options.

Confirmed. Same behaviour and environment as described by HB1000 but with Windows 8.1 x64.
Outlook displays a message inside the mail "decrypting message..." (something like that) and then the message window is blanc as if there is no content.

Do you have any idea about this issue?
Exactly same behaviour here.
Windows 7 Enterprise 64-Bit, Outlook 2010 (Version 14.0.7188.5002, 32-Bit), GpgOL 2.0.1
Tell me if you need any diagnostic logs, ...

I'm also facing the same issue here.

Oh, God, someone please solve this problem. It is so annoying. Tried everything I could, installed and uninstalled the softwares and accomplished nothing.

i'm facing the same problem. Would love to see this problem solved

I'm also facing the same issue here.

I’m facing this issue too..

That seems to be a conflict between the two extensions. We need to look deeper into that so learn why it could go wrong and whether there is a way to work around the conflicts.

If someone could help me on how to debug on outlook, I could produce more information about this bug.

See T3441 for one additional screenshot with error codes.

The log file shows that gpgex (or explorer) crashes.

The output from gpgsm -K in the last quote is perfectly okay. -K works by iterating over all public keys and checking for each public key whether the private key part is also available. If the private key is not available gpg-agent returns an error.

This doesn't seem just to affect E-Mails but also File-Encryption.

I'm trying to find all relevant information first, then we can discuss who should work on this.

So, who is going to work on this?

I recieved the Log File of a user which may helps analyzing this problem further

I think it was a version problem.
I have now installed gpgOL (2.0.1) and gpg4win version 3
It's working.
Just that emails do not directly access "decrypt", but those that are sent from MAC arrive as an attachment, with ASC termination. I need to change the extension to PGP, decrypt, and generate a file without extension. Then I need to change the extension to EML and then I'll be fine.
Can you fix it?

I assume you installed gpg4win. Which version did you install? 3.0 is the latest.