For an additional quick test I forwarded a signed+encrypted mail from KMail as attachment, the mail containing the attachment was a) signed only, b) signed+encrypted.

My recommendation would be to include this change together with the other changes from today even in a minor release since any changes are behind:

I tested all scenarios I could think of with multiple embedded mails and mails which had themself embedded mails. signed, unsigned, s/mime and openpgp.

This is caused by "Mail::removeOurAttachments_o()" to avoid that when you forward an encrypted mail, that the decrypted attachments are also attached as well as the original mail. Same goes for send again.

The whole problem that we now had to take care of marking mails as Read was a misunderstanding of the code. As I assumed since we saved the mail. The property change of "UnRead" would then not be synced to the server, but more testing and user feedback after the last release has shown that the even FC99 which we observed in the "Uncancellable write event" cases was sent to us in conjunction with the property change of UnRead.

This is another side effect of: dd3ff8397aaf62e58fa9405ddc5397cb6bcfdc29 and 1f9c757872b033e1be8199c4d488ac84bf8f07bd before that revision the code that changed IPM.Note.GpgOL.MultipartSigned to IPM.Note.SMIME.MultipartSigned was only executed for S/MIME mails. I do now understand that the code in question at the beginning of decryptVerify_o was meant for other Addins, Outlook Web Interface etc. to ensure that the message class on the server was always IPM.Note.SMIME and not some GpgOL specific class so that outlook or other tools like securePIM would still treat the mail as S/MIME.

This is not a distinct issue from T7242 but the same.

My suspiction with this is that here the exchange server / outlook parses the mail attachment into MAPI and somehow handles mails differently then other attachments. This automatic conversion regarding attached mails is why we always ask users in Support to send us a problematic mail as a file in a zip archive. Otherwise Exchange will convert an attached Outlook MAPI mail to MIME and on the receiving side we can no longer see the original strucutre. Similar things are probably happening on the receiving side where the MIME eml "file" is converted into a MAPIOBJECT holding the forwarded mail which then confuses our internal knowledge about the attachments causing this error.

This works now.

I am observing strange beavior on WIndows 10 22h2 and OL 16.0.17830.200056 even if no mail is displayed in the reading pane and the selection returns no selected mails, Outlook loads mails which are e.g. right clicked. I think a way which could prevent some problems and allow it again to change flags and categories for unselected mails would be for us to check in the Read event if the mail has some inspector and abort in that case. This could also increase compatibility with other addins. I will do some experiments with it.

I understand the problem now. The difference between my test yesterday and today was that I had disabled S/MIME support in my GpgOL. Since T7243: GpgOL: multipart/signed OpenPGP SMTP transfered mails are displayed as S/MIME is an issue that makes GpgOL think that it is looking at an S/MIME mail but S/MIME is disabled, it tries to write back the mail to the server in a way so that Outlooks internal S/MIME support can parse it on the next run. In the log you see:

Today this was reproducible for me, too. Not sure what the difference is yet to yesterday I could see in my logs that this time the mails were never completely unloaded so that might be a reason. But we cannot rely on that. So reopening mails must work of course even if the mail stays open. (Good to simulate by keeping outlook spy active on the mail when loading and unloading).

I cannot reproduce the duplication, there are probably errors in your log regarding that close / discard changes failed or something like that in this case as we leave the original message intact and only add the extracted mime parts as attachments and replace the body with the text mimepart. It would duplicate that when it would "reverrify" a mail that already went thorugh all this. But it is meant that while the mail exists in outlooks memory that GpgOL tracks that, too and so does not decrypt the same mail twice. What I can see is that multipart/signed without encryption is somehow parsed as S/MIME initially. This looks like some new behavior in Office 365 or recent versions of Outlook when the message class is changed to an S/MIME Message class. Which we do to get unmodified access to the MAPI structure. From the data objects looking at the mail in outlook spy:

As I could not reproduce the issue with different builds I realized that I was compiling and linking GpgOL for development using a very different version of winpthread.
When I switch to a consistent build and runtime library the crash no longer happens. I wonder if we can maybe statically link winpthread, too. But I think that is coming from Gpgme++ since GpgOL only uses windows threads.

I added some comments to the commit. But

Markus this ticket I find important as it has much user visible impact. While VS-NfD secops say you "should" not use H TML mail, most users and basically all non - VS-NfD users use the default of outlook anyway and use HTML.

We have solved this now by showing a configurable error message in that case instead of hard failure with a cryptic error in T6683: GpgOL: Configurable error if sign is selected and prefer_smime

A better solution might be to use categories to have that element "this message will be signed / this message will be encrypted" above the edit window. But what I find more important and so much more a high priority is that in cases we have a failure saving the draft info flags an error message should come up. This happened for a customer and in the logs I could see that MAPI returned an error. the button was not toggled in this case but the mail also was not marked for encryption. T7144 is the task for that so I'd suggest to start with that one.

In gpgoladdin:

Changing the icon is unusual and does not match a native look and feel in Outlook where toggle icons are there for a reason, to be toggled or not. This is also the way how Outlooks native encrypt & sign works and Microsoft will probably have thought about this a bit.

we are doing this for the last releases. The list of files can also be found in the repo now in gpg4win.mk.in

The unexpected behavior of the MAPI store needs to be tested and handled. I had indeed forgotten about POP Mail in my concerns not to leak decrypted mails back to storage.

In T6813#184976, @ebo wrote:

Works on Gpg4win 4.3.1, too.

But noticed an inconsistency for the key creation via GpgOL: Contrary to the behavior for key creation in Kleopatra in Gpg4win, you are asked for a password for the new key.

Works on Gpg4win 4.3.1, too.

Yellow indicates a warning. In the old days we used yellow in too many cases and people barely got a green. This raised more user questioned than it was helpful. There is also a problem with accessibility if we overload colors too much.

For VSD I somewhat agree since this is the difference between a VD Compliant signature. For the community edition though level 2 is usually enough and should also be indicated as trustworthy. So I am currently in two minds about this.

With Gpg4win-4.3.1 I consider this solved:

We're waiting for a RNP v0.17.1 release which intends to tolerate this mode.
https://github.com/rnpgp/rnp/issues/2198
https://github.com/rnpgp/rnp/pull/2190

This is fixed on RNPs side: https://github.com/rnpgp/rnp/issues/2198

Btw we should probably add TB in our QA environment to check for such things. Esp. with future changes in GnuPG we should try to use TB and maybe a bounycastle MUA (Greernshield?) to avoid creating accidental incompatibilities.

Talked to werner about this. We will but the list of signed files into the Gpg4win repo proper to that signing is part of the normal Gpg4win release (of course only if you have a signing key configured)'

Yeah I also signed all the binaries for the last Gpg4win release (4.2.0). I think we should support the case that only signed binaries are allowed on a system.

I guess that's what it is called. A person in the forum told that GpgOL could not be loaded in Outlook and saw that the signature is missing in the new version. But it was there in version 4.2.0. With the command Get-AuthenticodeSignature I could confirm that this is the case.

A workaround which (currently) works for flagging and categories both is:

That is an old bug report with a couple of fixes introduced over the years. As of now we sometimes see hangs on Windows on our test VMs. The common cause here seems to be USB card reader issues. Let's close this bug and wait for another bug report with current software versions.

In T4127#170518, @aheinecke wrote:

With the recent commit the old workaround works reliably again.

Thank you for the detailed report. I will look into it.

Since this is hard / impossible to test for, but the fix was obvious I am closing this directly. The fix for this is in GpgOL 2.5.12.

Yes they can, the workaround, which GpgOL even suggests in the error message is that the mail may not be visible as plain text while changing flags or categories. This usually means that you have to select a different mail and then use right click on the mail you wish to mark for followup or add a category to. The whole problem is that while the plaintext is visible in Outlook we have to prevent changes to the mail from beeing synced to the server or otherwise it will also sync the plaintext.

A user also report this problem with Microsoft365 and Outlook Versions 2302 and 2208. (Exchange is the latest online-Version.
Assuming current Gpg4win v4.2.0)

I have yet to reproduce this so I had not yet triaged this. The usual case to forward attached mail in Outlook is with .msg files but I recently noticed that Outlook on the web allows you to save mail also as .eml. Also .eml should in theory be much simpler to handle.

The issue was obvious but I looked at the wrong place. I looked for a ref counting error but the issue was that the control only returned a temporary pointer that had exactly one reference.

I am closing this as resolved for now. I would need a completely new client or mess with the registry keys in which outlook stores the performance data to test this. But I would bet it still lists us as responsible for the slow start of outlook. But the time it will then show should now be 0ms since we absolutely do nothing anymore in our DLLMain.

I don't really know how to test this though since it tracks this over time and history. Let us see if my change fixes this, It may be that outlook does not measure the DLLMain (which I am pretty sure it does) but the actual COM initialization, in which case my change did nothing. But I don't see any way in which my change could make things worse.

I think outlook shows any native addin there. As you can see by the empty bar we don't really do anything in there to slow it down. But let me check if I can move the extremely little code we have in there somewhere else.

I can confirm this

Works nicely for me in beta300

Looks good now

The Keyresolver did not allow me to encrypt to an S/MIME cert where the root CA was not in my trustlist.txt that was part of this feature to allow users to encrypt "non vs-nfd compliant" to such untrusted keys, like they would be able to also encrypt to untrusted openpgp keys.

New MR: https://invent.kde.org/pim/libkleo/-/merge_requests/61

MR for this: https://invent.kde.org/pim/libkleo/-/merge_requests/60/

I am temped to put the VSD-3.2 flag on it and raise prio to high because of strategic reasons... So if someone has a cheap fix for this. Please go for it.