That is on purpose. With a signed mail you have at least a way to tell who sent the mail. An unsigned but encrypted mail can be send by anyone and you netter don't use HTML links there.

I updated the branch.

This happens only in the 64-bit builds, i.e. with Gpg4win 5.

We also discussed emails that can't be decrypted. They are due to implementation details just currently skipped. They will also be so in the future as an implementation detail.

I just found out, that Drafts are not S/MIME encrypted, if

• draft encryption is activated and set to a S/MIME cert
• S/MIME is enabled
• S/MIME is not prefered

Note: I also activated Sign/Encrypt by default, if that matters

I implemented that in the old 2.2 branch for easier testing.

Please let us not clutter the code with OS specific things. We could use a gnupg_remove_ext or gnupg_remove_maybe_wait with a wait parameter which maps to a plain gnupg_remove for Unix. The GPGRT_PROCESS_DETACHED, in the asshelp is also the only specific thing which can be move to a file global macro.

I think that modifying gnupg_remove is a bit risky because it's used in many places.
I'd rather introduce new function for Windows; gnupg_w32_delete_file for this particular purpose.
Factoring out wait_when_sharing_violation function from gnupg_rename_file.

(writing this much later, since got lost)

I had a look at Qt 5. All of Qt's Windows styles are broken with regards to button or menu item styling. They change the background color of the hovered and/or selected button, but they use the default foreground color of the common base style class for the text. I don't think that fixing the (obsolete) Windows styles is worth the effort. As workaround we should use the Fusion style if high-contrast is active.

As this was finished more than a year ago, this should be included (and testable) in vsd

It was decided that we don't want to improve this in KConfig.

Tested a little late and on Windows 11 with VS-Desktop-3.3.90.16-Beta (a Beta for VSD 3.3.3):

The gnupg_remove should retry if it has a sharing violation. Similar to what we do in gnupg_rename_file. I just figured that we do a remove in the latter function too w/o handling a sharing violation.

Here is a possible fix: