Software

E-mail needs safe rendering

At the moment, the only really safe way to view e-mail is plain text. What if someone actually went to the trouble of creating a safe rich content rendering mode for an e-mail client?

In A practical example of why HTML email is a bad idea, I provided a very simple example of the kind of security dangers that can be avoided by nothing more complex than viewing email only as plain text. Of course, it's reasonable to expect that there will be occasions people will send you HTML e-mails, and you'll need to view the contents -- and it is reasonable to expect that you will want to be able to view these emails without having to visually sort through everything to find the parts that aren't extraneous, unnecessary markup. It is the convenience of not having to try to sort through the tangle of bad HTML in many emails that drives many to ignore security advice about viewing emails as plain text.

Much as I wish it were otherwise, it doesn't seem likely that everybody in the world will forsake their unnecessarily HTML-laden ways when it comes to composing emails, not only because many modern email clients default to HTML-formatted e-mails, but also because many people get deeply involved in choosing the right "stationery" background image, fancy fonts, and other pointless frippery when sending intensely interesting and highly informative e-mails like "yo, whats up? how r u?". Luckily, a lot of those clients do "the right thing" when composing HTML emails, which is to offer a plain text version as well without the person composing the email even having to know about it.

Sometimes, however, we don't get plain text versions along with the tangle of spaghetti HTML. This may be because, when certain things are done in HTML that cannot be reasonably well degraded to plain text, the email client just skips the plain text version; it may be because some Website developer doesn't know any better when he designs the automated feedback form reply script; it may even be because someone stupidly turned off the plain text copy capability. It may also simply be the fact that someone is using a particularly low-quality email client that only offers HTML formatted functionality.

Regardless of how it happens, the fact remains that sometimes we just need to be able to sift through the contents of an HTML-formatted e-mail, and probably don't want to have to do it without getting a headache. The choices are usually limited to:

  1. give up on secure practices and just view the rendered HTML e-mail somehow -- either within an HTML-capable email client or by viewing the email in an outside application that renders HTML
  2. live with the inconvenience of parsing all that markup by eye
  3. delete the offending email and request another copy without the unnecessary markup scattered through it

I used to run with number 2 all the time. After a while, I decided to write a simple script I call stripmark that would parse HTML out of the email so I could just view the plain text. Over time, it has acquired a few more capabilities, including translating linebreak tags into actual newline characters in the plain text output. This sort of thing is relatively easy to do, with tools like the Ruby programming language and a highly functional text-mode mail user agent such as Mutt. This, however, is far outside the range of what the average user is able to do, and isn't exactly within the range of what most technically oriented people are willing to do -- especially those whose tools are mostly limited to the MS Windows platform.

The script I use is gradually changing into something akin to the opposite of what text parsing libraries like Markdown do. Such libraries define a simplified markup language that is much easier to use to describe how text formatting should be specified via the keyboard, then parse text formatted in that manner, translating the document into an HTML or XHTML formatted document. In fact, I type these articles in plain text files using Vim, entering Markdown formatting signifiers by hand, then run a script that uses a Markdown library to transform the text formatting signifiers into Web markup before it gets published here at TechRepublic.

If it keeps evolving to that point, my stripmark script will eventually do the inverse: it will translate HTML or XHTML formatted documents into text with simple text formatting signifiers that make emphasis, linebreaks, and other simplified "rich text" characteristics obvious without making the text nigh-unreadable the way an actual Web markup language does.

At the moment, the script is just a dirty hack. Even if it was cleaned up, prettied up, and made worth distributing, though, its use would still be a dirty hack. What's really needed is for mail user agents and email clients to incorporate such safety related functionality directly, either via official plugins in the case of Unix MUAs or as integrated functionality in the case of mainstream GUI email clients.

By default, a "safety mode" for any e-mail client should perform a number of tasks for the user. A few examples include:

  1. Disallow embedded images, Flash objects, or anything else that isn't actual text and markup in the rendered "rich text" email display without a warning and specific user intervention.
  2. Disallow hiding URLs behind link text so that even the most casual, security-ignorant user will not be fooled into thinking a link that says "PayPal" but has a URL with a phishing.example.ru domain is a legitimate PayPal link.
  3. Disallow execution of any dynamic content, especially including JavaScript, VBScript, and similar programming languages, without a warning and specific user intervention.

The list could go on at great length, but it would probably be easier to just list things that should be allowed -- like italicizing text, bolding text, underlining text, manipulating colors, and physically altering the visible location of content on the screen in a manner that doesn't hide any content (such as via tables or CSS positioning). It should also clearly indicate when any text uses characters that are not part of the standard ASCII character set, just for good measure, in case someone wants to copy and paste a URL from an email to a browser.

This, at least, would allow people like me, who are aware of the security dangers of normal HTML e-mail rendering, to view the occasional marked up email without having to go to inconvenient lengths to read it without making ourselves susceptible to the dangers of rendered HTML emails.

Unless and until such a MUA or e-mail client that I want to use lands in my lap, though, I'd appreciate it if you'd all default to sending plain text e-mails only. Considering the overwhelming tendency of spammers and phishers to use HTML e-mail, and that most legitimate email users at least offer plain text along with the HTML formatted versions of their messages (whether they know it or not), my spam filtering identifies all HTML-only emails as high-risk targets. If I don't expect your email, and it's HTML formatted, you should be resigned to the expectation that I may never read it.

I value my security more than unsolicited emails, and -- contrary to my usual policy of avoiding false positives at any reasonable cost -- I'm willing to accept a few false positives to protect myself.

About

Chad Perrin is an IT consultant, developer, and freelance professional writer. He holds both Microsoft and CompTIA certifications and is a graduate of two IT industry trade schools.

19 comments
ian3880
ian3880

Chad almost got it right when he wrote "delete the offending email and request another copy without the unnecessary markup scattered through it" Just delete it. Do nothing more. When the sender rings/sends carrier pigeon asking why you haven't replied THEN you have their undivided attention and that's a good time to let them know HTML emails are BAD and plain-text emails are GOOD. [Remember the KISS principle] It's called people-training. Haven't had more than one html email per person - ever. :-) BTW fancy formatting and HTML glitz somehow doesn't overcome the problem of bad spelling and lousy grammar. Get the basics right.

John_Baines
John_Baines

I use Outlook and Groupwise. They are both set by default so that: 1. Disallow embedded images, until the user clicks in some way to allow them. 3. Disallow execution of any dynamic content, asking the user if execution is OK It would certainly be a good idea if they also preformed: 2. Disallow hiding URLs behind link text, which I have not found an easy way to do. Am I missing something? Is the situation worse than I thought and times 1 and 2 are still taking pace in some shape or form?

ceo
ceo

Microsoft moved the option to automatically open all emails as plain text when they introduced the Trust Center in Outlook 2007. Unlike previous versions of Outlook the option to automatically turn off HTML and to only receive plain text was moved from Preferences. By default Outlook 2007 starts up with HTML fully switched on. To force Outlook to only open plain text do the following: Open Outlook Click Tools Click Trust Center Click Email Security Put a tick in the Read all standard email in plain text. If you want to view a plain text message in its original format, click the InfoBar, and choose either Display as HTML or Display as Rich Text. Hope that helps.

mkathiravone
mkathiravone

On "Disallow embedded images, Flash objects, or anything else that isn?t actual text and markup in the rendered ?rich text? email display without a warning and specific user intervention." I think it has already been implemented in Outlook and other mail system like GMail. Isnt it? Cheers, Kathiravan Manoharan http://kathyravan.blogspot.com http://paisamechanic.blogspot.com

JackOfAllTech
JackOfAllTech

I'm going to write a program (and an add-in for my email client) that will input HTML, do all the things you mentioned, and output RTF. Goodbye risk, hello 'pretty' text. Thanks

apotheon
apotheon

It seems like a gross oversight that nobody has really provided safe rendering of "rich text" emails yet. Even the "simplified email" rendering option in several email clients fails in important areas, including something as simple as allowing the obfuscation of URLs behind link text. We really shouldn't be sending HTML emails most of the time anyway, and I for one delete almost all HTML emails immediately, without even reading them -- let alone rendering them for a prettified appearance on the screen. Sometimes, the need arises, though. For those times, we need email clients and mail user agents that provide a "safe rendering mode".

apotheon
apotheon

Points 1 and 3 are probably fine, as you describe your settings. Point two seems to be entirely unaddressed in the world of "rich" GUI email clients.

apotheon
apotheon

That solves the problem of images and Flash objects. It doesn't solve the problem of phishing emails with dangerous links in them, and other problems that arise from the actual markup. I haven't seen a single email client that offers completely sanitized display, other than when displaying in plain text format -- complete with the markup making it difficult to read.

StealthWiFi
StealthWiFi

Why not run your email client in a sandbox?

apotheon
apotheon

I'm actually aiming toward something that translates (X)HTML into a simplified markup language that is a lot easier to read -- something like Markdown, only "better" for purposes of reading (Markdown is optimized more for writing than reading, after all, and leaves some important HTML functionality unaddressed). Of course, parsing HTML is a severe pain in the butt. In some respects, it seems like the best way to handle it would be to use someone else's already written text user interface rendering engine, so I'll have to look at a few of those. I'll also have to check out the markup parsing libraries for languages like Perl and Ruby to see if they can be used for semi-comprehensive (X)HTML translation coverage. How would you plan on handling basic hyperlinks when translating to RTF? I'm curious.

cnet
cnet

I like reading HTML mail. I use the web interface of Fastmail.fm http://www.fastmail.fm and most everything you require is available there. OK, it's not a workstation client but I don't think you specified your MUA be local. When I get phishing mail the links are detected and displayed. When I read HTML mail I can settle for gray boxes which display instead of insecure content or I can click to download images.

StealthWiFi
StealthWiFi

Even if you are viewing plain text and copy/pate the phishing email into your un sandboxed browser (pretty stupid move but still possible) you would be on the phishing site, so plain text alone won't solve that one. And if you use a tool like SandBoxie for running your email client if you do click a link or anything else runs it runs in the sandbox with no contact to the system. Seems to me that is just as safe as plain text and you get the pretty features

apotheon
apotheon

Why not run your email client in a sandbox? Sandboxes don't solve all problems. There's no silver bullet for security.

JackOfAllTech
JackOfAllTech

But I'll be thinking about all those issues before I start planning the project.

apotheon
apotheon

If the link says "PayPal", they think it's PayPal a lot of the time. If it says "phishing.example.ru", on the other hand, they think it's a phishing link hosted in Russia. It's not true of everyone, but it's true of enough people to significantly reduce the percentage of people who are fooled, I think. Maybe we can't save everyone, but saving some would still be an improvement.

chris
chris

we've found that timely education sent to our users (corporate environment) reduced the number of "issues/infections/etc" by about 90%. We made everyone paranoid...and it worked. They just don't click stuff in emails. Less "fun" but no badness. --- Would there be a way to have the email client highlight (translate the url and make it yellow or something, or put up a warning box) for users so they can have their prettiness but be "coached" along the path of wisdom?

chris
chris

that the people who just blindly click email links to "update their account info" would even notice. I bet they would not. PS That's not to say you should just be stupid or throw up yer hands, but you are giving people too much credit. Sorry, that sounds bad, but being around plenty of "normal" people will prove me right.

apotheon
apotheon

Even if you are viewing plain text and copy/pate the phishing email into your un sandboxed browser (pretty stupid move but still possible) you would be on the phishing site Viewing plain text will tell you whether a link that pretends to be for PayPal is actually for something like phishing.example.ru instead. Sandboxes may help, but they're not the silver bullet -- sometimes they leak, and sometimes the problem with a link isn't solved by segregation from the rest of the OS environment (such as URLs that include information identifying the target email address as one that's actually monitored by a real human being). If using a sandbox is the only protection you have, you're still executing things -- and they can still prove dangerous. If you're viewing everything in plain text and know better than to just trust everything you see -- if you, for instance, know better than to trust URLs you don't recognize -- nothing executes. How do you get more secure than that?

chris
chris

Garlic, mirrors and crosses too, just to cover your bases. :-P

Editor's Picks