Steps 1. and 2. are now implemented in the async-enc branch of GpgOL. The keyresolver patches are updated for me and partially commited.

I have not seen this. But I suspect that it would be fixed if our encryption no longer causes Outlook to become "unresponsive". I'm already working on this for T3509 and have a development version which already does the encryption in a way that the pinentry / key resolution are just a modal dialog over outlook and no longer block the GUI of Outlook completely.

Ah under Linux we ran into an assert which made finding the problem easy. The bug was introduced by the fix for T3602. Will be fixed in the next release. Apologies for the inconvenience.

Thanks for your report. I tried this several times. Could not reproduce it at first but I could get it to crash sometimes. Even without GpgEX just by double clicking the signature file.

1. Collect all data in OOM, then start a thread to do the encryption.
2. Do a proof of concept that this actually works and outlook lets us do it with our usual window message async handling.
3. Update my Keyresolver patches in Libkleo and build a "libkleo-tool" to do the key resolving.
4. Figure out Window Management / Create a Qt Overlay over the Mail window to block it from closing while encryption happens. This will resolve all bugs related to window mangement of the current key resolution.

In T3714#109752, @werner wrote:

I have not checked whether we make this available in the GPGME API

As far as I can see GnuPG does not emit appropriate status lines:

From your log I can see that the verification fails with "Unsupported Protocol" which is weird in itself. But at least with the fixes for T3538 (they are included already in your version) it should then show the unverified body. So this is a second problem. I tried to reproduce this for sent mails but even if deliberately break them they are displayed correctly.

Damn I thought we had all these kinds of display issues fixed now with 3.0.3. Is this really GpgOL 2.0.6? (you can take a look at the option dialog of gpgol to confirm this)

We are always looking for ways to improve the messaging but the idea here was no keep it as simple as possible.

Indeed with debug dns I can see that what takes so long is the resolve_dns_name. After the debug output prints that line the key comes nearly instant.

The fix was released with Gpg4win-3.0.3

The default Pinentry for Windows is pinentry-qt it should both be accessible with descriptions and screenreader API support and it should allow you to paste in passphrases. The passphrase length is limited at 255 characters. This limitation comes from GnuPG and is there both for Windows and Linux. Have you tested Pinentry-qt with a screenreader?

as your behavior is unusual please verify that no other Addons interfere, we are still trying to figure out if there are incompatible other addons. So please try to disable any other addons and try again.

Gpg4win-3.0.3 has been released.

No more reports of this since 3.0.2. With 3.0.3 I fixed an additional memleak which should further improve this. Resolved for now.

For the 3.0.3 I tested more with Microsoft Exchange Online, an Exchange 2012 Server and could not reproduce such problems. So I'm lowering the priority to normal as I don't think many users are affected.

Multiple confirmations -> Resolved.

With git bisect I tracked it down to a0326ffb755c4a49a259cea3d83831d9ede7d5d9

Duplicate of T3576

GpgOL should use the same language detection code that GnuPG also uses. If you open a command line (cmd) and run "gpg" in that command line is it also in german?

I've noticed that myself and the cause for this is the code which we use to ensure that the key resolution dialog of Kleopatra opens in the foreground.

Thanks again for the test, your patience and the report :-)

Ok so I found out that you could even trigger this bug without persistent options just by activating and deactivating any S/MIME option on a mail. This somehow changed the behavior of Outlook.