Commons Email
  1. Commons Email
  2. EMAIL-50

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

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.0
    • Fix Version/s: 1.1
    • Labels:
      None
    • 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).

      1. ASF.LICENSE.NOT.GRANTED--HtmlEmail.java.patch
        8 kB
        Piero Ottuzzi
      2. ASF.LICENSE.NOT.GRANTED--HtmlEmail2.java
        10 kB
        Andrew Liles
      3. html-embed-images.patch
        14 kB
        Ben Speakmon

        Issue Links

          Activity

          Andrew Liles created issue -
          Hide
          Andrew Liles added a comment -

          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.

          Show
          Andrew Liles added a comment - 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.
          Hide
          David Eric Pugh added a comment -

          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.

          Show
          David Eric Pugh added a comment - 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.
          Hide
          dion gillard added a comment -

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

          Show
          dion gillard added a comment - I think we should look at: a) Fix HtmlEmail rather than introducing a HtmlEmail2 b) Make HtmlEmail easier to subclass.
          Hide
          Piero Ottuzzi added a comment -

          Created an attachment (id=17748)
          Patch to HtmlEmail

          This is HtmlEmail2 produced as a patch versus HtmlEmail

          Show
          Piero Ottuzzi added a comment - Created an attachment (id=17748) Patch to HtmlEmail This is HtmlEmail2 produced as a patch versus HtmlEmail
          Henri Yandell made changes -
          Field Original Value New Value
          issue.field.bugzillaimportkey 37344 12342675
          Henri Yandell made changes -
          Component/s Email [ 12311114 ]
          Key COM-2523 EMAIL-50
          Assignee Jakarta Commons Developers Mailing List [ commons-dev@jakarta.apache.org ]
          Affects Version/s 1.0 Final [ 12311651 ]
          Project Commons [ 12310458 ] Commons Email [ 12310474 ]
          Henri Yandell made changes -
          Affects Version/s 1.0 Final [ 12311731 ]
          Ben Speakmon made changes -
          Link This issue incorporates EMAIL-52 [ EMAIL-52 ]
          Ben Speakmon made changes -
          Link This issue relates to EMAIL-28 [ EMAIL-28 ]
          Hide
          Ben Speakmon added a comment -

          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.

          Show
          Ben Speakmon added a comment - 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.
          Ben Speakmon made changes -
          Attachment html-embed-images.patch [ 12350812 ]
          Henri Yandell made changes -
          Fix Version/s 1.1 [ 12312230 ]
          Hide
          dion gillard added a comment -

          Ben's patch works well. Applied.

          Show
          dion gillard added a comment - Ben's patch works well. Applied.
          dion gillard made changes -
          Resolution Fixed [ 1 ]
          Status Open [ 1 ] Resolved [ 5 ]
          Hide
          Morten Hattesen added a comment -

          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?

          Show
          Morten Hattesen added a comment - 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?
          Siegfried Goeschl made changes -
          Status Resolved [ 5 ] Closed [ 6 ]

          Error rendering 'com.atlassian.jirafisheyeplugin:fisheye-issuepanel'. Please contact your JIRA administrators.

            People

            • Assignee:
              Unassigned
              Reporter:
              Andrew Liles
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development