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
- 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?