Titelbild "HTML ist böse"

Vom Umgang mit der digitalen Post

Index

1/ Im Zeitalter des Kohlepapiers

Die Adressierung von eMails -- über Durchschläge und Blindkopien.

2/ Anhängsel

Attachments -- Wenn Daten und Dokumente mitversendet werden

3/ Regelwerke

Wie eMails automatisch sortiert werden können

4/ Hallo, ist da jemand?

Prompte Antwort als Zeichen von Professionalität

5/ Wer sind Sie?

Signaturen -- Ihre Visitenkarte via eMail

6/ eMail <> Web

HTML-eMails -- Wieso sie von Übel sind

7/ Es geht auch ohne

Formatierung in eMails -- Wie man auch ohne HTML-Befehle seine eMails formatieren und strukturieren kann

8/ Gefährliche Briefe

Viren und Hoaxes -- eMails als echte und falsche Sicherheitsrisiken

9/ Links

Dieser Artikel ist in Ausgabe 9/01 der Screen-Business-Online bzw. Woche 33-34/2001 der <e>MARKET erschienen. Da mir die redigierte Version des Artikels nicht digital vorliegt, ist im folgenden die nicht-redigierte und ungekürzte Fassung zu lesen. Der Artikel basiert auf einen von mir im Frühjahr 2001 verfassten Text "HTML ist böse", der wiederum entstanden ist nachdem verschiedene Internet/NewMedia-Agenturen plötzlich anfingen mir HTML-eMails zuzuschicken.

Update 020518: Da der Artikel ursprünglich für die <e>MARKET und ihre Zielgruppe, von mir als sog. "Krawattenträgern" bezeichnet, gedacht war, und nicht für Geeks oder Hardcore-Internet-Usern, zeichnet der Artikel schwarz-weiss. Der Artikel verzichtet bewußt auf Zwischentöne um die Message bei der Zielgruppe durchzubringen.

eMails gehören für viele Menschen zu wichtigen Werkzeugen. Umso erstaunlicher ist es, wie wenig bekannt selbst Essentielles ist.

Die Verwendung von HTML-eMails mag man anfänglich noch als bloßen Verstoß gegen die "Netiquette" ansehen können. Dank stärkerer Integration der eMail-Programme in die Betriebsysteme einerseits und andererseits dank hanebüchener Sorglosigkeit von Seiten der Benutzer sind sie aber zu einem Sicherheitsrisiko geworden.

Eine Petitesse führt mich zu so einer Beschreibung. Eine Petitesse namens HTML-eMails. HTML-eMails, die ich kurioserweise in den letzten Wochen von verschiedenen Leuten unabhängig voneinander bekommen habe.

Im Zeitalter des Kohlepapiers

Für die meisten Benutzer eine simple Angelegenheit: Wenn man eine eMail verschickt, trägt man den oder die Empfänger in das "An"-Feld ein, und fertig.

Doch die Spreu trennt sich vom Weizen bereits im Feld darunter, das mit "CC" oder "Kopie" beschriftet ist. "CC" ist die Abkürzung für "Carbon Copy" und bedeutet Kohlepapier, bzw. Durchschlag. Hier können weitere Adressaten eingetragen werden, die Kopien der eMail zugeschickt bekommen. Man kann mit CC einen Durchschlag der Mail an seinen Chef schicken, um ihn auf dem Laufenden bei einem Projekt zu halten.

Kaum bekannt ist das dritte Feld in der Adressierung: "BCC" -- "Blind Carbon Copy" (bzw. "Blindkopie"). Ähnlich wie bei "CC" wird auch hier an Adressaten eine Kopie der eMail verschickt. Während bei "CC" zu erkennen ist, wer alles Empfänger eines "Durchschlages" ist, sind die Empfänger eines "BCC" nicht zu erkennen. Wenn Sie einen Rundbrief an Kunden verschicken wollen, kann es zweckmäßig sein, dass nicht zu erkennen ist, wer alles zum Kundenkreis gehört.

Adressfeld in einer eMail
Abb1: Die drei Adressfelder

Anhängsel

eMails erlauben es in der Regel "Attachments" bzw. "Anhänge" oder "Anlagen" zu versenden. Es handelt sich dabei um Dateien, die an die eMail angehängt werden, egal ob Bilder, Word-Dokumente oder Photoshop-Dateien. Das Verschicken von Anhängen ist aber mit verschiedenen Problemen behaftet. Das fängt mit technischen Problemen an.

Die Buchstaben in einem Text sind im Computer-Speicher in Form von Zahlencodes von 0 bis 255 abgespeichert. Das große "A" hat z.B. die Codezahl 65. Andere Dateien wie Grafiken oder Programme enthalten zwar keinen Text, aber ihre Daten oder Programmcodes sind ebenfalls in Form von Zahlencodes von 0 bis 255 abgelegt. Wenn man solche Dateien mit eMails verschickt, wird eine wirre Folge von Buchstaben und Zeichen versendet, sozusagen die "textliche Interpretation" der Daten.

Die Probleme fangen aber damit an, dass international nur die Umwandlung von Text in Zahlen und umgekehrt zwischen den Codezahlen 0 und 128 festgelegt ist. In dem anderen Bereich hat jede Region ihre eigenen Umlaute, jedes Betriebssystem seine eigenen Sonderzeichen eingebaut. Und ein Teil der für die Weiterleitung von eMails zuständigen Software lässt gar nur diesen standardisierten Code-Bereich durch. Man kann sich vorstellen, was das bedeutet, wenn ein eMail-Programm versucht, aus dem empfangenen Buchstabensalat wieder eine Grafik zu erzeugen. Also müssen Anlagen vor dem Versenden durch das eMail-Programm so konvertiert werden, dass wirklich nur Zeichen aus dem standardisierten Bereich versandt werden.

Sie ahnen es: Für dieses Umwandeln wiederum gibt es verschiedene Standards und so kann es sein, dass Ihr Gegenüber die Anhängsel nicht aus der eMail extrahieren kann. Am weitesten verbreitet ist "MIME" als Übertragungs- und Umwandlungsstandard für eMails und ihre Anlagen. Wenn Sie Probleme beim Versenden von Anlagen haben, schauen Sie in Ihren Voreinstellungen nach.

Komprimierungseinstellungen
Abb2: Voreinstellung für die Kodierung von Anhängen

Langes Rätselraten oder Suchen bei Ihrem eMail-Kontakt können Sie vermeiden, indem Sie in der eMail ausdrücklich das Dateiformat der Anlage erwähnen und dem Dateinamen des Dokumentes auch die adäquaten Drei-Buchstaben-Kürzel geben, die die Zuordnung des Dokumentes zu dem zu öffnenden Programm erleichtern.

Wenn der Adressat nichts mit dem Anhang anfangen kann, könnte es aber auch daran liegen, dass er kein Programm besitzt, mit dem er das Dokument öffnen könnte. Selbst bei vermeintlich weit verbreiteten Programmen sollten Sie im Zweifel mit Ihrem Gegenüber über ein Dateiformat verständigen. Nicht jeder besitzt die allerletzte Version von Microsoft Word.

Wenn Sie Anlagen verschicken, überprüfen Sie, ob Sie das Dokument komprimieren können, damit die zu übertragende Datenmenge nicht ganz so groß ausfällt. Kleinster gemeinsamer Nenner bei Kompressionsformaten ist dabei das ZIP-Format. Programme zum Komprimieren und Dekomprimieren in oder von ZIP-Dateien gibt es für nahezu jede Plattform.

Die stärkste Kompression von Anlagen geschieht aber immer noch durch das Nicht-Verschicken von Anlagen. Überlegen Sie zweimal, ob Sie die Datei wirklich versenden müssen. Korrekturlisten müssen nicht in Word geschrieben werden, sondern können gleich als Text in die eMail reingeschrieben werden. HTML-Seiten müssen nicht mitgeschickt werden, die URL der Seite reicht völlig aus. Bei vielen eMail-Programmen wird eine URL als anklickbarer Link ausgegeben, wenn sie eine gewisse Nomenklatur einhält. Schreiben Sie die volle URL, also mit dem "http://"-Prefix, und klammern Sie die URL in "Größer"- und "Kleiner"-Zeichen ein: <http://web.siliconvalley.com/content/sv/opinion/dgillmor/weblog/>.

Ein weiterer Grund, weswegen Sie vorsichtig sein sollten, was Sie da verschicken, sind die Tücken die in den Dokumenten lauern. Word-Dokumente sind ein besonderes Beispiel, da die Dokumente viele Informationen enthalten, die nicht auf dem ersten Blick sichtbar sind. Das musste z.B. Alcatel schmerzhaft erfahren. Anfang April 2001 wurde eine Pressemitteilung über die Rückrufaktion eines DSL-Modems per Word-Dokument verbreitet. Wer in Word den Menüpunkt "Änderungen nachverfolgen" anwählte, konnte die ursprüngliche Fassung des Textes und die einzelnen Korrekturschritte nachverfolgen. Wenig schmeichelhaft für Alcatel [3] und eine Warnung gegen das blinde Versenden von Dateien.

Alcatel Presseerklärung in Word
Abb3: Von Alcatel als Word-Dokument veröffentlichter Text

Regelwerke

Spätestens, wenn Sie am Telefon das erste Mal die Aussage fällen müssen: "Moment, die eMail finde ich gleich ... gleich habe ich sie ... Moment, bleiben Sie dran", wissen Sie, dass es Zeit ist, sich um die Verwaltung Ihrer eMails zu kümmern.

EMail-Programme bietet mannigfaltige Möglichkeiten eingetroffene Mails zu strukturieren. Das fängt mit dem Einsortieren in Ordnern an. Die Programme erlauben es, neben dem "Eingangskorb" oder "Posteingang" weitere Ordner im Programm einzurichten. Diese Ordner können Sie nach Kunden, Mailinglisten oder Newsletter benennen, und die eMails in diesen Ordnern ablegen.

Beispiel Ordnerstruktur
Abb4: Übersicht über die Ordner-Struktur meines eMail-Programmes

Oder ablegen lassen. Nahezu alle eMail-Programme erlauben, eintreffende eMails zu bearbeiten. Diese können je nach Absender in Ihre Kundenordner verschoben werden. Bei einem wichtigen Kunden können Sie ein Tonsignal abspielen oder die Betreffzeile rot einfärben lassen.

Das Anlegen von Regeln folgt meistens demselbem Prinzip: Sie legen zuerst in einem "Mail-Filter" die Kriterien fest: "Wenn die eMail diese und diese Kriterien erfüllt ...". Die Kriterien sind mannigfaltig und unterscheiden sich von eMail-Programm zu Programm. Aber alle kennen als Minimum die Kriterien "Absender" oder "Betreff-Zeile". Der zweite Teil einer Regel besteht aus dem auszuführenden Vorgang: "Wenn die Kriterien erfüllt sind, dann tue mit der eMail das und das". Am häufigsten dürften Sie wohl die eMail je nach Absender in bestimmte Verzeichnisse verschieben wollen oder per Ton- oder Farbinformation von dem Eintreffen einer bestimmten eMail unterrichtet werden, oder bei bestimmten eMails eine Kopie an einen Kollegen schicken wollen.

eMail-Regeln inOutlook 5/Mac
Abb5: Erstellen von Regeln In Outlook für Mac

Unbeliebte Urlauber!

Wenn Sie in den Urlaub gehen, könnten Sie auf die pfiffige Idee kommen, jede eintreffende eMail per Regel mit einem "Ich bin vom 1.6. bis 2.7. in den USA im Urlaub" zu beantworten. Einige eMail-Programme bieten so etwas als Extra-Funktion unter dem Begriff "Auto-Responder" an. Achten Sie bitte darauf, auf welche eMails Sie den Auto-Responder oder die Regel anwenden! Wenn Sie Mitglied einer Mailingliste sind, müssen Sie damit rechnen, nach Ihrem Urlaub in Ihrer Mailbox einen Haufen unflätiger eMails vorzufinden und aus der Mailingliste ausgeschlossen worden zu sein. Denn jede von der Mailingliste ausgesandte eMail wurde von Ihnen mailinglisten-weit mit Ihrem Urlaubsspruch beantwortet. Bei einer Mailingliste mit einem Aufkommen von täglich 50 eMails haben Sie also die Abonnenten fünfzig Mal mit Ihrer Abwesenheitsnachricht beglückt. Keine "List-Mom" lässt sich so was bieten, sie wird Sie unverzüglich aus der Liste ausschließen.

Hallo, ist da jemand?

Urlaub oder sonstige Abwesenheit ist die einzige Entschuldigung, weswegen auf eine eMail nicht unverzüglich mit einer Antwort reagiert werden kann. Sinn und Zweck der elektronischen Post ist die schnelle Kommunikation. Wenn Sie tagelang mit der Beantwortung einer Kundenanfrage warten, können Sie die Antwort gleich per Postkutsche oder Pony-Express verschicken ... Reagieren Sie deswegen unverzüglich auf eMail-Anfragen, und sei es auch nur mit einer Bestätigung, dass die eMail angekommen ist und derzeit bearbeitet wird. Es verschlägt einem die Schrift zu sehen wie diese Grundregel der eMail-Kommunikation selbst von renommiertesten Konzenern nicht eingehalten wird.

Die Antwort auf eine Kundenanfrage ist der erste Kontakt des Kunden mit Ihnen und daher ist die eMail Ihre Visitenkarte. Sorgen Sie dafür, dass der erste Eindruck beim Kunden positiv ist und für Ihre Professionalität spricht.

Wer sind Sie?

Im geschäftlichen Verkehr ist es sinnvoll, jeder eMail Kontaktinformationen beizulegen: Name, Position, Firma, Adresse, Festnetz-, Fax- und Mobilfunknummer. Dies kann man per Hand am Ende einer eMail eintragen. Viel praktischer hingegen ist das automatische Einfügen dieser Informationen durch das eMail-Programm selber. Diese Informationen nennen sich "Signatur". Die eMail-Clients erlauben es, entweder im Programm selber die Signatur anzulegen oder eine einfache, kleine Textdatei anzugeben, aus der die Signatur jedes Mal ausgelesen und in die Mail eingefügt wird.

Aber auch hier gilt: Man sollte es nicht übertreiben und ganze Romane in der Signatur anlegen. Leider sind einige Unternehmen dazu übergegangen, ganze "Disclaimer" in die Signatur zu packen.

Etwas übertriebene Signatur
Abb6: Langer Disclaimer einer Consulting-Agentur

eMail <> Web

Zu den immer stärker um sich greifenden Unsitten zählt das Versenden von HTML-formatierten eMails.

Der Ausdruck bezeichnet schon, worum es sich handelt: eine eMail, die HTML-Code besitzt und daher mit Formatierungsmöglichkeiten ähnlich einer Webseite aufwarten kann. Man kann Texte fett auszeichnen, Schriftart und Farbe auswählen und Bilder einbauen. Sie schreiben und gestalten den Text, das eMail-Programm erzeugt den HTML-Code und verschickt ihn an den Empfänger, der wiederum den HTML-Code auswertet und im eMail-Client anzeigt.

Inzwischen sind leider einige Softwareproduzenten dazu übergegangen, ihre eMail-Clients voreingestellt HTML-eMails versenden zu lassen, so dass unbedarfte Benutzer sich wundern, wenn sie von übellaunigen Gesellen wie dem Schreiberling dieser Zeilen angepflaumt werden. "Wieso, ich habe doch nichts gemacht, ich benütze die normalen Voreinstellungen?"

Sie haben es gemerkt: Den HTML-eMails schwingt ein gewisser Haut-Gout mit. Und Sie werden sich vielleicht fragen wieso, ist doch die Möglichkeit eMails zu "gestalten" doch ganz nützlich?

HTML-eMails bergen so viele Probleme in sich, dass sie als Verstoß gegen die "Netiquette" [4], [5] gelten und man pauschal von der Benutzung abraten muss. Rollen wir die Probleme auf.

Ineffizienz: Der Vorteil von eMails ist die "Kommunikation pur". Es werden nur die notwendigsten Daten übertragen, keine Formatierungs-Anweisungen, kein HTML-Code. Alles reduziert sich auf die Information. Daher bleibt die zu übertragende Datenmenge klein, und darüber freut sich der Laie mit seinem 56k-Modem genauso wie der Hardcore-User, der viele Mailinglisten abonniert hat und über 500 eMails pro Tag bekommt.

Zudem verbraucht die Anzeige Systemresourcen. Bei komplexeren HTML-eMails schnappt sich Microsofts Outlook Express 5 auf meinem Mac plötzlich 10MB mehr RAM. Wenn mein Rechner durch andere geöffnete Programme bereits ausgelastet ist, quittiert mein Mac den Speicherverbrauch mit einem Absturz. Sie können sich vorstellen, mit welcher verkaufsfördernden Laune ich dann anschließend die Angebote in der HTML-eMail eines Computerhändlers lese ...

HTML? Was für ein HTML-Standard? Es gibt ihn nicht. Es gibt keinen HTML-Standard für eMails. Und so kommt es, dass die eMail-Programme unterschiedliche Teilmengen von HTML-Befehlen unterstützen. Wenn überhaupt. Mit anderen Worten: Ohne Absprache mit Ihrem eMail-Kontakt wissen Sie nicht, wie Ihre eMail auf der anderen Seite der Leitung ankommen. Bei geschäftlichen Kontakten spielen Sie mit dem Feuer.

Teure eMail: HTML-eMails sind so was wie "verschickte Webseiten". Folgerichtig können diese auch Bilder enthalten. Diese Bilder müssen aber nicht mitgeschickt werden, vielmehr können diese über ein Link in die eMail integriert sein. Wenn nun die eMail gelesen wird, bauen die meisten eMail-Programme automatisch eine Verbindung zum Internet auf und laden das Bild in den Speicher.

Die Kosten für den Aufbau der Internetleitung hat natürlich nicht der Absender zu zahlen, sondern Sie. Und zwar jedes Mal wenn Sie die eMail betrachten.

Spammers Freund: Die obige Argumentation lässt sich fortführen. "Spammer" sind Damen und Herren, die unaufgefordert Werbe-eMails für potenzfördernde blaue Pillen oder Geschäftsbeteiligungen in Nigeria preisen. Spammer lechzen nach eMail-Adressen und scannen unaufhörlich das Web nach diesem wertvollen Gut.

Eine Methode verschickt einfach mal auf Verdacht eMails an verschiedene Adressaten einer Domain: info@meier.de, webmaster@meier.de, help@meier.de, st@meier.de, stefan@meier.de, stefan.meier@meier.de usw. ...

Der Spammer muss nun rausbekommen, hinter welchen dieser generierten Adressen ein echter Mensch aus Fleisch und Blut sitzt. Zwar werden eMails bei nicht gefundenen Adressaten vom Server als unzustellbar zurückgeschickt. Da aber die Spammer wegen der Illegalität ihres Tuns ihren Absender fälschen, bekommen sie diese sogenannten "gebounceten" ("zurückgesprungenen") eMails nicht.

Stattdessen wird in eine HTML-eMail ein Link zu einem kleinen, 1x1 Pixel großen, Bild integriert. Wenn nun Herr Meier ahnungslos seine eMail liest, wird dieses Bild aus dem Internet geladen, und im Logfile des Servers des Spammers steht nun ein feinsäuberlicher Eintrag, wer welches Bild geladen hat. Herr Meier hat damit, ohne es zu wissen, seine Adresse für die weitere Bombardierung von eMail-Werbung freigeschaltet.

Crackers Freund: Und die Integration von HTML-Elementen in einer eMail führt gleich zu einer dritten Schwachstelle, dem Sicherheitsrisiko. Wie normale HTML-Seiten können auch HTML-eMails Script-Objekte, beispielsweise JavaScript-Code, enthalten, die, zum Teil in Kombination mit Plug-Ins, Schaden auf Ihrem Rechner anrichten oder Dateien auslesen können. So ist es z.B. möglich, mit einem eingebauten <OBJECT>-HTML-Befehl bei installiertem Office-Paket unbemerkt Dateien auf dem Rechner zu installieren [2].

Outing als Laie! Die oben aufgeführten Punkte machen deutlich, wieso HTML-eMails unter den Internet-Profis einen schlechten Ruf genießen und als Verstoß gegen die unausgesprochene "Netiquette" gelten. Im Umkehrschluss bedeutet das, dass es auf Sie zurückfällt, wenn Sie dennoch eine solche Mail versenden. Sie müssen es sich gefallen lassen, dass an Ihrer Internet-Kompetenz gezweifelt wird.

Ich muss draußen bleiben! Da einerseits das Ausnutzen von Sicherheitslücken via HTML-eMails immer stärker um sich greift, und andererseits immer mehr unbedarfte Benutzer ihre Voreinstellungen im eMail-Programm nicht verändern und nicht-wissentlich HTML-eMails versenden, greifen viele Betreiber von Mailinglisten zu radikalen Mitteln und verbannen HTML-eMails aus ihren Mailinglisten. Administratoren von Firewalls und eMail-Server blocken HTML-eMails ab. Mit HTML-eMails haben Sie also gute Chancen, ungelesen in dem virtuellen Internet-Lokus zu landen.

Update 020602: Dieser Abschnitt ist bzgl. der Verwendung von HTML für eMails weiter unten im Artikel ergänzt worden.

Advocatus Diaboli

Über eine Seite lang habe ich Ihnen eingepaukt, dass die Benutzung von HTML-eMails schlecht ist. Natürlich mus man das HTML-eMail-Verbot nicht so ideologisch sehen. Es sind sehr wohl Umstände denkbar, in der eine nach bestimmten Gesichtspunkten formatierte HTML-eMail die Kommunikation erleichtert. Die oben aufgeführte Argumentation hat aber die Schwachstellen deutlich gemacht. Bevor Sie mit Ihrem Gegenüber "in HTML parlieren", sprechen Sie sich mit ihm ab. Probieren Sie mit Ihrem Partner aus, was alles an Formatierungen machbar ist. Wenn Sie vorhaben, Rundbriefe oder Newsletter im HTML-Format an Ihre Kunden zu schicken, fragen Sie diese bitte vorher, schicken Sie nie unaufgefordert HTML-eMails. Idealerweise produzieren Sie zwei Versionen Ihres Newsletters für Kunden, die auf eine Textversion bestehen.

Es geht auch ohne

So verlockend es sein mag, bunte eMails zu versenden: Nahezu immer geht es eigentlich auch ohne Schnickschnack. Im Laufe der Jahre hat sich eine eigene Formatierungssprache herausgebildet.

Wenn Sie Wörter hervorheben wollen, setzen Sie das Wort in GROSSBUCHSTABEN, *markieren* es mit Sternchen ("*") oder Rauten ("#"). Das Setzen in Großbuchstaben wird als "lauter sprechen" angesehen. Sie müssen daher aufpassen: wenn Sie in Ihren eMails viele Wörter in Versalien schreiben, bekommen Sie den Ruf eines "Schreihalses", pardon, "SCHREIHALSES".

Umgekehrt müssen Sie beim Einsetzen von bestimmten Zeichen Vorsicht walten lassen. Das Internet ist vor allem eine Entwicklung angloamerikanischer Kreise, die wenig Rücksicht auf Sonderzeichen wie z.B. deutsche Umlaute haben walten lassen. Beim Einsatz von Umlauten in eMails kann es passieren, dass diese zu unleserlichen Zeichen bei Ihrem Gegenüber mutieren. Durch die Entwicklung des MIME-Standards sollte die Problematik aber selten auftauchen.

Erleichtern Sie das Lesen von eMails am Bildschirm indem Sie immer in kleinen Absätzen schreiben und die Absätze durch Leerzeilen trennen.

Im beruflichen Umgang werden eMails häufig archiviert oder bleiben lange zum Nachschlagen in den eMail-Ordnern. Erleichtern Sie Ihren Partnern das Nachschlagen durch aussagekräftige Betreffzeilen. Nach spätestens drei Monaten wird Ihnen der Titel "Wg. Test" nichts mehr sagen.

eMails verführen dazu "schnell mal was zu schreiben" und abzuschicken. Denken Sie daran, dass das Abschicken unwideruflich ist. Es braucht schon eine glückliche Netzwerk-Architektur, damit Sie im Notfall schnell zu Ihrem eMail-Server rennen können und eine geschäftsschädigende eMail durch beherzten Griff zum Netzschalter stoppen können.

Machen Sie sich Gedanken über die Anrede. Zu Beginn wird man bei Geschäftskontakten mit dem auch aus dem Briefverkehr bekannten "Sehr geehrter Herr Meier" anfangen. Im Laufe der Zeit schleift sich selbst bei seriösesten Geschäftspartnern ein "Hallo Herr Meier!" ein.

Diese Lässigkeit in Sachen Anrede soll aber nicht darüber hinwegtäuschen, dass sie gut daran täten bei Rechtschreibung, Grammatik und Formulierungen einen Mindeststandard beizubehalten. Die Schnelligkeit, mit der eine eMail geschrieben ist, verführt zur einer gewissen "Luschigkeit", die zu falschen Rückschlüssen auf Ihre Professionalität führen könnte. Hier ein Wechstabenverbuchsler, dort ein Wechsel der Satzkonstruktion, der führt zu einer Sinnleere des Satzes führen tut.

Wir haben die eMail vor allem aus beruflicher Sicht betrachtet. Im Umgang mit Freunden oder gleichgesinnten Kollegen ist es durchaus üblich, dass die Großschreibung zu Hause gelassen wird und sich auch sonst ein laxer Umgang mit eMails einschleicht. Bei einem solchen Dialog ist man bestrebt Schreibarbeit zu vermeiden. Im Laufe der Zeit haben sich daher einige Vereinfachungen entwickelt.

Um mit wenigen Buchstaben Sachverhalte auf den Punkt zu bringen, kann man "Akronyme" verwenden. Dabei handelt es sich um Abkürzungen von Formulierungen vor allem aus dem englischen Sprachraum, wiewohl das "CU" ("See you", "Bis später") oder "BTW" ("By the way", "Übrigens") es auch bis in deutsche eMails hinein geschafft haben.

Was der schriftlichen Kommunikation, gegenüber der visuellen oder akustischen, abgeht, sind Gefühlsregungen. Insbesondere Ironie ist ein zweischneidiges Schwert, wenn nicht sichergestellt wird, dass die Bezeichnung "Trottel" nur ein Spaß war. Wer sicher gehen will, kann daher mit "Emoticons" arbeiten. Das sind kleine Gesichter, die aus Buchstaben und Satzzeichen zusammengesetzt werden. Um die "Emoticons" zu "lesen", muss man dazu den Kopf nach links neigen. Und so wird aus :-) ein "Smiley" mit Augen, Nase und Lächeln.

Im Rahmen eines eMail-Dialoges ist es sinnvoll, aus vorgehenden eMails zu zitieren, damit der Empfänger weiß, auf was, bzw. welche eMail-Passagen Sie sich beziehen.

Wenn man auf eine eMail durch Klicken auf den Antwort-Button reagiert, wird normalerweise die gesamte eMail in die Antwort kopiert, und durch sog. "Zitierzeichen" ergänzt. Als Quasi-Standard hat sich das "Größer"-Zeichen ">" als Zitierzeichen eingebürgert. Die zitierte eMail bekommt einen festen Umbruch und am Zeilenanfang jeweils ein ">". Die eMail-Clients färben solche Zitate zur Hervorhebung eigenständig ein. Wohlgemerkt: die Farbe ist nur im Programm, nicht in der eMail vorhanden, das hat also nichts mit HTML-eMail zu tun.

Im Laufe eines Dialoges rutschen die Zitate immer eine Ebene tiefer und bekommen als Zitat des Zitats ein ">"-Zeichen mehr und eine andere Farbe verpasst.

Screenshot einer zitatenreichen eMail
Abb7: Beispiel-eMail mit verschachtelten Zitat-Ebenen

eMail-Programme gehen aber in der Regel ziemlich plump heran und zitieren die ganze Nachricht, selbst wenn Sie sich nur einen kleinen Teil beziehen. Wenn dann Ihr Gegenüber auch noch jeweils die kompletten eMails zitiert, haben Sie sich bald ein eMail-Monster erschaffen, dass nur noch träge aus den Internetleitungen tropft. Gewöhnen Sie es sich deshalb an, nur die notwendigen Passagen beizubehalten und den Rest zu löschen.

Am praktischsten ist es, wenn Sie zum Antworten auf den Antwort-Button klicken, irgendwelche durch das eMail-Programm eingefügten Präfixe löschen, mit Ihrer Anrede beginnen, und dann ihre Antwort an den passenden Stellen des Zitates einfügen. Fügen Sie vor und hinter ihren Antworten eine Leerzeile ein, streichen Sie die Absätze des Zitates die Sie zum Kontext Ihrer Antwort nicht brauchen. So bleibt Ihre Antwort verständlich, da der Bezug zur alten eMail erhalten geblieben ist, und Ihre eMail bleibt durch das Löschen überflüssiger Passagen schlank.

Gefährliche Briefe

Immer häufiger gehen Warnungen vor eMail-Viren durch die Medien. Um es ganz klar zu sagen: Wer eine reine Text-eMail bekommt, riskiert nichts. Die Virengefahr geht von HTML-eMails und Anhängseln aus. Auch hier gilt: Das eigentliche Sicherheitsrisiko sitzt zwischen Tastatur und Stuhl. Jede Software ist nur so sicher wie ihr Benutzer. Und wenn der User glaubt, er müsse ein Anhängsel unbekannter Herkunft öffnen, dann ist es ein klarer Fall von "Selbst Schuld"!

Es gibt drei Kategorien von Viren. Weiter oben sind wir bereits auf die Risiken der eMail selber zu sprechen gekommen. HTML-eMails können Scripte beherbergen und auf Ihrem Rechner ausführen.

Die zweite potentielle Gefahr geht von den Anhängen aus. Die mit eMails verschickten Dateien können entweder selber virenverseucht sein, wie z.B. Macro-Viren bei Office-Dokumente, oder selber ein Virus sein. Was für Sie auf den ersten Blick im Anhang wie eine Nacktaufnahme von Anna Kournikova aussieht, kann ein gefährliches Programm oder Skript sein, das nur darauf wartet, von Ihnen angeklickt zu werden und sein schädliches Tun zu starten.

Minimieren Sie die Risiken. Seien Sie skeptisch gegenüber jeder eMail, die unbekannter Herkunft ist oder die Sie nicht erwarten. Seien Sie skeptisch, wenn eine eMail bestimmte Schlagworte enthält, die Sie zum Öffnen der Mail animieren soll. Insbesondere, wenn es sich um eine Nacktaufnahme von Anna Kournikova handelt!

Abschließend soll noch die Rede von einer dritten Kategorie Viren sein. Sie vernichtet keine Daten, sondern nur Arbeitszeit: "Hoaxes" und Virenwarnungen. "Hoaxes" sind "falsche" Nachrichten. Immer wieder gibt es Warnungen, die behaupten, dass das bloße Öffnen einer reinen Text-eMail bereits zum Löschen der Festplatte führt, oder eine SMS auf dem Handy zur Vernichtung desselbigen führen kann. Zu dieser Gattung gehören auch Meldungen, dass Nokia Handys verschenkt, oder Ketten-eMails. Gegen solche "Informations-Viren" hilft kein Anti-Viren-Programm, sondern nur Information wie z.B. hoax-info.de [6]. Auch die Virenwarnungen selber arten in Viren aus, wie ich anlässlich des "Homepage"-Virus feststellen konnte. Virus: 0. Warnungen vor dem Virus: 8 eMails und 1 Telefonat. In Anspielung auf ein Zen-Sprichwort: Die Nachricht ist der Virus.

Update 020602: Im Mai 2002 hatte ich via eMail eine Diskussion mit Ben Buksch über die Verwendung von HTML in eMails.
Zwei Absätze weiter oben erwähne ich, dass Administratoren mitunter HTML-eMails wegen des potentiellen Sicherheitsrisiko abblocken. Ben weist mich zurecht darauf hin, dass eine solche Verfahrensweise unbedingt vorher bekanntgegeben muss. Auf der Website des Bundesbeauftragen für Datenschutz gibt es ein PDF-Dokument des "Arbeitskreises Medien" für öffentliche Stellen bei Bund und Land. [7].
Dort heißt es, dass aus "Gründen der Datensicherheit" E-Mails oder deren Anhänge unterdrückt werden dürfen, wenn diese ein Format aufweisen, das ausführbaren Code enthalten kann (als Beispiel wird HTML aufgeführt), und zwar sowohl bei beruflichen als auch privaten eMails.
Allerdings wird ausdrücklich daraufhingewiesen, dass die Mitarbeiter vorher über diese Verfahrensweise zu unterrichten sind, und über jede unterdrückte eMail benachrichtigt werden müssen.
Bei einem zweiten Diskussionspunkt sind wir uns nicht ganz einig geworden, inwieweit nämlich HTML der Weg ist, den eMails bestreiten sollten.
Bens Ansicht nach besitzen eMails bzgl. der Darstellungen derzeit zu viele ungelöste Probleme: Sonderzeichen, Umbrüche, Links auf Webseiten, Darstellung von Zitaten. Diese Probleme sind sowohl auf unzureichende Definition der Standards als auch mangelhafte Implementation der eMail-Programme zurückzuführen.
Es gibt zwei Wege aus der Misere: die jetzigen Standards nehmen, um teilweise bereits bestehende Vorschläge (z.B. RFC 2646 bzgl. Umbrüche) ergänzen oder aber gleich den Weg von HTML einschlagen, in dem alle Probleme gleich mit einem Standard "erschlagen" werden.
Bei beiden Wegen wäre es Grundvoraussetzung, das neue, sich wirklich an Standards haltende eMail-Programme produziert werden. Mit HTML gewänne man aber Flexibilität und würde eMail eine Dokumentenstruktur geben, die maschinell weiterverarbeitet werden könnte.
Es sei aber an dieser Stelle ausdrücklich betont, dass es sich dabei ausschließlich um Zukunftsszenarien handelt. Ich würde derzeit immer noch grundsätzlich von der Verwendung von HTML in eMails abraten.
Update 021019: Ich bedanke mich bei Frau Maren Giering-Desler für das Korrekturlesen.

 

<<= Brain-Indexseite

 

Kai Logo