Once upon a time, in a generation past, letters would be received with written text. There was a default form (paper with ink or pencil) and an encoding (in the language of the correspondents). Whilst this may all seem very trivial, it does have a particular importance for the subject at hand in the context of contemporary electronic mail. Can the recipient of your message actually read what you've sent them? Could imagine a situation where people knowingly sent written correspondence in a format that recipient couldn't read? Have you ever received an email attachment that you couldn't open?

For some senders, they simply don't care. They blithely add attachments and apply character encoding without any consideration of their recipients. Recipients are either likely to become frustrated at what they've received, or simply get in the habit of deleting material from the sender, unread. Spammers (and more legitimate advertisers) are certainly an example of this group. As the depend on a tiny percentage of readers to fall for their deceptions they apply whatever is most enticing for that percentage, which is whatever the majority is using at the time.

Whilst such uncaring behaviour is unsurprising, what is slightly more surprising is individuals and organisations have adopted behaviours in sending email which some people simply cannot or will not read. Technologically there are very well-established standards, carefully considered, designed to ensure that emails are human readable. In particular there is the Internet Message Format standard (and its update), several Mail Extension standards, and the Netiquette Guidelines.

But most people have tended to ignore standard in favour of whatever technology is force-fed to them. Starting with Microsoft Windows 95, rather well known for ignoring established standards, a number of cognisant users expressed increasing annoyance that they were receiving email in HTML and non-human-readable formats, starting the "ASCII ribbon" campaign. At the time, and still a continuing issue for those who care about such things, plain-text is vastly more efficient in terms of computer memory and disk space, let alone the use of attachments. Many systems administrators and programmers to this due prefer to use text-based email clients and often appropriate in an environment where that is all that's immediately available. Managers who complain about the increasing cost of the office computer systems and storage devices could start with thinking about their own emails.

HTML email is still an issue, even if it used by at least 90% of the population by 2002, although 31% then still indicated a primary preference for plain text. The problems are well known, with various email clients not parsing the html/css consistently with W3C specifications. Others have absolutely no clue about design but think they do (the field of aesthetics also has the Dunning-Kruger effect), and tend towards flashy designs that actually distract readers from content. It is also a superb vector for phishing attempts, with fake URLs masked to a casual viewer of the HTML-encoded email, or in the case of attachments, viruses.

Decent email servers are configured to comply with the aforementioned MIME standard, sending an email in both plain-text, with HTML attachments, and other non-text attachments. The early version of the standard makes the astoundingly sensible suggestion that user agents that compose multipart/alternative entities should place the body parts in increasing order of preference, that is, with the preferred format last. In other words, text first, then html email, and attachments list. Which brings one to the extraordinary situation where emails are being sent with astounding levels of ignorance and even rudeness, when the content of the message is included as a proprietary attachment. For the vision impaired, text is plainly best, and HTML email should be properly formatted.

This author takes particular issue with individuals and organisations that promote principles such as equality of opportunity and social justice, yet fail to apply these principles when it comes to even the most simple act of sending an email, and worse still, express little desire to learn. Ignorance can be accepted in the field of technology; continuing such behaviour however is hypocrisy.

A few examples worth considering from personal experience:

• A progressive MP whose staff sent out an invitation to a fund raising event. The text of the email was of the "see attachment" variety, with no useful information about what or where the event would be held. This was included in the MS-Word attachment which, apart from four lines of informative text, included an image which generated an 8 megabyte attachment; more than the complete works of Shakespeare. They sent it to over a thousand people.
• A well-known micro finance company for developing countries who insist on only sending out emails in HTML format with the fallacious claim that it is "too expensive" to provide plain-text and HTML emails, even though free software exists to provide such format alternatives, and thus have chosen the latter.
• A newsletter for the region division of progressive political party was sent in a poorly-designed MS-Word attachment. When the issue was raised with them, the idea of sending plain-text emails was considered "loopy". This is from region where the candidate was seriously vision impaired.
• A progressive political campaign group who, well aware of the need of text-based information and appropriate tags in HTML email, managed to include as alt-tags in one message: "The Plan" "Can't see?" "Try turning on images". The entire point of alt-tags is for those who can't see!

In summary, HTML formatted email and proprietary attachments can and do have their uses. However their usefulness is a lot rarer than their usage. This overuse of HTML formatted email and attachments reduces communication, is a dangerous vector to phishing attempts and viruses, and wastes time and money. Whenever possible, plain-text should be used in preference to HTML email, and external web-links to attachments. Remember, communication is a two-way process. In order to be successful it must be sent in a format and encoding which both parties can understand.