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

Status: NEW

(MailNews Core :: Composition, defect)

Description

[Eugene Savitsky]

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

Comment 1

[Eugene Savitsky]

Attachment: Saved in .eml message.

Comment 2

[Maurice Lanselle]

Attachment: Unforwardable message in Tbird file.

Comment 3

[Maurice Lanselle]

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

[Mike Cowperthwaite]

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.

Comment 5

[Mike Cowperthwaite]

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

Comment 6

[Maurice Lanselle]

(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

[Mike Cowperthwaite]

Updating summary for easier searching

Comment 8

[[:Aureliano Buendía]]

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

[Mike Cowperthwaite]

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.