[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jakarta-commons-dev
Subject:    [jira] Issue Comment Edited: (EMAIL-65) MIME layout generated by
From:       "Kenneth Gendron (JIRA)" <jira () apache ! org>
Date:       2008-11-29 18:12:44
Message-ID: 1570188310.1227982364339.JavaMail.jira () brutus
[Download RAW message or body]

[ 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 #2 (multipart/related)]

[Attachment #4 (multipart/alternative)]



[Attachment #7 (text/html)]


[Attachment #8 (image/jpeg)]
[Attachment #9 (image/jpeg)]
["file1.zip" ([some)]
["fileN.zip" ([some)]
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 #13 (multipart/related)]

[Attachment #15 (multipart/alternative)]



[Attachment #18 (text/html)]


[Attachment #19 (image/jpeg)]
[Attachment #20 (image/jpeg)]
["file1.zip" ([some)]
["fileN.zip" ([some)]
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.



[prev in list] [next in list] [prev in thread] [next in thread]