6.0.0-git
2019-03-22

[#7981] No way to get some attachments to a multipart message
Summary No way to get some attachments to a multipart message
Queue IMP
Queue Version Git master
Type Bug
State Resolved
Priority 2. Medium
Owners Horde Developers (at) , slusarz (at) horde (dot) org
Requester chuck (at) horde (dot) org
Created 2009-02-13 (3689 days ago)
Due
Updated 2010-01-13 (3355 days ago)
Assigned 2009-06-03 (3579 days ago)
Resolved 2009-11-09 (3420 days ago)
Milestone
Patch No

History
2009-11-09 19:40:37 Michael Slusarz Comment #11
State ⇒ Resolved
Reply to this comment
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.
2009-07-10 03:11:22 Chuck Hagenbuch Comment #9 Reply to this comment

[Show Quoted Text - 11 lines]
Agreed.
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."
Also agreed.

[Show Quoted Text - 20 lines]
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.

[Show Quoted Text - 9 lines]
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.
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.
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.
2009-06-11 16:16:34 Michael Slusarz Comment #8 Reply to this 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.
2009-06-03 03:12:19 Chuck Hagenbuch Comment #7
Assigned to Michael Slusarz
Assigned to Horde DevelopersHorde Developers
State ⇒ Assigned
Reply to this comment
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.
2009-06-02 19:40:53 Michael Slusarz Comment #6
Taken from Michael Slusarz
State ⇒ Not A Bug
Reply to this comment
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).
2009-02-13 05:58:22 Chuck Hagenbuch Comment #5
State ⇒ Assigned
Reply to this comment
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.
2009-02-13 05:30:03 Michael Slusarz Comment #4
State ⇒ Feedback
New Attachment: Clipboard01.png Download
Reply to this comment
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.
2009-02-13 05:20:50 Chuck Hagenbuch Comment #3 Reply to this comment
Weird. Probably my mistake. It's uploaded now.
2009-02-13 05:20:22 Chuck Hagenbuch New Attachment: test.eml Download
 
2009-02-13 05:15:41 Michael Slusarz Comment #2 Reply to this comment
Don't see an attachment.
2009-02-13 05:09:08 Chuck Hagenbuch Comment #1
Type ⇒ Bug
State ⇒ Assigned
Priority ⇒ 2. Medium
Summary ⇒ No way to get some attachments to a multipart message
Queue ⇒ IMP
Assigned to Michael Slusarz
Milestone ⇒
Patch ⇒ No
Reply to this comment
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.

Saved Queries