HTML mail

Charlie is not impressed by HTML mail, to put it delicately. He points out, correctly, that HTML mail can be used to track spam or distribute viruses (#3 and #4 in his top 10 reasons he does not read HTML mail - number 4 is a tad disingenuous as he’s not running a Windows computer which is vulnerable to viruses).

I think the other points are woolly thinking, though. And the more I think about it, HTML mail is what we should all be using - if only we can get around spammers and fuckwits. And I think we can, with a bit of effort.

1: I’ll read your mail in plain text - well, that’s just an argument for making sure you send a plain-text version as well. And, frankly, if Charlie’s mail client isn’t able, in this day and age, of doing some basic HTML conversion (possibly even piping to lynx - the good old Unix toolkit approach), then perhaps it should. (If Charlie meant to complain about people using different fonts and colours just for the sake of it, well, that’s fair enough, but this is something that is overrideable by the option of “always use my fonts and colours” that you get in all web browsers.)

2: HTML is not an RFC standard for mail text - I find this one bizarre, as the MIME RFCs clearly say that you can send a document of any type via email. And that includes sending an email as a Word document. I’m confused why it’s OK to send someone a PDF, with the rest of the body of the email just saying “See the PDF I just sent you”, but it’s bad to send an HTML and text-only version of the email, that your mail client can choose between.

3: I don’t want to download your graphics (because he might be reading his email on a 9,600 baud connection on his mobile). Well, first of all, any decent mail client should be configurable to not download external images (this foxes web bugs as well, incidentally, which is point 4) - Mail and Entourage on Mac OS X both do that. Secondly, I find the major source of unwanted attachments to be virus emails, which have nothing to do with HTML mail.

If bandwidth is so important, why not set up a server-side filter that removes all attachments from your mail and plonks the modified mail message in a special low-bandwidth folder?

6: HTML mail is bloated. This is the same problem as point 3, and the solution, again, is to make sure that if you’re reading mail on a text-only, low-bandwidth connection, then you’ve got a server-side filter that gets rid of large attachments or HTML versions of emails.

7: I want to continue using Mutt (and Mutt is text only). Well, first of all, this is the same point as point 1. And I’d personally be inclined to say that a fixed pitch mail client is just being stubborn - text reads far easier in a proportional font, as we’ve all known since the first Macintosh (almost 20 years), and I for one would not want to go back to monospaced emails.

8: SpamAssassin thinks all HTML mail is spam. This is the same as point 3 - HTML mail can be used by spammers. It appears to be a threat - if you send HTML mail, it may be misidentified your mail as spam. But how on earth is that the sender’s fault? Surely it’s the fault of whoever installed such a simplistic spam filter, and it’s down to them to fix it?

9: Mail clients that use HTML mail are often broken in other ways. This is just a fallacious argument. OK, so Outlook is vulnerable to viruses; and yes, Outlook defaults to HTML mail. But Outlook’s problem is not that it sends HTML mail; it’s that it displays HTML mail that it has received badly. Criticising HTML mail on those grounds is like complaining about people being able to send binary attachments because some mail clients open them up and install viruses on your system. Don’t shoot the messenger.

10: People who use HTML mail are clueless - this one I have more time for. And I think Charlie has forgotten the greatest crime of HTML mail, which is that, coupled with top-posting, it can make it impossible to work out who said what in a conversation. (More about top-posting in another post, I think.)

Charlie, incidentally, misses out the other problem of HTML mail: Yahoo Groups can insert HTML ads as opposed to plaintext ads, which are far more annoying.

The fact is, I think HTML mail has been misused, and a combination of poor security in the most common HTML-enabled mail client and lack of user education has brought us some pretty shoddy HTML mails in the past.

But, damnit, why are we still using 80 character-wide plain text when writing for other humans in the 21st century? I mean, consider some of the things that I do when replying to email:

1. I use the rewrap tool in my mail client. That’s because I’ve quoted someone else’s mail, and by adding the usual “> " to the beginning of each line, some of them end up longer than 80 characters. I manually select contiguous areas of text - usually just paragraphs - and tell Entourage to reformat them, moving the line breaks and quoting characters so the text lines up properly within 80 characters.
2. If I want to use any form of indenting, I have to manually manage inserting spaces, and God help me if I want to write more than one line of text indented, because then I have to manage line breaks as well.
3. I have to be careful about URLs being longer than 80 characters, because some email clients might break them across several lines and they won’t work. Sites like makeashorterlink.com and tinyurl.com exist purely so you can send long URLs via email.
4. Although it’s not related to plain text vs HTML per se, I have to get rid of duplicated signatures, extra blank lines, and artefacts of top-posting.

All this is fixable by using HTML mail. Except that HTML mail has been tarnished by spammers and fuckwits.

If we’re going to use rich text for email - which we damn well need to - we need to do the following things:

1. All originated HTML mail has to be converted into plain text reliably and silently. All formatting other than the really difficult stuff (e.g. complex tables or floats) should be converted into stuff that the text-only people will be happy with.
2. Mail should only be sent as HTML if it includes formatting that is superior to plain text. That means that if you send just a few paragraphs of standard text, there shouldn’t be an HTML version at all. Only if you use bold, italic, font size changes or tables should there be an HTML version.
3. Oh, and all HTML output should be wrapped to 80 characters. It helps people reading it under some circumstances, and doesn’t hamper anyone else.
4. ISPs should offer low-bandwidth versions of their mail feeds. This can include, for instance, taking all inline images / attachments, storing them on a password-protected web site, and giving you the option of downloading them if you want.
5. Mail clients should have the option of converting top-posted text to bottom-posted, and get rid of signatures when replying to messages.

I’m going to start using Mac OS X’s Mail client for a while to see how close to all of this it comes. I’ve been looking for an excuse for a while anyway.