Adam Fields (weblog)

This blog is largely deprecated, but is being preserved here for historical interest. Check out my index page at for more up to date info. My main trade is technology strategy, process/project management, and performance optimization consulting, with a focus on enterprise and open source CMS and related technologies. More information. I write periodic long pieces here, shorter stuff goes on twitter or


Comprehensive guide to configuring mailers for plain text

Filed under: — adam @ 9:50 am

“HTML is meant for the WWW; not for mailing lists, Usenet newsgroups postings, proper business E-mail correspondence and preferably not for personal E-mail unless the recipient is expecting it.”

I wholeheartedly agree.

2 Responses to “Comprehensive guide to configuring mailers for plain text”

  1. Emmanuel Pirsch Says:

    I disagree!

    HTML is not meant only for the WWW. Textual communication is not meant to be plaintext. Formatting text allow to put emphasis on things that are important.

    The size argument is really weak… It’s not like bandwidth and storage are scare resources nowaday.

    I believe Netiquette should mandate that there is always a plaintext version of the message if it’s sent in HTML. This way, client that do not support HTML, can display the message properly. It is the mail client that does not support multiparts that is a bad citizen.

    As for background color or other formatting, they can always be modified using user CSS (granted the e-mail client must support it).

    This argument is very much like the argument against using javascript in web pages. Yes these things can be abused, but that does not mean we should not use them.

  2. adam Says:

    I’ll accept that maybe some small amount of formatting would be okay for email. Personally, I find that there’s nothing I want to convey in email that I can’t convey in plain text (with text-equivalent annotations), with a URL, or a picture. The abuse of HTML mail frustrates me, and the fact that there’s no distinction between “good HTML” and “bad HTML” makes this difficult to implement partially in a way that’s not abusable. My biggest complaint is that under no circumstances should a mailer obscure the URL that the user is clicking on, yet this is possible in most of them. There’s just no good that can come of that.

    I won’t complain too loudly if people include a plaintext version, but I almost always refuse to read email that’s html-only.

    I don’t think that this is like the javascript argument. I really believe that while the web thrives on interactivity and design, I haven’t seen a compelling argument that email is any better when there’s more than just text.

Powered by WordPress