We confirmed in a remote session that the Titus Data Classification plugin ( https://www.titus.com/data-classification-product-collection.php#tmc ) interfered with GpgOL.

It's done. The maintainer of the jabber server will try to automate the renewal in the future.

I sent the maintainer of the jabber server a mail.

Thank you for the test :-/
So back to the drawing board.

The changes are made as described. Could you please try:

Trying to reproduce this / staring down the log, I think I might have found the problem.

I think the reason for this is not Exchange Online but that I was using two explorer Windows and switched between Mails while the decryption on the slow exchange folder was still running. This triggered an invalidate_ui while the parsing was active and that then triggered a write / unload just like in T3523

My current idea is that if GpgOL detects that the provider supports a web key service and one of the following is true:

Does this happen to you for all mails or just some? From the GpgOLXXX.dat I can't see anything wrong.
My expectation is that something goes wrong when updating the plain text into the message viewer. Again, could you please attach the GpgOL Debug output? That might help.

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.