All parts in a message can now be displayed using IMP 5.

Un-stalling for new mime lib.

Stalling with other IMP 5/Horde 4/etc. tickets.

Change milestone.  See: http://wiki.horde.org/NewMIMELib for coding 
needed to fix this reliably.

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.

See, e.g., Bug 2113 for an example of how it can be difficult to 
access portions of the message independently.

Fix this before the next minor version release.

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.

This makes sense to me.

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.

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.

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.

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).

Another tipical message.

"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.