[Tickets #9827] Re: attachments are not shown for this message

bugs at horde.org bugs at horde.org
Mon Apr 18 22:53:57 UTC 2011


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

Ticket URL: http://bugs.horde.org/ticket/9827
------------------------------------------------------------------------------
  Ticket             | 9827
  Updated By         | Michael Slusarz <slusarz at horde.org>
  Summary            | attachments are not shown for this message
  Queue              | IMP
  Version            | Git master
  Type               | Bug
  State              | Unconfirmed
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             |
------------------------------------------------------------------------------


Michael Slusarz <slusarz at horde.org> (2011-04-18 22:53) wrote:

>>> A valid workaround already exists to see these parts in standard view
>>> - by clicking on view all message parts.  If this feature was added
>>> to the dynamic view also, would this be sufficient?
>>
>> As told earlier, interpreting particular MUA messages differently
>> would be better, but at least for my users "View All Message Parts"
>> method is enough too.
>
> To me, "view all message parts" is a good workaround for power users  
> or really broken messages. But I'm guessing that most end users  
> won't find it (or know when to use it) without specific help, so I'd  
> prefer another solution. I'm okay if we want to treat messages from  
> a specific MUA differently, though it doesn't feel *quite* right to  
> me.
>
> I'm still wondering how many real-world use cases there are for  
> multipart/alternative parts that aren't text/plain or text/html? The  
> one that's been mentioned is calendar invites and that seems like  
> one we should special-case even if the invite *isn't* an alternative  
> part (i.e., text message with calendar attachment - we should show  
> the calendar response UI - along with any text - anyway). Beyond  
> that I don't know of any - just cases where a buggy MUA sends an  
> excel spreadsheet as one of the multipart/alternative parts, despite  
> clear user intent for the spreadsheet to be an attachment.

Here's just one example I can come up with of why we can't treat  
anything inside of a non-viewable alternative part as an attachment.

multipart/alternative
   text/plain
   multipart/related
     text/html
     image/png (content-disposition: attachment; image is used for  
HTML formatting)
     image/png (same)
     image/png (same)
     image/png (same)
     image/png (same)

This is a not uncommon message structure.  If text/html is disabled,  
the image/png's should definitely NOT be shown as attachments.  (This  
examples show that content-disposition is worthless for determining  
what parts are attachments).






More information about the bugs mailing list