This was implemented 0d2db8b81ab24e2ab02d7ba6832cabd07b72f852 in Gpg4win-3.1.11 but does not work reliably.

Closing with Info Needed.

I'm moving this from testing to open again. Especially the deletion is an issue. I had a report that even for a sent mail Outlook.com also stores an unencrypted variant in the "Trash Bin".

Works nicely

This was released in December 2019

Thanks for the logs. I can see the crashes, but I can't make heads or tails of them. We crash in completely valid code. I really don't want to play the blame game here but to me this would be explainable if there is an issue with refcounting in the GFI plugin that would release the IMessage or ISecureMessage MAPI Object from the ItemLoad event once to many. In that case the object we work with might be deleted at random times and that would explain it.

Thought of a way to at least mitigate it. When a mail is closed we know it's not printing.

After looking at this for 4h I could not see a way to detect it better when a print job is done. So we now treat every ItemLoad of a mail after we have seen the BeforePrint event as a print.

Outlook is a bit nasty here:

could you please go into the GpgOL setting and under "Debug" turn on logging on the highest level (+code trace) and then reproduce the crash and add the log here?
Including Data should not be needed so you can keep that checkbox unchecked to avoid having mail data in the logs.
This might help us to see where and why the crash occurs.

I'm not sure what to do here. The problem is that all users in clients without PGP/MIME Support will see the attachment names. That is why we use the names as they are.

There was a similar Problem in the past reported on our mailing list:

Thank you for your work, appreciated. Sorry I was a bit under the weather in April and could not get back to you earlier.

erstmal vielen dank für das Feedback. Ich habe momentan als Aufgabe ein neues Benutzerhandbuch auf Basis des Kompendiums zu erstellen und werde da die Hinweise auch mit Aufnehmen. Technisch ist sowohl der Inhalt als auch die Art wie das Handbuch erzeugt wird nicht mehr aktuell, wir brauchen da dringend etwas neues das wir auch online stellen können.
Sollte noch in diesem Jahr passieren.

Right. GpgEX is in serious need of polishing. I'm not sure if I'm in favor of processing all files recursively. But then the decrypt option should not even be shown.

From the commit message:

Thanks, I can reproduce the problem. I'll look into it, printing mails is important for some ;-)

This is not the first report I have gotten about mailstore problems. My suspicion here is that the mail is opened read only or somehow got the wrong properties from mailstore.

Thanks for the patch, applied!
You are correct the NEWS file states that this was added in 1.9.0

I can reproduce this.

I've just tried the test suite of GnuPG 1.4.23 on debian buster and all tests pass.

I keep it open as testing so that we keep it in mind for a release.

There was a patch for this by david faure which added an
#undef ttytype after including curses.h

Thanks for the report.

I'm working on better support for Smartcards and esp. multiple smartcards in Kleopatra. IMO it should not be required for a user to explicitly write a reader port in the config.

I'm giving this an initial priority of "Normal" so that it's out of the triage list.

If you have -g / -Og could you please provide a backtrace?

Hi,
sorry we cannot help you with that. The keyservers might have unreliable results. It would only be a bug in Kleopatra if GnuPG on the Command line would find a key and kleopatra wont. Does it find other keys?
So you can try on the command line with "gpg --search foo@bar.baz" this would also show you on which server the keys are searched.

Thanks for the report I tried to reproduce this but cannot reproduce the mentioned behavior. So for now Low priority until we have found a way to reproduce it. I have tried unencrypted and encrypted mails and it works as expected.

I have opened T4939 to add the keylist mode with keygrip.

To end the failures I have modified the test, that needed to be done anyway since different versions of GnuPG behave differently.

Your guess is correct, but as this hole "Wizard" thing uses Qt Regular expressions its not super quick fix without having to introduce new strings etc.
So I just reduced the length. The new key generation in Kleopatra is pending a rewrite anyway. Requires way too many clicks ATM.

Thanks for looking into this!