commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ben Speakmon (JIRA)" <>
Subject [jira] Commented: (EMAIL-65) MIME layout generated by HtmlEmail causes trouble
Date Tue, 21 Aug 2007 21:32:30 GMT


Ben Speakmon commented on EMAIL-65:

The current plan is to try to implement and test cases 2 and 3 above. Hopefully I'll get to
it soon -- this is the last thing blocking a 1.1 release.

> MIME layout generated by HtmlEmail causes trouble
> -------------------------------------------------
>                 Key: EMAIL-65
>                 URL:
>             Project: Commons Email
>          Issue Type: Bug
>    Affects Versions: 1.0
>            Reporter: Morten Hattesen
>             Fix For: 1.1
> Previous bugs (e.g. ) raised against commons-email
version 1.0 have complained about Outlook not being able to properly display multipart emails
generated by HtmlEmail. While this issue is resolved as of rev 510708, I believe there a several
issues regarding MIME layout, that still cause trouble to email clients.
> In the current codebase, a multipart email containing: plaintext part, html part, inline
images and attachments, is constructed (to the best of my knowledge) with a MIME layout like
> Generated by HtmlEmail. Contains parts: plaintext, html, embedded inline img, attach
> 1 multipart/related
> 1.1 multipart/alternative
> 1.1.1 text/plain (the plaintext content) 
> 1.1.2 text/html (the html content with cid: references to embedded images) 
> 1.2+ */* (attachment) 
> 1.3+ image/* (embedded image, referenced by 1.1.2) 
> ("+" above indicates that multiple (1..n) parts may be included)
> The above structure may cause email clients to display embedded images as attachments,
even though they are semantically part of the text/html content.
> Furthermore, the current codebase (as documented in the HtmlEmail.setMsg() JavaDoc) synthesizes
a html part by <pre>...</pre> wrapping the plaintext part, thus generating a bloated
(double size) message, for no apparent reason. In my opinion, HtmlEmail should degrade to
the mime layout of Email, if no html part is available.
> Proposed MIME layout
> ------------------------------
> To the best of my knowledge, a multipart email containing: plaintext part, html part,
inline images and attachments, should be constructed like so:
> 1. multipart/mixed
> 1.1 multipart/related
> 1.1.1 multipart/alternative
> text/plain (the plaintext content)
> text/html (the HTML content with cid: references to embedded images)
> 1.1.2+ image/* (embedded image, referenced by
> 1.2+ */* (attachment)
> The following simplifications of the above structure may be applied:
> a. If no embedded images are included, items 1.1.2+ and 1.1 are removed.
> b. if no text/html part is included, items and 1.1.1 are removed
> c. if no attachments are included, items 1.2+ and 1 are removed
> Incidentially, this MIME layout is used by GMail, which is an indication that it is the
"proper" way.
> I seriously believe that this issue should be investigated and resolved, if at all possible,
as part of version 1.1.
> I may be able to supply a patch to in the April/May 2007 timeframe, but
I am not prepared to put any body parts on the block on that one ;-)
> I welcome any comments!
> Morten Hattesen
> References:
> See for additional information and references

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message