You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Kenneth Gendron (JIRA)" <ji...@apache.org> on 2008/11/29 19:12:44 UTC
[jira] Issue Comment Edited: (EMAIL-65) MIME layout generated by
HtmlEmail causes trouble
[ https://issues.apache.org/jira/browse/EMAIL-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12651738#action_12651738 ]
nmccloud edited comment on EMAIL-65 at 11/29/08 10:12 AM:
-----------------------------------------------------------------
Since this has not been solved, I was wondering if I could put forth some code for evaluation and feedback. Martin is right, only the build() method in HtmlEmail must be fixed to properly handle text/html, inline images, and attachments. The quick solution would be to rewrite it so that the multiparts look something like this:
Content-Type: multipart/mixed; boundary="attachment"
--attachment
Content-Type: multipart/related; boundary="html-inline"
--html-inline
Content-Type: multipart/alternative; boundary="text-andor-html"
--text-andor-html
Content-Type: text/plain;
[Textual representation of message]
--text-andor-html
Content-Type: text/html;
[HTML representation of message with inline images]
--text-andor-html--
--html-inline
Content-Type: image/jpeg;
Content-ID: image1
--html-inline
Content-Type: image/jpeg;
Content-ID: imageN
--html-inline--
--attachment
Content-Type: [some type]; name=file1.zip
--attachment
Content-Type: [some type]; name=fileN.zip
--attachment--
Ken
See the HtmlEmail.java attachment
was (Author: nmccloud):
Since this has not been solved, I was wondering if I could put forth some code for evaluation and feedback. Martin is right, only the build() method in HtmlEmail must be fixed to properly handle text/html, inline images, and attachments. The quick solution would be to rewrite it so that the multiparts look something like this:
Content-Type: multipart/mixed; boundary="attachment"
--attachment
Content-Type: multipart/related; boundary="html-inline"
--html-inline
Content-Type: multipart/alternative; boundary="text-andor-html"
--text-andor-html
Content-Type: text/plain;
[Textual representation of message]
--text-andor-html
Content-Type: text/html;
[HTML representation of message with inline images]
--text-andor-html--
--html-inline
Content-Type: image/jpeg;
Content-ID: image1
--html-inline
Content-Type: image/jpeg;
Content-ID: imageN
--html-inline--
--attachment
Content-Type: [some type]; name=file1.zip
--attachment
Content-Type: [some type]; name=fileN.zip
--attachment--
Ken
> 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.0
> Reporter: Morten Hattesen
> Fix For: 2.0
>
> 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.