I recommend that you use <font> tags and other basic HTML formatting code within your HTML e-mail newsletters. Also, use <br> tags instead of <p> tags for line breaks as the former will preserve fonts. While using these tags will add to the complexity of your code, at least your newsletters will look as intended regardless of whether your recipients download images or not.
This kind of nonsense clearly misunderstands the capabilities and purposes of e-mail. E-mail is intended for basic textual communication. If you need a specific graphical design, send a bloody attached PDF (which, when properly designed, is both comparable in size to and more portable than an HTML-based design). HTML e-mail is a security and compatibility nightmare… and that's before we get to visual impairments, or people who are using dialup (whether because they're on the road, on a budget, on a slower/older machine, or whatever), or people who disagree with the usually crappy design choices made by HTML newsletter writers.
For example, I read e-mail in a relatively small window—just wide enough for an 82-column line. It's sort of like driving on the right-hand side of the road. Based on the capabilities of 90% or so of the population, we should be driving on the left, not the right. However, the standard in most of the world is to drive on the right. Thus, most cars must be built not to be optimal, but to be usable. That's where the 82-column line comes from: It's a standard. I'm far from unique in this; if you carefully look at the defaults for most major e-mail clients, their standard reading mode does not open each message in a full-screen window. Most HTML newsletters, though, assume a full-screen window. And assume what fonts are installed on the recipient's machine without regard to readability in general, or on a particular screen (for example, one of my machines has its monitor settings optimized for a very dark reading area).
What is most frustrating, though, is that in this day of increasingly clever and sophisticated intruder programs, TL is advocating use of HTML e-mail at all. Although Squillante gives lip service to security concerns in the top half of his "editorial," he basically discounts them (without being so bold as to say so) at the bottom. This brings back reminders of the repeated failures of "all in one" programs. Anybody remember Framemaker? Not the currently available database of that name, but the much-older "integrated program." Much older, as in "was supposed to take the world by storm in 1985." Similarly, despite Microsoft's efforts, have you noticed that the parts of its Office suite that cause the most trouble are precisely those that try to force different fundamentally incompatible data into unfamiliar territory (such as the graphical functions in Word)? Much the same is happening with e-mail clients and web browsers: Most software manufacturers are tying them every closer together without ensuring that the basic functionality works as intended first.
If design is really that important, don't you want your clients to have as machine-independent a format as possible? At this time, that means PDF. One can embed fonts into a PDF, so that if you really, really have a fetish for Cheltenham you can inflict it on your readers… and all of the page and line breaks really will be preserved. Your tables won't get mangled because a couple of your recipients happen to be in Eastern Europe and use a different character set. Your graphics will come through at the proper resolution without worrying about whether your readers have LCD or CRT displays. And so on.
In short, use the right tool for the right job. HTML e-mail is the wrong tool for just about any job; and those of us who care about security (in my case, because it was a primary job responsibility for so long) can continue to do so.