I was recently asked “why only allow plain text email formats for not only reading messages received, but also for our bulk outbound messages”. Apparently, some of the natives have grown restless and want to include large bold colorful type and pictures and bells and whistles with their messages. Whats the problem with that? Well, there are several.
I’m pretty sure that most people (I’m talking average people here) don’t know what HTML even means, never mind how to properly write and test it. HTML is the mark up language used for writing web pages, not email messages. It has a specific form, syntax, structure, and should conform to current standards. If not written correctly, you will experience problems of one sort or another. Then there is the problem of writing for different displays, engines, platforms etc. Each of these also introduces their own set of quirks, hacks and workarounds.
HTML email also has a history of security related vulnerabilities and issues, for example:
- embeded content
- scripts
- the ability to include links whose text is different from it’s target
- tracking and beacons
It’s no secret that Microsoft has released warnings on a number of seperate occasions stating that opening a specially crafted HTML email messages in their popular email software would lead to your system being compromised “just by opening the message”. That’s it, end of story. (this is not an invitation to bash microsoft)
HTML is also popular with SPAM and PHISING and because of that, spam filters are likely to give HTML messages a much higher SPAM score, increasing the chances of that message getting buried by a filter.
These are very generic samples and I could write pages on the subject but they also give an example of how inbound HTML can represent a security risk and how outbound messages are put at an increased risk of not reaching the target, or being unreadable.
According to RFC 2822, plain text is the default format for email and therefore is supported in all compliant readers. HTML formats however are not required to be supported. There is also an issue of non-standard support and proprietary rules among HTML rendering engines and software, which introduces compatibility issues and broken pages or layouts or even in some cases, completely blank pages.
Here’s my perspective. If the intention, and ultimately your business, is to get your message to your target or audience, don’t you want to know that they will be able to read it. Plain text gives you that guarantee. HTML is not as reliable.
So what do you think?
- Do you prefer HTML email over Plain Text?
- Does your company disable or limit inbound HTML email?
While I personally prefer text email, I think that HTML email definitely has a place when you’re doing broadcast mailings – but only if you’re doing it through a service like MyEmma. The cost is more than worth it, you get to put out beautiful emails that won’t be triggered by spam filters.
It happened to be the same issue bothering me a lot recently. My php mailer does mess up my text email [at least my test shows] extra lines, wrong line breaks. They do not look pretty at all. Today I got an email from Google, look very much like a text message, however, looking in to the source shows it is a html email with bare minimum tags for better formatting. In the worst case, html email must show the text part [if I understand it right]. Hence, I am going to use html email very soon. For the problem of deliverability, I added domain key and SPF.
I think both types of mailings have value, since it gives users the options to choose their preference depending on whether or not their more visually oriented vs. text oriented in their reading. Not to mention that, depending on what email options you have — web-based company email vs. the option to use a mail client vs. reading email on a mobile device — it’s nice to be able to pick and choose what works for you.
I’m more likely to subscribe to an email list or email updates if I have the option to switch to plain text, mostly because so many HTML mailings are coded really poorly even for a mail client, and I can’t usually see that until I receive the first one. I also tend to read email on my Blackberry a good deal, and fishing through the unrendered code for the text of the message it thoroughly unfun. If only mailers used elegantly-degrading methods…
Subhankar,
Thanks for your feedback. Part of my frustration with sending email is that you can’t control the how the message is rendered on the other end. I think plain text formats provide better support with fewer issues, but that could just as well be an easy way out. I think what you are describing is called Multi-part alternative. I think that adding the multi-part alternative headers and support to our lists is probably the best option. Good luck with your PHP mailer.
Andrea,
Thanks for your input. You make some good arguments especially with the mobile devices. “Elegantly-degrading methods”! – I am adding that to my wish list. Your right that, in the end, it should be up to the recipient of our messages to decide how they want to receive and read the email. In order to reach more devices and give readers more options, then I guess it’s a no brainer.