No, unfortunatelly problem is still existing.

Hat sich das Problem gelöst? Bei mir tritt das seit gestern auf auf. Ich kann nichts mehr signieren oder verschlüsseln. andere Plugins habe ich deaktiviert, es beliebt trotzdem.

Curious as to whether there's been any update on this. GPG4Win is the only approved whole email + attachment encryption solution on this end, and we're having trouble with inline images showing up as attachments only in Outlook 2016 (using GPG4Win 4.0.2). Of course, as you said, at least the attachment isn't being lost; however it does make reading rich emails more difficult.

Please disable all other Add-Ins as well as extra security tools running on that machine to see whether there is some interference with them.

I am closing this as the group support for gpgol is now in T5967

Still needs testing as this is a default off feature.

This needs to be tested with group configuration even for non mixed mode. There is an important wish to have the kleopatra group configuration be used in the keyresolver from outlook.

Please try a decent version of Gpg4win - we have fixed dozens of bugs in the mean time If the problems persists, please re-open this bug.

Conflicts between Add-Ins are often unavoidable. We have a list of known issues at:
https://wiki.gnupg.org/GpgOL/IncompatibleAddons
If you have more information on that ESET thingy please enter it into the above wiki or leave some description here.

is there any update ? I having the same Issue here on Windows 11 Pro, Outlook Version 2203 (Microsoft 365) 64bit

Any idea? Any update?

Have you selected an Output file in a location where you can write files with your permissions?

I had already tried both, to deselct all other add-ins and to select all possible add-ins.
No change of the behaviour.

Could you please create a log file using the debug settings with Outlook Object Model debugging enabled?

we have a similar problem in our organization. We're using Outlook from Office 365. For two weeks now we have set a GPO for Outlook to prefer plain text messages like in @kimmoal's organization environment.
This causes the same problem: We are getting blank emails when they are encrypted or signed.

I had some more time to test this bug.

we replace the encrypted text and attachments with the decrypted / verified parts

The current links should be replaced or removed.

You could verify this with another email address containing a +.

How can I check this, @ikloecker ?

Can you check whether the + character in the email addresses is causing this?

Because I'm just starting with GpgOL: Are we talking about adding links in the "Configure GpgOL" window or are there any other windows? If that is the right window maybe we could add a new tab "FAQ" and add the links there. At first I thought the links could be added to the tab "GpgOL" but there are already many entries and the other tabs don't fit well.

gpgol/doc/gpl.texi (line 9)
gpgol/COPYING-ICONS (line 52)

What are the other to places?

When I greped for links to the FSF page (grep with string "fsf" I found out that there is one link to https://emailselfdefense.fsf.org/en/infographic.html in line 722 of src/ribbon-callbacks.cpp. Is that the link that was meant?

I agree. @cklassen can you make a suggestion?

Fixed.

Please describe your problem in more detail. Also: Which version of GpgOl and Outlook are you using, SMTP/IMAP or Exchange?

I'm not sure. In KeyResolverCore::Private::resolve() line 668 reads

const bool pgpOnly = (!mEncrypt || !hasUnresolvedRecipients(mEncKeys, OpenPGP)) && (!mSign || mSigKeys.contains(OpenPGP));

I'd say this is supposed to check if there is an OpenPGP signing key, but I guess mSigKeys[OpenPGP] is an empty list. This may be a regression introduced by the resultion of key groups because in KeyResolverCore::Private::resolveSigningGroups() the entry mSigKeys[OpenPGP] is always set (unless we are in CMS-only mode).

Yes, unit tests still pass. So its ok with you to commit this?

Sounds familiar, that the signing keys are not considered. I think when I worked on this, I thought that is was a bad idea to mix resolving signing and encryption keys. Do the unit tests still pass with your change?

@ikloecker
If I test the resolver code from libkleo with gpg4win-tools keyresolver binary:

The problem is that we replace the encrypted text and attachments with the decrypted / verified parts. This would already be a modification even without such changes like the category.

As well as GnuPG VS-Desktop. 3.1.21. We should also do a new gpg4win release.

GpgOL 2.5.2 has been released

This and some other issues with draft encryption are now fixed in master and need a release of GpgOL.

We now autoselect the key.

I am tending towards wontfix. The reason is here that the sender attempts to send HTML with inline pgp. Which is not supported. Then that HTML apparently tries to be mutlipart/related which is not supported for inline PGP. Then it would require us to correct a wrongly sent content type of the inline attachment so that outlook does not interpret it as a png. And in that Format it could even be that Attachment1.pgp is not encrypted but instead png data, as the content type indicates.

Unfortunately same story for GpgOL v42.5.1. Tried disabling all non-Microsoft plugins, however to no avail. Signed and encrypted messages are shown as blank, whereas I can see the content of the signed e-mails in the Outlook web client and on my iOS device.

Tested both with the policies key and with the normal key and with HKLM fallback. Works as expected. There was also an issue where the error handling in case setting the HTML body failed did no longer work, probably since the verification preview changes. This was fixed with 76b43345cdd3e932dae7b677e5c021ca52191f8e

Enigmail's support for Thunderbird 68 ends in two days:
https://www.enigmail.net/index.php/en/home/news/71-2021-08-31-end-of-support-for-thunderbird

Should be mostly done. What's missing is selection of groups in the approval dialog. Groups are not (yet) supported by the KeySelectionCombo.