No.  The entire MIME system has been rewritten for Horde 4.

Hi,

I'm rellay interested in that correction. I see it's not a patch but 
is it possible to apply it to an existing system ?



I'm working under Debian an the IMP 5.0 version is not going to be 
accepted soon...



Could you give me some hints to correct this problem ?



Thanks in advance.

This is fixed in IMP 5.0.

un-stalling

No need to raise priority since this is not something that can/will be 
fixed before 5.0.

I suggest raising the priority to at least Medium, because HTML inline 
rendering is turned off by default in IMP. And this bug is serious 
enough with that setting.

See Bug 4073.

As mentioned previously, there is not much we can do about displaying 
this message with the current status of the code without breaking 
display of another message.

I turned off display of the part inline, but I still must have a link 
(or any other method) to access it. In this case I get a link with a 
part, but as I said I get only empty file. This is definetely not right.

Well, for this one we should just say there are no parts that can be 
displayed inline. Probably we're tripped up by the 
multipart/alternative, but since it only has one part, not much else 
we can do if you've turned off display of that part.

Unfortunately, I don't know if we can fix this issue (given the 
current MIME rendering code) without either breaking BC and/or without 
breaking rendering of other messages.

Another sample of message where no parts is displayed if HTML inline 
is turned off.



IMP displays only a link to multipart/alternative and if you click on 
it, IMP downloads an empy file.

No. There is no plaintext part in the multipart/related part anyway.

Chuck, has this been fixed with your changes regarding inline 
configuration of the plain viewer in mime_drivers.php?

No one said it's invalid. It's perfectly valid, we just don't have 
good logic for figuring out if a multipart/* part is "displayable" - 
we assume we'll find something in it to display, even if that ends up 
not being the case.

I must note, that MIME structure of the example message was created by 
Thunderbird. And also, I personally asked Michael a couple of months 
ago is it correct, and he said it is.

I can reproduce this now if I turn off inline html. I'm guessing you 
don't see the alternative display because the text part isn't 
displayed, and that's where the alternative text would be.



I think the problem may be that the 2nd part isn't text/html, it's 
multipart/related, so when we're looking at what we can display, we 
see text/plain vs. multipart/related and we blindly go with the 
multipart/related. Then we get there and inline html is off, so we 
don't have anything to display.



Michael, that sound right? Any idea what we can do about it?

Actually I have it activated and set to 'below'.

If you want the "old" behavior, you need to activate the preference 
'alternative_display'.

Yes, I have HTML inline parts set to off.



Can IMP then show plain part inline if HTML is disabled? And I still 
think IMP must keep access to HTML part somewhere (e.g. in alternative 
part/attachment list).

I'm guessing you have html inline turned off? We're now matching the 
behavior of other email clients much more closely for alternative 
parts; we show the richest one we can, and ignore the others. I see 
the HTML part just fine if I have html inline turned on.

Still don't work for me. I only see one plain/text part and only as 
attachment.



2 weeks (or so) before it was shown like plain/text message with 
alternative html/text part.

Works perfectly for me.

Multipart messages with alternative parts are not longer displayed in 
recent CVS. Example message attached.