technology from back to front

HTML Email is hard to get right

For a recent project, we developed support for sending
automatically-generated HTML emails. Now, most people do this by
including a message body with href=”http://www.iana.org/assignments/media-types/”>MIME-type
text/html. For extra points, sometimes there’s also a
text/plain part alongside the HTML in a
multipart/alternative container.

The problem with doing things this way is that you can’t include any
images or other resources (such as CSS) as separate parts of the email
linked to from the main HTML body-part. For that, you need to use the
href=”http://www.rfc-editor.org/rfc/rfc2387.txt”>multipart/related
MIME-type. Unfortunately, few commonly-used email clients render
multipart/related HTML-plus-resource aggregations well.

We only tried the arrangement where the multipart/related,
containing the main HTML page and its associated resources, was a
sibling of the text/plain part within the
multipart/alternative container. The inverse arrangement,
with the multipart/alternative as the main document within
the multipart/related part, was something we have yet to
experiment with.

Here’s a picture of the structure of our initial attempts:

multipart/alternative
 |
 +-- text/plain
 +-- multipart/related
      |
      +-- text/html
      +-- image/gif
      +-- text/css

This worked reasonably well in Thunderbird and Outlook 2002,
but we had consistent reports from our customer that the images and
stylesheet would randomly fail to display in Outlook 2003 (SP2). After
lots of mucking around trying to get Outlook to either work reliably
or fail reliably, we gave up on that line and instead simplified the
structure of our emails, putting the CSS styling inline in the HTML
HEAD element:

multipart/alternative
 |
 +-- text/plain
 +-- multipart/related
      |
      +-- text/html (with text/css inline in HEAD)
      +-- image/gif

This didn’t work particularly well, either: it seems many email
clients ignore styles set in the HEAD element. Finally, we
moved to applying CSS styling inline, using a style attribute
on each styled element. We were able to use an XSLT transformation to
allow us to write clean HTML and apply the CSS style
attribute automatically. The final structure of the emails we sent:

multipart/alternative
 |
 +-- text/plain
 +-- multipart/related
      |
      +-- text/html (with text/css copied on to each element!)
      +-- image/gif

This seems to work more-or-less reliably across

* Thunderbird
* Outlook 2002
* Outlook 2003 SP2
* Google Gmail
* MS Hotmail

If I was to do it all again, I’d give serious consideration to the
traditional non-multipart text/html solution with images
hosted by some public-facing web server. We managed to get our
multipart-HTML-emails working acceptably, but only by the skin of our
teeth.

References:

* The MIME
media type registry

* multipart/alternative: href=”http://www.rfc-editor.org/rfc/rfc2045.txt”>RFC 2045, href=”http://www.rfc-editor.org/rfc/rfc2046.txt”>RFC 2046
* multipart/related: href=”http://www.rfc-editor.org/rfc/rfc2387.txt”>RFC 2387

by
tonyg
on
18/07/06
  1. I have my email client configured to block remote image loading for security reasons – it gives others a way to see when you’re reading their email. In particular, I don’t want spammers to be able to tune their subject lines to maximize the probability that I’ll read their email, which they can otherwise do using “web bugs”. So your last solution won’t reliably work either – sorry!

  2. http://css-discuss.incutio.com/?page=StyleInEmail is the best summary I’ve seen of what email clients can and will do with HTML emails (and it’s recent).

    It’s worth stating that our problem was mainly with making the emails work perfectly in one email client, rather than good-enough in all clients—in the latter case, this followup to an AListApart article http://www.campaignmonitor.com/blog/archives/2005/08/optimizingcss1.html is a handy reference also.

  3. ((I accidentally deleted a bunch of comments I didn’t mean to delete today, so I’m having to repost them manually:))

    Matthew Sherborne wrote:

    I’ve just been through the same exercise. Could I get a copy of your XSLT sheet please :)

  4. ((I accidentally deleted a bunch of comments I didn’t mean to delete today, so I’m having to repost them manually:))

    mikeb wrote:

    @Matthew: the XSLT is from our domain model to a very simple MIME-container + HTML model; the actual assembly of the MIME message is done in Scheme. The XSLT really just lets us apply the style attribute consistently.

  5. can you give me som more info on how you did the XSLT to move the CSS inline? We are looking for the same thing and would love a jump start

 
 


4 × = twenty eight

2000-14 LShift Ltd, 1st Floor, Hoxton Point, 6 Rufus Street, London, N1 6PE, UK+44 (0)20 7729 7060   Contact us