You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Siegfried Goeschl (JIRA)" <ji...@apache.org> on 2008/12/29 18:48:46 UTC

[jira] Resolved: (EMAIL-65) MIME layout generated by HtmlEmail causes trouble

     [ 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.