Changes have been made in Git for this ticket:

Bug #7981: Fix multipart/alternative display

http://git.horde.org/diff.php/imp/lib/Contents.php?rt=horde-git&r1=ca9f1cefefcec92e06426308ce9fbbb27db995ef&r2=0c44534434df22f1c14487a2669a452d888003f2
http://git.horde.org/diff.php/imp/lib/Mime/Viewer/Alternative.php?rt=horde-git&r1=03b873a3c2c36e31645423438c483ca2c3ccc51d&r2=0c44534434df22f1c14487a2669a452d888003f2
http://git.horde.org/diff.php/imp/lib/UI/Message.php?rt=horde-git&r1=65bda1b07fd3799a36980f3bbd8f9716c8649bbe&r2=0c44534434df22f1c14487a2669a452d888003f2

Fixed.  Turns out we were handling the embedded multipart/mixed in 
multipart/alternative correctly - there simply wasn't a way (in IMP 4) 
to show an attachment contained within a list of inline viewable parts 
underneath multipart/alternative.  Luckily in IMP 5, this was able to 
be added with only a few lines of code.

Changes have been made in Git for this ticket:

Bug #7981: Fix multipart/alternative display

http://git.horde.org/diff.php/imp/lib/Contents.php?rt=horde-hatchery&r1=ca9f1cefefcec92e06426308ce9fbbb27db995ef&r2=0c44534434df22f1c14487a2669a452d888003f2
http://git.horde.org/diff.php/imp/lib/Mime/Viewer/Alternative.php?rt=horde-hatchery&r1=03b873a3c2c36e31645423438c483ca2c3ccc51d&r2=0c44534434df22f1c14487a2669a452d888003f2
http://git.horde.org/diff.php/imp/lib/UI/Message.php?rt=horde-hatchery&r1=65bda1b07fd3799a36980f3bbd8f9716c8649bbe&r2=0c44534434df22f1c14487a2669a452d888003f2

Agreed.
Also agreed.

I'm not sure it is. Looking at the message structure, you have text 
vs. mixed. So if we can display mixed, and we can, seems like we 
should just treat the message as though it were html - excel - html. 
The entire 3-part string is the alternative - they aren't alternatives 
for each other.

Actually, why can't we put a download icon there? We might not want 
to, and the code for it might be ugly, but technically it's possible.
This is why it's not necessarily great usability to flag for the user 
each different part of the message. If we don't call out each part, 
but display what we can and provide download links for the rest, then 
the user doesn't have to *know* there's an empty part. There might 
just be a little extra space at the end of the message. But they don't 
need to care about it, because the UI doesn't have to make it obvious.



In the end, as long as we can do something where I get a download link 
for the spreadsheet in this message, without having to turn on the 
full parts list (which I don't think is a user-friendly thing, but 
that's a separate issue perhaps), then I'm happy.



Thanks for working through this.

[Note: I had written a long explanation of why this was message at 
some point - evidently, it was never posted to the ticket.  So my 
response was probably not as clear as needed because it was lacking 
this context]
I think we are talking about 2 separate issues here.  Issue 1 is how 
to display (alleged) attachments that are not ordinarily displayable 
in a MIME message.  Two examples would be parts of a multipart/related 
message that are not linked in the base message and 
multipart/alternative parts that are not displayable in the browser 
(which, as it turns out, is not the present issue - see below).  In 
both cases, for exactly the usability reasons discussed below, these 
parts CAN NOT be displayed inline as attachments unless attachment 
inline viewing is turned on.  Doing so means that there is no longer 
multipart/related or multipart/alternative messages - we just display 
everything as multipart/mixed.  This can not be the case.



e.g. For multipart/alternative parts, displaying the "alternative 
parts" box was a usability nightmare also so that should not be 
brought back.  Especially in light of this mandate from the RFC: "What 
is most critical, however, is that the user not automatically be shown 
multiple versions of the same data."



The 2nd issue is simpler: tweaking the display of 
multipart/alternative parts.  That is the present case.  The MIME 
structure here is as follows:



multipart/alternative

  text/plain

  multipart/mixed

   test/html

   application/vnd.ms-excel

   test/html



This oh-so-unenlightening remark from RFC 2046 [5.1.4] is the key:



    In the case where one of the

    alternatives is itself of type "multipart" and contains unrecognized

    sub-parts, the user agent may choose either to show that alternative,

    an earlier alternative, or both.



So the RFC tells us nothing in this situation.  Useful.  Displaying 
both is just bad usability IMHO.  And the current method of handling 
this message (displaying an earlier alternative) is what is being 
complained about.  So what needs to be done here is revamping the 
display algorithm to show the later multipart alternative even if it 
may contain parts that are not viewable inline. (Do we display the 
multipart alternative even if it contains no viewable parts?  It is 
not clear from the RFC.)



Finally, my rant: This message does nothing to alter my view of 
Mail.app (and it's not just me - if you want to see some real Mail.app 
bashing, read the dovecot list sometime).  This message apparently 
assumes that the receiving user is on a desktop-ish machine - it seems 
as though the message wants the spreadsheet attachment to be living in 
the middle of the HTML part.  This display tactic may work on a 
desktop machine, where one can display a little spreadsheet icon a 
user can click/drag-drop/etc., but is not practical on something like 
webmail.  The resulting display on clients that can't generate this 
kind of UI (webmail, pine/alpine/elm) will be an HTML part, a link to 
download the spreadsheet attachment, and then *another* HTML part that 
is completely empty of content.  With that last part: how is that not 
a usability nightmare?  I can imagine a bunch of users complaining why 
they are being shown a part with no content and/or why the software is 
broken and not showing the correct contents of that part.  At a 
minimum, the generation of this MIME message is ignorant.
I don't have a Mac handy to view this.  But see my desktop vs. 
non-desktop discussion above.
These changes have been brought about precisely because of the 
numerous complaints of the way we currently handle attachment lists.

Well, we need to find some way to reconcile the standards and 
usability. The parts list is *not* a user friendly or obvious solution 
to this. And your statements about what the sending user intended are 
over inferential in my opinion. I'm pretty sure the sender of the 
message that inspired this test intended me to be able to download the 
excel spreadsheet without a). picking it from a raw list of every part 
of the message, and b). being able to view it inline in my mail client.



What do you think is wrong about how Mail.app displays this message?



We did a lot of work during the initial DIMP project on usability of 
the attachments list, trying to match up with other user-friendly 
clients, etc. I don't want IMP 5 to lose this.

I still vehemently disagree with this.  If we are receiving a message 
that is broken, I am fine with not trying to "guess" what the user 
meant to send.  Because what you are asking for is to convert the 
explicit definition of multipart/alternative into, essentially, 
multipart/mixed.  And that's not what it is.  Why stop there, then?   
Theoretically, if a message "looks" like a MIME message but doesn't 
have a MIME-Version header, we could go ahead and parse the message 
anyway.  But that's *not* what the sending user intended.



The fact that this part doesn't show in IMP 5 is exactly what is 
intended (vs. IMP 4).  Again, for access to any part of the message 
(whether it is viewable or legal or not), going forward the only 
location to do this will be in the 'Parts' section of the header.  The 
inline section is only intended to show legal parts meant to be viewed 
inline (and if atc mode is on, it will also show downloadable legal 
parts).

If you set the parts_display preference to atc, there is no trace of 
it. I can see this with parts_display set to none, but not set to 
explicitly show attachments. I know it's part of the alternative part, 
but this was generated with your favorite client (Apple Mail) and 
people are going to run into it.

It's there - you need to look at the parts list (see attachment).  It 
shouldn't show by default because it is part of the alternative part.

Weird. Probably my mistake. It's uploaded now.

Don't see an attachment.

The attached message has an excel spreadsheet part, which IMP 5 
provides no way to access. I'm guessing that the spreadsheet, as an 
attachment, should be part 3 instead of part 2.2, but we should still 
make it possible to download parts like this.