AFAICS the bounce is correctly reported. You get the 550 at the mail from so that there won't be a need for several SPF checks if a sender wants to send to several recipients.

I extracted data from https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-pqc-02 and compose x25519 key and MLKEM768 key. Here they are.
x25519 :

We have discussed this yesterday. The idea/plan is to release the core library and the bindings as separate tarballs (created from the same repo) in the future.

Thanks for reporting this. Returning error codes to upper layers is not always easy because the original logic is that we have a global error counter to decide whether an operation succeeded. My fix to check the error code before emitting the DECRYPTION_OKAY status,

Hello Werner,
the above is an excerpt from the exim log, I do not think the full bounce is more enlightening, vsrv21575.customer.vlinux.de got 550 from ellsberg.gnupg.com after " MAIL FROM:<ametzler@bebt.de>":

handle_plaintext gets data returned by iobuf_read, and does not check the error status of the iobuf object.

But only if you can figure out in a transaction or locked sytate whether the card needs a verify. Otherwise we have a race between changing the PIN and verifying a PIN.

This rejection could be relaxed.

Changes:

• The maximum allowed difference of the expiration between subkey and primary key is now +/-1 hour.
• If the user has no choice whether to update the subkeys together with the primary key (because either all subkeys will be skipped because they don't fulfil the conditions mentioned in the first comment or because the subkeys share the expiration of the primary key) then the checkbox is not shown. That was easier to implement and it doesn't confuse the users with a "choice" they are not allowed to change.