[Tickets #7981] Re: No way to get some attachments to a multipart message
bugs at horde.org
bugs at horde.org
Thu Jun 11 16:16:34 UTC 2009
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
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
> 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:
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.
More information about the bugs