User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.8.0.2) Gecko/20060308 Firefox/1.5.0.2 Build Identifier: 1.5.0.2 Japanese Message body is not displayed in case of (2), whereas (1) no problem. It seems that some headers(X-xxxx) below 'boundary=' line cause this. Other major mailer in Japanese market, like "Outlook" "Beckey!2", CAN display body correctly. (1) -- snip -- Subject: Hello Date: Tue, 18 Apr 2006 02:50:02 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--02475884590182678" ----02475884590182678 Content-Type: text/plain; Content-Transfer-Encoding: base64 gmeEq4LIhKuO4YSriZyEq4KzhKuC8YSrgvCEq5X4hKuCooSrgsSEq4LdhKuC3ISrgrmEq4Lx -- snip -- (2) -- snip -- Subject: Hello Date: Wed, 19 Apr 2006 22:13:43 +0400 X-Mailer: AOL 9.0 for Windows US sub 802 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--6985123198803202" X-Priority: 3 X-MSMail-Priority: Normal X-IP:112.24.104.42 ----6985123198803202 Content-Type: text/plain; Content-Transfer-Encoding: base64 hKyB9ISthKyB9ISthKyB9ISthKyB9ISthKyB9ISthKyB9ISthKyB9ISthKyB9ISthKyB9ISt -- snip -- Reproducible: Always Steps to Reproduce: Just receive mail Actual Results: body part is not displayed Expected Results: body part is displayed this problem occurs mainly in X-Mailer: AOL 6.0 for Windows US

This problem cannot be solved with fragments of the message. Please provide an entire message -- save it as a .EML file and attach it the bug using the Create New Attachment link, above.

I added 2 files. Please examine those.

What appears to be the critical difference between the two messages is the blank line that appears, in the OK message, between the headers and first MIME boundary. If I edit the NG message and insert a blank line there, the message is displayed, presumably as expected. Both messages are technically malformed: the headers contain raw multibyte data, and the charset is not specified for the text/plain part; but TB manages to do more or less the right thing for these messages anyway, except for not displaying the body This is similar to the symptom I note in bug 333880 comment 2, altho that bug is about a different problem. Like that bug, this problem also appears in Seamonkey, so moving to Core.

(In reply to comment #0) > Message body is not displayed in case of (2), whereas (1) no problem. > (1) >(snip) > Subject: Hello >(snip) > Content-Type: multipart/alternative; > boundary="--02475884590182678" >(snip) ><This is Null line = Delimiter of mail header portion and mail payload portion> > ----02475884590182678 >(snip) > (2) >(snip) > Subject: Hello >(snip) > Content-Type: multipart/alternative; > boundary="--6985123198803202" >(snip) > X-IP:112.24.104.42 ><Null line is required at here, in order to start mail payload, but not> > ----6985123198803202 "Base64 or not" never has relation to phenomenon. First "Null line" is "Delimiter of mail header portion and mail payload portion", and is mandatory except when really no mail payload(mail of null data). This is one of most basic rules of RFC822 and RFC2822(successor of RFC822). And all lines before first "null line" have to be considered as lines in mail header portion. Culprit is found to be "spam/junk filtering software at mail server" in many bug reports to bugzilla.mozilla.org for this phenomenon of "lack of the delimiter". But in your case, culprit seems to be "AOL 6.0 for Windows". INVALID