8bit mime support? (linked to thunderbird issue)

[JL]

>  a smart server would have received the data, and decoded once for 
> all, like this, it'll have been network efficient and storage 
> efficient, but this introduce the issue of PGP signing... since the 
> message is "modified" and don't know how to scope with this matter... 
> is it possible to "sign" each part before encoding? (like a checksum 
> file containing all the checksum of every attached file for example)
>
> if it's assumed that the message MUST not be altered, you have to go 
> the safe way : encode everything in 7bit ASCII
>
> if the signing can be done "part by part in binary" then there is 
> nothing to worry about "re-formating" and a SMTP server can choose to 
> send it binary (if BINARYMIME and BDAT is supported) or re-code it....
>
replying to myself after reading the

  * rfc4880 " OpenPGP Message Format"
  * rfc3156 "MIME Security with OpenPGP"

the latter state that, because the message can be reformated,

    However, many existing mail gateways will detect if the next
    hop does not support MIME or 8-bit data and perform conversion to
    either Quoted-Printable or Base64.  This presents serious problems
    for multipart/signed, in particular, where the signature is
    invalidated when such an operation occurs.  For this reason all data
    signed according to this protocol MUST be constrained to 7 bits (8-
    bit data MUST be encoded using either Quoted-Printable or Base64).

that's too bad, since in fact the "format" is enforced before signing, 
while they could have chosen the opposite : enforcing all binary fike to 
be presented into binary format in the mime message, and signing 
versification should only be performed once restored to original format....

and in fact a false issue... the signature won't be invalidated if the 
presentation change, since the presentation shall not alter the original 
content and is reversible... so it just needed to force the orginal 
format to create the message with binary data when binary data, 8bit 
strings when 8bits strings, eg removing the formating process.

On reception, the receiver remove the formating, going back to binary 
for things that are binary, and validate the unformatted content... it 
would have been compatible with other RFC effort to allow binary data to 
go through the smtp protocol...

really, too bad...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250802/04f0a78c/attachment-0001.html>