[ https://issues.apache.org/jira/browse/EMAIL-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Siegfried Goeschl resolved EMAIL-65. ------------------------------------ Resolution: Fixed Used Kenneth's implementation of HtmlEmail.buildMimeMessage() and did some field testing (Outlook, Outlook WebAccess, GMX WebMail, Apple Mail, Thunderbird) - it looks good. The other guys are much more knowledgeable regarding mail spec ... :-) ... so I hope this solves the issue. > MIME layout generated by HtmlEmail causes trouble > ------------------------------------------------- > > Key: EMAIL-65 > URL: https://issues.apache.org/jira/browse/EMAIL-65 > Project: Commons Email > Issue Type: Bug > Affects Versions: 1.1 > Reporter: Morten Hattesen > Assignee: Siegfried Goeschl > Fix For: 1.2 > > Attachments: CustomHtmlEmail.java, HtmlEmail.java > > > Previous bugs (e.g. http://issues.apache.org/jira/browse/EMAIL-50 ) 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 this: > Generated by HtmlEmail. Contains parts: plaintext, html, embedded inline img, > attach > PART#, MIME_TYPE, (COMMENTS) > 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: > PART#, MIME_TYPE, (COMMENTS) > 1. multipart/mixed > 1.1 multipart/related > 1.1.1 multipart/alternative > 1.1.1.1 text/plain (the plaintext content) > 1.1.1.2 text/html (the HTML content with cid: references to embedded images) > 1.1.2+ image/* (embedded image, referenced by 1.1.1.2) > 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 1.1.1.2 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 HtmlEmail.java 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 http://en.wikipedia.org/wiki/MIME 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.