From Bugzilla Helper: User-Agent: Mozilla/4.78 (Macintosh; U; PPC) BuildID: 201103108 Handling multipart MIME messages correctly is very important. We need to be able to fold and unfold each successive part, and choose which to save. That little box on the upper right just doesn't make the grade. The message parts should be displayed in some form of outline: part 1 part 2 part 2.1 part 2.2 This was a long-standing bug in 4.x, unable to be displayed. This is especially important to me, as it is the reason I have to use another mailer (Eudora) to read such messages. Eudora doesn't handle it quite right, either, but at least Eudora displays it! I receive a lot of IETF announce multipart messages, combining /mixed with /alternative. Note the nesting. Reproducible: Always Steps to Reproduce: 1.subscribe to ietf-announce@ietf.org (via ietf-announce-request@ietf.org or via the ietf.org web page) Example message: Message-Id: <200110171113.HAA17932@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-otp-00.txt Date: Wed, 17 Oct 2001 07:13:31 -0400 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu X-Mozilla-Status: 0000 X-Mozilla-Status2: 00000000 X-UIDL: 9437893 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : The One Time Password (OTP) and Generic Token Card Authentication Protocols Author(s) : L. Blunk, J. Vollbrecht, B. Aboba Filename : draft-ietf-pppext-otp-00.txt Pages : 12 Date : 16-Oct-01 EAP is an authentication protocol which supports multiple authentication mechanisms. EAP typically runs directly over the link layer without requiring IP and therefore includes its own support for in-order delivery and re-transmission. While EAP was originally developed for use with PPP, it is also now in use with IEEE 802. This document defines the One Time Password (OTP) and Generic Token Card EAP methods. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-otp-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-otp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-otp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011016113137.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-otp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-otp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011016113137.I-D@ietf.org> --OtherAccess-- --NextPart-- 2. 3. Message-Id: <200110171113.HAA17932@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-otp-00.txt Date: Wed, 17 Oct 2001 07:13:31 -0400 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu X-Mozilla-Status: 0000 X-Mozilla-Status2: 00000000 X-UIDL: 9437893 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : The One Time Password (OTP) and Generic Token Card Authentication Protocols Author(s) : L. Blunk, J. Vollbrecht, B. Aboba Filename : draft-ietf-pppext-otp-00.txt Pages : 12 Date : 16-Oct-01 EAP is an authentication protocol which supports multiple authentication mechanisms. EAP typically runs directly over the link layer without requiring IP and therefore includes its own support for in-order delivery and re-transmission. While EAP was originally developed for use with PPP, it is also now in use with IEEE 802. This document defines the One Time Password (OTP) and Generic Token Card EAP methods. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-otp-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-otp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-otp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011016113137.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-otp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-otp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011016113137.I-D@ietf.org> --OtherAccess-- --NextPart--

William, can you still reproduce this problem using Mozilla 0.9.6? Also, please put your example message in a file and attach it hereon, for convenience. Also, have a look at bug 101719, as it may be related to this.

This bug basically says "our attachment UI is not flexible enough". Confirmed that it is not.

The message you have posted above is in fact 2 message, the first one stop at the line --NextPart-- the message structure is the following: message/rfc822 Multipart/Mixed <no content-type, text/plain use by default> Multipart/Alternative Message/External-body text/plain Message/External-body text/plain Looks like we are not able to process a message/external-body as an alternative part therefore the only part we are showing is the first mixed part, the one without content-type. At this point I don't know if it's a bug or not. This is a very special case.

suggest renmaing to: improve MIME multipart handling & replace attachment box with MIME heirarchy Instead of having an attachments box, it would indeed be more reasonable to show a representation of the structure of the message with the different text, HTML, and other type parts appearing according to the message structure. I don't think it will hurt usability for the common user (e.g. this can be disabled for 1-part messages, or the tree view can be flattened out (enabled by preference), or only show the tree of attachments (enabled by preference) ). Of course implementing this will also mean a similar arrangement in the File menu - instead of an attachment submenu, there would be a Message Parts submenu, with the leafs of the menu tree being the context menus for attachments/parts. This is of course bound up with (at the risk of sounding too presumptuous) a vision I have of seeing mozilla representing messages internally as tree-like objects reflecting the MIME heirarchy, which are manipulable as such and are only 'flattened out' when being sent or written to a local mail folder file. Proper implementation of this will also fix: - bug 3901, bug 11013, bug 204612 (assuming clever implementation) - bug 11521 (clicking a node on the tree which represents an alternative medium would mean "view as this alternative medium") - partially, by workaround, bug 149771, bug 182627 - bug 162138 (it would be 'reasonable' to not display the text/blah if you display the message structure so the user can do something with the text/blah part) - bug 184869 (even if the initial decision is to only display the introductory text without any more parts, the user can click other nodes in the structure tree and have them displayed) (ok this is a bit of a stretch, the fact is that part of implementing this is fixing bug 184869 as-it-is). - and probably some more... Note that there needs to be some consideration of what is to be opened like an attachment, what is to be displayed all-in-sequence and what is to be displayed separately. BTW, where/what is the pref for viewing attachments inline or not?

As noted in comment 3, the reason the attachments to the message in comment 0 don't display is because of the external-body. Bug 260730 was opened for support of that spec (also bug 260724). This new attachment is a simple nesting of multipart/alternative under multipart/mixed: Content-Type: multipart/mixed Part 1: text/plain Part 2: multipart/alternative Part 2.1: text/plain Part 2.2: text/html This displays almost as I would expect: Part 1 (the message body) is displayed, followed by a horizontal rule, followed by part 2.2 (text/html). If View | Message Body As | Plain Text then part 2.1 (text/plain) is shown instead of part 2.2. The one thing that is odd that is even if View|Display Attachments Inline is turned off, the chosen part of the alternatives is still shown. If the message had the top-level parts reversed (multipart/alternative first, text/plain second) then turning that option off would hide the text/plain part. It's true there's no UI for navigating multipart/alternative; ideally, one would not be necessary, but bug 130119 is about allowing individual selection.

Reducing severity and resetting milestone. If comment 2 should be taken at face value, this is actually an enhancement and should be resummarized; otherwise, I'd say this is a dupe of one of the two bugs mentioned in comment 5.

Nice that after so many years, somebody is taking a look at this.... As to reducing severity, when originally posted, this was a very odd bug, where the message would briefly flash and then the window would close. Not exactly crashing bug, but impossible to view message. It appeared to be because of the nesting level, and that's how I reported it. I can confirm that no longer happens. The message displays, merely without the proper attachments. So something got fixed a little bit somewhere. However, I'd call handling these messages "critical", since these messages are the very messages sent out by the creators of MIME. You cannot display IETF messages, it's pretty clear that you don't follow the IETF requirements. That's serious. Not merely an enhancement.... And it shouldn't be a surprise that Hadmut Danisch (bug 260724 and bug 260730) is a fellow IETFer. However, I'd say that his are completely independent of mine, as mine is/was about the nesting display bug, and his are about a missing required feature. I liked the long view of comment 4, where a lot of related reports could be fixed with a rethinking of the nesting display.

I don't think this is a dupe of 260730 or 260724 which are strictly about external-body for attachments. This bug is much more general. As for the severity, 'critical' is for crashes, hangs and dataloss. I would say properly handling MIME messages is the core feature of a mail client, so "Major: A Major Feature is Broken" seems to fit here. And it's not just the UI that's a problem... I believe a lot of code and design from libmime upto the UI needs some rethinking (see also bug 248846).

(In reply to comment #8) > I would say properly handling MIME messages is the core feature of a mail > client, so "Major: A Major Feature is Broken" seems to fit here. Um -- what, exactly, are you claiming is broken? I believe the test case I attached to this bug shows that display of nested MIME objects is working. (In reply to comment #7) > Nice that after so many years, somebody is taking a look at this.... Don't get too excited; I don't code and I don't have any influence over those who do. > However, I'd call handling these messages "critical" ... > serious. Not merely an enhancement.... "Critical" has a specific meaning, as which failing to display a particular message does not qualify. And nobody said this is an "enhancement". > However, I'd say that his are completely independent of mine, > as mine is/was about the nesting display bug, and his are about a missing > required feature. In that case, this bug should be resolved as WorksForMe, because display of nested messages, for supported types, *does* work.

Actually, the test case "simple nesting example" is wrong for this bug, as the latter should be Part 2.1: text/plain Part 2.2: text/plain (not text/html) Either both should be displayed (as equal), or some mechanism for selecting between them, with a clear indication that there are alternatives up in the attachments box. Since there are other bugs describing these more specific design solutions, I'll just add some depends for now. And yes, comment 9, you said it was just an enhancement in comment 6. Still I thank you for bringing the process forward, as it was previously scheduled for 1.2alpha some years ago, but not finished. Doesn't work for me, and until it does, I cannot use the software, since I have hundreds (and thousands archived) of these messages. As mentioned in the original posting circa 2001, I have to use Eudora (I set up a separate email just for these announcements). Since the time that I originally posted this, Eudora has fixed that annoying feature where it put all the alteratives into separate attachment files. (It still puts other kinds of attachments into files).

(In reply to comment #10) > Actually, the test case "simple nesting example" is wrong for this bug, as the > latter should be > > Part 2.1: text/plain > Part 2.2: text/plain (not text/html) > > Either both should be displayed (as equal), or some mechanism for selecting > between them, with a clear indication that there are alternatives up in the > attachments box. Your expectation is contrary to the spec. There should be no need for the user to select a part -- particularly and specifically when there are multiple text/ plain external-body parts -- and there is an explicit prohibition against displaying both. From RFC 2046, Part 5.1.5 <http://rfc.net/rfc2046.html#s5.1.4> "What is most critical, however, is that the user not automatically be shown multiple versions of the same data." "several parts of type "message/external-body" specify alternate ways to access the identical data..." Those messages you see with multiple text/plain parts are multiply specified because, e.g., one of the servers might be down. > Doesn't work for me, The reason you can't read those messages is Mozilla's lack of support for external-body -- which is a different bug, as already pointed out. THIS bug should be WFM'd unless you can demonstrate something that is actually broken about MIME nesting.

William 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 ?

Wow! Another 5 years! Total 9 years have elapsed. Anyway, I'm not easily able to backup my profile and test, as my profile is some 6.7G total according to du.... I'll be happy to test as soon as the code is released, and see whether the specific MIME format listed in comment 0 works yet. Bug 351224 seems to be a complete re-write of MIME handling, so that should be helpful.

(In reply to william.allen.simpson from comment #13) > Wow! Another 5 years! Total 9 years have elapsed. > > Anyway, I'm not easily able to backup my profile and test, as my profile is > some 6.7G total according to du.... afaik, the mail store is not needed to test this. note, mozbackup can backup profiles without the mail > I'll be happy to test as soon as the code is released, now is the time :)

RESOLVED INCOMPLETE due to lack of response to previous question. If you feel this change was made in error, please respond to this bug with your reasons why.

The issue is genuine and relevant, I believe - unless it's been fixed lately (I'm not using nightlies right now).

I did not reply to comment #14, as while trying to upgrade Thunderbird destroyed all my .msf files. See the catastrophic Bug 682588. It took me a long time before the .msf regeneration bug was fixed in release. This long-standing bug is not fixed yet either. I can easily test against the following message, very similar to my original report (personal Received lines omitted): Return-Path: <i-d-announce-bounces@ietf.org> Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHMyL-0004ZT-9A; Mon, 19 Sep 2005 10:50:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHMy3-0004UM-RF for i-d-announce@megatron.ietf.org; Mon, 19 Sep 2005 10:50:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25753 for <i-d-announce@ietf.org>; Mon, 19 Sep 2005 10:50:00 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHN3g-0000lZ-KS for i-d-announce@ietf.org; Mon, 19 Sep 2005 10:55:53 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EHMy2-0005a5-48 for i-d-announce@ietf.org; Mon, 19 Sep 2005 10:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <E1EHMy2-0005a5-48@newodin.ietf.org> Date: Mon, 19 Sep 2005 10:50:02 -0400 Subject: I-D ACTION:draft-bellovin-useipsec-04.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>, <mailto:i-d-announce-request@ietf.org?subject=unsubscribe> List-Post: <mailto:i-d-announce@ietf.org> List-Help: <mailto:i-d-announce-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>, <mailto:i-d-announce-request@ietf.org?subject=subscribe> Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Guidelines for Mandating the Use of IPsec Author(s) : S. Bellovin Filename : draft-bellovin-useipsec-04.txt Pages : 13 Date : 2005-9-19 The Security Considerations sections of many Internet Drafts say, in effect, "just use IPsec". While this is sometimes correct, more often it will leave users without real, interoperable security mechanisms. This memo offers some guidance on when IPsec should and should not be specified. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bellovin-useipsec-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-bellovin-useipsec-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-bellovin-useipsec-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-9-19103529.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-bellovin-useipsec-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-bellovin-useipsec-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-9-19103529.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart--

Today's attachment shows that the MIME compliant subsections do not appear between: Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. and: I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce This reader is not MIME compliant, according to the folks that defined MIME compliance.

First of all, please ATTACH mail data to this bug as Mike Cowperthwaite done in Comment #5, instead of pasting long mail data with non-essential data like Received: header, long message text etc. Concept of "Attachment pane display" of Tb is basically "provide a way to save attached file to a disk file", but it was sometimes different from user's expectation for historical reasons. Tb's "Attachment pane display" was sorted out, but it still has some issues, and it can be called "not RFC compliant" or "RFC violation" in some cases. Known issues even when simple multipart/mixed mail are; (1) Bug 747770 : affected by attachment or inline, name= and filename= (2) If attachment and/or name=/filename= is specified for message body part of multipart/mixed mail(first sub part), the part data is not shown. This is a variant of Bug 747770, but different problem is involved. (3) For test mail attached to Comment #5. multipart/mixed part-1 : text/plain message body part-2 : multipart/alternative part-2-1 : text/plain part-2-2 : text/html (3-a) Selection in multipart/alternative is affected by View/Message Body As. Plain Text : text/plain is chosen by Tb for inline display Original/Simple HTML : text/html is chosen by Tb for inline display (3-b) If no name=/no filname= and no Content-Disposition:attachment, the chosen part of multipart/alternative is not shown in attachment pane. If one of name=, filename=, Content-Disposition:attachment is specified, the chosen part of multipart/alternative is shown in attachment pane. This is Bug 747770. After fix of Bug 747770, I think Tb's behavior is debatable, but I think it is a reasonable one. (4) Your case. multipart/mixed part-1 : text/plain message body part-2 : multipart/alternative part-2-1 : Message/External-body; access-type="mail-server" without name= parameter part-2-2 : Message/External-body; access-type="anon-ftp" with name="...txt" In this case, some different issues are involved. (i) Selection in multipart/alternative for Message/External-body (ii) Handling of Message/External-body part (iii) Display in inline or as attachment when Message/External-body (iv) Show chosen Message/External-body part as if attachment in attachment pane, or not. Bug 747770 is relevant to both (iii) and (iv). If filename= is added to Message/External-body part, Bug 747770 is bypassed. If following is placed under multipart/mixed directly(not under multipart/alternative), Tb 12.0.1 and Tb trunk(2012/5/22 build) showed it in attachment pane. This is same as example in RFC 2017. > --NextPart > Content-Type: Message/External-body; access-type=URL; URL="http://tools.ietf.org/rfc/rfc2017" > Content-Disposition: inline; filename="external-body-03.txt" > > Content-Type: text/plain > > THIS IS NOT REALLY THE BODY! > > --NextPart-- When this attachment was opened(viewed) by notepad.exe, following was shown. > Content-Type: text/plain > > THIS IS NOT REALLY THE BODY! External-Body Subtype, access-type=URL is defined by; > http://tools.ietf.org/html/rfc2046#section-5.2.3 > http://tools.ietf.org/rfc/rfc2017 Partial Subtype is defined by; > http://tools.ietf.org/html/rfc2046#section-5.2.2 but Tb currently doesn't support message/partial. It looks that Tb doesn't support message/external-body yet. Bug opener, message/external-body is actually supported, so you opened this bug for "multiple message/external-body parts under multipart/alternative part in multipart/mixed mail"? Please separate "problem in Message/External-body handling" and "problem in multipart/alternative handling" and "problem in Content-Disposition:attachment/inline, name=/filenme= handling(Bug 747770)".

WADA, I've tried the attached message and it seems that the only issue is that someone removed all the code that prints out message/external-body content got removed back in 1999 (!). I have a work-in-progress patch that adds some output and it fixes the issue in this bug. The title is probably inaccurate though, since this is just about message/external-body being broken.

FYI. Message/External-body bugs pointed by Eyal Rozenberg in Comment #8 on 2005-02-04. Bug 260730 : display of Message/External-body. Closed as EXPIRED. Bug 260724 : mail composition with Message/External-body. Closed as EXPIRED. Currently open bug with "message && external-body" in bug summary. Bug 669010 : RFC2046, RFC2017: Thunderbird doesn't parse message/external-body correctly.

(In reply to Jim Porter (:squib) from comment #20) > WADA, I've tried the attached message and it seems that the only issue is > that someone removed all the code that prints out message/external-body > content got removed back in 1999 (!). I was somewhat involved in the early development circa 1998. This report was filed in 2001, but is not my first bug report. > I have a work-in-progress patch that > adds some output and it fixes the issue in this bug. > Looking forward to it after ~11 years. > The title is probably inaccurate though, since this is just about > message/external-body being broken. Once upon a time, everything was so broken that the message would briefly flash and then the window would close. Not exactly crashing bug, but impossible to view the message at all. Some things have been fixed over the intervening years.... Comment #7.

Changing bug summary, to make this bug for problem in Message/External-body only.

Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.

The message in attachment 173184 [details] is Multipart/Mixed, the first part is text/plain, the second part it Multipart/Alternative, with text/plain and text/HTML. 49.0a1 (2016-05-17) displays: Message body in plain text. --- Nested mult/alt body part 1: plain text or Message body in plain text. --- Nested mult/alt body part 2: HTML depending on the view settings. This works well enough, so I'm closing this. This bug is fifteen years old and I don't see that further improvement is needed.

I assure you, this doesn't work. The attachment has nothing to do with this bug, really.

OK, it will rest another fifteen years until someone can state in short what the problem is.

See comment 20.

Oh, comment #20 says that you had a WIP patch four years ago almost to the day (2012-05-23). So your saying it won't take another 15 years to see some action here? ;-)

(In reply to Jorg K (PTO during summer, NI me) from comment #27) Thank you for reopening Simple explanation: * Ignore the title to avoid confusion (it was relevant when people knew what had been removed). * MailNews should support displaying the part structure of a multipart message * MailNews should support multipart-relevant features in a more versatile and explicit manner: Choosing between individual alternative subparts in Multipart/Alternative, folding individual parts/sub-parts in the hierarchy of Multipart/Mixed, choosing to save any individual (sub)part etc. I would suggest at least changing the title to reflect this summary. I'll also say that this has been sorely missing for years; and, please do not be overly offended, but I believe your suggestion that "this works well enough" is a testament to how the passage of time has made many people forget what that an email client - a MIME client - can and should support.

(In reply to Jorg K (PTO during summer, NI me) from comment #29) > Oh, comment #20 says that you had a WIP patch four years ago almost to the > day (2012-05-23). So your saying it won't take another 15 years to see some > action here? ;-) I'm very unlikely to touch anything in libmime ever again, given that jsmime is due to replace it. Once jsmime is enabled for parsing all messages, I might take another look at this issue. (In reply to Eyal Rozenberg from comment #30) > * MailNews should support displaying the part structure of a multipart > message If that's what this bug should be about, then I'd argue for WONTFIXing it. I don't think the extra complexity of showing part structure is worth it, given that most messages (especially these days) are pretty simple. For the (in my estimation) rare case where this isn't enough, add-ons *should* have enough information that they can display the full part structure. In fact, I wrote such an add-on, but hardly anyone ever downloaded it, so I largely abandoned it: <https://addons.mozilla.org/en-US/thunderbird/addon/attachment-tree/>. However, there *is* a real bug with the message in comment 0, and that's that external body parts aren't shown properly.

Please suggest a suitable title if you don't have the rights to change it. (In reply to Eyal Rozenberg from comment #30) > I'll also say that this has been sorely missing for years; and, please do > not be overly offended, but I believe your suggestion that "this works well > enough" is a testament to how the passage of time has made many people > forget what that an email client - a MIME client - can and should support. I'm not offended at all. I've been through the process of looking at all the dependents of bug 505172 to check their status. Many of them were fixed or duplicates or complaints about TB not working well on bad/invalid data. If I understand your comment #30 well enough, this should be an enhancement, since for most people, TB does actually work well enough. It is actually a desktop e-mail client and most 99.995% of our users wouldn't have the faintest clue about MIME, parts, etc. Personally, only being on the project for about one year, I don't understand the Mozilla attitude. It seems to me, that having a lot of open bugs make people happy. To me, bug equals "problem", so I'd try to keep the number low, also to focus the development effort of the few (unpaid) volunteers onto more important problems. A bug that has been open for fifteen years with someone who had a WIP patch four years ago doesn't help anyone, IMHO. <off topic> My pet hate is for example is that when searching messages, instead of searching the base64-decoded body, we search the raw data. So you will never find what you're looking for. That just to show you that we have more pressing issues that satisfying people who haven't forgotten what a MIME client should be able to do. </off topic>

(In reply to Jorg K (PTO during summer, NI me) from comment #32) > Personally, only being on the project for about one year, I don't understand > the Mozilla attitude. It seems to me, that having a lot of open bugs make > people happy. To me, bug equals "problem", so I'd try to keep the number > low, also to focus the development effort of the few (unpaid) volunteers > onto more important problems. A bug that has been open for fifteen years > with someone who had a WIP patch four years ago doesn't help anyone, IMHO. If an issue is valid (i.e. it makes sense and is a real problem or a reasonable feature request) and we haven't decided to WONTFIX it, it should remain open. Age shouldn't be a factor; some bugs are just low-priority, but that doesn't make them not bugs. Leaving these bugs open also helps users find existing bugs to add their comments to instead of filing duplicates. In any case, there are so many valid bugs that I don't think closing a handful of them is a realistic way to direct volunteer efforts. Instead, we should be using our discussion groups (e.g. tb-planning) to coordinate our efforts on areas that we think are important.

(In reply to Jorg K (PTO during summer, NI me) from comment #32) > If I understand your comment #30 well enough, this should be an enhancement, > since for most people, TB does actually work well enough. It is actually a > desktop e-mail client and most 99.995% of our users wouldn't have the > faintest clue about MIME, parts, etc. You know, for about a decade there was this obscure feature of HTML 4 which wasn't properly supported by Gecko; it was some kind of a table column alignment bug,, with bug ID under 1000 (I forget which). Now, Mozilla was "actually a desktop browser", not an HTML renderer, and 99.995% of our users wouldn't have the faintest clue about that feature and could care less. Obviously, nobody would think of marking that issue as an 'enhancement'. A desktop mail client is supposed to support the Multipurpose Internet Mail Exchange protocol. Not having the functionality described here is part of how development on Netscape Communicator did not continue with the transition to the Mozilla project (or was stunted even before that). Now, many (most?) non-GUI desktop email clients have some or all of this functionality, but most people using GUI clients have just not seen it for 20 years, since Mozilla and Microsoft have not cared to implement it. On the other hand, people who were exposed to other clients - such as Eudora - did expect it, which is how this bug got filed. You can, and should, imagine a future in which clients have proper MIME support, and then you could start seeing: - Multiple character encodings in different parts of the same message - Easy switching between text, Markdown, HTML4/5 and whatever-comes-after - Braille as part of Multipart/alternative - Hierarchies of "attachments" conveying relations between them - Different attachments for different parts of the message and so on. _Those_ are some of the enhancements.

<off-topic> (In reply to Jim Porter (:squib) from comment #33) > In any case, there are so many valid bugs that I don't think closing a > handful of them is a realistic way to direct volunteer efforts. As I said, I was surveying the dependents of bug 505172. I found bug 253830 worth looking into, also given that bug 348045 comment #6 claims that this bug will get fixed, too. I think it would be a bonus to show the text/plain part and not a stripped down text/HTML part. Also, fixing bug 348045 would be nice so TB can handle missing parts more gracefully. Other than that, I have no inclination to work on MIME or multipart stuff given that I ironed out a few charset issues in TB 45. As far as I can see, valid multipart messages work well enough now. </off-topic>

<off-topic> (In reply to Jorg K (PTO during summer, NI me) from comment #32) > I don't understand the Mozilla attitude. It seems to me, that having a lot of open bugs make > people happy. To me, bug equals "problem", so I'd try to keep the number low, also to focus the > development effort of the few (unpaid) volunteers onto more important problems. At the risk of veering too far off-topic, I'll add a few words to Jim Porter's comments. You should not try to keep bug numbers low or high. Bug counts are an artificial statistic to begin with, and once bugs are closed for the purpose of being closed (which is what you describe) - it becomes meaningless. I know this is easier to preach than to follow - in my own projects, the existence of bugs annoy me (even though usually I opened them) and I get the urge occasionally to justify closing some of them, so that I can feel I have things more under control. But I know that's a nasty habit :-) once more people are involved, this becomes untenable, and bug closures often end up being applications of brute coercive force within the community of developers and users. Focusing development effort, on the other hand, is perfectly valid - but bug closure is not the method to go about it. Bug tracking systems have relevant features for that - several features, actually; Bugzilla has the P1-P5 priority marking; or you can use custom tags; or keywords; or tracker bugs corresponding to the foci for a certain period of time; and so on. </off-topic>