8bit mime support? (linked to thunderbird issue)

[JL]

Le 30/07/2025 à 21:34, Andrew Gallagher a écrit :
> On 30 Jul 2025, at 19:35, JL <devm23k73ju29h3r at dolce-energy.com> wrote:
>> here what I get when sending a signed message :
>>
>>
>> This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
>> --------------O0jQavEJzad0tdgqdlXTuPu2
>> Content-Type: multipart/mixed; boundary="------------FWDnkJ83p73oQajQk66iKNQY";
>> protected-headers="v1"
>> From: XXXXXXX
>> Reply-To: XXXXX
>> To: YYYYYY
>> Message-ID: <8176a3b2-bafa-4339-8776-7768e72a0333 at dolce-energy.com>
>> Subject: ZZZZZZ
>>
> Yes, and here’s what I get when printing to PDF:
>
> %PDF-1.3
> %���������
> 3 0 obj
> << /Filter /FlateDecode /Length 364 >>
> stream
> &؀���k_L1lc�`�V�����.)���͋�Ŷ��HZ�}��!�5Y�CZޕ"��1�m�F�gv:��B�G�Y��
> �+<���+$|�*r)+?fE���\{��D{S�                                   �Cԗ"�5
>                               ]O���H˘�������`�[
>                                                �����;��fs��j�@��p=�_�6�@B��sR���2fnM���M����3g:k��&��ه�"��Y�B{ڃ/5U��u��2Q�X�ș��b���(M�UoN�����f򑣁7��_�%�?�O�`p�!Ӌ�dc�D�
> r���¢���1�a��&�g���
> endstream
> endobj
> 1 0 obj
>
>
> What’s the problem? Emails and PDFs may *contain* plaintext, but they aren’t raw plaintext, and never have been. The fact that one particular encoding of emails happens to look very similar to plaintext IFF you are using a language that only requires US-ASCII characters is a historical curiosity. Email encodings are completely transparent to the end user if you use an actual email program and not a text editor.
>
> My honest and heartfelt advice is to please stop worrying about it, it’s been a solved problem for several decades now. If you have limited disk space, base64 compresses really efficiently. Please don’t read your emails in vim, you’ll only generate excess cortisol and shorten your lifespan.
>
> A

well it does compress, however you can't compress it on the imap server, 
and to be frank, you gain about 50% average compared to the base64 eml, 
you finish with about 2% overhead on a jpeg file (that  that's still 
waste of disk space... you only solve the matter of disc space 
"somehow", and the bandwidth matter, server storage matter? and after? 
is there ".emlz" format? email reader that know how to handle them? what 
the point of a zipped email if to open it you have to decompress it, and 
then open it through a email reader? I also have to compress it by hand, 
one after another... nice! (even if I can script it for encoding, for 
reading I need to it one email after another) don't worry! you gain disc 
space and loose your life doing it... non even counting how you perform 
search once it's out of the mail application? and the fact that to open 
a single email it'll takes 10s just to decompress it... and the power 
consumption, CPU consumption... well! really, I should not worry about 
it! the solution is as worst as the base64... why not cipher it? like 
this you'll never be able to find it again and you'll just loose space!

and the "Emails and PDFs may *contain* plaintext" => great..... and?

does theses software know about the 
boundary="------------FWDnkJ83p73oQajQk66iKNQY" (example) ? why are they 
processing the text contained? it's nonsense! and a bug (not counting 
it's also a security issue, since you can perform code injection using 
the fact it will try to interpret the data)(now I understand how some 
people done virus using jpeg file at a time, if the email client might 
do something because in the jpeg there is injected ASCII...) ... 
boundary were created to detect the end of the attachment, anything 
between is just... DATA!

the code is rather simple : while(curr!=eof && strncmp(curr, boundary, 
sizeof(boundary)) curr++;

if fact, wathever the encoding, there is no need to interpret the 
data... even if there is ascii in the attachement, the client has no 
need to say "oh! there is ascii there, maybe should I do some stupid 
thing with? or change my processing mode? oh! looks, it's some script! I 
should try to execute it!!" if the encoding is 8bitMIME, then there is 
nothing to do, just consume the data until the boundary is found... 
other encoding need to be decoded into memory (so you can't do a mapped 
file access, you need either to dump it in temporary file, or store it 
into memory... 2 inefficient resource access)

"it's a solved problem for several decades now" ahaha... a solved 
problem... there is nothing solved... it's just workaround, and not a 
good workaround (if there are "good" workaround), no wonder we need 
today 16GB of ram, ryzen 7 12 cores CPU, and fiber optic 1Gbps 
connection to just surf the web, read some emails and type some word 
document...

just some tests  : a 33MB random pdf file that was sent to a client, AMD 
Ryzen 7 5825U

time to compress using 7za : 14s the base64 version, 7s the pdf version 
(twice the time...) and 14s overhead compared to raw access on a modern 
CPU (ok, not the fastest... but there is something wrong if you need a 
supercomputer to read emails...)

base64 overhead once compressed : 2MB..... (yes, after compression, the 
file is bigger if gone through base64, it's 33% smaller if the raw file 
is compressed)

and this is a SINGLE FILE, so now do it on all the emails, and all the 
attachments

yes, really, I should not worry! I just have to change computer every 2 
years and buy some storage every 6 months, change my network connection 
every 3 years...

the solution is inefficient, resource consuming, and just to avoid doing 
a thing that is 30 year old... seems indeed that at this time, because 
they didn't had supercomputer, slow connections, they done the thing 
that is not <biiip> and that is the only thing to do, rather than trying 
to say "don't worry, we solved the issue, do a <biiip> workaround"

it remember the ones that says "oh you need that? well I'll teach you 
how to need it"

best regards