This bug is seperated from bug 66098. When doing forward inline, the non-MIME encoded multiple line header of the original mail is not displayed correctly. Steps to reproduce: 1.Unzip the following zip file containing a testing mail http://bugzilla.mozilla.org/attachment.cgi?id=25725&action=view 2. Put the testing mail in your local folder. 3. Restart mail, select the folder containing the testing mail, change the folder charset to Japanese (ISO-2022-JP) to correct the view 4. After the view is corrected, click on Forward icon, observe the To: field of the original mail, they are displayed as question marks.

reassign to nhotta

This bug WFM with TB 1.6a1-1117. Reporter (Ji) -- can you confirm?

Clarification: There is a problem with this message, but the described behavior of forwarding is WFM. There are multiple To: headers which don't display in any context -- not in the envelope panel, not in the forward. If I Reply All to the message while enforcing my ISO-8859-1 charset on replies, the original's From: message is copied over correctly, but the To: is not. But if I allow the original message's charset in the reply, both fields are correct. I think this last bit is already a bug somewhere.

I need to withdraw comment 2 & 3; I thought I was testing with the same message, but in fact I was testing with an edited version that no longer had the multiple recipients. My mistake. I did some further testing. The initial mail consists of a single, folded To: header with nine comma-separated addresses; the realname portion of each address is in ISO-2022-JP, rather than MIME-encoding. When forwarded-inline, these bytes are copied verbatim into the new message (which always has the ISO-2022-JP encoding that was correctly specified in the original message body). In the compose window, these names appear as they would looking at the message source in an ASCII text editor; this is the original bug report. However, when the message is sent, and the sent version viewed, the bytes are properly interpreted as ISO-2022-JP and displayed as the expected Japanese characters. I then tweaked the message, in light of a different symptom reported elsewhere (bug 318705). The edited version had a To: header with only one address, a CC: header with a single address, and second a CC: header with seven comma-separated addresses. When *this* message is forwarded-inline, the compose window displays the in-body To: header (with a single address) as expected; and it shows a single, eight-address CC: header with the characters appearing as ASCII. I re-tweaked to have two single-address To: headers and one seven-address CC: header; in the forwarded message body, both headers appeared as ASCII. In other words, the To: or CC: headers will appear correctly in the compose window if there is only one To: or CC: address in the message.