8bit CTE is used in plaintext part of plaintext + html (multipart) message although in the header (Content-Transfer-Encoding) is set to base64

RESOLVED FIXED

Status

RESOLVED FIXED
15 years ago
6 years ago

People

(Reporter: jshin1987, Assigned: jshin1987)

Tracking

({fixed1.7, intl})

Trunk
fixed1.7, intl

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: fixed-aviary1.0)

Attachments

(1 attachment)

(Assignee)

Description

15 years ago
Spun off from bug 234597 comment #6.

When Mozilla-mail/TB is configured to use 'quoted-printable' for outgoing
messages with 8bit characters and plain text + html format is selected, the
plain text part of the message has 

Content-Transfer-Encoding: base64 
(if there are enough number of 8bit characters to make base64 more
space-efficient), but the actual content-transfer-encoding used is 8bit. This
mismatch makes the plain text part unreadable when read by a mail program that
can't deal with html part.

Observed in TB 0.5 and Mozilla trunk

Comment 1

15 years ago
Should Mozilla's mail engine send base64 for text/plain at all?  Popular
spam-blocking software run on ISPs' servers assigns a high "spamminess"
score to text/plain encoded with base64 because for a few months, spam
tended to use base64 to evade content-based filters that had not yet
upgraded to grok base64.  Do we want to see "Mail sent in non-Latin
scripts is often blocked as spam" evangelism bug reports?
(Assignee)

Comment 2

15 years ago
(In reply to comment #1)
> Should Mozilla's mail engine send base64 for text/plain at all?  

That's a valid question, but this bug is not about that. 

>  Do we want to see "Mail sent in non-Latin
> scripts is often blocked as spam" evangelism bug reports?

I guess so. 'base64' factor can be taken into account by spam blocking programs,
but should not be given such a high 'spamness' score. (spam blocking programs
should be able to decode base64 part.) It's not just mozilla but Pine (and
probably other mail programs) that use base64 for text/plain messages with high
percentage of 8bit characters.

(Assignee)

Comment 3

14 years ago
This is a rather serious bug and needs to be noted in the release notes. A
work-around is to turn off 'use quote-printable' if one's preferred format of
outgoing messages is 'multipart' (html + plain). 

Assignee: sspitzer → jshin
Keywords: intl, relnote
Summary: 8bit CTE is used in plaintext part of plaintext + html message although in the header (Content-Transfer-Encoding) is set to base64 → 8bit CTE is used in plaintext part of plaintext + html (multipart) message although in the header (Content-Transfer-Encoding) is set to base64
(Assignee)

Comment 4

14 years ago
Created attachment 151430 [details] [diff] [review]
patch

this is a trivial patch.
(Assignee)

Comment 5

14 years ago
Comment on attachment 151430 [details] [diff] [review]
patch

This patch just does for Base64 what's done for QP.
Attachment #151430 - Flags: superreview?(mscott)
Attachment #151430 - Flags: review?(sspitzer)

Updated

14 years ago
Attachment #151430 - Flags: review?(sspitzer) → review+

Updated

14 years ago
Attachment #151430 - Flags: superreview?(mscott) → superreview+

Updated

14 years ago
Whiteboard: fixed-aviary1.0
(Assignee)

Comment 6

14 years ago
Thanks for r/sr and committing to aviary-1.0 branch. Fix checked into the trunk.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
(Assignee)

Comment 7

14 years ago
Comment on attachment 151430 [details] [diff] [review]
patch

asking for a1.7.1
This was fixed on aviary-1.0 as well as on trunk. 

It's a trivial fix that does for base64 what's done for quoted-printable.  It
seems like somehow base64 case was not taken care of when this part was
originally written.
Attachment #151430 - Flags: approval1.7.1?

Comment 8

14 years ago
Comment on attachment 151430 [details] [diff] [review]
patch

a=mkaply
Attachment #151430 - Flags: approval1.7.1? → approval1.7.1+
(Assignee)

Comment 9

14 years ago
Thanks for a. It's fixed in 1.7branch.
Keywords: fixed1.7

Comment 10

14 years ago
I also fixed this on the 0.7.1 branch
Product: MailNews → Core
Product: Core → MailNews Core
Keywords: relnote
You need to log in before you can comment on or make changes to this bug.