well yes, it ends now in "_signiert.pdf" with German language settings and "_signed.pdf" in English.

To say this differently, the problem fixed recently which Relaxed detection of encrypted mails might still fix your problem. But the "corruption" of the mail which makes it harder to detect as a crypto mail for GpgOL does not happen when you send a mail, it appears to happen when you receive a mail.

Received, but it is not the same problem at least on your side. Your mail looks perfect. It would have been handled by any version of GpgOL on my side. So I think it is the receiving side meaning your incoming crypto mails are modfied by some middleware in a way that GpgOL does not detect them as crypto mails anymore. But before we debug more here with logs for you, let me finish up some other work on GpgOL and I can probably give you and some others in the tracker here a beta this week where we can then confirm if its already fixed. I'm currently actively working on GpgOL.

I sent the test encrypted email

Thanks once more... and appreciate your swift response.

Yes the resolution in that issue is "I have fixed this, you need to wait for the next update." The comments above explain the problem, the mail is modified in transit, if you change something there then you can maybe workaround in the meantime. The exact comment I linked gave the instructions on how to assist with analyizing this issue. If you would follow them I could also tell you for sure weather or not this is your problem. https://dev.gnupg.org/T6686#174856

ok, with the new testversion VS-Desktop-3.2.0.0-beta214 and without Debug redirection (mea culpa), the info window looks like this:

Thank you for your reply.

This sounds a bit more like you would maybe better suited with a batch script or command line usage anyway if you always want to encrypt in the same way you don't really need a fancy GUI for that.

Ok. Let me unpack this for you. I think your problem is that now since you switched to your new domain the mails in Outlook are no longer directly decrypted, then you open the attachment and get this message.

I am closing this, for now as this issue lacks actionable details, we would need an example mail or debug data. So my intent is just to close it and reopen if the issue still occurs with Gpg4win-4.2.1

Noticed this issue while searching for a different one.
I think this could be fixed with T6686 if it has not already been fixed by a previous change that relaxed the detection of the encrypted message part better.

Why do you think that no WKD lookup occurs for keys of unknown origin? gpg and therefore Kleopatra doesn't report any import results for certificates that are not published via WKD when doing --locate-external-keys --auto-key-locate clear,wkd.

Hi, it would be great to make Kleopatra remember the last used settings.

Thank you for your time and your answer, we really do appreciate your work. We invested in this in hope to help make the software better. Please try it, so you will see how it works. We were able to reproduce the problem the way I described. When installed as a normal user it won't work. Installed as an Administrator user it works. So the more secure way does not work currently.

The way how you install it can have nothing to do with that, it must be a different issue, but it sounds to me like you are messing with privileges a bit too much. Did you ever receive the warning of Kleopatra that you are running it as Administrator and that will mess up the rights in your GnuPG folder? Be honest. :)

You mean if you right click on a file and select sign & encrypt or if you choose the action from Kleopatra?

For another user this change caused endless syncs. Since I do not yet see a way to fix this without risking again that the plaintext leaks to the server under some circumstances, because the problem is that I still do not know how to reproduce these circumstances, my plan is to at least add an option in the debug tab of Kleopatra to disable this "save back" feature.

PR that removes the "Show key details" link from the response email: https://invent.kde.org/pim/kdepim-addons/-/merge_requests/37

It took a bit of time to set things up, but I was able to manually perform the WKS dance and open each email in KMail to check how it works.

This looks to me like the typical thing where you also do not get the "Diagnostics" button viewed. Because log-file is set in the various .conf files and the stderr does not get back to GPGME / Kleopatra so we have nothing to show there because the actual error ended up in a log file.

In T5960#175407, @ebo wrote:

The result of your changes is a bit unexpected for me, maybe something is missing in the testversion Gpg4win-4.2.1-beta31?

[6064] org.kde.pim.libkleo: gpgConfGetConsoleOutputCodePage returns 65001
[6064] org.kde.pim.libkleo: stringFromGpgOutput trying to decode "" using codepage 65001

Was already with gpgme 1.21.0. Note that I used the done column but in future a milestone would be more useful than that catch all "done".

Also fixed for gnupg22

My issue was that it makes no sense to publish a revocation of a local certification...
I'm fine with it in the case if the certification was exportable.

Btw. if the keyserver is set to "none" or whatever the new value is worded we should remove all the publishing options from the UI. But that is a different issue, I just noticed this while talking about this ticket.

If I revoke a certificcation I am asked to "publish revocation".
When certifying there is the checkbox to publish.

Tested with current version. Works.