Letzte Änderung: 21.10.98 von B. Tritsch
Stichworte:
Nachdem in den vorangehenden Kapiteln sehr viel über Protokolle und Dienste im Internet gesprochen wurde, kommen wir jetzt zu einer "echten" Anwendung. Denn wenn man jemanden fragt, was er jetzt gleich machen wird, so antwortet er wohl selten: "Ich gehe jetzt ein paar Rechnernamen im DNS nachschauen". Vielmehr wird die Antwort sein, daß Leute im "Web surfen" oder ihre Email lesen.
Architektur und Dienste
Electronic Mail oder kürzer Email ist inzwischen recht verbreitet. Es ist doch immerhin seit fast zwei Jahrzehnten in Gebrauch. Die ersten Email-Systeme bestanden einfach aus Dateitransfer-Protokollen mit der Konvention, daß die erste Zeile der Nachricht (Message) die Empfängeradresse enthielt. Mit der Zeit wurden jedoch Schwachstellen dieser Technik offensichtlich:
Aus diesen Gründen wurden mit der Zeit bessere Vorschläge für Email-Systeme gemacht. 1982 wurde der ARPANET Email-Vorschlag als RFCs veröffentlicht. Diese wurden seither de facto Internet-Standards. Zwei Jahre später wurde der CCITT-Standard X.400 verabschieded, der sich jedoch nie etablieren konnte.
Obwohl X.400 von einem offiziellen internationalen Standard, allen Telekombetrieben, vielen Regierungen und einem substantiellen Teil der Computer-Industrie unterstützt wurde, konnte eine handvoll Informatiker mit einem "Hack" ihr System weltweit durchsetzen. Dies lag weniger an der guten Qualität des ARPANET-Vorschlags als vielmehr an dem sehr schlechten und komplexen Design von X.400. Die Wahl zwischen einem einfachen und funktionierenden System gegenüber einem mächtigen aber nicht operablen System fiel der Netzwerkgemeinde nicht schwer.
Im folgenden soll ein Überblick über die Organisation von Email-Systemen gegeben werden. Sie bestehen normalerweise aus zwei Subsystemen: Der User Agent, der das Lesen und Verschicken von Email erlaubt und der Message Transfer Agent, der die Nachricht von Sender zu Empfänger bewegt. Der User Agent ist hierbei ein lokales Programm, das kommandobasierte, menübasierte oder graphische Methoden der Interaktion mit einem Email-System bereitstellt. Die Message Transfer Agents sind oftmals Hintergrundprozesse, die Email-Nachrichten durch das System transportieren.
Typischerweise unterstützen Email-Systeme fünf Basisfunktionalitäten, wie sie im folgenden beschrieben werden:
Die meisten Email-Systeme erlauben die Einrichtung von Mailboxen zum Abspeichern eintreffender Nachrichten. Hierzu werden Kommandos benötigt, die das Erzeugen und Löschen von Mailboxen, das Inspizieren des Inhalts sowie das Einfügen und Löschen einzelner Nachrichten betreffen.
Eine weitere Funktionalität, die oftmals gefordert wird, sind Mailing-Listen, die es erlauben eine Nachricht an eine ganze Gruppe von Benutzern zu schicken. Eine andere Option, die manchmal gewünscht wird, ist die Registrierung von Email. Damit erfährt der Absender, wann seine Nachricht beim Empfänger angekommen ist. Weitere Optionen sind Durchschläge, hoch priorisierte Email, sichere (verschlüsselte) Nachrichten, alternative Empfänger falls der erste nicht verfügbar ist und die Möglichkeit daß Sekretariate die Emails ihrer Chefs bearbeiten.
Ein Schlüsselkonzept moderner Email-Systeme ist die Unterscheidung zwischen dem Umschlag und dem Inhalt. Der Umschlag umschleßt den Inhalt und enthält alle Informationen, um den Inhalt zu transportieren. Der Message Transport Agent nutzt diese Informationen für die Auslieferung der Nachricht. Die Nachricht in einem Umschlag besteht zumeist aus zwei Teilen, den Kopf (Header) und den Körper (Body). Der Header enthält dabei Kontrollinformationen für den User Agent. Der Body ist ausschließlich für den menschlichen Benutzer gedacht.
Der User Agent
Der User Agent - auch Email Reader genannt - akzeptiert normalerweise eine Reihe von Kommandos für die Komposition, dem Empfang und die Beantwortung von Nachrichten sowie für die Manipulation von Mailboxen. Einige User Agents haben aufwendige Menü- oder Graphik-basierte Benutzerschnittstellen für die man eine Maus benötigt, während andere einfache Tastatureingaben erwarten. Funktional gesehen sind sie meist identisch.
Startet man einen Email Reader, so wird er typischerweise zuerst in die Eingangs-Mailbox (Incoming) des Benutzers schauen ob für ihn eine Nachricht angekommen ist. Dann wird er die Anzahl der eingetroffenen Nachrichten oder einzeilige Zusammenfassungen aller Nachrichten anzeigen. Weitere Angaben können dabei zusätzlich auf dem Bildschirm erscheinen: Die Nachricht ist neu, die Nachricht ist nicht neu wurde aber in der Mailbox belassen, auf die Nachricht wurde schon geantwortet, die Nachricht wurde an jemanden "geforwarded", usw.Weitere Angaben können die Größe der Nachricht in Bytes sein, der Absender und ein sogenanntes Subject. Das Subject-Feld ist eine Analogie zu der Betreff-Zeile in einem Brief und wird in Email-Readern zumeist als Zusammenfassung angezeigt. Daher ist es in Emails recht wichtig ein aussagekräftiges Subject zu formulieren.
Eine Sammlung häufig implementierter Kommandos auf einem Email Reader zeigt die folgende Liste:
Um eine Email abzuschicken, muß der Benutzer zunächst die Nachricht formulieren, die Zieladresse angeben und möglicherweise weitere Parameter zur Verfügung stellen. Insbesondere die Zieladresse muß in einem Format angegeben werden, die der User Agent versteht. Viele User Agents akzeptieren Email-Adressen in der Form mailbox@location, z.B. "tritsch@zgdv.de". Aber auch die X.400-Adressen lohnen einen Blick. Sie sehen viel anders aus als die Email-Adressen. Sie werden aus Attribut = Wert-Paaren gebildet:
/C=US/SP=MASSACHUSETTS/L=CAMBRIDGE/PA=360 MEMORIAL DR./CN=KEN SMITH/
Diese Adresse spezifiziert Land, Staat, Ort, persönliche Adresse und einen Namen. Viele andere Attribute sind möglich. Daher kann man eine Email an jemanden schicken, dessen Namen man nicht kennt, über den man aber viele andere Informationen besitzt. Typischerweise würde man jedoch zumeist Aliase (benutzerspezifische Kurzbezeichnungen) verwenden, auch bei den DNS-Adressen.
Nachrichtenformate
Wie schon weiter oben gesagt bestehen Emails aus einem primitven Umschlag, einigen Header-Feldern, einer leeren Zeile zur Abtrennung und einem Nachrichtenkörper. Jedes Header-Feld besteht aus einem ASCII-String, der einen Feldnamen, einen Doppelpunkt und einem Wert besteht. Die grundlegenden Header-Felder sind in der nachstehenden Tabelle aufgelistet:
| Header | Bedeutung |
|---|---|
| To: | Email-Adressen der primären Empfänger |
| Cc: | Email-Adressen weiterer Empfänger |
| Bcc: | Email-Adressen für Durchschläge |
| From: | Person, die die Nachricht erstellte |
| Sender: | Email-Adresse des Absenders |
| Received: | Eine Zeile wird hier von jedem Transfer Agent auf dem Weg zum Ziel hinzugefügt |
| Return-Path: | Kann genutzt werden um einen Weg zurück zum Absender zu identifizieren |
Tabelle 5.1: Standardisierte Header-Felder
Zusätzlich zu den Standardfeldern können noch eine Reihe von anderen Feldern genutzt werden. Die gebräuchlichsten listet die folgende Tabelle auf:
| Header | Bedeutung |
|---|---|
| Date: | Datum und Zeit wann die Nachricht abgeschickt wurde (mit Zeitzone) |
| Reply-To: | Email-Adresse an wen Antworten geschickt werden sollen |
| Message-Id: | Einzigartige Nummer, mit der die Nachricht später referenziert werden kann |
| In-Reply-To: | Message-Id der Nachricht zu der diese Nachricht eine Antwort ist |
| Reference: | Andere relevante Message-Ids |
| Keywords: | Benutzerspezifische Schlüsselworte |
| Subject: | Kurze Zusammenfassung der Nachricht (Betreff-Zeile) |
Tabelle 5.2: Zusätzlich Header-Felder
Nach dem Header kommt der Nachrichtenkörper. Ein Benutzer kann dort jedes gültige Zeichen hineinschreiben. Einige Leute beenden ihre Nachrichten mit einer Signatur mit Namen und Adresse, kleinen ASCII-Cartoons und Anmerkungen von sehr unterschiedlicher Phantasie und Wichtigkeit.
In den frühen Tagen von ARPANET beinhalteten Emails ausschließlich textuelle Nachrichten in Englisch und im ASCII-Standard. Heute beinhalten Nachrichten
Als Lösung für solche Nachrichten wurde die Multipurpose Internet Mail Extension (MIME) vorgeschlagen, die inzwischen weltweit genutzt wird. Grundsätzlich wird bei MIME eine Struktur zum Message-Körper hinzugefügt, die die Kodierungsregeln für Nicht-ASCII-Nachrichten definiert. Alles was dann noch getan werden muß, ist das absendende und das empfangende Programm zu ändern. Diese MIME-fähigen Programme kodieren/dekodieren alle Nicht-ASCII-Elemente in einer speziellen Art, daß sie auf ASCII-Basis übertragen werden können.
MIME-Elemente werden mit einem speziellen Header gekennzeichnet. Die gängigsten MIME-Typen zeigt die folgende Tabelle auf.
| Typ | Untertyp | Beschreibung |
|---|---|---|
| Text | Plain | Unformatierter Text |
| Text | Richtext | Text mit einfachen Formatierungskommandos |
| Image | Gif | Bild im GIF-Format |
| Image | Jpeg | Bild im JPEG-Format |
| Audio | Basic | Wiedergabefähiger Sound |
| Video | Mpeg | Video im MPEG-Format |
| Application | Octet-stream | Eine uninterpretierte Byte-Sequenz |
| Application | Postscript | Ein druckbares Dokument im Postscript-Format |
Tabelle 5.3: MIME-Typen und -Untertypen wie sie in RFC 1521 definert werden.
Nachrichtenübertragung
Im Internet wird eine Email von einer Quelle verschickt, indem die zugehörige Maschine eine TCP-Verbindung auf Port 25 zu einer Zielmaschine etabliert. An diesem Port lauscht auf der Empfängerseite ein Hintergrundprozeß (Daemon), der das Simple Mail Transfer Protocol (SMTP) versteht. Der Daemon akzeptiert eintreffende Verbindungen und kopiert Nachrichten zu ihren zugehörigen Mailboxen. Kann eine Nachricht nicht ausgeliefert werden, wird eine Fehlermeldung zurückgeschickt. SMTP ist ein einfaches ASCII-Protokoll. Nach Aufbau der TCP-Verbindung über Port 25 agiert die sendende Maschine als Client und die empfangende Maschine als Server. Die Größe der Nachricht sollte jedoch in vielen Fällen 64 kBytes nicht übersteigen. Der Server schickt die Nachricht mit Hilfe von DNS weiter, bis der engültige Empfänger erreicht ist.
Email über SMTP funktioniert am besten, wenn sich sowohl Sender als auch Empfänger auf dem Internet befinden und TCP-Verbindungen aufnehmen können. Jedoch sind nicht alle Maschinen, die Email schicken oder empfangen wollen, auf dem Internet. In diesem Falle existieren Email Gateways, die von einer Email-Konvention zur anderen übersetzen können, z.B. von SMTP nach X.400.
Bisher sind wir von der Situation ausgegangen, daß eine Maschine direkt aus dem Internet Email empfangen kann. Jedoch ist es in vielen Firmen die Email-Infrastruktur auf der Basis eines zentralen Email-Servers aufgebaut. Die Benutzer holen sich auf diesem Server mit Hilfe von Client-Rechnern ihre Emails ab.
Das gebräuchlichste Protokoll hierfür ist das Post Office Protocol 3 (POP3). Eine Client-Software mit diesem Protokoll hat Kommandos um sich beim Server einzuloggen, Nachrichten abzuholen und Nachrichten zu löschen. Das Protokoll selbst sieht dabei ähnlich wie SMTP aus. Die grundlegende Idee bei POP3 ist, daß alle Email-Nachrichten vom Server auf den Client kopiert werden und die lokalen Nachrichten dort verarbeitet werden.
Ein etwas weitergehendes und moderneres Protokoll ist das Interactive Mail Access Protocol (IMAP). Es wurde entwickelt, um mehrere Client-Rechner zu unterstützen zwischen denen sich der Benutzer bewegt. Daher ist die Grundidee von IMAP, die Email-Nachrichten immer an einem zentralen Ort vorzuhalten.
Spamming
Kaum ein Thema sorgt in letzter Zeit für soviel Gesprächsstoff in der Internet-Gemeinde wie die steigende Zahl unerwünschter Emails. "Werden Sie Millionär in 30 Tagen" oder " Bei uns bekommen Sie den besten Rechner des Universums" sind Botschaften, die zuhauf in den Mailboxen eintreffen.
Dieses sogenannte Spamming - benannt nach einem amerikanischen Büchsenfleisch zweifelhafter Qualität - geht inzwischen über das Ärgernis hinaus. Firmen verlieren beträchtliche Geldsummen durch Spamming-Angriffe auf den Email-Server. Internet-Provider müssen immer öfter Kundenbeschwerden wegen Spam-Mails bearbeiten. So sind dies beispielsweise bei Earthlink, Pasadena inzwischen 1000 bis 3000 Beschwerden pro Tag!
Bei einer Umfrage im Jahr 1997 sagten über 15% der Benutzer, daß sie sehr viel Spam-Mail erhalten, ca. 24% viel, ca. 28% wenig, ca. 20% wenige und nur ca. 12% keine. War vor noch nicht allzu langer Zeit die Antwort der Internet-Gemeinde auf Spamming das sogenannte Mail-Bombing, d.h. das Überfluten des Absenders mit Antworten, so wird dies immer schwieriger. Kommerzielle Spam-Versender nutzen spezielle Internet-Technologien, um ihre Absenderadresse zu verbergen.