Against all HTML e-mail and proprietary attachments
Welcome to the official homepage of the ASCII ribbon campaign. Started as a semi-serious effort, it has become clear that more people should be made aware of some basic facts and guidelines about sending e-mail, in regards to HTML e-mail and proprietary e-mail formats. Since only a few scattered pages can be found, on different servers with no clear official homepage, this was a sign that something needed to be done. So www.asciiribbon.org was born!
Everyone is encouraged to spread the word on this campaign, and to direct people to this site for more information.
What is this campaign about?
Well, simply put: it opposes any and all HTML e-mail, and e-mail with proprietary attachments. Why? Actually, a number of reasons:
Quite a few e-mail clients (especially those embedded in mobile devices) do not (properly) support HTML in e-mail. This means that people who receive your e-mail are most likely unable to read it, as it'll be displayed wrongly or partially, or as raw HTML code, or even not at all and just give an error message!
Other clients have a very poor or broken HTML rendering, causing the messages to be unreadable as well, and sending similarly broken HTML e-mail.
Sending HTML e-mails causes great overhead, and is very inefficient. HTML e-mail sizes are always much larger than plain text messages, even if they don't contain any graphics. A big portion of the internet users has a pay-per-time/MB connection and/or a download limit on their account and will actually have to pay when they exceed it.
HTML e-mails with a background image, flashy graphics (for instance the service Incredimail offers), are usually a complete waste of bandwidth, inbox space, and time. Having to download 200kb or more for an e-mail that contains a few lines of text is quite ridiculous. The same can be done in a fraction of that size (like, 0.1% of it!) when using plain text, saying exactly the same, and communicating exactly the same information. As an example here the breakdown of a (real-life, used with permission) message with actually a lot of text typed (3 kilobytes), most messages won't get this large at all unless writing a half-essay to someone else:
Message: "FRIENDS WITHOUT FACES~(w/sound)".
I 1 <no description> [multipa/alternativ, 7bit, 17K]
I 2 <no description> [text/plain, quoted, iso-8859-1, 3.0K]
I 3 <no description> [text/html, 7bit, iso-8859-1, 14K]
I 4 DOT_Flowersg4a122212222332224221222.jpg [image/jpeg, base64, 100K]
I 5 !cid_03f701c31824$5b06d6d0$2edb98c8@cida [image/gif, base64, 29K]
I 6 monoset purple344434444554446443444.gif [image/gif, base64, 10K]
I 7 BLUEAN~125665557554555.GIF [image/gif, base64, 58K]
I 8 Friends Without Faces6111511112211131171 [audio/wav, base64, 635K]
853 KB total.
People that are limited to a text-only terminal, people with disabilities, blind people, basically anyone that cannot use a graphical interface easily or at all, are likely unable to read your mail.
Very few companies actually are free of HTML email or proprietry attachments. To see a good example of a company that abides by what we think is acceptable, please see a company called Samara James.
It even poses a serious security risk if "inline graphics" are used and downloaded on-the-fly when you preview or open an HTML e-mail. Smartly constructed image links can "call home" to, for instance, an advertisement server and get a confirmation with your e-mail address and IP address, browser type, operating system, time zone, and even more information, confirming that the e-mail was indeed opened and viewed, all automatically, and with that confirming your address as being read and a good target to send SPAM! A real-life example of such a link that I received in an e-mail (domain name obfuscated, no personal attack is intended against any company here):
Which would mean -if- my e-mail reader would try to display this image, it would contact spamserver.com, tell them the mail was actually opened, and if my browser was set to default behaviour, give them my e-mail address entered in it as well as the time zone I'm in, my IP, browser type, operating system, (a lot of information is passed in a default header of a web browser requesting any page) and whatever the specific code means for them internally that is passed to the script in this link... Security, anyone?
Another security issue to consider: Since HTML e-mail is usually rendered by some browser back-end, either internally or externally supplied, any vulnerabilities in those back-ends will also be a risk for the recipients of e-mail. An exploit can be directly targeted at groups of users, and simply viewing the e-mail would pose a serious risk. For example, an Internet Explorer vulnerability would pose a danger to people using Outlook.
More reasons can be found than these of course. Many more, in fact.
Proprietary mails are even worse. They impose on the recipient the use of a certain operating system, certain program, or certain office suite even to open and read e-mail. Think of getting an e-mail in the form of a Microsoft Word document. The idea behind it is that one can send a word document and have text formatting and layout preserved regardless of the recipient's e-mail client. However, e-mail clients will never be able to open this kind of document internally, are often limited to launching an external program, or a program that may not even be available for their operating system at all. Not to mention the fact that the document headers usually contain personal information, installation information, and more, about the sender that unknowingly gets sent along.
A number of people have raised counter-arguments, defending the use of HTML e-mail because plaintext would be too limiting. However, those arguments are often based on a lack of knowledge of what exactly is possible in plaintext e-mail and what can not be done (properly) in HTML:
"I need my e-mail to be formatted a specific way/I want to have it carry the corporate house style of the company": Basic text formatting and layout can also be done in plain text. If layout and colours are of the utmost importance, then HTML will not suffice either because it can and will be rendered differently on the recipient's system. They may not have the required fonts, for example. In that case, for example for official documents, one needs to use a platform-independent document format as an attachment (e.g. RTF).
"I need a corporate logo displayed in-line": E-mail, by nature, is a text medium and trying to in-line graphics is wrought with problems. HTML is considered to be "the solution" for this, but nothing is less true: In-line display of a company logo will fail on many clients, because there is no standard way in HTML e-mail to do this with the actual graphic included in the e-mail. Any graphic included in the e-mail is, by definition, an attachment, but the ways of referencing such an attachment differs per client. E.g. Outlook's method of specifying in-line graphics using a "cid" marker will fail on non-Outlook clients, etc. The other option would be to specify a URL to an on-line HTML IMG element, but a good portion of the e-mail clients will block external graphics (mostly because of the security consideration also noted above), and it would inherently require that a computer with an e-mail client has free access to the Internet to collect the logo, which is not the case for most corporate environments.
"Plaintext e-mail can't use proportional fonts": Using text/plain does not imply or enforce the use of a specific font in an e-mail client. Quite often, a fixed-width font is the default, but it's not a requirement. This default is usually chosen to allow more easily reproducible formatting of, for example, make-shift tables in text using whitespace.
"I can't use long lines of text that get wrapped/I must use 72 or 78 character lines with line breaks": Although RFC2822 specifically states that lines of characters in e-mail may not exceed 998 characters, with a strong suggestion to limit them to 78 characters, this only applies to the actual raw e-mail body. In many cases, this can be the way a message is sent, but this is not a limitation: Using MIME, which is suggested at all times anyway because it allows you to specify different character sets/code pages for text (for accented characters, different non-latin characters, etc.), you can also specify a content-encoding that can allow for arbitrarily long lines (that get wrapped dynamically by the recipient's client), for example using quoted-printable, or even exotic character sets that might otherwise interfere with the transport of e-mail (you can transport this by using Base64).
"I am legally obligated to include a corporate footer with company information": A corporate footer is provided for by any RFC compliant e-mail client in plaintext by using the "signature" marker, also known as a tear-off line, and by several other names: a double dash -- and a space on a line by itself. Anything below that marker will be the "signature footer", or "sig block" [Wiki]; many clients, when replying, will automatically not quote this footer, preventing unnecessary content in replies - something that is not an option with HTML footers. Also common practice is having this information in a "vcard" attachment which is supported as standard by almost all mail clients - in fact, using a vcard would make adding corporate data to one's address book as quick as a single mouse operation; once again, something not possible with a proprietary formatted HTML-footer.
Of note is that netiquette prescribes a signature block to be plaintext: NO rich text formatting, HTML or images are allowed.
What can I do to help?
I'm glad you asked! You can actually do a few things to help:
First and foremost, configure your e-mail client to send only text messages.
Secondly, show your support by adding an ASCII Ribbon Campaign signature to the e-mails you send out. Some examples:
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
ASCII ribbon campaign ( )
against HTML e-mail X
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
More can be found on the pages linked to below!
Thirdly, spread the word that e-mail should be, and remain, a plain text communication medium - it is what it was designed for, and it is exceedingly efficient at it! Using plain text doesn't limit you in any way; you can still send attachments and images to your friends and contacts, it just means that the actual content of your messages is in a format that can be displayed correctly on any system. And to those who ask the question "and non-Latin alphabets?", please note that plain text is open to all encodings (including UTF-8). Plain text e-mails can thus be in Chinese as well as in Cyrillic, Arabic, Hebrew, etc.
If you have additions, comments, complaints, you can drop me a line by using this contact form.