8bit mime support? (linked to thunderbird issue)

[JL]

Le 01/08/2025 à 12:40, Jeffrey Walton via Gnupg-devel a écrit :
>
>
> On Fri, Aug 1, 2025 at 3:49 AM Ingo Klöcker <kloecker at kde.org> wrote:
>
>     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.
>
>
> I would hazard a guess that it relates to searching and sorting. IMAP 
> supports the SEARCH command. The SEARCH command allows searching on 
> the server based on keywords/free text, date ranges, and header fields.

this is server side... doesn't apply to local storage, you might want to 
keep things on server, I don't. Even if it's usefull, a server is a good 
target for hackers, even google, apple, facebook, got hacked, they often 
assure that "no personal emails were gatered" we just have their words, 
no one beside them know the truth... since emails on servers are not 
cyphered, all the important data is freely accessible.

Beside, there is mail quota... so you can't store everything on imap

>     Given the insane growth of email headers it would actually make
>     sense that the
>     IMAP server used compression. Taking your message (as it is stored
>     on my IMAP
>     server) as example:
>     Size of the header: 12,315 bytes
>     Size of the body: 8,556 bytes.
>
>     By the way, why is the body of your message base64 encoded? Was is
>     re-encoded
>     in flight or did your Thunderbird send your unsigned plain text
>     message base64
>     encoded?
>
Because it's the safe fallback, and rather than make the things evolve, 
all email client prefer the safe way : the one that will works even on 
30 years ago server/client.

8bit mime isn't perfect because it didn't defined way to handle the crlf 
in binary or because it didn't enforced that the buffer has to be 
filled. Smtp defined a way to prevent end of transmission if the message 
contains <cr><lf>.<cr><lf> but I didn't saw some escape mecanism for 8 
bit mime... which means that it's up to the client to handle this case 
(even if in binary data, it should occurs not so often) don´t know if 
there is some rfc that define way to escape <cr><lf> so that they could 
be dropped by client (for example <cr><lf> in data recoded into 
\<cr>\<lf> so that <cr><lf> can be dropped) anyway this is only a smtp 
issue, or the server should handle rfc3030 "BDAT" command for example 
that is cleaner...

beside the smtp consideration, on IMAP side, the data can be accessed in 
binary, and mime has a "Content-Transfer-Encoding" binary... so from the 
client point of view, the received message could be "decoded" on the fly 
and stored with decoded value...

some server might transform the data (because one server on the way 
don't handle BDAT for exemple) but the end server could re-code it as 
binary... instead of keeping it base64...  The problem is that client 
often "write the data to file" and then "send the file through smtp" so 
not knowing if the smtp server can handle the BDAT... so the safe way, 
if you don't know the server, is to encode everything in base64...

so the problem is multiple :

  * user email client : don't handle well binary.... and don´t encode
    data "on the fly" when talking with the smtp server....
  * SMTP : a server might encode to base64 because the other server
    don't handle BDAT transmission, if there are relay server, they
    should reverse it back to binary.... and the final server should
    re-format the data...

best regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250801/be02af8e/attachment.html>