You are running in a codepath that means "Outlook told us this was S/MIME, but we have not seen the proper message headers and neither does the data look like it is S/MIME."
Sadly your log does not help much in that case because it marked the mail as bad and aborts.
I've changed that "marking a mail as bad" so that future logs will be more helpful and that it will still try to treat this case as "encrypted" maybe that will already work, although I doubt it. The log will at least be a bit more helpful.

As I see it Bernhard is just asking for the flat strucuture so basically some export script that creates the needed files on windows.

Gets reported multiple times and should be fixed for the next Gpg4win release as it is a bad first impression. (Although it can convert users to Kleopatra ;-) )

not yet, I try to get to it this week.

I'm closing this issues as "Invalid" because it is not an issue of Gpg4win. You can still comment and discuss here.

Ok. If you can confirm that then it means that my analysis is right. Still unexpected to get an error there. I have to do some more tests with Exchange Online but that would be another issue. If this issue is fixed by turning of debugging then it will also be fixed by my patches.

While I can't reproduce it myself (because I probably don't have the right mails in my exchange) looking at your log I think that I see the problem there might be an issue with the error handling in openProperty. So for old mails the openProperty probably fails because we have exchange online for that and the property is not yet available in Outlook and then the error is not correctly handled and it crashes.

3.1.5 was released on 13.11.2018

Was released with 3.1.5

Was released with 3.1.5

3.1.5 is released with this change.

This should work with Gpg4win-3.1.5

You seem to accept it. So Normal Prio and assigned to you :-p

Just as a note: I think the main selling point of GnuPG is that its stable. We care about backwards compatibility and we (are || want to be) rock solid. Even if there is a rare race. With millions of installations, that race will happen regularly. So I really would like us to get all this fixed without losing to much performance by locking to much.

Happens though. With the test invocation above there is only one key in the keyring.

1.9.0-beta68

Forgot to mention. run-threaded is a new test tool in GPGME.

Bug or user error?

Thanks for reporting your problem. We are highly interested in any crash. But please note that our minimum supported Exchange Version is 2010 because 2007 has reached end of life in april 2017. So I cannot test with that Server.

I'm lowering the priority as this does not appear to be a general problem. Otherwise more people would have reported it and I can't reproduce it yet.

Strange, even if I take that codepath it just works for me. Just to clarify you are also saying that if you enable "Block Outlook during encryption" it works for you? Which would be doubly strange because in your log I can see that the attachment is detected and due to T4131 we currently still always block Outlook when we detect an attachment.

I'll look into it.

I can reproduce it if I enter your or an unknown IP address.

I have a workflow now that does this without the openings. The mail is kept open by Outlook anyway when the properties are changed.

Mmh. It still makes a bit sense to me as I think it will be faster. But of course for memory mapped files the OS might decide.

Strange, I don't know of an issue that is related to that. There were a lot of changes to the DNS code but if you are using an IP. I've tested that using an IP works for me. I used https://192.146.137.99:443 for testing.