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.

It worked as I expected. I've tested it with the run-messenger test and I can close and later "re-decrypt" again. The only surprising thing might be for your users that they have to unlock their secret key again if it is not already unlocked.

Right. While switching the Mail works for me if there are no other references to the mail open (e.g. If I have the mail opened in Outlook Spy switching does not work as the mail is not unloaded). It is better to make it explicit. The code is all there I just have to add a window message handler for it. I'll do that.

The problem is probably that you are also holding a reference to the mail in question. For me the close triggers an unload so that GpgOL completely detaches from the mail in question.
I've now added a more explicit tracking of when it should be allowed to write namely after our close with discard changes.

Marking this as resolved as it was forgotten in the testing state.

I think this is resolved by kleopatra's watchdog. There is a bug that the agent becomes unresponsive somehow then the loading also hangs but this is unrelated to kleopatra.

Sorry I did not see your first comment.

I would change gpgme_addrspec_from_uid and the gnupg equivalent to strip out the subaddress.

First let me say that it is never a good Idea to use outdated / unmaintained security software. PGP Messages are external input and you pass that to unmaintained software.

I've added two message handling routines and a small program to test it (run-messenger.cpp) You can use run-messenger.cpp for reference.

To reproduce it the key is to close Outlook through the file -> close option.

In the log I can see where it uses a non default codepath:

Yep, I can access this property.

It happens with 3.1.4, too.

Works nicely now. I added a "yellow" warning to indicate that the message is a crypto message that can't be handled by GpgOL in the Junk folder. I see no way to actually decrypt in the Junk folder as we are not allowed to access attachments.