gpg4win 3.1.4 = gpgOL 2.3.1 = prefer smime does not work

“prefer smime” does not work so far, because the gpgOL plugin uses pgp keys instead of smime keys.

No solution until yet.

Would be the best to remove totally the “prefer SMIME” option, because with every update I at first enjoy this function only to be disappointed to notice that this function does not work.

Are you sure that you: Have a valid and trusted S/MIME certificate with secret key for the mail address you are sending from and that you have a valid and trusted certificate for each recipient.

E.g. if you see the interactive key resolver is it green for each recipient without changing anything if you select S/MIME there.

Sorry if I’m asking redundant questions. Also have you tried with CRL checks disabled?

Before GpgOL uses S/MIME certificates it checks with dirmngr if they are valid and that could cause a CRL check which might take longer then it takes to start the encryption process.

If all that is the case a debug log would help me. But it would require “Data Debugging” enabled to be helpful because otherwise the key resolution is left out to avoid leaking recipient names. You could send it to me encrypted by mail (my PGP key is )

To clarify why I think that it is something special with your setup:
It not only works for me but also for a customer who requested the general “Prefer S/MIME”, because only S/MIME preference on autoresolving (which also worked for the customer) was not enough and they wanted to have the manual resolver start with S/MIME selected, too.

Hi Andre,

many thanks for your efforts.

All my imported SMIME pulic and private keys in Kleopatra are valid. If I use manual OpenGL-encryption and signing, all my test emails are sent correctly.

Only if I use automatic resolving and “prefer SMIME”, the problem is that only sometimes it works, but in most cases OpenPGP-keys are used instead of SMIME keys.

I disactivated “CRL”, but the problem still exists.

Enclosed the Logfile gpgol.txt for one email I wanted to mail using “SMIME”, but PGP was used.


gpgol.txt (9.16 KB)

Thanks for the log!

Did you close / start outlook with the composer window already open and the composer already had a recipient entered?

I can see in the log that the internal key cache of GpgOL is not filled.

For some background. Currently the key cache is filled (it looks for certificates for the sender and all recipients.) when:

  1. The encrypt / sign button is toggled.
    → I believe this did not happen for you because you have always sign enabled. So it was not toggled.
  2. The list of recipients changes while the encrypt / sign button is toggled.
    → I believe that this did not happen for you as I don’t see it in the debug output. That is why I suspect that maybe the composer was restored after a restart.
  3. The list of recipients changes and the option to automatically secure messages is enabled.
    → This did not happen to you because you have that option disabled.

I had in mind to just load all keys into the keycache in the background on startup to speed up signature verification. That should also fix your problem.

I’ve opened a task for this: and will try to do this for the next version.

Hi Andre,

thanks for your answer.

First of all, I have to deny all of your 3 questions/thoughts.

I made a new test with a fresh Hyper-V VM and a new Outlook and gpg4win-installation. I only set one email-account in Outlook and imported only the private OpenPGP and SMIME keys for the sender account and the public keys for the recipient in Kleopatra.

The result is the same that PGP is always preferred.


Could you give 3.1.5 a try? We are now querying all keys on startup so S/MIME keys should be in the internal cache and preferred.

HERO !!! It works. Great job. Many thanks.

Thank you for testing it!

Btw. We fixed a major stability issue regarding S/MIME use of GpgOL in 3.1.5 this should also be nice for you and your users ;-).