r2 - 14 Jul 2006 - 13:48:00 - TravisVachonYou are here: OSAF > Journal Web > ContributorNotes > TravisVachonNotes > MIMEHandlingJuly14
Multipart message handling in Chandler
A multipart message received by Chandler will sometimes have its mimeParts variable loaded with the Chandler representations of some of its subparts. This seems to be the case especially when the message contains binary data like an image. Sometimes, however, it does not. The following examples are messages loaded with Chandler's IMAP client from my OSAF mail account. In each case, I present the representation of the message as seen from Chandler's webserver-based repository inspector, and discuss the problems I believe exist. It is entirely likely that I have simply misunderstood the approach taken with these messages, and I would like to apologize ahead of time for these misunderstandings.Multipart messages with multiple text parts:
The following message was sent with an HTML and a text representation. In a text-only mail client like pine (or Chandler) it should display the first part, while in Thunderbird it should display the second part. This multipart structure is not reflected in the chandler object (except in the rfc2822Message attribute): MIMEHandlingJuly14Image#PlainHTML In this case, it would be ideal to have mimeParts contain two MIMEText Items created from this message:Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Test 123
and this message:
Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Test<br> <font face="Helvetica, Arial, sans-serif">1<font face="Courier New, Courier, monospace">2<font face="Times New Roman, Times, serif">3</font></font></font><br> </body> </html>
That is, a structure like this:
* MailMessage (mimeType: multipart/alternative)
- mimeParts
- MIMEText (The plain text part)
- MIMEText (The HTML part)
Multipart messages with a mix of text and image parts:
Handling appears to be a better here, but still flawed. This is a multipart message with a text and HTML representation as above, but this message also has both an inline image and an attached image: MIMEHandlingJuly14Image#PlainHTMLImages The rfc8288Message attribute contents can be found here: MIMEHandlingJuly14TextImageSource Right now, the Chandler representation of this looks like this:* MailMessage (mimeType: multipart/alternative)
- mimeParts
- MIMEText (The HTML version)
- MIMEBinary (The inline image)
- MIMEBinary (The attached image)
While for me the ideal structure would be:
* MailMessage (mimeType: multipart/mixed)
- mimeParts
- MIMEContainer (mimeType: multipart/alternative)
- mimeParts
- MIMEText (The Text version)
- MIMEContainer (mimeType: multipart/related)
- mimeParts
- MIMEText (The HTML version)
- MIMEBinary (The inline image)
- mimeParts
- mimeParts
- MIMEBinary (The attachment)
- MIMEContainer (mimeType: multipart/alternative)
to mirror the MIME representation. These changes would allow me to map the Chandler representation to the representation expected by twisted's IMAP server in a much more elegant and performant way. In addition, it seems like it wouldn't be a bad thing to have Chandler's internal representation of mail messages match with the MIME tree-structure. -- TravisVachon - 14 Jul 2006
Log In
Except where otherwise noted, this site and its content are licensed by OSAF under an Creative Commons License, Attribution Only 3.0.
See list of page contributors for attributions.
See list of page contributors for attributions.