Garbled message body on inline-forward of UTF-8/Cyrillic message (text/plain)

NEW
Unassigned

Status

MailNews Core
Composition
15 years ago
9 years ago

People

(Reporter: Eugene Savitsky, Unassigned)

Tracking

({intl})

Trunk
x86
Windows XP

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

15 years ago
I'm using inline forwarding and today I could not forward this attached to bug
message.

Pressing Fprward brings the forward windows, but without the formawded message
body. Only subject and my signature.

moz 2003030504
(Reporter)

Comment 1

15 years ago
Created attachment 116431 [details]
Saved in .eml message.
Product: MailNews → Core

Comment 2

13 years ago
Created attachment 169181 [details]
Unforwardable message in Tbird file.

Comment 3

13 years ago
I have messages which also disappear when I forward but not when I reply, save
as file, or copy/paste the body into a new message. May be a different problem,
as my header says "multipart/alternative" but there is only one part; would that
cause a problem?
 
Occurs with Thunderbird 0.9, 1.0 on Win XP SP2.  

Headers and body transition like this:

Subject: ***SPAM*** HIV: This may help. Checkout the site ASAP
MIME-Version: 1.0 (produced by chromatographygreece 5.9)
Content-Type: multipart/alternative;
	boundary="--1107861157280680257"

----1107861157280680257
Content-Type: text/plain;
	charset="iso-6727-5"
Content-Transfer-Encoding: quoted-printable
Content-Description: cutset earthmen ferromagnet

I have not attached an eml file (T-bird would not allow forwarding) but a
message in its T-bird file. If necessary, I can add the msf file that goes with it.

Comment 4

13 years ago
With TB 1.0+0506, attachment 116431 [details] -- an apparently correct, UTF-8 encoded 
Cyrillic message -- yields a completely empty message body on Forward Inline.  
The compose window title indicates "UTF-8" but the encoding menu has no checked 
item.  Subject has been correctly copied.  No errors on the JS console.



Attachment 169181 [details] is not correct -- ISO-6727-5 is not a legal charset.  When 
that message is forwarded inline, the headers and the first line of text are 
copied correctly to the new message body, but immediately after the first line 
is a line containing only     =A0     (shown as '?' in the message pane).

Changing the charset *or* removing the "quoted-printable" header allows the 
entire message body to be copied on forward.

These are actually two different bugs, I think.
Keywords: intl

Comment 5

13 years ago
Maurice Lanselle, see also bug 173012 and bug 137022 for problems similar to 
yours.

Comment 6

13 years ago
(In reply to comment #4)
> 
> Attachment 169181 [details] [edit] is not correct -- ISO-6727-5 is not a legal charset.
 When 
> that message is forwarded inline, the headers and the first line of text are 
> copied correctly to the new message body, but immediately after the first line 
> is a line containing only     =A0     (shown as '?' in the message pane).
> 
> Changing the charset *or* removing the "quoted-printable" header allows the 
> entire message body to be copied on forward.
> 
I see. I have found similar not-legal declarations (I suspect, but do not know
what all charsets are legal), charset="iso-5835-5" and charset="iso-0056-3", in
other messages that vanished during inline forwarding.  I suspect these
declarations were deliberately invalid in the hope that spam filters would not
try to process them.  

On the other hand, "forward as an attachment" succeeds, preview of the
attachment before sending fails, the attachment content is visible in the lower
part of the  new message after sending, and the not-legal charset remains in
place in the attachment.  So apparently the *appropriate* behavior is to ignore
invalid charset declarations and to attempt rendering with the default charset.
 If I am right, then TB would have a minor dilemma in this case-- ignore and
leave the invalid charset declaration, or remove it?  I cannot think of any good
reason not to remove it and get on with rendering/sending with the client's
default charset.

Comment 7

12 years ago
Updating summary for easier searching
Summary: Inline forwarding does not works on this message → Blank message body on inline-forward of UTF-8/Cyrillic message (text/plain)

Updated

10 years ago
Assignee: ducarroz → nobody
QA Contact: esther → composition
(Assignee)

Updated

10 years ago
Product: Core → MailNews Core
It happens also to me when I forward an microsoft outlook 11 with 

Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

not Cyrillic message here (italian)

Comment 9

9 years ago
In Shredder [rv:1.9.1.3pre // Gecko/20090801 Shredder/3.0b4pre] the symptom has changed, but is still incorrect.  Inline-forward of attachment 116431 [details] yields a message with correct quoted headers, including the Subject field which has a lot of Cyrillic in it, but the forwarded body is all undecoded UTF-8.  Window title still states "UTF-8" and the Options | Encoding menu still has no selection checked.
Summary: Blank message body on inline-forward of UTF-8/Cyrillic message (text/plain) → Garbled message body on inline-forward of UTF-8/Cyrillic message (text/plain)
You need to log in before you can comment on or make changes to this bug.