please do not mix signed+encrypted headers with unsigned+cleartext headers

[dkg]

Over in https://0xacab.org/schleuder/schleuder/merge_requests/46 i learned that mail-gpg handles an encrypted PGP/MIME message this way when asked for decryption:

mail-gpg […] Use[s] the decrypted parts as new mail-object and add all headers from the "outer", encrypted message into it (without overwriting any headers).

Either way we end up with a message that contains the cleartext, and also headers from the "outer" message.

This means that the resulting decrypted message object (which is also associated with some sort of signature status, if there was a signature within the encryption as well) has a mixture of cleartext+unsigned headers and encrypted+signed headers.

This is potentially pretty bad news, if any subsequent message handler infers something about the body of the message based on the headers which it thinks are signed, or had been protected by encryption. Is there no way to distinguish between the "inner" headers and the "outer" headers once decryption is done?

mail-gpg should provide the decrypted part independently from the outer cleartext/forgable layer so that handlers can distinguish between them.

[jkraemer]

That is an interesting point.

One of the design goals of mail-gpg was to be as transparent as possible, that's why it is the way it is (encrypted mail Message object in, clear text mail Message object out). I'd like to find a way to mark the headers somehow while keeping this transparency for systems that rely on it.

[dkg]

Unfortunately, the way that e-mail is constructed in general, it's not possible to reason clearly in this way.

Marking headers would be a good first step. However, it's not only headers that a MUA needs to think about -- it could also be MIME parts as well.

For example, what does mail-gpg do if only a subpart of the message was encrypted+signed? for example, you could have a message where only an inner part was encrypted+signed, but additional (spoofed) data is additionally attached.

[duckdalbe]

One option could be to store the verification-result with every header and mime-part, I think. E.g. by monkey-patching the corresponding classes and adding methods like was_signed?, was_encrypted?, signature, etc.