Outlook 2007 in Curmudgeon Mode

I am fed up with HTML email. I’m not sure if I just got one too many horrible emails with fuchsia comic sans text on a mauve background or white text on black background which becomes black text on black background after reply or forward. Or maybe it was the series of HTML email security disasters in Outlook 2002 from Office XP that could sploit you by just previewing a message. Probably both.

Regardless, I started reading all of my Outlook email as plain text in early 2002. I rarely want to look at the messages in HTML. I just I want everything to be plain text by default. That probably makes me a tech curmudgeon but life is so much better this way.

  • Phishing looks much more fishy in plain text because the evil URLs are exposed.
  • I get to choose the most readable font and color—Consolas 10.5 Black—instead of the sender—Comic Sans MS 12 Pink. (Seriously, I have known several people love to send email in big pink comic sans.)
  • The Internet Explorer (mshtml) HTML rendering engine is not invoked unless I specifically request the email to be displayed as HTML.
  • Rendering plain text defeats web beacons and exposes tracking URLs that marketing people hide in HTML email to track your behavior.

HTLM email is really most useful for marketing campaigns, hackers and phishers. The simplest way to opt-out of the target pool is to opt-out of HTML email.

Since Outlook 2002 SP1, Outlook has the capability to string HTML from incoming messages and display them as plain text. It started out as a registry tweak when the feature was rolled out with SP1 for Office XP, but it is now a full-fledged option.

Tools > Trust Center > Email Security

Check the “Read all standard mail in plain text” option.


Outlook has a dubious feature whereby it attempts to remove “extra” line breaks from plain text messages by default.

And I also don’t want Outlook to reformat my plain text because it messes up code, other deliberate formatting and PGP signed messages.

Tools > Options > Email Options (button)

Uncheck “Remove extra line breaks in plain text messages”



Barack’s people are tracking clicks

Emails sent by Barack Obama’s people often have URLs in them.


That’s fine but Mr. Obama’s people use a phishing technique where the link displayed is not the real link. My mail reader converts the emails to plain text by default, so it is obvious.


The text “http://my.barackobama.com/Haiti” is actually linked to some obscure URL at my.barackobama.com. This URL probably encodes information about the page to display as well as my identity. It is almost certainly there so that the people running my.barackobama.com can track my behavior if I were to click this link.

This is nothing new. Mr. Obama’s people have been doing things this way since the campaign and it is a common technique for tracking the behavior of people in email marketing campaigns. It has always bugged me, though, that Barack Obama does this.

Who is reading your email?

Email has no privacy assurance whatsoever

Email is short for “electronic mail”. The implication is that this is a direct metaphorical equivalent for the familiar paper process, but it just ain’t so. One of the points of departure from user expectation is the concept of a sealed envelope.

When you put a paper letter in a paper envelope and seal it, there is an expectation of privacy because someone has to physically break the seal which is difficult to do without obviously damaging the envelope. Email, by contrast has no secure envelope. It is transferred over the Internet using plain text over TCP port 25.

The implication is that anyone can read your mail without you realizing it. Most people think the only point of concern is that an attacker capturing packets at a public WiFi hotspot will snoop your mail. The most obvious countermeasure is using SSL with webmail. This is a good countermeasure as far as it goes but it only encrypts the communication between you and your post office. However the transport of your message between post offices is still going to be in plain text and will likely pass through several routers on the Internet en route.

So what? Who can tap traffic on those routers? Perhaps some uber-hacker is siphoning of traffic for analysis but man that seems like a huge amount of data to sift through and not likely worth doing, right?

Unfortunately Deep Packet Inspection is now ubiquitous. ISPs and governments, including the USA, have widely deployed hardware to capture and mine data out of unencrypted data packets passing through the Internet. Effectively that means it is safe to assume that all of your email (and other traffic) is being captured and analyzed by one or more automated systems trying to determine if it matches patterns of “bad behavior”. Deep Packet Inspection, by the way, is the mechanism that ISPs use to provide “tiered service” and detect copyright violations.

Maybe you think this sounds OK because you aren’t doing anything wrong, but consider whether you trust all of the people who have access to this data to do no evil, trust these people and algorithms to never make mistakes and trust that they never lose control of your private data.

A Modest Proposal

RFC 2478 describes a cryptographic mechanism similar to SSL for web sites that places a strong cryptographic layer over the transfer of email via SMTP. This transport layer security is widely supported by mail servers today and is the mechanism by which SMTP client programs like Microsoft Outlook, Mozilla Thunderbird and Apple Mail are able to communicate securely with an SMTP gateway. Many mail providers, like Gmail, already require (or at least offer) SMTP over TLS connections for clients sending mail.

RFC 2478 was published more than ten years ago. Most, if not all, contemporary SMTP gateways are capable of supporting secure SMTP over TLS. If all mail servers simply transferred all messages between each other with TLS encryption then nobody could read the messages except the administrators of the destination and source post offices and the intended recipients. This could be phased in over a reasonable period of time.

  • SMTP in the clear becomes deprecated.
  • During the deprecation period servers are configured to attempt to communicate with TLS by default.
  • After some time, administrators can configure warnings in the headers and to-line like “[UNSECURED]”. This is an important user-education step.
  • SMTP in the clear becomes a banned protocol and servers are forbidden from supporting it. (Testing and troubleshooting SMTP can still be done via classical telnet by using OpenSSL as a wrapper.)
  • Servers will refuse connections from servers that do not offer TLS which will cause the message to bounce to the sender with a statement that their mail server is not secure.

Securing all SMTP traffic in a TLS envelope would go a long way toward restoring some reality to the baseline assumption that nobody is reading email in transit. The technology has been standardized since 1999. Why do we not have secure server-to-server mail transfer ten years later?

%d bloggers like this: