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.

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.

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.

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.

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:

Ok. Thank you for sharing informations!

Yep, I can access this property.

So maybe closing the inspector, too is necessary here so that the real close / unload on the mail is triggered. But it might just be that Outlook immediately reopens the mail in your case. Then it won't help but I think you should try that, too because any Interprocess communication will be more effort.

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.

In T4241#119944, @msc wrote:

I wonder if it would be possible for you to close the mail / inspector of the mail with DiscardChanges before doing a save as?

Discarding changes with the Close(OlDiscard) method has no effect on the issue.

Yes that is expected, we block the save event as long as we have replaced the Body / Attachments of the mail with decrypted contents are shown. In our debug log you would see the message "Canceling write event".

Yes, I can confirm that log entry.

Yes I see the problem and have a fix for it. I'm just trying to make it nice now :-)

Yes, I also can't decrypt the files there. As Outlook warns about
restricting access to attachments and active contents, the reason is
clear. The mail must be moved elsewhere.

I can reproduce that it won't be moved.

This issue is pretty old and I think anything here was fixed in recent releases. So let's close this to avoid artifacts in the tracker.

This was likely one form of T4111

3.1.4 was released.

This had also something to do with the missing keycache that will be released in 3.1.5 so that sometimes S/MIME keys were not cached internally and so would not be used.

This was fixed with the Gpg4win-3.1.4 release. Apologies that I forgot to mention a pre release version / installer in this issue.

I've tried to reproduce it but failed. Even If I open the message in a new window or a new explorer the message is correctly caught.

Yes that is expected, we block the save event as long as we have replaced the Body / Attachments of the mail with decrypted contents are shown. In our debug log you would see the message "Canceling write event".

Yes. Thanks! I'm at over 2500 S/MIME verify operations without a crash now!

The T4237 fix should also fix this one.

Did you have the chance to try it out with 3.1.4?

For what it's worth I found some more places where data leaked out even in log level 1. It will probably be a bit of a process to get this clean to a 100% as there is no automated way to decide what needs to be filtered and what not.

There were two ways to access the registry and the config value load did not fallback to HKLM. I've removed the second way and I've tested it and it works now as it uses the codepath with the fallback.

Thanks for the quick reply!

Thanks. I've never seen that, so my test definitely did not test moving junk mails.

Hi,
As for getting Help, we all speak German ;-P

Thank you for the feedback. Very strange, that should have been solved indeed and in my tests it works and I also got feedback from other reporters who had that problem with 3.1.3 that it works in 3.1.4.

It is propably related to decrypting large (single) tar-files. It works flawlessly when renaming the tar-files to another extension before encrypting and afterwards decrypting it again. But as long as it is named xyz.tar Kleopatra crashes. Could it be that untarring causes some "out of memory" failure? I recognized that while decrypting the tar there was no sign that the decryption process would allocate any disk space. There is just an empty randomly named folder being created upon decryption.

With Gpg4win 3.1.4 and the two blocking options, searching for any name in Inbox, entering more than 2 letters will crash Outlook 100%.

My pic didn't appear inline, so I'll add it again as attachment

maybe a setting is also involved. marking the mail in the Junk folder gives:

There was a report about this in the past T3956
I tried it out then with a junk folder and for me it worked so I closed the issue as a duplicate of the general moving mail problem.

I broke it a day before the release and didn't notice.
Since f34cd2782bc0cd6f359c14de4d4a889ec4e49a6e it accidentally logs all string allocations if one of DEBUG_TRACE DEBUG_MEMORY or DEBUG_DATA is set. The intention was that it should log when all three are set.

Hi Andre,

I think it has something to do with the number of files. Just encrypting / decrypting a 10GB random data file did not show a problem.

Hi Andre,
thanks for the fast feedback. I will wait for the 3.1.4 Release then and test it afterwards. If it still occurs i will update this thread. Thanks for your help!
All the best
Dorian

Hi Andre,
thanks for the feedback, will try this asap when i have the chance to get on the laptop of my co-worker. Will update you afterwards. Thanks for the help!
All the best
Dorian