<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">Le 01/08/2025 à 12:40, Jeffrey Walton
via Gnupg-devel a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:CAH8yC8=1Q-1VFBBP7cSoy6+EE+0QeenU55d-0U-bVoLzRj2w3A@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr"><br>
</div>
<br>
<div class="gmail_quote gmail_quote_container">
<div dir="ltr" class="gmail_attr">On Fri, Aug 1, 2025 at
3:49 AM Ingo Klöcker <<a href="mailto:kloecker@kde.org"
moz-do-not-send="true" class="moz-txt-link-freetext">kloecker@kde.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On
Donnerstag, 31. Juli 2025 23:28:51 Mitteleuropäische
Sommerzeit JL wrote:<br>
> well it does compress, however you can't compress it on
the imap server,<br>
<br>
Pardon my ignorance, but why can't the IMAP server store
your emails <br>
compressed? Maybe you should complain to the operator of the
IMAP server if, <br>
in your opinion, they are wasting storage space. Or complain
to its authors if <br>
you are operate the server yourself.<br>
</blockquote>
<div><br>
</div>
<div>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.</div>
</div>
</div>
</blockquote>
<p>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.</p>
<p>Beside, there is mail quota... so you can't store everything on
imap</p>
<blockquote type="cite"
cite="mid:CAH8yC8=1Q-1VFBBP7cSoy6+EE+0QeenU55d-0U-bVoLzRj2w3A@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote gmail_quote_container">
<div> </div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Given the insane growth of email headers it would actually
make sense that the <br>
IMAP server used compression. Taking your message (as it is
stored on my IMAP <br>
server) as example:<br>
Size of the header: 12,315 bytes<br>
Size of the body: 8,556 bytes.<br>
<br>
By the way, why is the body of your message base64 encoded?
Was is re-encoded <br>
in flight or did your Thunderbird send your unsigned plain
text message base64 <br>
encoded?<br>
</blockquote>
</div>
</div>
</blockquote>
<p>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.</p>
<p>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...</p>
<p>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... </p>
<p>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... </p>
<p>so the problem is multiple :</p>
<ul>
<li>user email client : don't handle well binary.... and don´t
encode data "on the fly" when talking with the smtp server....</li>
<li>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... </li>
</ul>
<p>best regards</p>
</body>
</html>