Hi @hs,
given that you have used the instructions from the link above to look at the message,
I'll take it that you are using an IMAP/SMTP setup for mail transportation?

A signed but not encrypted message appears in the same way (visible in Sent, empty in Inbox)

Thanx for your immediate reply -- highly appreciated :)

Kleopatra's debug output can be seen with DebugView https://docs.microsoft.com/en-us/sysinternals/downloads/debugview

It's a bit stange, following szenario (I have just tested it):

Looking at the messages from above using another PC, same Windows 7 and Outlook 2010 but Gpg4Win 2.3.3 :

• received message in Inbox is decrypted shown correctly inline both in preview and opening it
• original message in Sent is not decrypted, but shown as encrypted with gpgolXXX.dat attachment

Hence, it shows the opposite behavior to the 3.0.2 handling.

I can't reproduce this with Kleopatra 3.0.1 from Gpg4win 3.0.2. It just works as expected. Both if I encrypt the files as an archive or if I encrypt them seperately.

You start Windows Explorer (the file manager thingy)

I feel dumb for asking this, but I'm a Mac guy, and my client is on Windows 10. How do I exactly "move away the data directory"?

One problem seems to be that the content of Inbox message differs from this one in the Sent folder (10 vs. 20 KB).
The content of the Inbox is shown as empty, even using the "show source" option. Saving the message as plain text shows a PGP part inside, but this is ignored by Outlook.
I tried this advice:
How to view the message source in Outlook
But the result is the same, after maked as read, the message becomes unreadable.

I could somewhat reproduce this problem when I disconnected the connection to Exchange from my Outlook and then tried to respond to an exchange mail. Although for me Outlook did not Hang and an error message (with a General Error) showed up.

• fresh install of Gpg4Win 3.0.2
• reboot
• openening Outlook 2010 with only one plugin (GpgOL)
• sending an encrypted email to myself
• trying to open that email (no content)

Thanks for the report and the log.
I see the problem. In your case of a reply outlook does not give us the SMTP address for the recipient but an Exchange DN

@aheinecke Because it was mentioned in another comment, I've tried to restart Outlook with the GpgOl plugin enabled, only. Same result. But the fact that I could see the message just after arrival, but not in a second approach may point in a direction that incoming messages are processed by an server-based filter changing potentially vulnerable email content (as embedded links).
I could try to log the complete process of sending an email to myself, decrypting once and failing in a second trail. This would actually increase the size of the log file.

@hs Your log is interesting but I don't yet understand it. We see a "Load" event for an encrypted mail, create our internal data modelling. But later there is a mismatch between the reference Outlook gives us and our internal reference (Failed to find mail in map).
Out of the blue there might be something I could do in that case but it's still somewhat unclear to me why this state occurs.

Just installed Gpg4Win 3.0.2.
Had a very similar effect with Windows 7 / Outlook 2010:

• Sending an encrypted e-mail to myself.
• E-mail will be decypted once after receiving.
• After that, e-mail is shown as "unsecure" and with empty message body (both in preview and own window).
• E-mail in "Sent" folder still decryptable with right content.

I've added gpgol.log for opening Outlook again after receiving the e-mail (with empy body, now).

Debian has this with migrate-pubring-from-classic-gpg ( https://sources.debian.org/src/gnupg2/2.2.3-1/debian/migrate-pubring-from-classic-gpg/ )

Please reopen or comment if that problem still happens if you move away the gnupg home directory.

This goes to wontfix I investigated and there is no way to attach a file trough the mailto protocol with outlook. Only the parameters from https://msdn.microsoft.com/en-us/library/aa767737.aspx are supported.
Theoretically Kleopatra "could" use MAPI to achieve creating a mail with attachment but this would be overkill. Kleopatra puts up a big warning that attaching may not have worked and ok.

Well the problem is both TCP and UDP. Somehow dirmngr tries to open a listening socket. I think that may be some feature probing in the DNS resolver. Because if the Firewall access is denied I don't see any feature loss.

This is very likely dirmngr's DNS resolver which uses UDP by default. Fixies: a) use Tor. b) We add an option to use only TCP queries.

Correct, this was also the case before, sorry for the misunderstanding.

The HTML in the body below the text on the GpgOL-1.4 side is a known issue of GpgOL-1.x we only added proper HTML handling with GpgOL 2.
GpgOL before 2.0 just appended the text/html mime part to the text/plain mimepart in multipart/alternative mails.

PS: And I can confirm that I have a lot of HTML Garbage in my mail body (on the receiver plain text side):

I can confirm that it works for me, too: Fantastic, thanks!

no i have not any software that interfieres.

Strange, do you have any unusual Group Policies or some "Security Software" that might interfere with the running of GPA / Kleopatra (they open a local socket).

In my tests it's fixed with: b8276a4f3acecee2e467c0530007aedc9db5936a the plain text body now uses similar code to the html part. Makes sense anyway. The difference was mostly historic as GpgOL before 2.0 did not handle HTML parts at all.

If I send "Nur Text" (plaintext only) under formatting it works as expected. We query Outlook for the Body from the MAPI Data model and just get the wrong value returned. For the HTML part we use the Outlook Object Model (as we had a similar problem there that the MAPI data was not updated properly.)
The fix is obvious. We can use similar code to our handling of the HTML body. This is a workaround for an Outlook bug IMO, why should sending from drafts differ from the usual sending *sigh*

Wow, fast reaction! I'm happy to help evaluate a possible fix for this.

I can reproduce that problem and have opened T3614 for this.

Hi, first of all I want to report back that with beta15 that the following issues did NOT arise anymore, fantastic!

gpa not starting as well

This is the question:

Forgot to mention the revision. It's https://commits.kde.org/kleopatra/0428c744fbd56a305d3e249215d74fe6ad811acf

I implemented a text export action that uses the details of a certificate as comments. This will bring back the old copy & paste able details and has the additional advantage of a nice and quick export.

I only installed 3.0.2 this morning so this hasn't had much of a chance to happen.

I checked the mingw runtime and did not found any allocation of a new console. Thus I don't understand why a console pops up when gpgconf is used. gpgconf spawns gpg et. al to read its options and it does this without using DETACHED_PROCESS. Thus all these subprocesses inherit the parents console - which is for gpgme started process no console (due to DETACHED_PROCESS used in gpgme_w32spwn). For a GUI application like Kleopatra which has no console, the use use DETACHED_PROCESS sould not make a difference because there is no console to inherit. Andre's test however show that it makes a difference.

Does this still happen with gpg4win-3.0.2?

This works now. There is a problem still if the agent is not running with the default homedir or under other users. But this is handled in T2146

This works now. There is a problem still if the agent is not running with the default homedir or under other users. But this is handled in T2146

@werner This is sometimes still an issue. E.g. if the agent is started with a different homedir. Is it ok to just use TerminateProcess on any gpg-agent?

The assuan_pipe_connect function is called with bit 7 set for example to start pinentry or scdaemon:

I'm changing this issue to resolved as I opened T3601 and T3602 for the problems mentioned in this issue. As it is better to have them separated.

I thought about (2) when implementing the new "decrypt" action in Kleopatra but we did not give it high priority as we were unsure if this is a real world problem.

*cough* That change made it into Gpg4win 3.0.2 *cough*

The option now has the following logic:

• If encrypted is selected and the message is not signed.

and

• If the message has no attachments.

and

• If the option for inline sending is enabled

Fixed at last.

I tried to reproduce this with current GpgOL and it just worked. Even if I connected Enigmail to Exchange (Outlook.com).

With Gpg4win 3.0 we registered associations for S/MIME and OpenPGP Files:

I just tested with intevation's CA on Windows and it works. It also worked with our test.ca in the base test before the 3.0.1 release. I think this is resolved.

We now check for an error of the gnupg-w32 installation (which should not happen normally) and show a Message Box on error.

It's also fixed. There was a problem with the error handing. A canceled pinentry is communicated as an error with code operation canceled.

In T3577#107074, @aheinecke wrote:

So if the user had a "real" error it might have crashed instead of showing the error.

As a note: The second crash might be related in that the crash could happen on any error. So if the user had a "real" error it might have crashed instead of showing the error.

Indeed easily reproducible issue.

Indeed. Since Gpg4win-3.0 Gpg4win uses the "official" GnuPG-w32 installer. This installer is bundled with Gpg4win and extracted during installation into the temporary directory and executed from there. So your problem is likely that GnuPG is not installed. As GnuPG is the core component of Gpg4win this will lead to a broken setup (although the error should be detected so I'll leave this issue open for that problem.

@patoberli This looks very much like a crash I also observed on close and fixed with 1d0660fa53d357247ac84545f9259244a1d9400c the crash has nothing to do with the hang but thanks for the feedback anyway.

I finally had a crash again today, when I tried to close outlook.
I was running the debug log for several days now, until it finally crashed. Using gpg4win 3.0.1.
Here from the debug file:
*removed entries for privacy reasons*
12:28:46/19196/oomhelp.cpp:remove_category: category 'GpgOL: Verschlüsselte Nachricht' not found.
12:28:46/19196/mail.cpp:parsing_done:882: tracepoint
12:28:46/19196/mail.cpp:parsing_done:885: tracepoint
12:28:46/19196/gpgoladdin.cpp:gpgoladdin_invalidate_ui: Invalidating ribbon: 1D363A70
12:28:46/19196/mail.cpp:parsing_done:900: tracepoint
12:28:46/18768/parsecontroller.cpp:~ParseController
12:28:46/18768/mimedataprovider.cpp:~MimeDataProvider
12:28:46/18768/attachment.cpp:~Attachment
12:28:46/18768/mimedataprovider.cpp:~MimeDataProvider
***here I closed Outlook, but Outlook froze. I then killed the process in Windows.
12:34:02/19196/windowmessages.cpp:gpgol_hook: WM_CLOSE windowmessage for explorer. Closing all mails.
12:34:02/19196/mail.cpp:close_all_mails:1084: tracepoint
12:34:02/19196/returned from invoke

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\

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.

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.

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

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