Looking at the structure of the message, by the letter of the RFC 
(2387) it appears that we actually *are* displaying it correctly.



This message is structured as follows:



multipart/related

   multipart/alternative

     text/plain

     text/html

   image/jpeg

   image/jpeg

   ...



What's important is that the image files are under the 
multipart/related.  From that RFC, it states that MUA's that can not 
handle multipart/related will display this message as multipart/mixed. 
  However,

   "User Agents that understand Multipart/Related shall ignore the 
disposition type within a Multipart/Related body part."

   "for a Multipart/Related object, proper display cannot be achieved by

    individually displaying the constituent body parts"



If the 'root' object of the multipart/related object does not 
reference the other data objects in that part, they do *not* 
necessarily need to be displayed to the user and can be ignored.



But obviously it would be nice to have a way to display all MIME parts 
available in a message.  However, this means that this bug is simply 
another duplicate of Bugs 1863 and Bugs 1866.

... and the file, since I haven't fixed this damn bug in Whups yet.

Viewing the attached email in IMP, I don't have an option anywhere to 
view or download the image attachment, though it appears to be a valid 
message (generated by Outlook though it is).