Fri, 10 Apr 2026 03:14:09 +0000 https://bugs.horde.org/ticket/1866 Displaying all MIME part summary information "download all attachments" link display is incorrect. It is chown in all multipart messages even when there is no files attached. I attached source code of such message for testing purposes. Tue, 26 Apr 2005 09:30:09 +0000 https://bugs.horde.org/ticket/1866#t7689 Another tipical message. Tue, 26 Apr 2005 11:01:03 +0000 https://bugs.horde.org/ticket/1866#t7692 Nope - your first example has 1 attachment (the non-viewed part of the multipart/altenative part) and your second example has 2 attachments (the message error details part and the returned message part). Therefore, since there is more than 1 part to the message, the Download All link is proper. You may be getting confused - an "attachment" is not necessarily something a user actively attaches to a message. Rather, it is any part other than the first viewable part in the message. See IMP_Contents::getDownloadAllList() for the list of additional MIME_Parts that we *don't* consider an attachment (i.e. the exclusion list). Fri, 29 Apr 2005 04:13:35 +0000 https://bugs.horde.org/ticket/1866#t7796 I still don't understand one thing. Why would users want to download all linked parts of the message then there is no _real_ attachments in it. I understand that from developer's perspective all other linked parts except first viewable one is attachment. But for average user it is not. One more thing. When I create a HTML message with IMP, I get 2 parts: text and HTML version. When I hit "download all" link I see html version of the message in zip file. But.. When I create a HTML message with attachment (an image for example) and hit "download all", I see only image in the archive. Alternatively when I create HTML message with inline attached image, I don't see it in the list attachments, but I can download it with "download all" link. I think I can remember that this link behaviour was correct in early days of IMP4 pre/alpha/beta and wonder why it was changed in such confusing way. Fri, 29 Apr 2005 06:38:49 +0000 https://bugs.horde.org/ticket/1866#t7798 Responding to your first paragraph: then what is an attachment? What are the rules for an attachment? Why would, say, an image be considered an attachment if it appears in a multipart/alternative part, and yet a text part in a multipart/alternative is not? In other words, what exactly is an "attachment" to an average user? Remember, whatever your definition is it *has* to be coded somehow. You can't do a "I can't define it but I'll know it when I see it" (ala Justice Stewart in Jacobellis v. Ohio). Responding to the second pargraph - there are serious technical limitations to converting a MIME message->file download. Your first example is handled correctly - the zip file contains the one part of the multipart/altenative file that isn't seen. The second example is handled correctly - the image (which is completely separate from the HTML message) is the attachment and appears in the zip file. The third example is an example of a certain MIME type (i.e. multipart/related) that simply can not be downloaded in a single file since it is the joinder of two (or more) elements. You can't see a download on the message page because there *is* no image to download - the multipart/related type instead requires all of its components to be viewed together. No single component is displayed separately. However, when it comes down to downloading all attachments, we made a choice that it would be better to include these images (since the images may be the important part of the message and is what the user wants to download) in the zip file since they fit our definition of an attachment. Fri, 29 Apr 2005 06:56:26 +0000 https://bugs.horde.org/ticket/1866#t7800 In my opinion, IMP should treat attachments as Thunderbird, The Bat or even Outlook. Attachments for these clients are: 1) parts with Content-Disposition: attachment; 2) special cases, for example encapsulated MIME messages. Just like in my second example message (I agree now that this message has attachment :). 3) and NOT multipart/alternative or multipart/relative inline parts. Also I think that "download all" link behaviour must be 'syncronized' with attachment list above it. If there are no attachments there, don't show "download all" link also. Fri, 29 Apr 2005 07:20:34 +0000 https://bugs.horde.org/ticket/1866#t7802 > Also I think that "download all" link behaviour must be 'syncronized' with > attachment list above it. If there are no attachments there, don't show > "download all" link also. This makes sense to me. Fri, 29 Apr 2005 14:31:50 +0000 https://bugs.horde.org/ticket/1866#t7810 I'm currently working on some changes (involving use of Horde_Tree) to greatly improve the MIME message tree display in the header area. This should help alleviate some of the concerns illustrated in this report, as well as Bug 1863. Sat, 04 Jun 2005 07:51:16 +0000 https://bugs.horde.org/ticket/1866#t8849 Fix this before the next minor version release. Thu, 22 Sep 2005 06:56:24 +0000 https://bugs.horde.org/ticket/1866#t11679 See, e.g., Bug 2113 for an example of how it can be difficult to access portions of the message independently. Wed, 26 Oct 2005 07:10:57 +0000 https://bugs.horde.org/ticket/1866#t13057 See Bug 2938 for an example message that technically appears to be broken but we still want a way to access all independent MIME parts within the message. Sun, 13 Nov 2005 20:22:58 +0000 https://bugs.horde.org/ticket/1866#t13661 Change milestone. See: http://wiki.horde.org/NewMIMELib for coding needed to fix this reliably. Wed, 01 Mar 2006 20:55:27 +0000 https://bugs.horde.org/ticket/1866#t17189 Stalling with other IMP 5/Horde 4/etc. tickets. Sun, 13 May 2007 03:34:13 +0000 https://bugs.horde.org/ticket/1866#t33000 Un-stalling for new mime lib. Sun, 09 Nov 2008 02:34:05 +0000 https://bugs.horde.org/ticket/1866#t50520 All parts in a message can now be displayed using IMP 5. Fri, 14 Nov 2008 20:44:37 +0000 https://bugs.horde.org/ticket/1866#t50754