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

* Your Email Address
* Spam protection	Enter the letters below: .__..___..___. ..__ [__] \| [__ \| \|\| \ \| \| \| [___\|/\\|\|__/
Comment	>>> 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.
Attachment
Watch this ticket

Saved Queries