Sending HTML and Plain Text E-Mail Simultaneously

Back in the bad old days, all e-mail came in plain text. It was predictable, if ugly. Now you can send HTML e-mail to the majority of your recipients, and they can all see it -- you just can't predict exactly how it will look. Those with old e-mail client programs will probably see it as text (though some will see ugly HTML coding, too). Those with newer e-mail programs such as Outlook Express, Outlook 98/2000, Netscape Communicator, and Eudora 3.x/4.x will see the HTML coding and images, more or less.

But those of use who use HTML e-mail in our businesses, that isn't enough. To help you understand this better I'll attempt a pseudo-technical explanation of how it works. If your eyes glaze over, don't say you weren't warned.

Multipart Alternative

This two-faced plain text/HTML trick doesn't always work, but when it does it's success is due to what is called MIME content type multipart alternative. The e-mail message includes both plain text for old programs and HTML for the newer programs. Of course, the message is more than twice as long as a result, but both recipients can read the message -- if you're careful. This multipart alternative approach is the standard now used in most newer e-mail programs. They don't send just HTML, but both text and HTML messages together.

It may be difficult to view all the parts of your e-mail message to see how this works. View|Source may only show the HTML portion of the message. Without Outlook 2000, the only way I can view both parts of the message is to forward an HTML message to a non-existent e-mail address. When the bounced message comes back I'm able to see each part of the multipart message.

Document Types

The e-mail is laid out in this way:

Content-Type: multipart/alternative tells the e-mail program to expect different parts to follow, separated by a boundary which specified in quotation marks. Actually the boundary could be anything, though hyphens, equal signs, and underscores insure that the e-mail program won't try to display this boundary to the recipient.

Now we have a boundary, followed by the first content-type: text/plain. This is intended for recipients who can see only plain text, and not HTML. The full content of the message is given in plain text, perhaps not too neatly, but usually readably.

After the text comes another boundary, and then another content-type: text/html. If you look at the raw message the HTML looks a bit strange, the "quoted-printable" encoding turns all the spaces into "=20" and an "=" sign into "=3D" and so forth. If your recipient has a HTML-capable e-mail program it will skip the text/plain content and go on to decode and display only the text/html content.

After the HTML comes the final boundary, and the message is done.

The Best of Both Worlds

If you want the best of both worlds, you'll format the text/plain section separately from the text/html section. That way you could make the plain text version very clear and the HTML version very clear. The only problem is no e-mail programs I know of allow you to format separately each part of this multipart e-mail message, except Broadc@ast HTML from MailWorkZ.com (http://www.mailworkz.com) and Gammadyne Mailer (http://www.gammadyne.com/mmail.htm). (If you know of others, please let me know.) What you're left with is your e-mail interpreting the HTML into plain text. Sometimes it does a decent job, but sometimes it looks terrible.

It's important if you want to send multipart HTML/Text e-mail to AOL recipients to use a program that sends the text part before it sends the HTML part of the message (such as Gammadyne Mailer). Since AOL 5.0 doesn't follow normal Internet e-mail MIME standards, its e-mail reader can't distinguish multipart messages correctly. Nor does it interpret HTML e-mail messages accurately. It's necessary therefore to send the text part, then the HTML part, so at least AOL users can see something decent (the text part) before they see the HTML part and get disgusted with non-AOL-specific newsletter publishers. :-)

The Lowest Common Denominator

I generally write my newsletters in Microsoft Word, but when it comes time to lay it out for HTML I use Microsoft FrontPage 2000 (NOT FrontPage 98). When I'm satisfied and ready to do my first test, I Edit|Select All and then Edit|Copy to place the text on my clipboard. Then I open a new e-mail message, using Format|HTML in Outlook 2000, and paste in the contents of my clipboard.

You must test again and again until you find a formatting system that shows up well in both text and HTML. Here are some guidelines I found useful:

• Include an HTML link (visible in the HTML version only) and then repeat the URL again (visible in the text and HTML version).
• Provide separators between sections so that it is clear to text recipients that this topic is different from what was above. You could use a string of 20 or 30 underscores to accomplish this.
• Use capitals (or at least capitalized first letters) in headlines so the headline is distinguishable from the following description in the text format where no bold, italics, fonts, and sizes are available to provide visual clues.

One Newsletter to Serve Both Plain Text and HTML Recipients

High-end listservers can "sniff" out whether the e-mail program used by recipients detects HTML or not, and then deliver the message only in the appropriate format. But low-end listservers within the budget of many small businesses don't have such highly developed noses. These are your choices:

• Send your message in plain text only, the lowest common denominator that all can see. This works, but Hotmail.com viewers, among others, won't see the URLs as hot links and will complain.
• Send your message in Multipart Alternative described above, which more than doubles the size of the message but offers both text and HTML alternatives in the same message. This works fairly well for short newsletters with a title, a sentence or two, and a URL pointing to the full articles on the website.
• Offer two separate lists -- one for plain text and the other for HTML. This is a pain to maintain, but the only real answer for lengthy e-mail newsletters.

Test and Test Again

If you decide to use the multipart alternative approach, my advice is to test and test again your HTML formatting. Then send the message to an echo mailer such as mailto:echo@tu-berlin.de or mailto:echo@tu-chemnitz.de so you can see in the message how it looks in plain text. Then make modifications and test again so that both the HTML and the text versions look acceptable. Good luck, and please let me know what you learn.