Tickets :: Comment on [#3367] Mime Message shows no parts

* Your Email Address
* Spam protection	Enter the letters below: .___.._.. . ..___ \| \| \ / \|[__ \| _\|_ \/ \__\|[___
Comment	>>> There shouldn't be a link to the image since > >>> this is a multipart/related part > >> Correct. The image is referenced in the HTML. I > >> stripped it out with all of the extra parts. They > >> have this: > >> <IMG alt="" hspace=0 src="cid:000001" > >> align=baseline border=0> > >> in order to display the image > > > > Are you saying that if this is in there that the image isn't > displayed when viewed in a pop-up window? I can't reproduce this. > > > >>> $mime_drivers['imp']['html']['inline'] = false; > >>> If you want inline display of HTML messages, > >>> then this has to be true. > >> I believe that this should be the default then, as > >> a new installation of horde (as I did for 3.2) has > >> this set to false by default. Ideally, text should > >> take priority, but no text part should then return > >> the html message if it exists. At present a clean > >> distribution of imp has html inline set to false. > >> I'm against HTML mail as with many, but it's a little > >> too commonplace these days to ignore as more people > >> send just html. > > > > But, as mime_drivers.php clearly states, allowing HTML messages to be > viewed automatically (or at all) can open huge security holes. We > try to strip the HTML of "bad tags" as best as possible, but readily > admit it is not 100% perfect. So we have decided to go with the > OpenBSD method of "secure by default" and leave it up to the > individual admin to activate this feature and accept the potential > issues associated with activating it. > > > > Additionally your description of how the MIME system decides which > parts to show appears to be a bit off. You suggest that a text part > should "ideally" take priority and then HTML if a text part doesn't > exist. THis is incorrect. Text parts don't take priority over any > parts. There is no RFC that says this, and this is certainly not > what we do. Instead, we ask the admin (through mime_drivers.php) > which MIME types they would like to display inline. Then we use RFC > rules to determine what parts should be displayed. > > > > For example, with multipart/alternative, the RFC clearly states that > the most feature rich element of that multipart that can be displayed > by the software should be presented to the user - and the > "feature-richness" is determined by the order the part appears in the > multipart. We have no say in which part is shown - it is completely > determined by what types the user has defined to display inline in > mime_drivers.php and the structure of the message. If a user wants > to disable text/plain parts, they are more than welcome to do this - > no matter how badly it may stunt their effective use of the software.
Attachment
Watch this ticket

Saved Queries