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
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.
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.
(In reply to comment #4) > > 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. > 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.
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)
Assignee: ducarroz → nobody
QA Contact: esther → composition
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)
In Shredder [rv:220.127.116.11pre // 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.