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