[email] HTML Emails with images don't display in Outlook 2000

• Key: EMAIL-50
• Type: Improvement
• Status: Resolved
• Resolution: Fixed
• Priority: Minor
• Assignee: Unassigned
• Reporter: Andrew Liles
• Affects Version/s: 1.0
• Fix Version/s: 1.1

Environment

Operating System: other
Platform: Other

Description

I was having a problem sending HTML Emails with inline image attachments against
the client Microsoft Outlook 2000 SP-3. I am using commons-email-1.0.jar.

This bug report proposes a solution include code.

Suppose with an HtmlEmail I am embedding 2 images, adding an HTML part and Text
part.

The resultant Body structure is:

Entity Content-Type Encoding
1 text/plain 7bit
2 multipart/related
2.1 text/html 7bit
2.2 image/jpeg base64
2.3 image/jpeg base64

Outlook, by default, shows the text part with the HTML email as an attachment
(correctly showing the images). My "problem" is that I think the HTML should be
shown by default.

I am guessing that it is an issue with this particular email client and the Body
Structure format ? (see here, for example: COM-1526)

—

I have fixed this for my own purposes and am recording the details here for the
benefit of others. I don't know whether this should be categorised as a bug in
commons-email-1.0.jar or a bug in Outlook. I suspect the latter, but since back
versions of Outlook will never get fixed, the pragmatic solution is to alter
commons-email, particularly in cases if you are targeting a known finite set of
email clients.

I am fully expecting a committer to categorize this as WONTFIX, but at least the
attachment I will add may allow others to use my code.

My code has been tested to work on:
Microsoft Outlook Express 6.00
Microsoft Outlook 2000 SP-3
Microsoft Outlook 2002
Microsoft Outlook 2003
Qualcomm Eudora 6.0.3.0
SquirrelMail 1.5.1 (webmail client)
Hotmail (as of November 2005)
Gmail (as of November 2005)

These clients are all happy to receive and display HTML emails in the expected
way using this Body Structure:
Entity Content-Type Encoding
1 multipart/alternative
1.1 text/plain 7bit
1.2 text/html 7bit
2 image/jpeg base64
3 image/jpeg base64

I have not tested with attachments that do not relate to the HTML and may not
support this scenario; however this is not normal usage scenario (well, for me
anyway).

Comments

[Andrew Liles]

Created an attachment (id=16859)
HtmlEmail2.java

Some notes about my contributed code:

I chose not to patch HtmlEmail so that my implementation can co-exist with the
original HtmlEmail class; my class is named HtmlEmail2. Secondly I subclassed
MultiPartEmail not HtmlEmail since some methods in HtmlEmail were private and
in the end my work touched pretty much everything in HtmlEmail.

I also raised an issue (COM-2497) with HtmlEmail that if a caller embededs the
same image several times into an email then it is encoded several times into
the payload of the email. A typical usage scenario for Html emails is that one
uses common 'spacer' images. Of course the caller could resolve this for
themselves, but as a convenience I chose to implement embed() in a way that
identifies common images (using the 'name' parameter) adding them only once
into the email. This fix is included in my HtmlEmail2 class.

Certain useful methods in the org.apache.commons.mail package have package
access restrictions. My code is pacakged in this package so there is no issue,
but users of my code will not be able to remove my code into their own package
and may get sealing violation issues if they attempt to use it in a separate
jar from the binary distribution of commons-email.jar. A simple solution is to
obtain the source for commons-email and compile your own jar from source,
co-locating my src code with the rest of the formal distribution of the
package.

[David Eric Pugh]

It seems to me that what you have done could be the basis of commons-email 1.1. I have never
thought that the package structure, scope of methods, etc was very well thought out. I'd be happy to
take your patches if you wanted to rework them to be improvements on the existing code versus
standalone code. And if we can beef up the testing.

For my part, I am not an email guru, I was just shepherding commons-email to get it to 1.0, so I can't
validate the structure of the emails generated. On the other hand, looking at Andrew's comments, it
seems like he IS an expert on html emails. So I'd be happy to take some of it on a bit of faith, and his
word that his changes are tested on various platforms, which he seems to have done with the current
patch. So Andrew, if you are interested in moving the ball forward on commons-email, fixing some of
the odd things like bad method scope, hidden conveince methods, odd inhertance instead of
composition structure, then I'm all for it.

[dion gillard]

I think we should look at:
a) Fix HtmlEmail rather than introducing a HtmlEmail2
b) Make HtmlEmail easier to subclass.

[Piero Ottuzzi]

Created an attachment (id=17748)
Patch to HtmlEmail

This is HtmlEmail2 produced as a patch versus HtmlEmail

[Ben Speakmon]

Attaching a cleaned-up and debugged version of the original HtmlEmail patch with new embed() tests. Confirmed to work properly on Thunderbird, Gmail, and Mac Mail.

EMAIL-28 was being caused by the same things that were causing Outlook to fail, so the important point is that this was never an Outlook-specific problem but was a bug in how commons-email was constructing complex HTML messages. This patch fixes EMAIL-28 as well as this patch.

The original patch also fixed EMAIL-52, and this one does the same.

[dion gillard]

Ben's patch works well. Applied.

[Morten Hattesen]

I don't think the current multi-part structure is strictly according to the MIME recommendations.

The currently proposed layout of a multi-part message containing a text/plain part, as well as a text/html part with embedded images is...

Entity Content-Type Encoding
1 multipart/alternative
1.1 text/plain 7bit
1.2 text/html 7bit
2 image/jpeg base64
3 image/jpeg base64

... but since the embedded images are part of the text/html part, and thus should not be available to a text/plain reader, I believe the proper layout of such a message should be:

Entity Content-Type Encoding
1 multipart/alternative
1.1 text/plain 7bit
1.2 multipart/related
1.2.1 text/html 7bit
1.2.2 image/jpeg base64
1.2.3 image/jpeg base64

... with possible attachments appearing as (2, 3, ...).

Furthermore, I believe that if a HtmlEmail is composed with only a text/plain component, it should result in a message identical to a MultiPartEmail message, rather than synthetically generating a text/html message with the plaintext contained in a <pre>...</pre> block, which bloats the smtp message to twice the size, for no reason.

Should this be raised as two separate (new) JIRA reports against EMAIL version 1.1?