As far as I know this is a v4 only network. I tried what you said and get this log:

2020-01-17 15:39:33 dirmngr[18656.6] DBG: chan_6 <- END
2020-01-17 15:39:33 dirmngr[18656.6] DBG: dns: libdns initialized
2020-01-17 15:39:33 dirmngr[18656.6] DBG: dns: getsrv(_pgpkey-https._tcp.keys.openpgp.org) -> 0 records
2020-01-17 15:39:33 dirmngr[18656.6] DBG: dns: resolve_dns_name(keys.openpgp.org): Success
2020-01-17 15:39:33 dirmngr[18656.6] resolve_dns_addr for 'keys.openpgp.org': 'keys.openpgp.org' [already known]
2020-01-17 15:39:33 dirmngr[18656.6] resolve_dns_addr for 'keys.openpgp.org': 'keys.openpgp.org' [already known]
2020-01-17 15:39:33 dirmngr[18656.6] number of system provided CAs: 142
2020-01-17 15:39:33 dirmngr[18656.6] DBG: dns: resolve_dns_name(keys.openpgp.org): Success
2020-01-17 15:39:33 dirmngr[18656.6] error creating socket: Address family not supported by protocol
2020-01-17 15:39:33 dirmngr[18656.6] error connecting to 'https://keys.openpgp.org:443': Address family not supported by protocol
2020-01-17 15:39:33 dirmngr[18656.6] marking host 'keys.openpgp.org' as dead
2020-01-17 15:39:33 dirmngr[18656.6] host 'keys.openpgp.org' marked as dead
2020-01-17 15:39:33 dirmngr[18656.6] command 'KS_PUT' failed: No keyserver available
2020-01-17 15:39:33 dirmngr[18656.6] DBG: chan_6 -> ERR 167772346 No keyserver available <Dirmngr>
2020-01-17 15:39:33 dirmngr[18656.6] DBG: chan_6 <- BYE
2020-01-17 15:39:33 dirmngr[18656.6] DBG: chan_6 -> OK closing connection
2020-01-17 15:39:33 dirmngr[18656.6] handler for fd 6 terminated

The problem is likely that you don't have IPv4 support but keys.openpgp.org resolves only to a v4 address.
You should also use

An updated build is available here: https://files.gpg4win.org/Beta/gpgol/2.4.6-beta3/

Implemented in master.

It looks good.

thanks for the fix, @aheinecke ! can you post screenshots of the changes? or do you have a nightly build i could test?

BTW, I just pushed some new features to maste for the gpg-card tool. You can now do

Yes that is fine with me.

I have checked the eMail header of the eMail from Sender X in the Exchange mailbox of User A and I see Sender X is using Mozilla Thunderbird and I tested it with Thunderbird also, but it works for me.
I cannot provide all details of the eMail from Sender X because it's a customer of another customer, but I have replaced the IP addresses and other private information in the eMail header and this is the result:

thanks for the report. This is definitely a sore spot and we need to look at it again. I did some experiments a while a go trying to fix this issue but so far I was unable to get to stable results so for now this is a known issue.
I'm a bit suprised that the workaround with not having the mail open does not work for you.

Is this about any special version of Symantec? As far as I knew Symantec Endpoint Security Desktop (or whatever they call it nowadays) supports reading PGP/MIME and even sending it if forced.

This again,...
That error always occurs when the Exchange Server is unhappy with the structure of our PGP/MIME Mails. It has nothing to do with S/MIME, that is only because Exchange only knows about S/MIME, so our PGP/MIME Mails also claim to be S/MIME mails.

Display now looks good to me in all cases. We still keep the subject when a reply / forward is done, but that is the same as before. To do this properly I would have to actually do the protected headers sending,.. as then I could automatically flag such a message to be sent with protected headers. But that would be a new feature and I rather work on properly doing BCC sending as the next privacy enhancing feature.

Well that is due to "--debug packet" (aka --debug 1). We have this code

Reported.

With new "KEYINFO" command of scdaemon, finally, we can move on to support better selection of signing key.
(Note: having a private key on multiple cards had already been solved in T4301: Handling multiple subkeys on two SmartCards.)

In master, it has been implemented.

The first "SCD SERIALNO" command let scdaemon re-scan smartcards/tokens.

With new "KEYINFO" command in scdaemon, a list of card keys can be retrieved by:

There is no use cases for $SIGNKEYID.

$ENCRKEYID use case have been removed.

Fixed and backported.

You may.. Comments were relevant. Bye.

FWIW, the GTK and QT pinentries do have a qualitybar. However is is only enabled:

I agree.

Err.. Just removing the check may be the correct fix; It doesn't make sense to limit capability here.

At least one configuration error I could identify by myself: Kleopartra -> GnuPG-System -> Smartcard -> Connecting Reader with port N. If it is written: Yubico YubiKey OTP+FIDO+CCID 0 then Yubikey is recognized. I forgot to write "Yubico Yubikey" at the beginning and the "0" at the end. Now smart cards and Yubikeys are working for gpg. What is still a problem is SSH. A SSH key is on smart card or the Yubikey.

The base64 for the version is not needed. I rebuilt and did a test for that. I was testing with Outlook 2016 to Outlook.com to another exchange server. One of the servers in the chain is converting the mime parts to base64.
The MAPI headers in gpgol are causing the auto-decryption of Symantec to stop checking for the MIME attachments. On internal emails the MAPI format is retained and that causes an issue with the symantec client. When they leave the exchange server the base MIME format is what is sent and that works with the Symantec client.

In T4809#131931, @werner wrote:

BTW, the qualitybar is not shown by default, only if you configure sme of the extra password checks. We may even remove it completely because it leads to wrong assumption on why a passphrase is required.

@Rycky_Tigg cases 1, 2, and 3 that you document here each show the behavior that i would expect from pinentry-gnome3, given the definition of its Assuan-based API and its use of gcr-prompter. (i'm assuming that in case 3 the user just waited longer than the allowed timeout)

Thank you for resolving this issue! I am successfully using version 2.2.19 from the gnupg (2.2.19-1~bpo10+1) package of Debian Backports.

"more specific about what you think is wrong"; From https://bugs.kde.org/show_bug.cgi?id=412569 copied)/pasted:

I think rGe573e6188dad: gpg: Fix --default-key checks. should be fixed as:

diff --git a/g10/getkey.c b/g10/getkey.c
index ad5dd8e01..cc908964e 100644
--- a/g10/getkey.c
+++ b/g10/getkey.c
@@ -1860,7 +1860,8 @@ parse_def_secret_key (ctrl_t ctrl)
           PKT_public_key *pk = node->pkt->pkt.public_key;

$ export GNUPGHOME=<somewhere>
# Create a key with "C"-only capability
$ gpg --quick-gen-key "test-user <chuji@gniibe.org>" ed25519 cert
# Create another key (or get/import it)
$ gpg --quick-gen-key "2020-user <chuji2020@gniibe.org>" ed25519
# Sign with the first key to the second key with --default-key
$ gpg --default-key 7694AB44DED1154CEB981059B0B36418AF85C918 --lsign 72FF31542DB059A507BAF81BE05523DEB4B018E6

(where 7694AB...85C918 is the first key and 72FF31..B018E6 is the second key)

rGe573e6188dad: gpg: Fix --default-key checks. is suspicious.

BTW, the qualitybar is not shown by default, only if you configure sme of the extra password checks. We may even remove it completely because it leads to wrong assumption on why a passphrase is required.

pinentry-gnome uses gcr's gcr_prompt_set_password_new to prompt for a new password, and ignores the SETQUALITYBAR assuan command.

It seems that gnome-keyring-daemon has some incompatible changes which breaks that version of pinentry-gnome. Or GKR has not been setup properly. I'd suggest to use pinentry-gtk until folks with knowledge about Gnome folks have figured out what is going wrong.

Hey. As reference – Complete set of features while run in Windows.

Please describe which features are missing.

Caching of the OpenPGP PIN while switching to and from PIV does now work in master

Using base64 encoding for a fixed format part in us-ascii is not a good idea because in practise many PGP/MIME decoders won't be able to detect and then decyrypt such a message.