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.
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.
Counter-arguments
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. A tutorial for Outlook and Netscape can be found
here.
Thunderbird:
here.
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.
Links
This page wouldn't have been possible without the people that started
this effort. Please find below links to some (but surely not all) pages
related to this campaign with more information, more signatures, and more
help! If you feel there is something absolutely essential missing here let
me know.