8bit mime support? (linked to thunderbird issue)

Steffen Nurpmeso steffen at sdaoden.eu
Tue Jul 29 18:33:43 CEST 2025


bonjour,

JL wrote in
 <5f128210-e6f3-40a5-af14-3547769edc8f at dolce-energy.com>:
 |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"

I see you meant it "beyond GPG", but in general.
Here: as above, certain characters are not allowed in email
protocols, and, as far as i see that, i do not think that will
change.  So "anything binary", it will need an encoding.

 |> 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...

Fun fact.  The MUA i maintain still sends (in the released
version) anything 8-bit over SMTP .. without using the according
SMTP extension.  It does so for way over twenty years, and the
program was a bit famous by then (long before i took
maintainership).  I never saw nor heard complaints.

 |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?

Certain people do the latter.
And i think you overcomplain a bit, because for example the
terrible but omnipresent XML and JSON do not support the full
spectrum too, you need a different kind of encoding to pass data
through them.  (There are certain SMTP extensions to send binary
data though.)  As i love (an unconstrained) email i find it unfair
to only complain on the very old (and misused) lady email, when
those "new" protocols/formats fail to deliver what you want?

 |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

I know such wall hammerings.  I will have no remaining
intellectual teeths when i die, and it could be i end with only
"More Light!", in famous company thus.

 |best regards

Ciao,

 |>|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



More information about the Gnupg-devel mailing list