[
https://issues.apache.org/jira/browse/EMAIL-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12480692
]
Ben Speakmon commented on EMAIL-65:
-----------------------------------
What clients, specifically, do you see choking? I'll take a closer look. Your
MIME structures also look correct in the examples you give.
Regarding a 1.1 release: when I started working on this, I noticed quickly that
there were some design choices that I didn't agree with. For example, I'm not
particularly happy with the inheritance hierarchy; I see no reason for
HtmlEmail to extend MultiPartEmail, since the former does not have an is-a
relationship with the latter. However, I figured that it could be made to work
in the current incarnation, and since there are already people using this
library, maintaining the API contract and avoiding breaking changes wherever
possible was the most important consideration. Unfortunately, this makes it
tricky to address situations like this where the objectively best solution is
to refactor.
I hope it's easier to see where I'm coming from now...
In Examples 1 and 4, if you just want to send a plaintext email, then use
SimpleEmail; that's what it's for. While you could certainly argue that
HtmlEmail should know how to reshape its MIME structure to handle a plaintext
email, you could also make the same argument that MultiPartEmail should know
how to handle HTML text without attachments in the same way. And also for
SimpleEmail to handle HTML text, and so on. Suddenly there are three classes
that have the exact same functionality, so naturally you refactor them into one
class or start abstracting out interfaces and concrete classes... but doing
that breaks the API contract, and you're back to square one.
The least evil solution I can see is getting the existing classes to work as
well as possible while maintaining the contracts and then helping users to
understand that they need to use the right class for the right task. To that
end, it's probably a good idea to try to fix examples 2 and 3. I'll take a look
this week and see what I can do.
> 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:
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
