[imp] Re: [horde] message/rfc822 inline?

Wed Mar 24 15:19:02 PST 2004

Quoting Jason Parsons <jparsons-lists at saffron.net>:

>> It does. And it did so for a long time, as long as the attachment
>> disposition is set to "inline".
>
> I'm having trouble with the inlining of a message structured as so:
>
> 1. multipart/mixed
>    1.1. text/html
>    1.2. message/rfc822
>      1.2.1. multipart/alternative
>        1.2.1.1. text/plain
>        1.2.1.2. text/html

In the below example (assuming that the below structure is the entire 
message),
the parts would actually be:
  0. multipart/mixed
     1. text/html
     2.0 message/rfc822
       2. multipart/alternative
         2.1 text/plain
         2.2 text/html

So i will use those ID #'s in the discussion below.

> The first text/html is inlined, but the mutilpart/alternative message
> is not inlined.  I've included the MIME framework from an example
> message below.
>
> I would appreciate any guidance on how to make this message inline, or
> what might be wrong with the MIME that's causing it to not inline.

First off, the below headers aren't enough to test with - it is not a 
valid MIME
message.  I needed to add the following two headers below:

>
>> Content-Type: multipart/mixed;
>>         boundary="----0_=_-c905e04ue3-W85LkfK2f1=_EtR6p"
MIME-Version: 1.0
>>
>> ------0_=_-c905e04ue3-W85LkfK2f1=_EtR6p
>> Content-Type: text/html
>> Content-Disposition: inline
>>
>> <HTML>
>>    - This HTML message is shown inline in IMP.
>> </HTML>
>>
>>
>> ------0_=_-c905e04ue3-W85LkfK2f1=_EtR6p
>> Content-Type: message/rfc822
>> Content-Disposition: inline
>>
>> Content-Type: multipart/alternative; 
>> boundary="MIMEBoundary3467548fea01cf007ebc0
>> c46039baf9d"
MIME-Version: 1.0

>> --MIMEBoundary3467548fea01cf007ebc0c46039baf9d
>> Content-Type: text/plain;
>>         charset="ISO-8859-1"
>> Content-Transfer-Encoding: 8bit
>>
>>  ... This text is not inlined in IMP.
>>
>> --MIMEBoundary3467548fea01cf007ebc0c46039baf9d
>> Content-Type: text/html;
>>         charset="ISO-8859-1"
>> Content-Transfer-Encoding: 8bit
>>
>> <html>
>> This HTML is not inlined in IMP.
>> </html>
>>
>>
>> --MIMEBoundary3467548fea01cf007ebc0c46039baf9d--
>>
>> ------0_=_-c905e04ue3-W85LkfK2f1=_EtR6p--

Second, this renders perfectly in IMP HEAD (i.e. part 1 is shown, the headers
from the RFC822 (part 2.0) message is shown (in this case, there are no 
headers
- only the box that says that this is a rfc822 part), and part 2.2 is 
shown (it
is the preferred alternative part)).

If using IMP 3.x, then this message won't render correctly (mostly because
multipart/alternative isn't supported) and is one of the reasons MIME support
has been completely rewritten in HEAD.

michael

______________________________________________
Michael Slusarz [slusarz at bigworm.colorado.edu]
The University of Colorado at Boulder