I've got an email from associates@amazon.com and it shows up empty tbird version 3.0a1pre (2007120503)

Following is mail data structure. >(snip) > Content-Type: multipart/alternative;boundary="___BoUnDaRy_1010943140549"[CRLF] > Message-Id: <20071206093318.B29AB58132@associates-6002.iad6.amazon.com>[CRLF] > Date: Thu, 6 Dec 2007 01:33:18 -0800 (PST)[CRLF] > [CRLF] > (2 [CRLF] lines) > Your email client is not capable of reading MIME messages.[CRLF] > [CRLF] > --___BoUnDaRy_1010943140549[CRLF] > [CRLF] > Content-Type: text/plain[CRLF] > [CRLF] >(snip) > --___BoUnDaRy_1010943140549[CRLF] > [CRLF] > Content-Type: text/html[CRLF] > [CRLF] >(snip) > --___BoUnDaRy_1010943140549--[CRLF] > [CRLF] > --___BoUnDaRy_1010943140549--[CRLF] >(snip) There are at least two problems in the spam mail. (1) No mail header before first null line in each part. (2) Two close boundary lines. (needless close boundary line data after close boundary) What is your choice of View/"Message Body As"? What is displayed when you choose "Plain Text"? If text in a part(last part is proper, I think) is displayed when "Plain Text", and if empty display when "Original HTML" or "Simple HTML", I think it is correct behavior, because no text/html part in multipart/alternative due to (1). By the way, when "empty display", there is no chance to click link in the spam. He is very kind spammer, isn't he? :-)

why do you think it's a spam mail? I dont think so.

(In reply to comment #2) > why do you think it's a spam mail? I dont think so. Reason why I think it's a spam is existence of following Received: headers. >[A. last=top Received: header] > Received: from murder ([unix socket]) > by m00.opasia.dk (Cyrus v2.2.12-Invoca-RPM-2.2.12-16) with LMTPA; > Thu, 06 Dec 2007 10:33:34 +0100 > X-Sieve: CMU Sieve 2.2 >[B. just before(=below) the last Received: header] > Received: from avmx.opasia.dk (avmx.opasia.dk [193.88.185.115]) > by m00.opasia.dk (Postfix) with ESMTP id 906756540B6 > for <gemal@m00.opasia.dk>; Thu, 6 Dec 2007 10:33:34 +0100 (CET) According to these headers, flow is as follows. (1) [B] avmx.opasia.dk => m00.opasia.dk (Postfix) (2) [?] m00.opasia.dk (Postfix) => ... => murder ([unix socket]) (3) [A] murder ([unix socket]) => m00.opasia.dk (Cyrus v2.2.12-...) I can't imagine configuration at m00.opasia.dk which produces above flow between "m00.opasia.dk (Postfix)" and "m00.opasia.dk (Cyrus v2.2.12-...)" without Received: header(s) for step (2).

(In reply to comment #3) > (In reply to comment #2) > > why do you think it's a spam mail? I dont think so. > > Reason why I think it's a spam is existence of following Received: headers. > >[A. last=top Received: header] > > Received: from murder ([unix socket]) > > by m00.opasia.dk (Cyrus v2.2.12-Invoca-RPM-2.2.12-16) with LMTPA; > > Thu, 06 Dec 2007 10:33:34 +0100 > > X-Sieve: CMU Sieve 2.2 > >[B. just before(=below) the last Received: header] > > Received: from avmx.opasia.dk (avmx.opasia.dk [193.88.185.115]) > > by m00.opasia.dk (Postfix) with ESMTP id 906756540B6 > > for <gemal@m00.opasia.dk>; Thu, 6 Dec 2007 10:33:34 +0100 (CET) > > According to these headers, flow is as follows. > (1) [B] avmx.opasia.dk => m00.opasia.dk (Postfix) > (2) [?] m00.opasia.dk (Postfix) => ... => murder ([unix socket]) > (3) [A] murder ([unix socket]) => m00.opasia.dk (Cyrus v2.2.12-...) > I can't imagine configuration at m00.opasia.dk which produces above flow > between "m00.opasia.dk (Postfix)" and "m00.opasia.dk (Cyrus v2.2.12-...)" > without Received: header(s) for step (2). > avmx and m00 are all server in my network. I'm not the admin of the mail I'm pretty sure this is not a spam mail

(In reply to comment #4) > avmx and m00 are all server in my network. Are saying that "murder ([unix socket])", who passed the mail to your final mail recipient sever("m00.opasia.dk (Cyrus ...)"), is also a server in your network?

(In reply to comment #5) > (In reply to comment #4) > > avmx and m00 are all server in my network. > > Are saying that "murder ([unix socket])", who passed the mail to your final > mail recipient sever("m00.opasia.dk (Cyrus ...)"), is also a server in your > network? > yes. It says that in all of my mails

I could reach next page via Google search with "murder ([unix socket])", > http://discussions.apple.com/thread.jspa?threadID=1274544&tstart=0 and this page says; > Murder is your local cyrus agent and the last step before mail gets to your inbox. So all Received: headers in the mail seems to be trustable. (and, the mail content looks to be normal mail from amazon.com) If it is true, culprit of malformed mail can be; (A) Software at amazon.com, original sender of the mail, failed to generate proper mail header. (B) Filtering software at your server(s) inserted null line between boundary line for a part of multipart and "Content-Type:" header for part. Before contact with amazon.com, contact with your server administrator, in order to rule out your server side fault.

this email from my telephone provider does not display any content in the message window either in the preview window or when opening in a new window. When this came in today I read it on the web mail system and it was okay to read fine. In the past when I was using outlook it worked also fine (had one email every month letting me know the bill was ready), but I'm new to thunderbird in the last few days only. This is the first time it has occurred. The source in the file was taken from a ctrl-u. I'm running vista if that makes any difference.

(In reply to comment #8) > an example email that does not display any content To Glenn Smith: Have check mail structure of the mail? What is your View/Message Body As setting? Because Content-Type:multipart/alternative;, text/plain part is used when View/Message Body As == Plain Text. And, because the text/plain part contains null line only, blank is properly displayed.

I've tried all three with no joy, when I open the email it's currently set to Original HTML.

(In reply to comment #10) > it's currently set to Original HTML. Press CTRL+A at mail display pane. You can probably see some blank only lines. The Content-Type:text/html part contains HTML tags, and contains following too. (MS proprietary XML name space, I think) > <html xmlns:v="urn:schemas-microsoft-com:vml" > xmlns:o="urn:schemas-microsoft-com:office:office" > xmlns:w="urn:schemas-microsoft-com:office:word" > xmlns:st1="urn:schemas-microsoft-com:office:smarttags" > xmlns="http://www.w3.org/TR/REC-html40"> XML parser of browser perhaps can handle it. (Semonkey rendered it when HTML portion is saved as .html file). But mail probably doesn't permit XML statement in Content-Type:text/html. So all of tags by XML is treated as unknown tag, and text string between "<!--" and "-->" (comment of HTML 4) is ignored. And HTML tags don't contain displayable text in it, except some characters such as &nbsp;. I think this is the reason why "blank display". To Glenn Smith: Your problem is completely different issue from this bug, even though "blank display of a mail" is same. Sorry but I dont't know RFC/spec on XML in Content-Type:text/html part of a mail. Open separate bug, please.

To Henrik Gemal(bug opener): Thunderbird can do nothing when such malformed mail. If you want some enhancements such as (A) way to choose part to display, (B) way to force ad-hoc Content-Type:, (C) way to force ad-hoc view option(HTML or text,...) etc., please open separate enhancement request bug, after search bugzilla.mozilla.org well for already opened bugs, please. Adding "inserted null line" in bug summary, and closing as INVALID, to avoid confusion.

WADA, RfC 1521, section 7.2 says: > Each part starts with an encapsulation boundary, and then contains a > body part consisting of header area, a blank line, and a body area. ... > NO header fields are actually required in body parts. A body part > that starts with a blank line, therefore, is allowed and is a body > part for which all default values are to be assumed. Given Gemal's > --___BoUnDaRy_1010943140549[CRLF] > [CRLF] > Content-Type: text/plain[CRLF] the body to be shown is clearly the raw text "Content-Type: text/plain", but it isn't. This sounds like a bug to me...

(In reply to comment #13) > the body to be shown is clearly the raw text "Content-Type: text/plain", but it isn't. Oh, sorry for my misunderstanding. The phenomenon was re-produced with Tb 2.0.0.12. Phenomenon is also observed with following Content-Type: header. 1. No parameter : Content-Type: 2. Invalid mime type : Content-Type: xxx/yyy; charset=us-ascii Re-opening. RFC says that default when no Content-Type: header or Content-Type: with invalid/no parameter is mime-type==text/plain && charset==us-ascii. "Defaulting to text/plain" doesn't seem to work when search for a part in multipart/alternative. I don't know whether the defaulting is applicable to search for a part of specific mime-type in multipart/alternative or not.

Henrik this might have been fixed by bug 351224. Could you take a few minutes and download the latest nightly ( http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-central/ ), backup your profile and test and let us know if this is fixed or not ?

The message in attachment 310100 [details] doesn't display. It is multipart/alternative and has two parts: First the text/html part and second the text/plain part which is empty. TB seems to display the second empty part. If I add text to the second part, that text is displayed. If I move the text/plain part to the first position, the second HTML part is displayed properly. RFC 1341 says that the last part should be displayed: https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html 7.2.3 The Multipart/alternative subtype. Clearly this sample does not comply. As for attachment 291923 [details]: This has three(!!) parts, the last part is empty. Removing the last part and the empty line between the boundaries and the content type, the message displays fine. This bug is nine years old. We have no resources to fix problems where invalid data is presented.

BTW, there is bug 574989 to cover HTML and plain part in the wrong order.