cd ~/

Home of Daniel Graf

Benutzer-Werkzeuge

Webseiten-Werkzeuge


Seitenleiste

cd ~/

Home of Daniel Graf

Seiten

Suche

Blog Meta

Dynamo Dresden

Galerie

braindump:ascii_ribbon_campaign

ASCII Ribbon Campaign

Against all HTML e-mail and proprietary attachments

Welcome to my mirror-page of the official 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 (officially ended in June, 2013 - RIP) 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 support HTML e-mail. This means that people who receive your e-mail are most likely unable to read it, as it'll be displayed 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.
  • 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 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):
<img src="http://www.spamserver.com/buyersvcs/warranty_wbe_opened.jsptracker?ccode=bs_war_wbe_1" />
  • … 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 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. Basic text formatting and layout can also be done in plain text. 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.

Source: http://web.archive.org/web/20120311194018/http://www.asciiribbon.org/

braindump/ascii_ribbon_campaign.txt · Zuletzt geändert: 2016/04/14 13:31 von Daniel Graf