8bit mime support? (linked to thunderbird issue)

[JL]

Le 01/08/2025 à 09:48, Ingo Klöcker a écrit :
> On Donnerstag, 31. Juli 2025 23:28:51 Mitteleuropäische Sommerzeit JL wrote:
>> well it does compress, however you can't compress it on the imap server,
> Pardon my ignorance, but why can't the IMAP server store your emails
> compressed? Maybe you should complain to the operator of the IMAP server if,
> in your opinion, they are wasting storage space. Or complain to its authors if
> you are operate the server yourself.

you have nothing to be pardonned, I'm not the most up-to-date and rather 
ignorant on the matter...

well, they might, but it don't means your quota will (and then that 
you'll benefit) they surely do it, storing on filesystem with 
transparent compression... But they can't compress it serverside without 
rewriting the message (they have to keep the mime file format so that 
the client can read them... 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....

just guessing, how a smtp server will handle if it received a BINARYMIME 
and have to talk to a non BINARYMIME server, what will they do?

enclose the whole message into a

    Content-Type: message/rfc822;
    boundary="------------AF0V9AuRuaNTRxYbEuAis34i";
    Content-Transfer-Encoding: base64
    XXXXXXXXXXXX
    XXXXXXXXXXXX
    ------------AF0V9AuRuaNTRxYbEuAis34i"

?

best regards


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