Or when there is no name the email will be taken:

Probably the same as T4257

I used already the mentioned blog ass base of my work. But the Yubikey is not recognized in ssh and I do not know how to mitigate.

A reference might help:
https://blogs.itemis.com/en/openpgp-on-the-job-part-8-ssh-with-openpgp-and-yubikey

Thank you very much for working on this issue.
I think there might be a problem with your fix, if there is a mail arriving with
more than 1 attachment with invalid filenames. I expect all but the last
processed attachment with invalid filename will be overriden by this fix. I
think this will happen very rarely but maybe it is worth consider this also.
Of course I may be totally wrong with my thoughts as I'm not a programmer and
don't know how gpgol is handling attachments in mails.
kind regards
Helmut Häfner

I can reproduce the issue. GpgOL creates a temporary file using the original filename and that fails because the pipe is one of the invalid filename characters on Windows / NTFS.

After digging through our complete parser code it turns out that we did everything correctly but Outlook adds the line break when we change the bodyformat from HTML to plain text. So this issue only existed since the fix for: T4639

Sorry, my fault. I found this command line in the internet (I am relatively new) so I mixed it up. Ok, skip ssh-add, it was my mistake! But the problem is that my Yubikey is not recognized by PuTTY in an ordinary ssh session. In the cmd window and in Cleopatra it works, but not with PuTTY.

So, where does "ssh-add" command come from? IIUC, it is from OpenSSH.

No, you are wrong, I speak not about OpenSSH!!! I speak from PuTTY. As explained in my first message, if I copy my ssh key on an USB stick and if I use PuTTY in combination with this stick, it is fine, I can connect to my server. If want to use my Yubikey 5NFC in combination with PuTTY, ssh authentication fail!

You mean running OpenSSH (and its tool ssh-add) on Windows, right?
It is not supported. PuTTY is supported.

Yes :-). I see it also in line rows (many '_' characters). As I wrote, I (and probably all others) always exptected this to be a formatting error on the sender's side :-).

It's not only for URL's. I've tested with any long line when sending "text/plain" GpgOL properly sends this but displays it wrongly.

Thanks,
I edited the task and now you can edit it too.

Hi,
could you please change the edit policy back to all users so that I can change the status of this task?

I think this might be the issue with High DPI support problems. T4819 which is not yet released.

The problem is with the code for T3656

Thanks for the report. I can reproduce this by replying to S/MIME enc & sign mails.

@Angel: The mail server log showed 0 bytes for the affected messages.

Are they actually zero-byte mails, or is the content mungled as an attachment? (which those replying probably overlooked, and would still be hard to interpret, as it would containe MIME parts)

I observe the same problem since I installed gpg4win 3.1.11 (german) in Outlook, Office Professional Plus 2019, Version 2004: Occasionally "zero byte mails" are sent by replying to an s/mine certified and encrypted mail. In my case the option s/mine support is disabled in GpgOL menu.

This was implemented 0d2db8b81ab24e2ab02d7ba6832cabd07b72f852 in Gpg4win-3.1.11 but does not work reliably.

Closing with Info Needed.

I'm moving this from testing to open again. Especially the deletion is an issue. I had a report that even for a sent mail Outlook.com also stores an unencrypted variant in the "Trash Bin".

Works nicely

This was released in December 2019

"Wyszukaj na na serwerze..." has been changed to "Wyszukaj na serwerze..." and should appear in the next release of Kleopatra.

Thanks for the logs. I can see the crashes, but I can't make heads or tails of them. We crash in completely valid code. I really don't want to play the blame game here but to me this would be explainable if there is an issue with refcounting in the GFI plugin that would release the IMessage or ISecureMessage MAPI Object from the ItemLoad event once to many. In that case the object we work with might be deleted at random times and that would explain it.

I added the log file.

It'll be fixed soon. Please use https://sourceforge.net/p/kdei18n-pl/mailman/kdei18n-pl-uwagi/ next time.

could you please go into the GpgOL setting and under "Debug" turn on logging on the highest level (+code trace) and then reproduce the crash and add the log here?
Including Data should not be needed so you can keep that checkbox unchecked to avoid having mail data in the logs.
This might help us to see where and why the crash occurs.

@aheinecke right, it's also fixed.

Cool. Falls du einen Korrekturleser für die neue Fassung brauchst, sag gerne Bescheid. Ich hab da Erfahrung …

hello
thanks for the feedback
it s indeed exchange 2007 (migration planned on long term)
we will try the imap workaround

There was a similar Problem in the past reported on our mailing list:

Thank you for your work, appreciated. Sorry I was a bit under the weather in April and could not get back to you earlier.

erstmal vielen dank für das Feedback. Ich habe momentan als Aufgabe ein neues Benutzerhandbuch auf Basis des Kompendiums zu erstellen und werde da die Hinweise auch mit Aufnehmen. Technisch ist sowohl der Inhalt als auch die Art wie das Handbuch erzeugt wird nicht mehr aktuell, wir brauchen da dringend etwas neues das wir auch online stellen können.
Sollte noch in diesem Jahr passieren.

Thanks for the report.

I'm working on better support for Smartcards and esp. multiple smartcards in Kleopatra. IMO it should not be required for a user to explicitly write a reader port in the config.

Hi,
sorry we cannot help you with that. The keyservers might have unreliable results. It would only be a bug in Kleopatra if GnuPG on the Command line would find a key and kleopatra wont. Does it find other keys?
So you can try on the command line with "gpg --search foo@bar.baz" this would also show you on which server the keys are searched.

The issue has been fixed in Kleopatra: https://commits.kde.org/kleopatra/15ce46717636cecd1c1b8949d12b0ab6c3fed69a

I'm honestly surprised this isn't being given any sort of priority.
gnupg for windows is simply broken. Even Kleopatra, its supplied and designated key management application doesn't work re: keyserver communication.

Noch was: Die Tipps für die Passphrase auf Seite 26 sind teilweise katastrophal. Der Tipp mit "jeden 3. Buchstaben" sollte entfallen. Die Überschrift heißt doch Passphrase, nicht Passwort. Eine Phrase kann gerne lang sein und auch vollständige Wörter enthalten, es müssen nur genug davon sein.

Today I wanted to check linked issue: main window of Kleopatra doesn't remember size.
I worked on it again full day and found really good solution which is already present in KDE libs.
This is new fix for dialogs mentioned in this ticket and for MainWindow:
https://phabricator.kde.org/D28580

Patch with my fix: https://dev.gnupg.org/D498
(now I know how to submit it!)

Thanks for looking into this!

I've tested this issue on my Windows10 laptop.

This bug is linked to restoring window size in case of multi-monitor multi-DPI setup.
There is QT bug report: https://bugreports.qt.io/browse/QTBUG-77385