<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi,</p>
<p>replying inline</p>
<div class="moz-cite-prefix">Le 28/07/2025 à 23:59, Steffen Nurpmeso
a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:20250728215919.fPT7hycU@steffen%25sdaoden.eu">
<pre wrap="" class="moz-quote-pre">JL wrote in
<a class="moz-txt-link-rfc2396E" href="mailto:d0e9c13f-8f1b-41fe-ac47-7531b0357669@dolce-energy.com"><d0e9c13f-8f1b-41fe-ac47-7531b0357669@dolce-energy.com></a>:
|I wanted to open a ticket on GPGME because thunderbird team says they
|can't encode email using 8bit mime because of GPGME not handling
|correctly 8 bit content
|
|<a class="moz-txt-link-freetext" href="https://bugzilla.mozilla.org/show_bug.cgi?id=1966019">https://bugzilla.mozilla.org/show_bug.cgi?id=1966019</a>
|
|8bit RFC is 30 year old, using base64 to "keep compatibility with old
|not maintained server/client" is energy/storage/network inefficient.
8bit brings you nowhere because of line endings for example, which
must be normalized. This cannot be expressed in 8-bit.</pre>
</blockquote>
ah... so '\n', '\r' and '\r\n' are not 8 bit on my text files ;).
There is no need to "normalize" because after all it's only 8bit
wide or aligned (see later for 7bits)
<blockquote type="cite"
cite="mid:20250728215919.fPT7hycU@steffen%25sdaoden.eu">
<pre wrap="" class="moz-quote-pre">
Also, during fly, for example mailing-lists, message reencodings
happen. (For example Mantis seems to enforce 8-bit *at times*,
mailman(2) is notorious for base64.)</pre>
</blockquote>
don´t care if some stupid software have bandwidth to loose... as
long it's not mine. If a SA is old enough and don't care about it's
storage to still use mailman and enforce base64... well, fine, but
it has to worry about security of it's server... because a software
that enforce base64 just to "correct" some bug (afterall, base64 was
only created to go through 7bit servers)
<blockquote type="cite"
cite="mid:20250728215919.fPT7hycU@steffen%25sdaoden.eu">
<pre wrap="" class="moz-quote-pre">
Sometimes you need to use encoding anyway, for example overlong
lines, ^From_ lines (really SHOULD), control characters...
So content-transfer-encodings like base64 and quoted-printable
will not go away in the future, no matter what.
The question to me is why it disturbs you in practice, beyond
a possible mind itching -- the latter i can understand, but
actually, over time, turned into a complete SMTPUTF8 and other
such stuff well heavy disliker.
(I concur that Unicode for email local-part's must be done
somehow, but that is it; and message/global definetely not, for
me.)</pre>
</blockquote>
<p>because I've work duties, and amongst them, be sure that I've
proof that the documents where not modified and that I sent the
documents to the clients, such documents takes spaces and are
base64 encoded with NO REASON because they are BINARY,</p>
<p>that the header have some base64, well fine, the overhead won't
be too much because the content is small, but because of some
gpgme bug, thunderbird enforce base64 and then even on binary
content. If the message is sent unsigned, without GPG, then the
8bitMime is used </p>
<p>it distrub me in practice because</p>
<ul>
<li>local stored emails are taking much more space in base64, </li>
<li>because I often have to keep the same data in multiple format
: original on disk, to be able to access it, one copy on disk in
eml format for legal purpose, in "source format" also..... this
takes lot of space, if you add the base64 overhead... it count
in GB overhead for... nothing... </li>
<li>that it consume network data, that I've limited data (I use
cellphone sharing, because I move a lot and can't have an fixed
point connection) </li>
<li>that I often have to split the message into part, and the
base64 makes more parts because of it's overhead, so it create
more work</li>
<li>because I can't use "cloud" storage, because they are not
legal proof. (not mentionning the fact that I've to keep the
data on the network drive for 10 years, that it'll be accessed
once, and that it have to have a 24/24 7/7 power consumption and
instant storage access for something that can stay on a backup
mass storage.... and that MIGHT be asked) </li>
<li>and it distrub me because thunderbird has to change 8bit mime
to base64 just because of some gpg bug... </li>
</ul>
<blockquote type="cite"
cite="mid:20250728215919.fPT7hycU@steffen%25sdaoden.eu">
<pre wrap="" class="moz-quote-pre">
My reasoning finally was and is that the email content
representation can never be an end-user thing, despite
sensational representations during engineer congresses.
The email headers become a more and more crowded mess (look for
example out Outlook.com header content), and certain parts of the
actual content will also always require "utilities" (image etc
viewer).
So in fact there is nothing plain text except for possibly (and
lesser and lesser so) a single text/plain part.
And for that alone, why all the hassle?</pre>
</blockquote>
because 8bit mime, is not for plaintext... it's, as the 'MIME' says,
attachement, and attachements are... 8bit data, not "text"
<blockquote type="cite"
cite="mid:20250728215919.fPT7hycU@steffen%25sdaoden.eu">
<pre wrap="" class="moz-quote-pre">
If you look at the email in a MUA, you will see the content as
desired, if you store the part somewhere on the disk it will have
been converted also. I presume all that, say.</pre>
</blockquote>
you presume, because in fact, the clients are just transfering the
eml as is, store them as is, and just be able to handle all the
cases, like a text editor handle '\r\n' dos endofline, '\n' unix
endofline... they just "detect" what is used, decode them.
<blockquote type="cite"
cite="mid:20250728215919.fPT7hycU@steffen%25sdaoden.eu">
<pre wrap="" class="moz-quote-pre">
So why does it have to be 8-bit?</pre>
</blockquote>
<p>because all what you said, is somewhat false, even headers could
be 8 bit without issue, keeping appart some stupid unmaintained
MTA/client/webmail that rely on some old RFC.</p>
<p>WHY? because the data transfered on network is 8bit boundary,
7bit was already not so widely used when I first used my dad
computer 38 years ago, and there was no internet at this time in
France, 4 years latter when 14,4kbps modem appeared, it was
already 8bit .... ok there was at this time some 7bit (already
old) computers... and ebdict IBM "supercomputer".... are they
still working? doubt it... </p>
<p>so why do we still ENFORCE 7bit ascii for something that is
no-where more used? do you know a single 7bit CPU still there?????</p>
<p>if you can handle 8bits, you can handle 7bits... so leave the
oldies rest in peace and move forward. </p>
<p>base64, 7bit ascii, EBDICT, base32... quoted printable... are
just oldies... they had their use, they are now just no more
needed and belongs to history... you still use the old 5"1/4
floppy disk?</p>
<p>now it's just energy inefficient, storage inefficient, network
inefficient... and like keeping able to speek with a 1rst century
english people... it's fun to read and not understand, but... it's
no use</p>
<p>best regards</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:20250728215919.fPT7hycU@steffen%25sdaoden.eu">
<pre wrap="" class="moz-quote-pre">
|the thunderbird teams introduce workaround instead of working with GPG
|team to have the issue fixed.... seems that non gpg email are 8bit mime
|on thunderbird for the main message, base64 for the attachements
|
|would be nice to have the issue fixed so that base64 mime could be
|dropped, but don't know what is the issue they faced... maybe someone
|can participate on the thunderbird ticket so that the subject can go on?
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
|
|During summer's humble, here's David Leonard's grumble
|
|The black bear, The black bear,
|blithely holds his own holds himself at leisure
|beating it, up and down tossing over his ups and downs with pleasure
|
|Farewell, dear collar bear
_______________________________________________
Gnupg-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Gnupg-devel@gnupg.org">Gnupg-devel@gnupg.org</a>
<a class="moz-txt-link-freetext" href="https://lists.gnupg.org/mailman/listinfo/gnupg-devel">https://lists.gnupg.org/mailman/listinfo/gnupg-devel</a>
</pre>
</blockquote>
</body>
</html>