Die "ASCII-Ribbon"-Kampagne

Willkommen auf der offiziellen Seite der "ASCII-Ribbon"-Kampagne. Was einst als nicht ganz ernstgemeinter Versuch begann, erwies sich schnell als Leitfaden für Grundregeln und Richtlinien für das Versenden von E-Mails bezüglich HTML-E-Mail und proprietären Mailformaten. Im Netz lassen sich nur ein paar vereinzelt verstreute Seiten zu diesem Thema finden - welche sich zudem auf verschiedenen Servern ohne richtige Hauptseite befinden. Dies war ein Anzeichen dafür, dass etwas getan werden musste.

Also wurde www.asciiribbon.org ins Leben gerufen!

Jedermann ist dazu aufgefordert, das Ziel dieser Kampagne anderen mitzuteilen, und diese für weiterführende Informationen auf diese Seite zu verweisen.

Um was geht es genau bei dieser Kampagne?

In knappen Worten: sie hat die Ablehnung jeglicher HTML-E-mail, sowie E-Mail mit Dateianhängen in proprietären Formaten zum Gegenstand. Wieso? Im folgenden sollen ein paar Gründe erläutert werden:

• Einige E-Mail-Clients unterstützen kein HTML-Format für E-Mails oder implementieren es nur fehlerhaft (speziell solche auf Mobilgeräten). Das bedeutet, dass der Empfänger mit großer Wahrscheinlichkeit nicht imstande ist, Ihre Mail zu lesen: Sie würde nur fehlerhaft, im HTML-Quellcode oder oder gar überhaupt nicht angezeigt und somit eine Fehlermeldung produzieren!
• Andere E-Mail-Clients können HTML entweder nur sehr unzureichend oder gar nicht rendern, was dazu führt, dass die E-Mails wiederum unleserlich sind. Ebenso können diese auch fehlerhaftes HTML versenden.
• Das Verschicken von HTML-E-Mail verursacht einen beträchtlichen Overhead (Serverlast), und ist daher äußerst unwirtschaftlich. Gemessen an der Dateigröße sind HTML-E-Mails stets größer als Nur-Text-Mails, selbst dann, wenn erstere keine Grafiken enthalten. Ein Großteil der Internetnutzer (selbst in Deutschland hat nicht jeder unbegrenzte Flatrates) ist an einen zeitabhängigen Tarif und/oder ein Downloadlimit gebunden, und somit würden bei Überschreitung dieses Limits zusätzliche Kosten zu deren Lasten entstehen.
• HTML-E-Mails mit darin eingebettetem Hintergrundbild, möglicherweise gar animierten Grafiken (wie beispielsweise bei Incredimail) stellen im Normalfall eine völlig unnötige Verschwendung von Bandbreite, verfügbarem Speicher für den Posteingangsordner, und nicht zuletzt an Zeit dar. Es ist schlicht lächerlich, für eine lediglich ein paar wenige Textzeilen umfassende E-Mail ganze 200 Kilobyte herunterladen zu müssen. Bei Verwendung von Nur-Text hingegen ist dasselbe in einem Bruchteil der genannten Größe möglich (annähernd 0.1%); die Mail sagt nach wie vor noch dasselbe aus, und gibt auch denselben Umfang an Informationen an den Adressaten weiter.
  Hier als Beispiel einmal eine detaillierte Analyse einer (mit freundlicher Genehmigung abgedruckten echten) Nachricht mit einer großen Menge an Text (3 Kilobyte): (hier ist anzumerken, dass die meisten Nachrichten wohl niemals diese Größe erreichen würden, es sei denn, jemand verschickte einen halben Aufsatz an jemanden anderen per Mail)

  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.
  

• Für Personen, die nur ein Text-Terminal zur Verfügung haben, sowie körperlich eingeschränkte Personen und Blinde - im Grunde somit für alle Menschen, die nicht in der (glücklichen) Lage sind, eine grafische Benutzeroberfläche verwenden zu können - könnte ihre Mail nicht lesbar sein.
• Das Öffnen von sogenannten "Inline-Grafiken" stellt außerdem ein ernstzunehmendes Sicherheitsrisiko dar, vor allem wenn diese "on-the-fly" heruntergeladen und sofort danach dargestellt werden. Dies passiert z. B. dann, wenn Sie bei Ihrem Mail-Programm die Vorschaufunktion verwenden oder die HTML-Mail dort in einem separaten Fenster öffnen. Ganz besonders raffiniert konstruierte Links zu Bildern können zudem "nach Hause telefonieren", z. B. einen Server einer Werbefirma kontaktieren und diesem eine positive Rückmeldung über ihre voll funktionsfähige E-Mail- und IP-Adresse geben; weiterhin über den von Ihnen verwendeten Browser, Ihr Betriebssystem, Ihre Zeitzone und noch viel mehr - dazu könnte dann u. U. noch eine Bestätigung kommen, dass Sie die E-Mail auch geöffnet und gelesen haben, und Sie somit die ideale Zielscheibe für zukünftige Spammer abgeben!
  Hier ein Beispiel aus dem wahren (Netz-)Leben für einen solchen Link, den ich einmal in einer E-Mail bekommen hatte (der Domainname wurde unkenntlich gemacht, um keine gezielten persönlichen Angriffe gegen beliebige Firmen vermuten zu lassen):

  <img src="http://www.spamserver.com/buyersvcs/warranty_wbe_opened.jsptracker?ccode=bs_war_wbe_1" />
  

  Was würde das nun bedeuten? Ganz einfach: WENN mein E-Mail-Programm nun dieses Bild anzeigen würde, würde sogleich der Spam-Server unter der Adresse spamserver.com kontaktiert werden und diesem sogleich mitteilen, dass die E-Mail tatsächlich von mir geöffnet wurde. Im Falle, dass mein Browser dazu noch Standardeinstellungen verwendet, würde ihm sogar noch meine E-Mail-Adresse sowie meine Zeitzone, meine IP, mein verwendeter Browser und mein Betriebssystem mitgeteilt werden - zumal ja bekanntlich ohnehin eine Menge an Informationen im HTTP-Header jeder angeforderten Seite enthalten sind -, und womöglich noch dazu im Link verborgene interne Informationen an diesen Server schicken ...

  Sicher ist anders.

• Natürlich lassen sich noch eine Reihe mehr Gründe finden als die genannten: sehr viel mehr sogar.

Noch schlimmer verhält es sich jedoch mit proprietären Mails, welche beim Empfänger voraussetzen, dass sie entweder ein bestimmtes Betriebssystem, Programm oder gar ein bestimmtes Office-Paket zur Abwicklung ihres Mailverkehrs einsetzen. Stellen Sie sich doch einmal vor, sie bekämen eine E-Mail in Form eines Word-Dokuments. Prinzipiell steckt dahinter die Überlegung, ein Word-Dokument unter Beibehaltung seiner ursprünglichen Textformatierung und seines Layouts zu verschicken, ungeachtet des verwendeten E-Mail-Clients auf seiten des Adressaten. Der Teufel steckt jedoch im Detail: niemals wird das E-Mail-Programm imstande sein, diese Mail tatsächlich intern zu öffnen, sondern es wird entweder jedes Mal auf installierte externe Software angewiesen bleiben, oder gar gänzlich aufgeben müssen, weil das zugrundeliegende Betriebssystem die benötigte Software gar nicht unterstützt. Selbst in Nur-Text-Mail lässt sich eine grundlegende Textformatierung und ein grundlegendes Layout realisieren, wobei gleichzeitig vermieden werden kann, die oft in Word-Dokumenten enthaltenen persönlichen Daten und anderen Informationen - meist ohne Wissen des Absenders - mitzuschicken.

Gegenargumente

Eine Reihe von Leuten hat Gegenargumente parat, die die Nutzung von HTML-E-Mail zu verteidigen suchen. Angeblich sind Nur-Text-Mails einfach zu beschränkt. Allerdings sind diese Argumente oft mit mangelnder Kenntnis dessen, was mit einfachem Text in E-Mails möglich ist und auch was in HTML nicht (ordentlich) erreicht werden kann:

• "Ich will meine E-Mails speziell formatieren / Sie sollen den wiedererkennbaren Stil meines Unternehmens zeigen.": Grundlegende Textformatierung ist auch mit Nur-Text möglich. Wenn Layout und Farben von größter Wichtigkeit sind, dann wird auch HTML nicht reichen, weil es beim Empfänger nicht zwangsläufig identisch dargestellt wird. Zum Beispiel könnten passende Schriftarten fehlen. In diesem Fall, z.B. för offizielle Dokumente, muss man auf plattformunabhängige Formate (z.B. RTF oder PDF) ausweichen, die als Anhang zu einer E-Mail verschickt werden können.
• "Ich brauche mein Unternehmenslogo im Fließtext.": E-Mail ist grundsätzlich ein textuelles Medium und das direkte Einbinden von Graphiken ist mit Problemen verbunden. HTML wird als "Lösung" dieser angesehen, aber nichts ist weniger wahr: Die Darstellung des Logos wird bei vielen Empfängern fehlschlagen, da es keinen Standardweg für HTML-E-Mail mit inbegriffenen Bildern gibt. Jedes Bild in einer E-Mail ist per Definition ein Anhang und der Weg, einen solchen Anhang in HTML zu adressieren, variiert von Programm zu Programm. So ist der Methode von Outlook, diese Bilder mit einem "cid"-Marker zu versehen, kein Erfolg bei anderen Programmen garantiert. Die andere Option wäre die Angabe einer Webadresse mit dem Bild, aber ein guter Teil von E-Mail-Programmen blockiert externe Bilder (hauptsächlich aus Sicherheitsgründen, wie oben angedeutet) und dies erfordert, dass ein Compute mit E-Mail-Programm auch unbeschränkten Zugang zum Internet (speziell WWW) hat. Von Letzterem kann man in Unernehmensumgebungen generell nicht ausgehen.
• "In Nur-Text-Mail kann man keine proportionalen Schriften verwenden.": Nutzung von text/plain sagt nichts zur Schriftart, die für die Anzeige genutzt wird. Die Wahl der Schrift ist Aufgabe des Anzeigeprogrammes. Oft ist eine Schrift mit fester Breite die Voreinstellung, aber das ist kein Zwang. Üblicherweise dient diese Voreinstellung zur einfacheren Erhaltung von Formatierungen, wie Pseudo-Tabellen, die durch Leerzeichen ausgerichtet werden.
• "Ich kann keine langen Zeilen verwenden, die dann passend zur Anzeige zu Absätzen umgebrochen werden/I muss 72 oder 78 Zeichen lange Zeilen mit festen Umbrüchen verwenden.": Obwohl RFC2822 genau festlegt, dass Zeilen in E-Mail 998 Zeichen nicht überschreiten dürfen und empfiehlt, sie unter 78 Zeichen zu halten, betrifft das nur den Rohzustand der E-Mail, wie sie versendet wird. Das ist keine echte Schranke, wenn man MIME verwendet, was generell zu empfehlen ist, weil es die Nutzung verschiedener Zeichensätze fü Text erlaubt (fü Akzente, Umlaute, nicht-lateinische Zeichen). Mit MIME gibt es verschiedene Inhaltskodierungen, die beliebig lange Zeilen erlauben (die beim Empfänger dann passend umgebrochen werden), als da wären quoted-printable oder gar Base64 für problematische Zeichensätze.
• "Ich bin gesetzlich verpflichtet, einen Signaturteil mit Unternehmensinformationen einzufügen.": Eine Unternehmenssignatur wird von jedem RFC-konformen E-Mailprogramm auch im einfachen Text unterstützt. Seit langem kommt dazu die Signaturmarkierung (zwei Bindestriche und ein Leerzeichen allein auf einer Zeile) zum Einsatz, die den normalen Text vom sog. Signaturblock trennt. Viele Programme schneiden diesen Block bei Zitaten automatisch ab, um den dort unnötigen Text zu vermeiden. Dies ist bei Signaturblöcken in HTML nicht möglich. Eine weitere übliche Praxis ist das Anhängen einer "vCard", was von fast allen Mailclients unterstützt wird. Tatsächlich kann oft die Information einer vCard mit einer Mausoperation ins Adressbuch eingetragen werden, erneut etwas, dass mit eigenmächtig HTML-formatierten Kontaktdaten nicht möglich ist. Es sei angemerkt, dass Netiquette in einem Signaturblock einfachen Text vorschreibt: Kein "rich text", HTML oder Bilder.

Was kann ich tun, um mitzuhelfen?

Danke der Nachfrage!
Folgendes können Sie tun:

• Zu allererst sollten Sie Ihren E-Mail-Client so konfigurieren, dass er nur Text-Nachrichten verschickt. Hier können Sie eine Anleitung für Netscape und Outlook Express herunterladen. Thunderbird: hier.
• Als zweiten Schritt können Sie ihre Bereitschaft zur Unterstützung der "ASCII Ribbon"-Kampagne signalisieren, indem Sie eine entsprechende Signatur anfügen. Zum Beispiel:

  ()  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

  
  Auf den unten verlinkten Seiten finden Sie noch mehr Vorschläge dazu.
• Drittens und letztens: erzählen Sie weiter, dass E-Mail seit seiner Entstehung ein rein textuelles Kommunikationsmittel gewesen ist und auch zukünftig sein sollte: genau dafür wurde E-Mail geschaffen, und ist dort über alle Maßen effizient! Die Verwendung von reinem Text schränkt Sie keineswegs in Ihren Möglichkeiten ein! Nach wie vor können Sie Anhänge und Bilder an Ihre Freunde und Bekannte verschicken; lediglich besteht der Unterschied, dass der eigentliche Inhalt Ihrer Nachricht in einem Format vorliegt, das auf jedem beliebigenComputersystem in korrekter Form angezeigt werden kann.

Verweise

Ohne die Menschen, die diese Kampagne gestartet haben, wäre diese Seite nicht realisierbar gewesen. Weiter unten wurden noch Links zu einigen (aber natürlich nicht allen) Seiten aufgenommen, die sich mit der Thematik dieser Kampagne befassen, ferner auch noch mehr Signaturvorschläge und mehr Hilfetexte. Wenn Sie den Eindruck haben, dass etwas äußerst Wichtiges noch fehlt, setzen Sie mich darüber bitte in Kenntnis.

the semi-official, semi-serious ascii ribbon campaign against gratuitous graphics on the web! (English)
ascii ribbon campaign (English)
7 reasons why html e-mail is evil (English)
no html mail (tot) (English)
losderover.be (tot) (Dutch)
ascii ribbon campaign (German)
ascii ribbon campaign (English)
ascii ribbon campaign (tot) (English)
Please, no MS Office documents (multi-lingual)
Rant against HTML mail (English, tot) [translated in German/auf Deutsch]
Put an end to Word attachments (English)

Kontakt

If you have additions, comments, complaints, you can drop me a line by using this contact form.

Translation by: Andreas Eibach, Thomas Orgis