:-(

Ok here's an update.

Superb! Testing gnupg-2.2.3_171201.exe as I type, and it's already working past the time it would normally cease to respond :)

The registry key does not exist on my system, and neither does the c:\program files (x86)\GnuPG\bin directory. There is only the Share directory under c:\program files (x86)\GnuPG\

Received a test message and I understand it now. The header lines in the test mail are so large that they cannot be queried as a single property (out of memory because the max is pretty low, 4k or so) but have to be accessed through a stream interface. Many of the headers relate to Thread and In Reply To etc. so this explains why the problem only happens on reply.
I think I can quickly fix it.

A new installer with an updated libassuan is now available. To download gnupg-2.2.3_171201.exe please go to https://gnupg.org/download/ . If you had the disable-check-own-socket in your gpg-agent.conf, please remove it so that we can really see whether that version fixes the problem.

A new installer with an updated libassuan is now available. To download gnupg-2.2.3_171201.exe please go to https://gnupg.org/download/ . If you had the disable-check-own-socket in your gpg-agent.conf, please remove it so that we can really see whether that version fixes the problem.

The error is fixed with "disable-check-own-socket"
If someone is interested for next times, the log-file "gpg-agent.log" is on the path "C:\Users\<my user>\AppData\Local\VirtualStore\Program Files (x86)\Mozilla Thunderbird\".

Many improvements since dec 2016 to gpgol. Latest master is much more stable (needs a Gpg4win release)

Adding Windows again because on Unix it is unlikley that our close will block. A documented blocking behavior is only defined for STREAMS

Yeah, that looks correct. Good catch. The bug exhibits itself when gpg-agent checks its own socket. In this case gpg-agent is both, client and server, and due to our userland multi-threading we get blocked. The suspend/resume things makes the deadlock more likely. Note that we have the same problem on Unix.

Last commit of the series: https://commits.kde.org/kleopatra/c5567d6915bb0e76284281590282d942966322b0

Implemented with https://commits.kde.org/kleopatra/3ddc062f72853738904d1e25dd2d4440e348fd43

Yes please you can send it directly to mailto://aheinecke@intevation.de
If you want to encrypt it my key is 94A5C9A03C2FE5CA3B095D8E1FDF723CF462B6B1

I am very happy to hear that! Thanks.

After a week with the current version, including a registry cleanup, I had no crashes in Outlook. At the moment it seems to be running stable.

Applied.

To sum up: Outlook can't decrypt a reply, although it can decrypt a direct email from the same sender.
Another thing I just noticed: once Outlook receives the reply (the one it can't decrypt), I can no longer move emails to other folders. If I deactivate GpgOL plugin, I can move the messages again.
Can I pm you the saved message ?

Thanks everyone. I think that the problem is identified and fixed in libassuan.

Added with https://commits.kde.org/kleopatra/2b22bccfa852cd22e62d95c2270187c7f23b63cf

Better to fail loudly instead of silently breaking.

For now I've added messages to make it clear to the user that most actions won't work with G Sync.
Better to fail loudly instead of silently breaking.

Update: It was my mistake (typical beginners failure): I had to create gpg-agent.conf instead of usig gpg.conf.
Adding disable-check-own-socket resulted in the right behavior, till now:
After some time-out, GpgOL asks for password again and decrypts the content as expected.

I am using an Antergos Linux (Arch Linux).

Implemented with https://commits.kde.org/kleopatra/805f5cfafe9f464de6f6a22619a74062ae781bfd

Please do not paste such long debug messages - they are not helpful. Please try to explain the error. From what I can see from that long dump the DNS server failed.

Indeed, this was lost by switching to the new dialog. Fixed with: https://commits.kde.org/kleopatra/005a28149fcb7f318676de47aee3014fc83b3f78

I can no longer reproduce this. We had another report about this were we also tested this and it's ok with recent GpgOL 2.x versions. -> Resolved

Fixed with https://cgit.kde.org/kleopatra.git/commit/?id=59ebe7da257131757f98e77912e39b3fd14ae3af Kleopatra was too agressive in the dialogs and always tried to stay on top. This makes sense for the Certificate selection dialog in GpgOL but not for the file dialog.

Nevermind. The keylist can be accessed by activating the line action (clicking on the button)

Suppose a client which connects stopped task of server on Windows. In this situation, if the client blocks on closesocket, that is, some user space work is needed for server side for closing socket of client side, this bug can be explained.

Does not happen for current GpgOL versions and OL < 2010 support in GpgOL is no longer maintained -> resolved

Fixed / Workarounded with https://commits.kde.org/kleopatra/9bef188fd2a2b820a63e9c7ed130c0990b7f3ce5
I was unable to reproduce this on Linux so no Valgrind / GDB. Fix is not pretty but works and ultimately we want to replace that dialog anyway.

If disable-check-own-socket can stop hanging, D454: assuan_close with nPth could be related.

Mostly done

Problem was indeed that QFile::Rename does not work across partitions.

It would be very helpful if you could export ("Save As") such a mail in Outlook and attach it here / send it to me. I don't have to be able to decrypt it but I would probably be able to figure out why it's not detected as a crypto mail.

The connection is a POP3 connection. Email server is a 3rd party email service provider. I doubt is an Exchange server (I believe they run a Linux server).
Switching to a different mail and back makes no difference - no email body displayed for the encrypted email.

I have created the file "gpg-agent.conf" in the path "C:\Users\<my user>\AppData\Roaming\gnupg\" with the following content:

It's working for me now with that config file as well so far. I'll keep watching too.

I added "disable-check-own-socket" to gpg-agent.conf .
Since 8 hours no "hanging".
I will watch it furthermore...

Could confirm a similar behavior with Windows 7 and Outlook 2010 using GPG4Win 3.0.1.
Time frame for loosing the decryption ability is about one hour or more.
Setting disable-check-own-socket in gpg.conf (didn't find gpg-agent.conf) resulted in "no data" error on all
encrypted e-mails.

As the crash is fixed and awaits release I think this issue is resolved. But that does not mean that we support G Suite sync. I don't see a quick fix :-/

Priority High as we should decide for the next release in which direction we should move.

Fantastic! I have these following issues:

Thanks for the confirmation.

Hi, sorry for coming back so late due to lack of time - but good news is: With GPGol 2.0.4-beta15 decryption now also works for us, great! Now we only have to check for a Outlook 2016 stability issue...

For reference here is @mcgrof's dump in a directly readable format:

00:29:33.472844 IP 192.168.4.7.10218 > 192.168.4.1.domain: 53039+ SRV? _pgpkey-https._tcp.hkps.pool.sks-keyservers.net. (65)
00:29:33.879268 IP 192.168.4.1.domain > 192.168.4.7.10218: 53039 FormErr 0/0/0 (65)
00:29:33.880719 IP 192.168.4.7.10218 > 192.168.4.1.domain: 51133+ Type0 (Class 8448)? _pgpkey-https._tcp.hkps.pool.sks-keyservers.net. (66)
00:29:33.902115 IP 192.168.4.1.domain > 192.168.4.7.10218: 51133 FormErr 0/0/0 (65)

I tried a bit to find a Workaround. As far as I can tell Outlooks built in S/MIME Support does not even work with GSync. If anyone can send S/MIME encrypted or validly signed mails trough GSync please let me know.

If more fine-grained control is needed with suspend-to-ram, we need to write kernel driver for USB access.

In T3378#106503, @raysatiro wrote:

I assume it goes in %APPDATA%\gnupg\gpg-agent.conf.