No.  I have no problem seeing plaintext parts in related messages 
displayed inline.  (Nor have i heard anyone else with this issue.)

It does.

I can confirm a multipart/alternative message of the following structure:

   - text/plain
   - multipart/related
     - text/html
     - [...]

Will display the text/plain part if HTML inline display is off.

Hi,

I think one can get your point, the problem is that Horde's admin FAQ 
plainly says :
   « Enabling inline HTML attachments is discouraged »

... which no one would deny and probably not the original reporter !

So it seems we're sort-of caught in a loop : since IMP _can_ display 
HTML, it won't display text/plain but since it is _not configured_ to 
display HTML by default (out of rightful reasons), the final user is 
doomed to have those messages contents displayed in a new window.

Am I getting you right ?

phep

Thanks a lot,
But, in configuration, the html inline display is not allowed. So 
Horde cannot display Multipart/Related, the richest format. 
Consecutively, according to RFC, it should display another part.
Best regards,
P.Borel

This is correct behavior.

RFC 2046 [5.1.4] (http://tools.ietf.org/html/rfc2046#section-5.1.4):

    Receiving user agents should pick and display the last format
    they are capable of displaying...What is most critical, however, is that
    the user not automatically be shown multiple versions of the same data.

We display the richest content of the related part we can.  This is 
correct behavior.  You can use the show all parts button  to display 
any other part that isn't shown.

Hi,
IMP don't display text/plain mime part in this case:
The message is enclosed in Multipart/Alternative messages with 2 subparts:
- A "text/plain" mime part
- A "multipart/relative" mime part which enclose several basic mime 
type (text/html, image/png)...
IMP don't display text/plain message inline in the main browsing 
panel. We need to open the message part separately.

It's possible to display mime text/plain sub-part if another sub-parts 
are not multipart/relative.

The RFC spécification 1342 
(http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html)  says that:
In general, user agents that compose multipart/alternative entities 
should place the body parts in increasing order of preference, that 
is, with the preferred format last. For fancy text, the sending user 
agent should put the plainest format first and the richest format 
last. Receiving user agents should pick and display the last format 
they are capable of displaying. In the case where one of the 
alternatives is itself of type "multipart" and contains unrecognized 
sub-parts, the user agent may choose either to show that alternative, 
an earlier alternative, or both.

So, it seems IMP's behavior is not correct. Is it just ? Is there a 
patch or a configuration's rule to correct that ?
I join an example.
Best regards,
Patrice Borel