Decompiled

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?

I know that I’ve been a bit off when it comes to writing for this blog and I could come up with a nember of legitimate excuses..but I won’t. I’ll give just one. Truth is, I’ve been having so much fun trying out new software, applications, web sites, and other geeky stuff that I just didn’t want to stop. It’s not for lack of subject matter..no..just the opposite. There has been to much subject matter.

• Installing and testing different Wikis (by the way, I really like Deki Wiki so far)
• Signing up for and poking about on different Social Media sites and web apps.
• Trying out different OSS alternatives to Microsoft and Windows based software
• Experimenting with Social Media in business
• Even writing my own .Net twitter client for windows called TwitterPatter

Honestly, there is no good reason why I couldn’t just take some time to share what I discovered or learned over the past few weeks. I sort of feel like a kid being called home at the end of a long summer day and thinking “Aw, just a little longer…??”.