Let me also note that gpg-zip was not installed since 2006 due a conflict with gpg1.

gpg-zip is deprecated because we have replaced it by gpgtar. Given that you have a workaround for Debian I tend to close this bug as WONTFIX.

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.

The corresponding fix can be found here: https://github.com/smuellerDD/jitterentropy-library/commit/9048af7f06fc1488904f54852e0a2f8da45a4745

Please note that this issue in Jitterentropy has been already fixed by upstream: http://www.chronox.de/jent.html

Default settings in Outlook are as following: (i) S/MIME encryption disabled, (ii) S/MIME signature enabled.

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 think there are some races in the crl updated code but no real harm.
To improve you patch we could write a wait_for_idle function which counts the active connections and the housekeeping threads. It would also need to block new connections etc.

I'll look into it.

Ok, I will reload the mail item then!

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

Thanks for reply.

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.

Indeed, I use a S/MIME certificate in Outlook for signing by default all e-mails. However, if I intend to send a PGP mail, I manually disable this feature and I manually opt for PGP signature & encryption. I am sure, that this standard procedure applied in this case. Therefore, I am surprised, that the message appears.

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.

Thank you! The beta38 is working for me. Guess the mail->setPassWrite (true); line from the last commit did the trick. I did not need to reload the mail object again.

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.

I tested these window messages with the provided beta build. Both messages gets processed and the e-mail is encrypted again but I still receive the 0x80004004 (E_ABORT) error when trying to save the message via the outlook api.