6.0.0-beta6
▾
Tasks
New Task
Search
Photos
Wiki
▾
Tickets
New Ticket
Search
dev.horde.org
Toggle Alerts Log
Help
4/10/26
H
istory
A
ttachments
C
omment
W
atch
Download
Comment on [#7981] No way to get some attachments to a multipart message
*
Your Email Address
*
Spam protection
Enter the letters below:
. .. . .__ . . \ /| | [__)\ / \/ |___|___| \/
Comment
> [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.
Attachment
Watch this ticket
N
ew Ticket
M
y Tickets
S
earch
Q
uery Builder
R
eports
Saved Queries
Open Bugs
Bugs waiting for Feedback
Open Bugs in Releases
Open Enhancements
Enhancements waiting for Feedback
Bugs with Patches
Enhancements with Patches
Release Showstoppers
Stalled Tickets
New Tickets
Horde 5 Showstoppers