It makes --export-secret-key-p12 the recommended way to transport a privat CMS key. (fine, if this is, what was intended).
(Note that there is a typo in line 259).

On saturday I could observe the problem with a fresh Windows 10 Home edition.

Here is the firefox warning

Another observation: Just opening the file from the explorer is not enough, but once I was on the details of the digital signature, opening works. So for whatever reasons Firefox and Chromium do not trigger the security check.

Observation: When downloading a new version of Firefox, there is another dialog before the UAC comes and the following UAC is fine then. Question: Why does Gpg4win3.exe directly goes to the UAC and firefox.exe triggers a different dialog?

So I can reproduce the problem on a Windows 7 virtual machine with all important updates up to the 5th of February, 2018.

When disabling CRL checks, you expose the user to drawbacks by outdated or revoked certificates. While I agree that improving implementations to not check the validation information too often or even build proxies is a good idea, I have a tendency to keep crl checking enabled for CMS crypto operations because it seems to be a lesser drawback.

Still open.

For transparency reasons: Intevation will make Werner an offer for maintaining dev.gnupg.org.

Still not solved.

If you are encountering the problem, please

1. Check that you have updated your Windows operation system to the latest version and you've got all security updates. (As some necessary certificates may have come later with an update.)
2. Does the behaviour change if you "investigate the certificate chain" through -> Properties -> Digital Signatures?

Hi @hs,
given that you have used the instructions from the link above to look at the message,
I'll take it that you are using an IMAP/SMTP setup for mail transportation?

@tstreibl thanks for helping with your feedback!
Please note that this issue (T3442) still has the status "testing", because we want to perform some more tests before declaring it resolved. :)

@aheinecke Regarding closing: I'd say that we should have a test on this one and then close it for only the refocussed "send-folder problem".
Can you provide an updated gpgol.dll drop in replacement?
Some of the users in the forum may be willing to test as well.

So maybe there is also a display problem, as I saw 0:00 in Kleo. I have to recheck.

When receiving an S/MIME mail that is encrypted, the successful log looks like:

Comparing the gpgol.log files in the case of OpenPGP decryption (successful) and S/MIME decryption in send folder (failing).

Here is the link to the wald report by John Mrkva:
https://wald.intevation.org/forum/forum.php?thread_id=1785&forum_id=21&group_id=11

Hi, thanks for the report.

Yesterday I could reproduce that emails in the "send" folder cannot be decrypted anymore.

This week I'm trying to make progress with this issue.

Still failing.

I agree that it is better to keep it in two directories.
(The potential advantages outweight the drawbacks.)

@aheinecke thanks for your findings.

Retested today: Works again. So I can confirm the resolution of this task.
Thanks @marcus !

Gathered information:

@marcus you've closed it while I was adding stuff. Where shall we document the way forward? In wiki.gnupg.org or https://dev.gnupg.org/w/ or in this task?

Mail send: https://lists.gnupg.org/pipermail/gnupg-devel/2017-August/033012.html