bonjour, JL wrote in <5f128210-e6f3-40a5-af14-3547769ed...@dolce-energy.com>: |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" 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 _______________________________________________ Gnupg-devel mailing list Gnupg-devel@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-devel
