Tickets :: Comment on [#3381] "forward" handles multipart/alternative incorrectly

* Your Email Address
* Spam protection	Enter the letters below: .___ __..__ .___.._. [__ (__ [__) _/ \| \| .__)[__)./__._\|_
Comment	>> With multipart/alternative + forwarding inline, I'd also be fine with > >> just taking the text part from the alternative part and dropping the > >> rest. If at some point we can be smarter and take the HTML part if we > >> support HTML composition, that's a bonus. > > > > Not trying to be difficult here :) but here's the big issue w/ > multipart/alternative parts. Say you receive this message (which I > do, on a fairly consistent basis, from a known contact): > > > > + multipart/alternative > > + text/plain > > + text/html > > + application/pdf > > > > What I really want out of these three is the application/pdf. > Those other 2 are useful for displaying inline (since inline PDF > display isn't happening - at least very easily w/web based clients). > But when I forward this kind of message (which I often do), what I > really want is that application/pdf part to make it to the next user. > the text/plain and text/html parts are worthless when it comes to > formatting of that PDF part. So simply "picking" one part of the > multipart is not that easy...
Attachment
Watch this ticket