Right, it's the same with gpgol disabled. I set it to invalid.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Fri, Oct 24
But you are able to do this w/o gpgol being active?
Thu, Oct 23
That's not surprising. The fix was made after GpgOL 2.6.7. And gpg4win-5.0.0-beta395 still seems to include GpgOL 2.6.6 only.
Looks good to me on gpg4win-5.0.0-beta395 @ win11
Issue is still present in gpg4win-5.0.0-beta395 @ win11:
gpgol logs:
Maybe related to https://dev.gnupg.org/T7813
Looks good to me on gpg4win-5.0.0-beta395 @ win11
Looks good to me on gpg4win-5.0.0-beta395 @ win11
Looks good to me on gpg4win-5.0.0-beta395 @ win11
Wed, Oct 22
Tue, Oct 21
Might there be a relation to T7842? But I would have thought that then all signed messages would be unaffected.
Thu, Oct 16
Fri, Oct 10
Thu, Oct 9
Might be related to T7836?
Might this be related to T4953?
Wed, Oct 8
Mon, Oct 6
(auto resolved due to the keyword "resolved" in the commit message)
The window was not reenabled on failure
Sat, Oct 4
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.
Thu, Oct 2
This happens only in the 64-bit builds, i.e. with Gpg4win 5.
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
Wed, Oct 1
Tue, Sep 30
Mon, Sep 29
Sep 25 2025
We were testing different things. This instance of the move to folder issue is fixed, for variants we'll open new tickets with clear test cases.
Sep 24 2025
The following workflow works for Markus and me:
FWIW: The fix rO75f46829054e is part of GpgOL since 2.6.3
Same behavior (on vsd-3.3.3-beta90.12 @ win10) for smime encrypted mails:
Sep 23 2025
As there has been no more feedback on this for years, I'll close this.
Looks good to me on vsd-3.3.3-beta90.12 @ win10:
what ever was fixed with the attached commit we can not test.
I see no workaround.
The attachments in the original mail are not gone, yes.
But the mail can't be forwarded with them.