GNOME Bugzilla – Bug 207154
base64 vs stupid mailing lists
Last modified: 2017-10-09 23:41:57 UTC
Ability to select a 8bit-clean content-transfer-encoding for outgoing email is needed (i.e. the CTE that will be used when SMTP host or sendmail doesn't accept raw 8bit messages) - i.e. between quoted-printable and base64. It's because very popular list managers have severe bugs wrt support of base64 encoding (they just append list signature to base64-encoded body, that on decoding gives a binary garbage at the end of the mail that corrupts xterm screens or even crashes them). Solution to that problem is using quoted- printable for email. Most non-latin1 people will definitiely select quoted-printable, so it would be better to make it default.
See bug 206666 for the reverse of this (when we receive messages broken in this way.)
I think providing the user with a choice here is the wrong solution, because that allows the user to make the *wrong* choice. It would be better to have a solution that always does the right thing, whether or not the user is aware of the issues. One solution that wouldn't require user-cluefulness would be to always wrap base64-encoded parts inside a multipart, so you'd end up with Content-type: multipart/mixed --boundary Content-type: text/plain; charset=koi-8r Content-transfer-encoding: base64 base64 gunk --boundary-- Stupid non-MIME-compliant mailing list footer gets appended here Since non-MIME-compliant mail readers won't be able to decode the base64 anyway, it shouldn't make it any less readable... ? Contrariwise, we could say "don't use base64 except inside multiparts", meaning if we were sending a message with Content-type: text/plain, we'd always use quoted-printable, but if we were sending multiple parts (whether /mixed, /alternative, or /related), we'd allow base64 inside them. (Note that "we don't care about this because the mailing lists are broken" is not a good answer, given that the Ximian mailing lists exhibit this broken behavior :-)
Wow, thats a really awful problem. FWIW evolution only encodes if the smtp server says it doesn't support 8 bit. And only uses base64 if other smtp requirements demand it (embedded 0 characters, or lines longer than 999 characters), otherwise it uses quoted printable. Umm, we could use the stuff in camel from the mailer to determine if the message might be produced like this, and multipart it when sending? (this doesn't really have anything to do with i18n, fwiw - re the keyword).
*** This bug has been marked as a duplicate of 206666 ***
I think the discussion here is more useful than in 6666's, so I'm reversing the "is a duplicate of"-ness.
*** bug 206666 has been marked as a duplicate of this bug. ***
btw, I recently got a message sent with Outlook Express and it had the same exact issue. PC9CT0RZPg0KPC9odG1sPg0KGnupgdevelmailinglistGnupgdevelgnupgorghttp//listsgn upgorg/mailman/listinfo/gnupgdev
Dans solution seems best to me. I dont think this is really a 1.0 requirement though?
Agreed with notzed about 1.0; at some point after the gnome 2 port we should make all i18n problems an immediate priority but right now they just aren't.
BTW this has nothing to do with i18n, it has to do with stupidly broken mailing list software. (removing i18n keyword)
You said that evolution only encodes if the smtp server does not support 8 bit mime. But my server supports 8BITMIME even so evolution encodes the mail: 250-server.localnet Hello linux1.localnet [192.168.1.1], pleased to meet you 250-ENHANCEDSTATUSCODES 250-8BITMIME 250-SIZE 250-DSN 250-ONEX 250-ETRN 250-XUSR 250 HELP MAIL FROM: ... Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: base64 X-Mailer: Ximian Evolution 1.0.3 (1.0.3-4)
oh well i guess i was wrong. it is still a mailing list bug.