Here is my idea to implement the feature:
(1) Extend struct iobuf_struct to have a field of temporary output (of int), just after real_fname.

• OUTPUTFILE: When it's 1, a file generated with real_fname original suffix removed and appended .tmp is used for the output

(2) Modify get_output_file in plaintext.c and make_outfile_name in openfile.c, so that OUTPUTFILE above is used and the field in iobuf_struct is marked.
(3) Modify proc_encrypted in mainproc.c so that rename .tmp file to the OUTPUTFILE or remove it when failure.

Alright, I change it from for notation data (and name).

[GNUPG:] NOTATION_NAME foo@foo.org
[GNUPG:] NOTATION_FLAGS 0 1
[GNUPG:] NOTATION_DATA bla%20bla%20��%20blub

with change:

[GNUPG:] NOTATION_NAME foo@foo.org
[GNUPG:] NOTATION_FLAGS 0 1
[GNUPG:] NOTATION_DATA bla%20bla%20%81%82%20blub

Since rfc2440 the PGP specs say:

That's a good question. Looking at https://datatracker.ietf.org/doc/draft-koch-librepgp/, it doesn't really specify what encoding is used for "human-readable" notation, so I'd personally lean towards encoding it to stay on the safe side. Unless I'm mistaken, status-fd will only be used locally, so escaping overhead should not be a problem.

Will be in 2.5.14 but I am not yet sure whether or when we put support into gpgme

There will be a new "pfc" record to emit the used preferences after a "uid" record. --list-options show-pref must be given.

The question is who shall correct the wrong encoding of notation data (assuming it is flagged as human readable). Escaping is a solution but needs a lot of extra bytes.

Implemented but not tested at all.

For completeness, that's https://gitlab.freedesktop.org/poppler/poppler/-/issues/1595. dkg obviously filed that but it may be useful for others finding themselves here.

Fixed in 1.56.

I updated the branch.

We also discussed emails that can't be decrypted. They are due to implementation details just currently skipped. They will also be so in the future as an implementation detail.

Also implemented for 2.2

I see no workaround.
The attachments in the original mail are not gone, yes.
But the mail can't be forwarded with them.

ok, changed the text in the description of the ticket accordingly, but put two more "team" back in.

Dialogtext (winzige Politur):

We decided to

We got new suggestions for this:

Especially when an LDAP is configured, keys should be automatically refreshed in short intervals (5 days? Configurable?) to notify users about revoked keys or signatures from a trusted key.
Keys that are close to their expiration dates should be prioritized.
Maybe users want to configure for what mail domains a lookup on a configured LDAP should be done.

I think it is save to say that we will not implement pgp/inline encryption with attachments

The problem here is that we don't have the sha-2 fingerprint in our SQL tables. Thus we would not only need to do a full table search but also parse the actual blob to compute the sha-2 fingerprint.

I have done testing using my QES certificate with all combinations of the two options.