I'm not sure, if message format/content is wrong, but as user I feel problem. Attached mail has two parts, but M&N is displaying just second.

I also have a problem with multipart/alternative messages. In this case, the message window only displays the first part -- which in this email is blank, meaning I can't see the message at all. Source of message follows.

Complete message source.

OK, looking at this, the first case here, Mozilla is behaving according to the relevant standards, the original sender is sending a badly formed message. In the second case, Mozilla is behaving incorrectly. I also see this incorrect behaviour, which is why I'm here. According to RFC1341, when parsing a multipart/alternative message: The user agent should either choose the "best" type based on the user's environment and preferences, or offer the user the available alternatives. In general, choosing the best type means displaying only the LAST part that can be displayed. So, in the absence of the user having set any preferences (which is certainly the case for me) about what types to display, the last one in the message which is a recognised type should be shown per default. In the case of the second attachment above, that is the text/html section. I am aware that in the View menu there is an option 'Message Body As' from which you can choose HTML to switch to the HTML section, but this _should_ be the default, as per the recommendations in the RFC, when the HTML part is the last part recognised in the message.

Mozilla for Lindows (based on Debian) won't display 'multipart/alternative' messages, but offers to save a file named 'multipart.alternative' which I don't know how to handle.

(In reply to comment #4 by Julian Hall) > OK, looking at this, the first case here, Mozilla is behaving according to the > relevant standards, the original sender is sending a badly formed message. Could you be more specific about this? I'm not seeing the malformation. > In the second case, Mozilla is behaving incorrectly. I also see this > incorrect behaviour, which is why I'm here. [...] > So, in the absence of the user having set any preferences (which is certainly > the case for me) about what types to display, the last one in the message > which is a recognised type should be shown per default. In the case of the > second attachment above, that is the text/html section. > > I am aware that in the View menu there is an option 'Message Body As' from > which you can choose HTML to switch to the HTML section, but this _should_ > be the default, as per the recommendations in the RFC, when the HTML part is > the last part recognised in the message. First of all, I believe that "View|Message Body As|Original HTML" *is* the default; create a new profile and take a look at that setting in mail. Second of all, selecting "Plain Text" from that list is intended to force Mozilla to act like a plain-text-only message reader. If that is the setting, Mozilla should *not* display the HTML part if there is a text/plain part. tomb@progress: that means if you change that menu setting to "Original HTML" you should be able to read the message; I've integrated your attachment into my mail and it displays as expected.

(In reply to comment #6) > (In reply to comment #4 by Julian Hall) > > OK, looking at this, the first case here, Mozilla is behaving according to the > > relevant standards, the original sender is sending a badly formed message. > > Could you be more specific about this? I'm not seeing the malformation. OK, It's been a while since I posted that, but having a quick glance at the message in question, there are two things I note that are unusual: 1. The message is in multipart/alternative, yet there are two alternatives provided that have the same type. In this case, according to the specifications I quoted originally, the sender should have placed the information to be displayed in the last section, as it is perfectly correct behaviour for the client to only show the last section. 2. The content type line of the second part seems to be invalid (It ends ";charset=" and is not followed by a charset specification). I was probably referring to point 1. > First of all, I believe that "View|Message Body As|Original HTML" *is* the > default; create a new profile and take a look at that setting in mail. I believe it is, yes. And I have never changed it. I have not seen this problem since I originally posted; it seems to be that very occasionally a message is displayed with the incorrect setting, regardless of how your preferences are set. It could have been a bug in an earlier version that is now fixed? Do the other people who have experienced this still have similar problems?

(In reply to comment #7) > 1. The message is in multipart/alternative, yet there are two alternatives > provided that have the same type. In this case, according to the > specifications I quoted originally, the sender should have placed the > information to be displayed in the last section, as it is perfectly correct > behaviour for the client to only show the last section. See the message in Attachment 141645 [details] (from bug 234547). It appears very similar to Adam Hauner's attachment 123880 [details] from this bug, in that the final text/plain attachment was apparently tacked on to the end of an otherwise valid message; and it has this same null charset specified for that part. And in fact, the tacked-on part appears to be from the same mailing-list software -- both messages show the mailing list as "run by ezmlm."

Sorry, I just realized that Adam's sample is attachment 117996 [details]; and for comparison, bug 234547's sample is attachment 141645 [details] (that should properly linkify).

I was wandering if the default handling for these malformed email messages with the text/plain part incorrectly tacked on at the end of the message should be different. Outlook Express handles the case by displaying the main message and ignoring the last part. Or does this break the standard on the order of how the message is to be processed?

Does anyone know why attachment 141645 [details] fails and attachment 167805 [details] does not?

Ok I understand why now, attachment 167805 [details] has two multiparts, one that is mixed and one that is alternative. This correctly adds the mailing list signature to the email in plain text. Therefore does seem a bug by the ezmlm software on the way it attaches the signature from the mailing list. The maf mailing list demonstrates how it should be done. Now I understand the issue. Attachment 123880 [details] has a plain text alternate part and an html alternate part. If mozilla is set to plain text no message is displayed because there is nothing under that part. But if mozilla is set to html then the message is displayed because there is an html message under that part. This is correct behaviour. Attachment 117996 [details] has two alternate plain text parts, this is obviously a malformed email message since for alternate parts there should only be one plain text part followed by an html part. This situation isn't covered by the RFC but mozilla displays the second part while outlook express displays the first. I think mozilla should either follow outlook express behaviour in displaying the first part or ideally should join all the plain text alternate parts together to display. Note in regard to Mike Cowperthwaite in comment #8, I haven't seen this particular error with the version of the ezlm mailing list program myself. But now for attachment 141645 [details], it incorrectly displays the plain text part when the html part is set in preferences to display. This message was malformed by the ezlm messaging program by introducing two alternate plain text parts. If you remove the first plain text part then you are simply left with the situation of having the html part specified before the plain text part. As specified by the RFC 1341 this is the wrong order. The reason for this is for mailer programs that cannot display html content it will display everything and it is better for the email reader to be given the readable plain text version before seeing all the html garbage version underneath. But since mozilla can display html content for the purposes of displaying the message it shouldn't matter which order the alternate parts are supplied.

> Attachment 117996 [details] has two alternate plain text parts, this is obviously a > malformed email message since for alternate parts there should only be one plain > text part followed by an html part. This situation isn't covered by the RFC but > mozilla displays the second part while outlook express displays the first. I > think mozilla should either follow outlook express behaviour in displaying the > first part or ideally should join all the plain text alternate parts together to > display. Actually, both of these behaviours violate RFC 1341, which says: The user agent should either choose the "best" type based on the user's environment and preferences, or offer the user the available alternatives. In general, choosing the best type means displaying only the LAST part that can be displayed. (So, displaying the first rather than the last is just plain wrong) What is most critical, however, is that the user not automatically be shown multiple versions of the same data. Either the user should be shown the last recognized version or should explicitly be given the choice. (Joining them together risks showing the same data twice, so is not compliant. Giving the user the choice of which of them to display is the only permitted approach other than what is currently being done.)

Well I just figured that those RFC statements are for a correctly composed email. In this case offering "alternate" parts with the simplest parts listed first. At the moment that means offering plain text before rich text (Outlook) which I think is before html. The most visually appealing or "best type" is most likely going to be the more complicated part that should be listed last. However, we have two alternate parts with the same formatting, plain text. This makes no sense as alternate is designed for presenting the same message in different formats. Hence why it is critical that not more then one alternate part is displayed. That's why I don't think it is covered by that RFC. My suggestion of either showing the first plain text part or joing the parts together is more based on the most likely cause of the malformation. Which is a mailing list program adding a signature in an alternate part of a format type that has already been defined. In this case the more useful alternate part for the particular format is the first of the double entry. This for the moment will probably always be the case since outlook express is the most widely used email client and such a mistake would have been picked up had it presented the second of the double entry. However, I think the safest approach when mozilla comes across two alternate parts that have the same format to join them together since information loss is a more important issue then repeated information.

*** Bug 282664 has been marked as a duplicate of this bug. ***

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.