--rfc4880 option doesn't work after upgrading from gpg4win 4.0.3 to 4.1.0

We encrypt some files with the option --rfc4880, because a particular recipient got the error “unknown packet type 20”. This worked, the files could be decrypted. But after we upgraded gpg4win from version 4.0.3 to version 4.1.0 this doesn’t work anymore. We use the same command in our script but the recipient gets the error “unknown packet type 20”, just like before we added the --rfc4880 option.
We deinstalled version 4.1.0 and reinstalled version 4.0.3 and now the recipient can decrypt the files again.
So I think this is a bug in version 4.1.0 of gpg4win.
Is this a bug and is there another way to get the same results (as with the --rfc4880 option) which still works in version 4.1.0?
Windows version: Windows server 2016
gpg version which works: 2.3.7
gpg version whih doesn’t work: 2.4.0

Do you know which application the recipient is using to decrypt the file? At least I was able to decrypt a file with Gpg 2.3.7 that was encrypted with Gpg 2.4.0 (with option --rfc4880) and the other way around.

Thanks for the reply Christoph.
We asked the reciept what they use, they use the C# library bouncycastle.
They say that they strictly follow the RFC4880 standard and that the “packet type 20” isn’t part of the standard.
That is why we made a version of our script for them with the --rfc4880 option. This worked, but this didn’t work anymore after the upgrade.
We just also tested it with the option --openpgp, but this also doesn’t work with the new version.
Other recipients don’t have any problem.

I created this bug report: https://dev.gnupg.org/T6422. There you can see when the developers ork on this case. If you create an account on that website you can also subscribe to that case and receive emails when there are any updates.

It’s true: Packet type 20 is not part of RFC4880 (https://datatracker.ietf.org/doc/rfc4880/) which is from 2007. But there is an updated standard in work (https://datatracker.ietf.org/doc/draft-koch-openpgp-2015-rfc4880bis/) and it has some additional features. It seems that other clients have already implemented these features (GnuPG belonging to them) but that library hasn’t implemented them yet.

It may seem a bit weird that features are already implemented that are written down in a draft only but it’s often that way that there are reference implementations before there is a standard.

Thanks Christoph! The answer from the bug report solved the problem. I don’t know why we got the problem after the upgrade to version 4.1.0, maybe in the old version the --rfc4880 compatability option did override the preference system, but I’m not sure.
The public key we got from the recipient had indeed “A2” as a prefence listed. As the compatibility option doesn’t override the preference from the key we used “packet type 20”. We asked the recipient to remove the “A2” preference as described in the answer:
gpg --edit-key on your private key
gpg> pref
[ultimate] (1). someone@somewhere
S9 S8 S7 S2 A2 H10 H9 H8 H11 H2 Z2 Z3 Z1 [mdc] [aead] [no-ks-modify]
gpg> setpref S9 S8 S7 S2 H10 H9 H8 H11 H2 Z2 Z3 Z1 [mdc] [aead] [no-ks-modify]

After we got the public key from them and imported the public key the recipient could decrypt the files.

Thanks for telling us that it is working! Great to hear that you could solve the problem.

With regards,