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

[bugs at horde.org]

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-11 05:00) wrote:

>> But I don't understand how they could display these as attachments?
>> If they do they are going entirely against the wishes of the original
>> sender.
>
> I disagree - they're going against the expressed intent of the  
> sender's client, which may or may not be what the person sending the  
> mail intended.

I totally disagree with this statement.  A sender is given a set of  
rules on how to send a message.  We use those rules to interpret their  
intent.  What you are saying is that somehow we need to determine that  
their intent is completely opposite of what they actually sent.  Or,  
more succinctly, we simply need to ignore *all* message structure and  
display however we feel like.

>> If I send a message to you that says that you shouldn't see any
>> attachments if you can only view the text/plain part, then that's the
>> way I want the message to be viewed by you.
>
> I feel like we're not serving our user well in that case though,  
> since a) that view of how the message should be viewed could have  
> been constructed by a buggy MUA, and b) even if it was the express  
> intent of the sender, it could be really frustrating to the  
> receiver, and the receiver is our user and who we should be serving  
> imo.
>
> I feel like this whole area is a case of "be strict in what you omit  
> and liberal in what you accept".

But we simply CAN'T be doing this with these messages.  This defeats  
the ENTIRE purpose of multipart/alternative.  We might as well show  
all the alternative parts to the user every time by this reasoning.   
Which is essentially what you are asking us to do.

>> Or else, what's the point of any of these MIME types?
>
> I imagine an email spec written today would be greatly simplified.  
> So ... possibly in real world usage, some of them don't have a point.

That may be true, but multipart/alternative is not one of these types  
that doesn't have a point.  Instead, it has a clear purpose that is  
very useful: to provide a single representation of a message part  
without the user even being aware that other representations exist.