User-Agent: Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 Bug 87653 describes this as a 'back-end' bug, but I believe it is really in the rendering of the window, since the command 'View/Message Source' can display the actual message accurately. Otherwise, it is quite similar. Note bug 87653 is 2 years old. This bug seems to occur from yahoo groups mail messages; it is quite common. Once these emails have been forward, the body becomes visible. Attached is a mail file that contains 2 messages -- if you drag then between mail folders, they continue to exhibit the display problem. This is therefore NOT in the mail database but in the rendering code. Reproducible: Always Steps to Reproduce: 1. Import this file as a mail folder. 2. Review the message contents. 3. Use ^U or View/Message Source to validate actual contents. 4. Drag to another folder and notice the problem follows the message. Actual Results: Message body dipslays empty. Expected Results: Message body should be visible.

Back end includes a lot more than just the database.....

Reporter, did you change anything in the mail before you attached it here? If not, I guess the message composer did something wrong. Both boundary parameter contain a space (e.g. boundary="0-494422472-1076796191=: 98402), but the boundaries in the message body don't (e.g. --0-494422472-1076796191=:98402). So it's not surprising that Mozilla doesn't find anything to be displayed.

To the comment above, I also experience this problem and in the message source it doesn't have the problem you've described, I've attached the message above. Note the "CINLIST - The CETA INFORMATION LIST..." get's displayed but none of the message.

Michel, firstly your problem isn't exactly the same. The reason for your problem is that the composing mailer put text/html first and text/plain last which isn't the order it should be according to RFC 2046. See bug 230119 for this issue. I don't know if this should be fixed - since the order with text/plain first isn't a must, the mail format isn't illegal, only discouraged.

I'm seeing some similar issues when reading mail using Mozilla 1.6 on either Windows or Solaris and the mail is coming from our Exchange IMAP server. As far as I can tell, the following needs to be true before the problem appears: 1. The messages was sent as rich-text and it contains one or more attachments, exchnage in this case auto-converts the mail to a plain-text alternative when you attempt to access this message over IMAP. 2. The message resides in a folder outside of the inbox. I can view the entire message be either selecting view source or attempt to reply or forward the message. I switched on the IMAP debug and I can see the entire message scroll by in the log file when I attempt to view it in the mail window (either stand alone window or in the 3-pane view). The interesting thing is that this behaviour is not consistent for all messages that fit the above description, there are some messages that do display correctly. I have tried to compare the source of the message that works with the message that doesn't work and they look very similar to me. What should I be looking for in the source specifically ? If I save one of the messages with wont display in the mail window as an .eml file and I try to open the .eml file using file->open the message does indeed display correctly...

Response to comment #3: Christian Eyrich: Original attachment was not modified manually by the user; any modificiations that occurred were the result of dragging the message to an empty folder in order to upload a single-message folder as an attachement (i.e. using Mozilla 1.6). Note that moving this to a different folder does not change the rendering problem.

But the question still is, if the blank was originally present in the boundary delimiter or not. To attach a single mail you can use Save As File (.eml). If you again run into this problem, just view your inbox for matching/non-matching delimiters.

Daniel Nilsson, your problem might be related to bug 149771 comment 16 -- altho I'm not sure if that comment is applicable to the original bug there. Christian is right about Michael's attachment -- Mozilla is doing the right thing with the message as delivered. The real problem is that last MIME part (an ad or sig from the mail-list) was appended to the mail -- the original message appears as the first text/plain part, before the text/html. The complaint should be directed back to the mail-list administrators. Bursty's original message is similar to the one attached to bug 87653 (which was not necessarily the problem seen by 87653's reporter, who most inconveniently did not attach a sample email). The basic problem is the whitespace within the MIME boundary -- in that bug's case, the whitespace appears to have been expanded at the fold, causing a mismatch; in this case the space appears to have been stripped. (Even tho that bug is listed as in the "Back End" that isn't necessarily so.) To me, it makes no sense at all to put any whitespace into a boundary string, that's just asking for trouble; but Mozilla can't help how other programs format their outgoing mail. Bursty, you said this message was "imported" -- do you mean that in the Mozilla sense of importing mail from the database of a different mail client (such as Eudora)? Or do you merely mean it was retrieved from the server? Do you know of someone who is viewing these messages as originally sent without a problem? Via a web interface, or from a mail client? Is it possible to get a copy of the mail source that is being interpreted by that viewer? You also wrote: "Once these emails have been forward, the body becomes visible." Forwarded by whom? With which client? I integrated your attached messages into my mail, and if I reply or forward-as-inline, I still don't see the mail body; those messages are virtually empty, because (as posted) they are malformed. (Bug 87653's reporter said the same thing about forwarding, but we don't know what his message looked like.)

Michael (mcm_ham1): please see bug 149771 about your issue.

Sorry for the bugspam, I referenced the wrong bug. Michael, see bug 198565.

Bursty's problem may be a dupe of bug 229290.

To more simply state the problem the boundary identifier was specied as: "boundary="0-494422472-1076796191=: 98402" But through out the email this identifier was used: "boundary="0-494422472-1076796191=:98402" This is different, therefore mozilla was unable to recognise what the boundary it finds is. I think mozilla should handle the situation as outlook express does. If it comes across a boundary being started that hasn't been declared then all the email code from that point on should be displayed. This at least allows the email recipient to read the message if they can inside all the html garbage.

In case people are wandering I was refering to the original posters problem.

This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/

This bug has been automatically resolved after a period of inactivity (see above comment). If anyone thinks this is incorrect, they should feel free to reopen it.

first testcase still fails and should be tested again after bug 87653 lands. so reopening second testcase works.

(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #17) > first testcase still fails and should be tested again after bug 87653 lands. > so reopening needs retest

Still showing as blank. Do we keep this open even though bug 87653 was closed as WONTFIX? Thunderbird 52.0.1 (32-bit) Windows 7 64-bit

I'd say platform of "Windows 2000" can be changed. I doubt anyone still uses that.