Hi,
replying inline
Le 28/07/2025 à 23:59, Steffen Nurpmeso a écrit :
JL wrote in
<d0e9c13f-8f1b-41fe-ac47-7531b0357...@dolce-energy.com>:
|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
|
|https://bugzilla.mozilla.org/show_bug.cgi?id=1966019
|
|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.
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)
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.)
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)
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.)
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,
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
it distrub me in practice because
* local stored emails are taking much more space in base64,
* 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...
* 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)
* 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
* 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)
* and it distrub me because thunderbird has to change 8bit mime to
base64 just because of some gpg bug...
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?
because 8bit mime, is not for plaintext... it's, as the 'MIME' says,
attachement, and attachements are... 8bit data, not "text"
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.
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.
So why does it have to be 8-bit?
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.
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...
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?????
if you can handle 8bits, you can handle 7bits... so leave the oldies
rest in peace and move forward.
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?
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
best regards
|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
Gnupg-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-devel
_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-devel
