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 <kloec...@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
_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-devel
