Le 30/07/2025 à 21:34, Andrew Gallagher a écrit :
On 30 Jul 2025, at 19:35, JL <devm23k73ju29...@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-7768e72a0...@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�����f7��_�%�?�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
_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-devel
