Currently, when you receive a mailing list in MIME digest form, you see all the messages one by one in the message body, and in the list of attachments. You can open an attachment (i.e. an individual message), but it opens in a browser window, instead of a mail window, so the headers are not parsed, you cannot reply etc. The behaviour I would prefer is having the head and list of topics displayed initially, and being able to click on the individual message subjects to display one particular message. (There should then be a button/link to return to the list of topics.) Or, one could navigate between the individual messages using the attachment list, but then it should be resizable or something, because it's too small for that. I'm Using Mozilla 1.0RC2 on Win98SE. The particular mailing list I'm receiving is XFree86 Xpert.

This sounds like a nifty (though perhaps low-priority) feature. OS/Plat -> All, since this is not platform-specific. Attachments doesn't sound like the right component, but I can't figure out what the right one would be.

Why not choose the front-end component?

I would like functionality like in RMAIL, a mail reader for emacs. In RMAIL, digest mail can be converted to regular messages on a command (meta-x undigestify). The original message is marked for deletion, and the header and footer of the digest is preserved. I would also love for Mozilla to be able to handle Listserv type digests as well. They aren't really MIME-friendly, but they are widely-used. Finally, it would be cool if Mozilla were to attempt to render MIME messages in individual messages of a Listserv digest. Listserv tends to strip off MIME headers from items in a digest. In a way, that is more of a MIME feature request than anything.

Bug 188677 has a similar feature request.

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

Per the original report in this bug: RFC822 attachments do now open in their own message window, since Moz1.4. See bug 204350.

This would be an incredibly useful feature. I subscribe to multiple mailing lists and it is difficult to navigate, read and reply to individual messages in a digest.

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

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

Pegasus Mail handles mime-digests by displaying them as a virtual folder. Pegasus Mail uses MDI child windows, so it's easy and obvious how this works in that application. I'm not sure how to do this with the 3-pane view in Thunderbird. Anyway, I think something needs to be done to improve handling of mime digests.. thanks

I have some suggestions which may be less pain and suffering, but yield considerable usability enhancements (80/20 rule). TB could [brace yourself] parse the first text/plain part and add a hyperlink around the description text which jumps to the actual message in the pane. If that ugly "p" word creates too much pain and suffering, a TB-generated page to replace it would be Fine By Me(tm). The problem in my world is that the attachments are named "dev_1298.ezm" and similar, and yet there is no way I have to navigate between rfc822 subparts. Being able to jump to the message I want would be a huge improvement. Yet ANOTHER alternative (IMHO) is to do as Mutt does and ignore the "Content-Disposition: filename=" header, naming the subpart attachment using its Subject header instead. I am not afraid of a C compiler nor Javascript, but I have absolutely zero experience hacking on any of the Zilla products, so someone would need to guide me a bit. Even "these three pages are best to read" would be great.

Matthew Daniel in comment #11: > ... > I am not afraid of a C compiler nor Javascript, but I have absolutely zero > experience hacking on any of the Zilla products, so someone would need to guide > me a bit. Even "these three pages are best to read" would be great. Matthew Mike Cowperthwaite (who commented earlier), David Bienvenu and maybe others in bug 204350 could give you a start if asked :)

One approach would be to change the mime html emitter to insert anchors and links to the anchors when it's parsing a digest message. I don't know how to make our mime code do that but here are a couple places to look: http://lxr.mozilla.org/seamonkey/source/mailnews/mime/src/mimetpfl.cpp http://lxr.mozilla.org/mozilla/source/mailnews/mime/emitters/src/nsMimeHtmlEmitter.cpp

Just for curiousity: has there been any activity in realizing better operability to handle digests of mailing lists recently? I am still desperately missing this feature... --- and in the quite active mailing lists I have subscribed to there have been others who share this feeling: http://tolstoy.newcastle.edu.au/R/help/05/08/10118.html http://tolstoy.newcastle.edu.au/R/help/06/08/32715.html I had a short glimpse into the treatment in your mime html emitter --- but probably am not expert enough to provide enhancements in there. Another idea would be to combine your virtual folder concept and an enhanced mime html emitter --- I have no straightforward idea how to realize this, but "digesting" the multipart/digest mail with your mime html emitter, you could try and generate a new "virtual" mail for each of its message/rfc822-parts using the corresponding header information of each rfc822-part and then sort them into a virtual folder named after the subject of the original multipart/digest mail. I do not see how complicated this is to program --- but at least for me it would mean a great enhancement. Thanks for listening Peter

Replying a digest of a mailing list ends up in not quoting the entire digest, but just up to the first double hyphen separator. I see this bug has been around for 5 years.

(In reply to comment #15) > Replying a digest of a mailing list ends up in not quoting the entire digest, > but just up to the first double hyphen separator. > I see this bug has been around for 5 years. This issue is about MIME digests. You should never be trying to reply to a MIME digest as a whole, as that, unnecessarily, breaks threading, and requires you to fix up the subject line. You should reply to the individual message, in which case stripping the hyphen-hyphen-space, and what follows is just enforcing good practice.

(In reply to comment #0) > messages one by one in the message body, and in the list of attachments. You can > open an attachment (i.e. an individual message), but it opens in a browser > window, instead of a mail window, so the headers are not parsed, you cannot > reply etc. That no longer seems to be the case. I regularly reply to attachments, at least under Linux. Whilst having to find the right attachment is a bit unfriendly, the issue wasn't proposing anything better, and whilst the mechanism is somewhat buggy, I am raising those as separate issues. My feeling is that the original issue has been resolved, even if it was done independently of this issue.

(In reply to comment #17) > I regularly reply to attachments, at > least under Linux. How? Also, note that making this capability useful is obviously a criteria for considering it fixed.

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120418 Firefox/12.0 SeaMonkey/2.9 Ran into this this morning, trying to reply to a message in a digest. Currently, digests display nicely inline after the main message body. Comment 17 taught me that you can click on the digest part in the attachment list to open it discreetly, although it might be hard to find the right message. I would offer two ways to make displaying/replying to message digests easier: 1. When one double clicks on message content in the message pane, open the clicked upon content in its own window/tab. If one clicks on the main message body, the body opens in its own window. If one clicks on an inline displayed image, the image opens in its own window. If one clicks on a digest part, that digest message opens in its own window. 2. When one context (right) clicks on content in the message pane, the context should apply to that part, not the main message body (unless that's what one clicked on.) A minimal fix would just make sure that the reply/reply all options were applied to the current message part. That would pretty much take care of the usability issues associated with this bug? (Generically, the context menu could be made to be applicable to whatever kind of attached content one clicked on.) Perhaps bugs already exist for these enhancements, I haven't had a chance to search.