with VS-Desktop-3.3.97.11-Beta (GnuPG 2.2.54-beta9)

Without GpgsmCompatibility set and with the trust in the Root-CA established in the global trustlist file (the local one does not work for vs-complicane without GpgsmCompatibility=de-vs-trustlist , as expected), the compliance of a signature or decryption is now shown correctly and in accordance with the certificate status shown in Kleopatra. If the Root-CA is only trusted locally, the certificate and the signature are shown as "certified" resp. "not-compliant".
In short: everything works as expected if GpgsmCompatibility is not set.

with GnuPG-VS-Desktop-3.3.90.9-Beta-Standard gpgsm now never shows the line [GNUPG:] VERIFICATION_COMPLIANCE_MODE 23. Therefore Kleopatra always shows "not VS compliant" now on verification and decryption. Even though the certificate is shown a VS-compliant in the list an when encryping:

Here is my attempt for fixing the de-vs compliance check when verifying a signature:

Not a good idea. Because then the user will open it with the browser and the browser loads all kind of additional data including drive-by malware. If HTML *mail* is shown by a MUA no links should be followed to keep information and the fact that it was read confidential.

I put the new menu entries below the menu entry for the Quick Guide into the Help menu.

Done. And backported for VSD 3.4.

Note: I noticed that most of the old documents use underscores instead of hyphens in the document names. It doesn't really matter, but being consistent makes it easier to avoid typos.

In vsd 3.3.6 the option is now greyed out.

Marcus suggestion: offer the HTML mail content as attachment.

Looks good to me on gpg4win-5.0.2-beta2 @ win11.

• local conf after 2 saves (additional entry in local conf):
  
• local conf after 2 saves (additional entry in global conf):
  

Is this still a requirement?

Looks good to me on gpg4win-5.0.2-beta2 @ win11:

Looks good to me on parallel install of

1. gpg4win-5.0.2-beta2 @ win11
2. vsd-4.0.0-beta1203 @ win11

The workaround is ready for testing. Kleopatra shouldn't show duplicate LDAP servers in the settings dialog. As a side effect global ldapserver entries should no longer multiply in the local dirmngr.conf each time the LDAP servers are changed, but one copy of the global ldapserver entries is still written to the local dirmngr.conf.

The fix is only a workaround, the duplicate entries are no longer shown in Kleopatra, they still exist and multiply on save.

One doesn't even need a global config file to reproduce the duplication.