Hi Adam,

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

Thanks for the report. Prio High as this is data loss. I won't stop the 3.1.4 release which is currently in progress though as this issue does not appear to be a regression.

There is now an option in the debugging tab of the GpgOL config dialog to disable async decryption. This does not fully fix the issue but maybe mitigates it for some users that are very affected by this.

I finally got around to look at your examples. Sorry for the delay. I can reproduce the issue and understand the problem.

Thanks for the report I'll look into it. Won't make it into the next release though as we are currently very close to the release.

It's implemented.

This required some changes in the keyresolver / newkeyapprovaldialog in libkleo, too.

This is done now and can be accessed through the config dialog

I think with this warning and default off I can live with this option as it is now.

rev. 1b37aa01cc67d942de06c882fd9d30d39866b111 turns it off by default and even with it enabled only searches the X509 servers if there is no OpenPGP key for this address already available and S/MIME is not the preferred protocol.

This is how it looks like:

After several experiments with attachment flags to get the same behavior outlook does for unsigned mails I could not find a way to set both the content-id and cause the attachment not to be hidden.

The reason for this appears to be the "Content-ID", this is usually set for embedded attachments like images and not for attachments like PDF's.
This leads to the attachment being hidden, e.g. if you have embedded images you do not want them to show up in the list of attachments.

Turns out that that was not the problem.

In T4111#118259, @JJworx wrote:

That may be true, my Outlook crashes more often. Especially when dealing
with incoming S/MIME-signed mails!

This was a regression from 59e8a7ee3bcd16275091c9535626e49fc2a6c4af where a performance improvement to cache an object caused this problem.

That may be true, my Outlook crashes more often. Especially when dealing
with incoming S/MIME-signed mails!

updated example sent.

I confirm I have the same problem but, unfortunately, the beta did not help.

I'll try to reproduce it.

JJworx, thanks but I don't think a log would help me currently. With Gpg4win-3.1.3 I'm down in my main test instance to have these crashes ~0.25% (so I need around 400 verify/decrypt operations).

Cureently with the same machine using the old DLL I'm able to work with no problems. I tried several times to switch back to the new DLL and the problem appears immediatly.
If you need some other log I can produce it, just direct me. I used the procedure to enable gpgol logs I found on the forums.

Thank you for the report. I can't reproduce this behavior of course :-/ and from a first glance I also don't see any problem in your log. The last line logged says "GpgOL code is done, handing it back to Outlook".

Thanks for your report. Also thanks for trying the beta already. I think I know why this happens. Will be fixed!

I also have these seldom freezings. Any log / tracker I could activate that would help you?

I've uploaded a Gpg4win installer with this fix (3.1.4-beta3) to https://files.gpg4win.org/Beta/current/

I think this might be a ticket in itself. If I send a PGP signed email to someone who then responds to me, there should ideally not be issues with it - although I think it would be important to separate which parts are signed and which are not.

header of mail forwarded. looks like it says utf-8. either way, it does work with the right key.

Received. Thanks, so this is PGP Inline. Encoding handling in PGP Inline is always "Guessing" as it is no where defined which encoding is used for the message.

I've commited a fix and because this and another issue we might do a release sooner than originally planned.

interesting. email sent.

Mmh no, I can't reproduce this and my initial hunch was wrong. We do in fact handle encoding in that case.

I just tried the newest beta and I can confirm that sending Office attachments does work for me with this version.

Added gpgol and gpg4win project tags as this is important for these projects.

I was unable to figure out what the difference is between the handling of Office files and other files and why it comes to this error.

I can reproduce the issue and give it high priority. This is a curious problem of Outlook triggered by the improved send code in Gpg4win 3.1.3.

Here's the debug log file.

Thanks for your answer. So i think we must wait for the Update and downgrade to 3.1.2.

Da wir eine internationale Software sind bevorzugen wir in diesem Tracker Englisch. Ich hoffe das ist ok.

Thanks for the report. I was not aware of this but Indeed the fix should be easy. I think I already know the cause ;-)

Address book integration is in. What is still needed is to respect the overrides in the interactive key selection dialog.

I'm looking at my personal Inbox on both computers.
I received the encrypted mails, before I connected computer B with my Account
And yes, I'm using an exchange connection.

Thanks for the details. I tried to reproduce it but again for me it works. Still I give this high priority as this can be a blocker in deploying GpgOL and we should fix it for the next release.

I have additionally the problem, that signed and encrypted S/MIMI messages are handled by GPGOL even if S/MIME support is disabled.

The original reporter in the gpg4win-forums reports that this does not work reliably. :-/

Gpg4win-3.1.3 was released.

Gpg4win-3.1.3 was released. This issue can be closed. Hurray!