[#1866] Displaying all MIME part summary information
Summary Displaying all MIME part summary information
Queue IMP
Queue Version HEAD
Type Bug
State Resolved
Priority 2. Medium
Owners slusarz (at) horde (dot) org
Requester vilius (at) lnk (dot) lt
Created 2005-04-26 (5989 days ago)
Updated 2008-11-14 (4691 days ago)
Assigned 2008-11-09 (4696 days ago)
Resolved 2008-11-14 (4691 days ago)
Milestone IMP 5.0
Patch No

2008-11-14 20:44:37 Michael Slusarz Comment #15
State ⇒ Resolved
Reply to this comment
All parts in a message can now be displayed using IMP 5.
2008-11-09 02:34:05 Chuck Hagenbuch Comment #14
State ⇒ Assigned
Reply to this comment
Un-stalling for new mime lib.
2007-05-13 03:34:13 Chuck Hagenbuch Comment #13
State ⇒ Stalled
Reply to this comment
Stalling with other IMP 5/Horde 4/etc. tickets.
2006-03-01 20:56:40 Michael Slusarz Summary ⇒ Displaying all MIME part summary information
2006-03-01 20:55:27 Michael Slusarz Comment #12 Reply to this comment
Change milestone.  See: http://wiki.horde.org/NewMIMELib for coding 
needed to fix this reliably.
2005-11-13 20:22:58 Michael Slusarz Comment #11 Reply to this comment
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.
2005-10-26 07:10:57 Michael Slusarz Comment #10 Reply to this comment
See, e.g., Bug 2113 for an example of how it can be difficult to 
access portions of the message independently.
2005-10-23 13:22:19 Jan Schneider State ⇒ Assigned
2005-09-22 06:56:24 Michael Slusarz Comment #9
Priority ⇒ 2. Medium
Reply to this comment
Fix this before the next minor version release.
2005-06-04 07:51:16 Michael Slusarz Comment #8 Reply to this comment
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.
2005-04-29 14:31:50 Chuck Hagenbuch Comment #7
State ⇒
Reply to this comment
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.
2005-04-29 07:20:34 vilius (at) lnk (dot) lt Comment #6 Reply to this comment
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.
2005-04-29 06:56:26 Michael Slusarz Comment #5 Reply to this comment
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 
2005-04-29 06:38:49 vilius (at) lnk (dot) lt Comment #4 Reply to this comment
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.
2005-04-29 04:13:35 Michael Slusarz Comment #3
State ⇒ Not A Bug
Reply to this comment
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).
2005-04-27 21:39:28 Chuck Hagenbuch Assigned to Michael Slusarz
2005-04-26 11:01:03 vilius (at) lnk (dot) lt Comment #2
New Attachment: Undelivered Mail Returned to Sender.eml Download
Reply to this comment
Another tipical message.
2005-04-26 09:30:09 vilius (at) lnk (dot) lt Comment #1
Type ⇒ Bug
State ⇒ Unconfirmed
Priority ⇒ 1. Low
Summary ⇒ "download all attachments" link display
Queue ⇒ IMP
New Attachment: Re_ is SWATCH.eml Download
Reply to this comment
"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.

Saved Queries