Assigned to me for now to clarify what to do.
I wrote an encrypted mail with KMail 6.0 and Thunderbird did not decrypt it. Likely because the mime flag, Here is a list packets from GnuPG:
```
gpg: public key is 9601FCC868FBC929
gpg: public key is 2302FB703277A26E
gpg: public key is 5CB09E43DC49649F
gpg: using subkey 5CB09E43DC49649F instead of primary key 1FDF723CF462B6B1
gpg: encrypted with brainpoolP384r1 key, ID 5CB09E43DC49649F, created 2020-08-06
"Andre Heinecke <aheinecke@g10code.com>"
gpg: using subkey 2302FB703277A26E instead of primary key 50D0C31A3CAF5AF7
gpg: encrypted with cv25519 key, ID 2302FB703277A26E, created 2024-01-25
"someone"
gpg: using subkey 9601FCC868FBC929 instead of primary key 4D287687F33F47BF
gpg: encrypted with cv25519 key, ID 9601FCC868FBC929, created 2024-03-03
"someone else"
gpg: using "7093194AADBB8A2D14D3C9172978E9D40CBABA5C!" as default secret key for signing
gpg: using subkey 2978E9D40CBABA5C instead of primary key 1FDF723CF462B6B1
gpg: AES256.CFB encrypted data
gpg: keydb: handles=4 locks=0 parse=6 get=6
gpg: build=0 update=0 insert=0 delete=0
gpg: reset=2 found=6 not=0 cache=0 not=0
gpg: kid_not_found_cache: count=0 peak=0 flushes=0
gpg: sig_cache: total=72 cached=72 good=72 bad=0
gpg: objcache: keys=12/12/0 chains=371,1..1 buckets=383/20 attic=244
gpg: objcache: uids=3/3/0 chains=104,1..1 buckets=107/20
gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0
outmix=0 getlvl1=0/0 getlvl2=0/0
gpg: rndjent stat: collector=0x0000000000000000 calls=0 bytes=0
gpg: secmem usage: 0/32768 bytes in 0 blocks
# off=0 ctb=84 tag=1 hlen=2 plen=94
:pubkey enc packet: version 3, algo 18, keyid 9601FCC868FBC929
data: 4022F65778DD6B015C7B61578D1B9BD2F54493922720E5A6D31665415797B5996A
data: 30E77D89D8BBB2B180188DEB0E6652BB5ECD606777AE3601C03934420DEB3396AAD6E9C323BF5D8C3BFA147DD4785F21A9
# off=96 ctb=84 tag=1 hlen=2 plen=94
:pubkey enc packet: version 3, algo 18, keyid 2302FB703277A26E
data: 4096BD86DF64520C7DCCBB758899AC16EDE25E6B9329356E9C777680104FD70553
data: 3052AC1BE837AD9F992817CE803938B598B37A70E7EF91A44042039E5561B1ABCEFFF7A9805AE008581CB13DE31194EC85
# off=192 ctb=84 tag=1 hlen=2 plen=158
:pubkey enc packet: version 3, algo 18, keyid 5CB09E43DC49649F
data: 0410FEA1B9D07478B0922319456FABF7023FC491335C864856A22443475F15426130752B85E62001C83B69615620DFC50461D2A6C796C7A4FFBFA5D82775819B5C1B69FCB4623314F9622FC96DF9173560837E3051DB2316B5D49FAFD8630CDD10
data: 3073C584084CAF035F7969F4CD9D9C5258F4794D0C046766DE2D2494443ECF53E7260B792F9238330CA2B7568EB633430A
# off=352 ctb=d2 tag=18 hlen=2 plen=0 partial new-ctb
:encrypted data packet:
length: unknown
mdc_method: 2
# off=373 ctb=a3 tag=8 hlen=1 plen=0 indeterminate
:compressed packet: algo=2
# off=375 ctb=cb tag=11 hlen=2 plen=0 partial new-ctb
:literal data packet:
mode m (6D), created 1711445433, name="",
raw data: unknown length
```
The error in TB looks like:
{F8116729}
The likely candidates for changes on our side that triggered this are:
{T6582}
{T6583}