8bit mime support? (linked to thunderbird issue)

JL devm23k73ju29h3r at dolce-energy.com
Tue Jul 29 09:47:39 CEST 2025


Hi,

replying inline

Le 28/07/2025 à 23:59, Steffen Nurpmeso a écrit :
> JL wrote in
>   <d0e9c13f-8f1b-41fe-ac47-7531b0357669 at 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 at gnupg.org
> https://lists.gnupg.org/mailman/listinfo/gnupg-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250729/cda1bd4a/attachment-0001.html>


More information about the Gnupg-devel mailing list