The problem is with the code for T3656

Thanks for the report. I can reproduce this by replying to S/MIME enc & sign mails.

While triaging issues this looks to me more like a support case. And not an issue of the software itself. So I'm closing this issue.

Uh, I just noticed that this issue is from dec. 2019 I am unsure why I overlooked this and only noticed it in my regular tracker check today.

@JJworx Thanks for the suggestion / feature request.

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