So the default error is now:

When selecting OK:

You can also configure this with the hidden option "smimeNoCertSigErr" for something specific to your organization:

When you switch to openpgp you have the option to generate a key. If you stick with S/MIME it will send out an unsigned mail.

The error message is only shown once per start of outlook so as to not be too annoying.

The most difficult thing here was to actually support the case where the user then sees the keyresolver dialog and selects "yes i do not wish to sign" this never worked.

My solution for this was to implement something that goes a bit against the architectural design of async encryption but I doubt that we will ever see async encryption in GpgOL COM.

I realized that I still had "always show confirmation dialog" on... When I turn that off I get the default error message, but with encoding errors:

But, as I had switched to a keyring with a valid S/MIME certificate for the sender, this is unexpected.

Clicking OK then results in a switch to OpenPGP without any question or explanation:

Edit: In that keyring I had for the recipient an expired S/MIME and a valid OpenPGP one, though that one was not VS-NfD compliant because not certified. So I would expect the confirmation dialog to come up (with OpenPGP selected) instead of pinentry.

In T6683#176424, @ebo wrote:

Does anybody understand this? I had to check the source code to understand what "Identität und Integrität nicht bestätigen" ("Don't confirm identity and integrity") means. The tool tip reads "The E-Mail will not be cryptographically signed." which explains it, but I think we should improve the text in the drop down. Is "confirm" actually the correct word? Isn't "confirm identity and integrity" something that the receiver does by verifying the signature? Even if "confirm" fits, I think for me "certify" would make it clearer. Although my confusion comes mostly from the missing subject of confirmation, i.e. "the email".

So, maybe we should change it to "Don't confirm identity and integrity of the email". From the screenshot there's plenty of space for a longer text. (Even more correct would be "Don't confirm identity of the sender and integrity of the email", but that's probably getting too long.)

Thinking more about this, I'm wondering whether this dialog is actually the correct place to disable signing if signing was enabled in Outlook. There should at least be a big fat warning directly above the "OK" button that the email will be sent unsigned. (Or maybe there is another confirmation dialog shown before actually sending the email which I don't know about.)

Yes, the wording for this line should be improved, I agree.
In the current release and the releases up to now this action did not work at all when it was not used in combination with encrypt. That usually happens only if an administrator activates the "always_sign" option, prefers S/MIME and then does not issue users with S/MIME certificates. For OpenPGP we have the "Generate" option preselected in that case.

The reason to disable this here is that in Outlook you have a prominent "Secure" Button that enables sign + encrypt. And while encrypting without having a key for your own is an important use case this dialog made the most sense for me to say "don't sign, don't encrypt for myself."

The use case is that your communication partner only offers S/MIME certificates but you internally use only OpenPGP, you can then still send this recpient an S/MIME mail that you can't decrypt or sign but which at least the recipient will be able to read.

If I repeat this with a totally empty keyring, I get the new message regarding the missing signing certificate.

"OK" then opens the confirmation dialog, as you planned:

So it seems it works for the intended case but has unexpected side effects in other ones.

Although I suspect now that the "no 509 certificate" message box coming up in spite of a valid S/MIME for the sender was a side effect from restarting Outlook at the wrong time. I can not reproduce it at the moment, anyway.

The new "no 509 certificate" message box comes up always when restarting Outlook and then immediately composing and sending a message, even when the user has a certificate.
-> add a check if the cache is already loaded in GpgOL

But I wonder if we should not address https://dev.gnupg.org/T6683#176429, the text there is not changes in this Beta version.