1966019 - 8bit mime encoding ignored base64 always applied (30 years after rfc...)

Status: RESOLVED INVALID

(Thunderbird :: Untriaged, defect)

Description

[mozom23kqi362her]

Steps to reproduce:

I use eml mdir storage, lattely I had to send not so big file by email (gpg signed for legal purpose, so I can't send it using cloud storage since cloud files can be modified)
due to base64 encoding hoverhead, the email exceed the server capacity
I tried to force thunderbird attach as 8bitmime using mail.file_attach_binary, tried mail.strictly_mime as found when searching... no luck.... displaying the email source show that base64 used everytime

Actual results:

base64 used everytime (even for utf-8 which is a shame since utf-8 already introduce overhead....)
--------------0H0l0O0ve0LCC0brMLPANAI7
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: base64

Expected results:

the https://www.rfc-editor.org/rfc/rfc1869 is 30 year old, old smtp server that are not 8 bit compatible are either unsafe or not used anymore. BUT clients still force base64 and create overhead

• client/server storage overhead (when the storage is not related to smtp, eml files could be 8bitmime, even 8bitmime zipped)
• transfer overhead (the smtp server will, if needed recode into base64 if remote smtp server don't support 8bitmime)

8bit base encoding should be the default, not base64, we are not in pre-historic time anymore.

Comment 1

[Magnus Melin [:mkmelin]]

It's intentional: https://searchfox.org/comm-central/rev/73897d5732eac86ed38bd521ca6f4610a4411186/mail/extensions/openpgp/content/ui/enigmailMsgComposeOverlay.js#1309-1326

Comment 2

[mozom23kqi362her]

the comment state "the UTF-8 bytes given to GPGME might get incorrectly transformed, so let's use base64 here, too."
is it a problem of GPGME? what would make that the 8bits data get corrupted? I can sign/encrypt binary files using gpg with no problem....
if this is a bug of GPGME, maybe it has been fixed?

Comment 3

[mozom23kqi362her]

I tried with a not gpg signed unencrypted message with a pdf attacheement :

--------------0W9gi9agpZPs9ZIRhWUUCJwC--
--------------fhiKv9JJyrU7ZvJxUQJR8Sqf
Content-Type: application/pdf; name="wilo252503.pdf"
Content-Disposition: attachment; filename="wilo252503.pdf"
Content-Transfer-Encoding: base64

the pdf is still base64 encoded, when the comment state "We usually don't use base64 encoding for the inner payload"
so the bug is still valid : 8BITMIME isn't used.... whatever the message use GPG or not

the eml file on disk use 6.4M while the message is empty, only a subject and 4.7MB pdf attachement so 40% overhead....

Comment 4

[Magnus Melin [:mkmelin]]

(In reply to mozom23kqi362her from comment #2)

if this is a bug of GPGME, maybe it has been fixed?

Doubt it. That code was added within the last year, to fix compatibility.