The Name field in GnuPG needs to be at least 5 _bytes_ long. Given that UTF-8 is required for Hangul, a 3 _character_ name is at least 6 bytes long and thus passes gpg check. The Name field is also optional and the whole test can be skipped using --allow-freeform-uid.

Fixed in master and 2.2

there is no way to handle this correctly with such messages. The PGP Standard says that PGP Messages may have every encoding. This is a reason why we always talk about "you should use PGP/MIME" as this is basically PGP with added handling for content meta information like the text encoding.

It has now been over 6 months since the patches were available to fix this problem and they have not been adopted upstream.

This is fixed now.

This is fixed in Gpg4win-3.1.11

Related task: About subkeys is T4028

Prio raised and assigned to werner as he asked for it.

Considering the concrete use case(s), it is more rational to support listing by capability.

Many cards have some printed information and I consider them important to avoid testing one by one all the cards from my pocket.
This I am really in favor of beeing asked to insert the respective card. The new text format private key files make it much easier to maintain this info

The description comes from gpg/gpgsm while the prompts are from gpg-agent. Thus if the agent has been started with the German local but gpgsm without a local this would explain the behaviour.

As a note: They can still be saved when doing file->save as from the message list or by using drag & drop.

We currently do not have the resources to work on it as our focus is more on GpgOL.

Any news about adopting GPGrelay to GnuPG > 2.1?

Thanks for examination.
Providing an 'untouched .msg' seems to be complicate because OL receives several encrypted mails all day long, so GpgOl must be activated for common use. Additional: To avoid this issue, .txt mode has been deactivated, .html is allowed without downloading foreign items or pictures.

Thank you for the good report.

Thanks for the report.

Thanks for the report but I cannot reproduce the issue :-/. In multipart alternative mails GpgOL takes the text part if text mode is set in Outlook.

[When changing a bug to a possible FAQ item it should be resolved and not marked as invalid]

All output of Assuan data lines is percent escaped. That is obvious because it is a line based format. You need to unescape it. Either use command line option

--decode

in-line command

/decode

or use

/datafile NAME

to write to a file.

Will be released with 3.1.11