[Tickets #7981] Re: No way to get some attachments to a multipart message

[bugs at horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/7981
------------------------------------------------------------------------------
  Ticket             | 7981
  Updated By         | Michael Slusarz <slusarz at horde.org>
  Summary            | No way to get some attachments to a multipart message
  Queue              | IMP
  Version            | Git master
  Type               | Bug
  State              | Assigned
  Priority           | 2. Medium
  Milestone          |
  Patch              |
  Owners             | Horde Developers, Michael Slusarz
------------------------------------------------------------------------------


Michael Slusarz <slusarz at horde.org> (2009-06-11 12:16) wrote:

[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]

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

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.

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

I don't have a Mac handy to view this.  But see my desktop vs.  
non-desktop discussion above.

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

These changes have been brought about precisely because of the  
numerous complaints of the way we currently handle attachment lists.