[
https://issues.apache.org/jira/browse/EMAIL-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12480565
]
Morten Hattesen commented on EMAIL-65:
--------------------------------------
After a careful review of the current codebase (HtmlEmail.java rev 511673,
MultiPartEmail.java rev 517714), I have discovered, that the MIME layout
generated is not quite as described in my previous posting.
In many circumstances both HtmlEmail and MultiPartEmail generates MIME
structures that do not conform to MIME recommendations.
Below, I have listed the MIME structures generated, as well as how I believe
they should have been.
Example 1:
Generated by HtmlEmail. Contains parts: plaintext
PART#, MIME_TYPE, (COMMENTS)
1 multipart/related (WRONG!)
1.1 text/plain (the plaintext content)
Should have been:
PART#, MIME_TYPE, (COMMENTS)
1 text/plain (the plaintext content)
Example 2:
Generated by HtmlEmail. Contains parts: plaintext, html
PART#, MIME_TYPE, (COMMENTS)
1 multipart/related (WRONG!)
1.1 text/plain (the plaintext content)
1.2 text/html (the html content)
Should have been:
PART#, MIME_TYPE, (COMMENTS)
1 multipart/alternative
1.1 text/plain (the plaintext content)
1.2 text/html (the html content)
Example 3:
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)
should have been:
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)
Example 4:
Generated by MultiPartEmail. Contains parts: plaintext
MultiPartEmail: plaintext
PART#, MIME_TYPE, (COMMENTS)
1 multipart/mixed (WRONG!)
1.1 text/plain (the plaintext content)
should have been:
PART#, MIME_TYPE, (COMMENTS)
1 text/plain (the plaintext content)
Example 5:
Generated by MultiPartEmail. Contains parts: plaintext, attach
PART#, MIME_TYPE, (COMMENTS)
1 multipart/mixed
1.1 text/plain (the plaintext content)
1.2+ */* (attachment)
This one is well-structured!
Conclusion:
With regards to the automatically generated text/html part, based on the
text/plain part, I concede that this is part of the API contract (specified in
JavaDoc of HtmlEmail.setMsg(String) ), although I still believe that generating
redundant data is silly.
It is fairly easy to show email clients choking on the above MIME structures,
one example being embedded images being displayed as attachments by virtually
any clients.
I agree that the current codebase is an improvement on version 1.0, but I think
making the 1.1 release at this stage with MIME structures that violates even
the most basic MIME recommendations (see examples above) would be wrong.
One alternative possibility would be planning a version 1.2 with a (thoroughly
tested) restructuring of the MIME generation.
> 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: 1.1
>
>
> 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:
> PART#, MIME_TYPE, (COMMENTS)
> 1 multipart/alternative
> 1.1 text/plain (the plaintext content)
> 1.2 text/html (the html content with cid: references to embedded images)
> 2+ image/* (embedded image, referenced by 1.2)
> 3+ */* (attachment)
> ("+" 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
