[Tickets #3367] RESOLVED: Mime Message shows no parts

[bugs@bugs.horde.org]

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

Ticket URL: http://bugs.horde.org/ticket/?id=3367
-----------------------------------------------------------------------
 Ticket             | 3367
 Updated By         | Michael Slusarz <slusarz at mail.curecanti.org>
 Summary            | Mime Message shows no parts
 Queue              | IMP
 Version            | 4.0.4
 State              | Resolved
 Priority           | 1. Low
 Type               | Bug
 Owners             | Michael Slusarz
-----------------------------------------------------------------------


Michael Slusarz <slusarz at mail.curecanti.org> (2006-02-03 08:10) wrote:

>> 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.