Sending HTML and plain text emails simultaneously – multipart solution
Background
I cannot quite recall the first time I sent an email except that for all I know it was a long time ago and that it’s only intent was to notify its recipient that I had actually embraced the cyberspace. It was a time when having an email address was a privilege, not a right and 1200bps modems where top of the line. In today’s world I would be quite astonished if somebody told me they don’t have an email. In fact I will be even more surprised if they told me that they have an email which they don’t use on a daily basis to conduct personal and business activities but merely for the purpose of having one.
Today as email becomes more popular than traditional mail we send plain text emails, HTML emails and even rich media emails containing Flash. While the good old plaint text emails were easily readable they were ugly to say the least and not quite well organized as far as data presentation is concenred. With all the advantages that HTML layout and presantation brings to the table come some caveats: even if we assume that all your recepients will be able to see the content (if they have HTML enabled) we can’t be quite sure how it will look on different mail clients due to a number of reasons. The solution: Multipart emails.
What is the Multipart MIME?
The Multipart mime content is just another fancy term for providing more than one version of your email. In reality MIME stands for Multipurpose Internet Mail Extensions and was created as a standard to extend the existing one and provide support for [you guessed it] among other things support for multipart message body, non-text attachment and non-ASCII (e.g. UTF8) character encondings. The way multipart content works is by specifying a boundary in the “Content-type:” header of your email. The boundary is used to separate the different content types and looks something like this:
Content-type: multipart/mixed; boundary="fU3W4Vzr4G3D54f3"
There are no rules as of the content of the boundary but as it must not occur in any of the parts of your message content is usually a randomly generated sequence of numbers, letters or combination of both in order to guarantee uniqueness and differentiate from any possible dictionary words. So as you start your message each data type section is separated by “–” followed by the boundary sequence and the content type + encoding. After the last section “–” followed by the boundary followed by “–” is used to delimit the end of the message. Here is an example of a complete message:
MIME-version: 1.0 Content-type: multipart/mixed; boundary="fU3W4Vzr4G3D54f3" This is a multi-part message in MIME format. --fU3W4Vzr4G3D54f3
Content-type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable This is the body of the message. --fU3W4Vzr4G3D54f3
Content-type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit
<html> <head><title>A HTML email</title></head> <body>This is the body of the message.</body> </html>
--fU3W4Vzr4G3D54f3--
Note that for demonstration purposes we’ve oversimplified the HTML. In a real environment you would want to be as explicit as possible and provide a doctype for your HTML document as well as follow the guidelines as much as possible to ensure uniform rendering across engines.
Some useful tips
So far so good! Now that we are familiar with how the multiheader MIME emails can help you ensure that your message will reach its intended audience we need to spend some time and pay attention to some specifics of formatting.
- Keep it simple – concentrate on your content rather than sophisticated presentation. Focus on your message! As far has the HTML is concerned – don’t get too fancy and code a very simple, old school webpage.
- I can’t stress enough how important HTML formatting is but I want to reiterate that you need to be very careful and make sure to create valid, well formatted HTML. To ensure the quality of your code and the proper rendering I will suggest that you use a professional tool like Dreamweaver of Frontpage or an online validator as the one from the W3C. Of course in addition to that I will suggest testing the rendering in different browsers and email clients to avoid surprises.
- Along the same lines you will need to set an online version of the HTML document and include a link with the URL in the beginning of both the plaintext and HTML versions. This will ensure that your recipient can open the message in a browser if there are any rendering problems, the content is blocked by a spam engine or if the plaintext version is just not good enough. This comes quite useful as usually the purpose of your message is to get the recipient to visit the website and start some sort of interaction.
- Use tricks like capitalizing the headlines and spacing or underlining for distinguishable headlines and section separation. This can be very helpful for plaintext emails as they can often be hard to read.
- As usually spam blockers often prevent some of the images from displaying be careful and don’t overuse images for messages. For all images provide good ‘alt’ attribute description for the content of the image in the cases when they are not shown.
- Webmail based services are more than likely going to slightly modify your code so be prepared to have tags like DOCTYPE, BODY, and HEAD to be stripped. That’s expected as understandably those elements have the chance to interfere with their site.
- Avoid sophisticated designs requiring high width as a lot of the client email preview windows will be just a few hundred pixels wide.
- Don’t rely on heavy use of CSS styles as almost 90% of the time they will get stripped. That’s especially true for services like Hotmail, Yahoo Mail, and Gmail as your CSS has a chance to override their own styles.
- Tables are your friend. Really! Use TABLE tags to position the content within your web page. Go back to basics and rely on what’s proven and working across different rendering engines.
- Work with a carefully selected vocabulary. That’s especially true for words you include in the title as they are very likely to stand out when examined by the spam filters.
- Keep your message short. Remember that multiplart MIME emails technically double the length of your email so while they work great for relatively short emails
- Test, Test, Test – That’s really the safest way to make sure that there won’t be surprises. Apart from not accomplishing your goal you are running the risk to loose credibility with your audience.
NEXT: see an example on how to create a multipart MIME email web form in PHP (…coming soon)
Resources:
Mime
Sending both HTML and plain text emails
RFC2045, RFC2046, RFC2047, RFC4288, RFC4289, RFC2077
Leave a Reply
You must be logged in to post a comment.