Wirbelwind

Elektronische Post im Internet

Wissen | Know-how

Wer eine Brieffreundschaft mit Übersee pflegt, muß nicht mehr warten, bis Schiff oder Flugzeug die ersehnte Botschaft über den großen Teich gebracht haben. Elektronische Post flitzt per Internet blitzschnell zum Empfänger und kann binnen Sekunden auch den entlegensten Winkel der Welt erreichen.

Aufmacher

Ein Internet-Anschluß ist längst kein komplizierter Luxus mehr, den sich nur Technik-Freaks erlauben können. Online-Dienste und Internet-Provider werfen mit CD-ROMs und kostenlosen Probezugängen nur so um sich, und die Gebühren bröckeln ständig. Der Einstieg ist also kinderleicht: CD einlegen, ein paar Zugangsinformationen eingeben, und schon geht die elektronische Post ab - neudeutsch EMail. Wer nur ab und zu mal eine Mail mit Freunden oder Bekannten austauscht, ist möglicherweise mit der vom Provider gelieferten Software wunschlos glücklich. Doch für so manchen ist EMail mittlerweile zum wichtigsten Kommunikationsmittel geworden, teilweise wichtiger als das Telefon. In der c't-Redaktion gehen täglich weit mehr elektronische als "echte" Briefe ein. In solchen Umgebungen ist eine leistungsfähige Mail-Software das A und O. Die Frage nach dem besten EMail-Client ruft ähnliche Glaubenskriege hervor, wie die nach dem optimalen Editor. Unter den ab Seite 156 vorgestellten Programmen sollte jedoch für jeden Geschmack etwas dabei sein.

Eine wichtige Ursache für die explosionsartige Verbreitung von EMail ist, daß sie auf sehr einfachen, gut dokumentierten und seit vielen Jahren unveränderten Standards basiert. Weltweit können Mail-Programme auf den unterschiedlichsten Rechnern und über Betriebssystemgrenzen hinweg miteinander kommunizieren. Die grafischen Benutzeroberflächen machen den Versand einer EMail zum Kinderspiel. Doch nicht alle Optionen und Untiefen der Mail-Programme erschließen sich auf den ersten Blick. Nützliche Tips zum Umgang mit EMail finden Sie in c't 8/99 ab Seite 170.

Wenn Mails nicht ankommen, Umlaute entstellt oder Dateien verstümmelt werden, lohnt es sich, einmal hinter die Kulissen zu schauen, um zu verstehen, wie so etwas passieren kann. Als erste EMail-Systeme aufkamen, dachte man noch nicht an Texte in verschiedenen Schriftarten oder gar Audio- oder Video-Anhängsel. Der Kernstandard RFC 822, auf dem das heutige Mail-System beruht, gilt noch immer und beschreibt EMails als reine Textdateien [[#lit1 1]].

Eine Mail besteht aus einem "Header" mit Informationen über Absender und Empfänger, der in etwa mit einem Briefumschlag vergleichbar ist. Es folgt eine Leerzeile sowie der "Body" mit der eigentlichen Nachricht. Die wichtigsten Header sind "From:" für den Absender, "To:" für den Empfänger sowie "Date:" für das Absendedatum. Unter "Cc:" stehen weitere Empfänger, die die Mail sozusagen als Durchschlag (Carbon Copy) erhalten. Mit "Bcc:" lassen sich Durchschläge "heimlich" verschicken (Blind Carbon Copy); die Mailsoftware entfernt diesen Header aus der Nachricht, so daß die anderen Empfänger nichts von der zusätzlichen Kopie mitbekommen. Die meisten Mails enthalten den Header "Subject:", hinter dem sich der Betreff verbirgt.

Der Body besteht aus beliebig vielen ASCII-Zeichen. Damit ist der klassische US-amerikanische 7-Bit-Code gemeint; nur Zeichen mit Codes zwischen 0 und 127 sind zulässig. Ausführbare Programmdateien, Bilder oder Audiofiles können jedoch beliebige Bytes zwischen 0 und 255 enthalten. Um solch eine "Binärdatei" per Mail übertragen zu können, muß man den 8bittigen Datenstrom folglich irgendwie kodieren, so daß er sich in 7bittige ASCII-Zeichen zwängen läßt.

In "grauer Vorzeit" erledigte man das von Hand mit Programmen wie uuencode oder xxencode. Sie wandelten die Dateien für den Mail-Versand in eine Folge druckbarer ASCII-Zeichen um. Die entsprechenden Gegenstücke uudecode oder xxdecode konnten daraus wieder die Originaldateien herstellen. In der Macintosh-Welt erfüllte BinHex eine ähnliche Funktion.

Heutige Mail-Programme haben mit Umlauten kein Problem mehr und können beliebige Dateien als "Attachments" an EMails anhängen. Seit 1996 gibt es hierfür einen Standard namens MIME (Multipurpose Internet Mail Extensions). Er erweitert den RFC 822 und führt innerhalb des Body eine Struktur ein, die durch speziell formatierte Zeilen nach ähnlichem Muster wie im Header vorgegeben ist. Eine Mail läßt sich auf diese Weise in mehrere Teile einteilen, wobei jedem eine Art Header vorangeht, der angibt, um welche Art Information es sich handelt und wie sie kodiert ist. Sogar verschachtelte Strukturen sind möglich, das heißt ein Teil kann selbst wiederum aus mehreren Einzelteilen bestehen.

Die [#bild2 Beispiel-Mail] wurde mit dem HTML-Editor von Netscape geschrieben. Dort sieht sie aus wie abgebildet. Wer sie jedoch mit einem alten, nicht MIME-fähigen Mailer betrachtet, bekommt ihr wahres Gesicht zu sehen. Die MIME-Header sagen aus, daß sie den Typ "multipart/alternative" hat. Sie besteht also aus mehreren Teilen, die die gleiche Information in unterschiedlichen Darstellungsvarianten beinhalten. Der Client auf der Empfängerseite kann unter den von ihm unterstützten Varianten diejenige auswählen, die er am besten darstellen kann beziehungsweise die der Empfänger sehen will.

Der erste Teil ist gewöhnlicher Text (text/plain) mit Umlauten gemäß ISO 8859-1. Die Transferkodierung ist "8bit", Netscape verläßt sich also darauf, daß das achte Bit auf dem Transportweg nicht verlorengeht. Die MIME-Spezifikation läßt das zu, da inzwischen praktisch alle Mail-Verbindungen 8-Bit-transparent sind. Eine sicherere Transferkodierung wäre "quoted-printable". Hierbei würden alle Zeichen, die nicht in sieben Bits passen, durch ein Gleichheitszeichen und ihren Code als zweistellige Hex-Zahl dargestellt. Ein so kodierter Text w=E4re auch mit einem nicht MIME-f=E4higen Mailer noch halbwegs lesbar, s=E4he allerdings so aus wie dieser Satz.

Die zweite Teil besteht seinerseits aus zwei zusammengehörigen Teilen (multipart/related), einem Text im HTML-Format (text/html), in dem nur 7bittige ASCII-Zeichen vorkommen (charset=us-ascii, Content-Transfer-Encoding: 7bit), sowie einem Bild im GIF-Format (image/gif). HTML beinhaltet eine eigene Kodierung von Umlauten in druckbare ASCII-Zeichen, die sich ungefähr so schön liest wie in diesem Satz. Für das Bild kommt als Transferkodierung "base64" zum Einsatz. Base64 verwendet zur Darstellung der Daten eine Auswahl von 65 druckbaren ASCII-Zeichen. Mit 26 = 64 Zeichen lassen sich sechs Bit kodieren, das 65. Zeichen ("=") hat eine Sonderfunktion (siehe RFC 2045). Die Base-64-Kodierung packt jeweils drei Bytes à 8 Bit in vier Zeichen mit jeweils 6 Bit Informationsgehalt, vergrößert die Datenmenge also um ein Drittel. Dafür beschränkt sie sich auf druckbare Zeichen, die den Transport garantiert überstehen. Erweiterungen des MIME-Standards beschäftigen sich mit Verschlüsselung und digitalen Signaturen; mehr dazu in c't 8/99 ab Seite 174.

Nach diesem Ausflug in die Untiefen der Kodierung von EMails ist die entscheidende Frage, wie solch eine Mail vom Sender zum Empfänger gelangt. Die Basis hierfür bildet das Simple Mail Transfer Protocol (SMTP). Es beschreibt einen einfachen Dialog, mit dem sich eine Mail über eine Punkt-zu-Punkt-Verbindung zwischen zwei Rechnern übermitteln läßt. Im Internet handelt es sich dabei um eine TCP-Verbindung zum SMTP-Port 25 des Zielrechners (vgl. [#bild2 Beispiel]).

Es bleibt die Frage, woher der Absender weiß, wohin er sich wenden muß, um die Mail zuzustellen. Dafür ist das Domain Name System (DNS) zuständig. Seine Hauptaufgabe ist es, zwischen den für Menschen lesbaren Rechnernamen und den netzintern benutzten 4 Byte langen IP-Adressen zu vermitteln.

Rechnernamen im Internet sind hierarchisch aufgebaut. Sie bestehen aus mehreren durch Punkte getrennten Teilen, wobei der letzte Teil die sogenannte Top-Level-Domain enthält (etwa "de" für Deutschland), der vorletzte eine Unterdomain (etwa den Namen einer Firma oder eines Online-Dienstes innerhalb dieser Top-Level-Domain) und so weiter. Diese Hierarchie kann prinzipiell beliebig tief geschachtelt sein. Ein Rechner namens "machnix", der in der mathematischen Fakultät der Universität Stuttgart in Deutschland steht, heißt beispielsweise machnix.mathematik.uni-stuttgart.de, was deutlich leichter zu merken ist als die IP-Adresse 129.69.116.157.

Um aus dem symbolischen Rechnernamen die IP-Adresse zu ermitteln, fragt der Rechner den nächstgelegenen DNS-Server. Dazu muß er natürlich dessen IP-Adresse kennen. Der Name genügt nicht, denn dann müßte man erst einen DNS-Server fragen, um die IP-Adresse des DNS-Servers zu erfahren.

EMail-Adressen im Internet bestehen aus einem Benutzernamen, gefolgt von einem "@" und einem Domain-Namen, dessen Aufbau einem Rechnernamen gleicht. In der Anfangszeit war der Domain-Name tatsächlich einfach der Name des Zielrechners, auf dem sich der Account des Empfängers befand. Um eine Mail an user@machine.domain auszuliefern, baute der Absender eine direkte SMTP-Verbindung zum Zielrechner machine.domain auf.

Heute gibt es jedoch eine Zwischenstufe. Das Domain Name System speichert zu einem vorgegebenen Namen nicht nur eine IP-Adresse, sondern unterschiedliche Typen von Informationen in verschiedenen sogenannten Resource Records. Einer davon ist der MX-Record (Mail eXchange). Ein Programm, das eine Mail an user@domain.com abschicken möchte, fragt zunächst den DNS-Server nach dem MX-Record von domain.com. Es erhält eine Liste sogenannter Mail Exchanger, die bereit sind, Mails für domain.com entgegenzunehmen. Zu jedem Kandidaten gibt es einen Preference-Wert, der seine Priorität festlegt. Niedrigere Preference-Werte bedeuteten höhere Priorität, der Absender muß sich also an den Exchanger mit dem niedrigsten Zahlenwert wenden und darf nur notfalls auf solche mit höherer Preference ausweichen.

Mit dem Programm nslookup, das praktisch allen Betriebssystemen außer Windows 9x beiliegt, lassen sich diese Informationen über den Befehl "set querytype=mx", gefolgt von der gewünschten Domain, leicht abfragen. Für Windows 9x gibt es ein kostenloses Programm namens CyberKit [[#lit2 2]], das unter anderem Nameserver abfragen kann. Damit erfährt man, daß die Domain heise.de EMail bevorzugt (Preference 10) über relay.heise.de, notfalls (Preference 50) über relay.xlink.net oder höchst ungern (Preference 100) über hydra.pop-hannover. de entgegennimmt.

Es ist übrigens nicht die Aufgabe eines Mail-Client, das soeben skizzierte Mail-Routing vollständig zu beherrschen. Statt dessen gibt es eine Arbeitsteilung: Der Mail-Client, auch Mail User Agent genannt, kümmert sich um die Kommunikation mit dem Benutzer und übergibt zu versendende Mails zum eigentlichen Transport an einen Mail Transport Agent (MTA). Auf ihrem Weg durchs Netz macht eine EMail unter Umständen bei mehreren MTAs Station, bevor sie am Ziel ankommt.

Der Absender kann auf unterschiedliche Weise mit dem MTA kommunizieren. Unter Unix läuft als MTA üblicherweise das von Eric Allman entwickelte sendmail. Wenn der Client auf demselben Rechner arbeitet, kann er sendmail direkt aufrufen und ihm die Mail per Pipe übergeben. Sendmail bietet eine Vielzahl von Konfigurationsmöglichkeiten, weswegen wir ihm in der nächsten c't einen eigenen Artikel widmen.

Die meisten Anwender kommunizieren heute über eine Wählverbindung mit ihrem Internet-Provider. Die verbreitetste Schnittstelle zwischen Mail-Client und dem beim Provider stationierten MTA ist daher SMTP. Statt sich in die Untiefen einer sendmail-Konfiguration zu begeben, trägt der Anwender in seinem Mail-Client nur den Rechner des Internet-Providers ein. Abgehende Mail liefert der Client einfach per SMTP beim MTA des Providers ab, der sich um alles weitere kümmert.

Das vorläufige Endziel einer Mail auf dem Weg durchs Internet ist wiederum ein MTA. Dort bleibt sie so lange liegen, bis der Benutzer seinen Client anwirft und sie abholt. Unter Unix kann der Mail-Client dazu direkt auf die Mail-Dateien zugreifen (Linux-Anwender schauen beispielsweise einmal in /var/ spool/mail). Für den heute weit verbreiteten Fall, daß der Client nicht direkt auf das Spool-Verzeichnis zugreifen kann, gibt es das Post Office Protocol (POP). Praktisch alle Internet-Provider setzen es ein, um Mail an ihre Kunden auszuliefern.

POP ist ähnlich wie SMTP ein simpler Dialog zwischen Empfänger und Mail-Server. Nach dem Vorgeplänkel (Username, Paßwort) gibt es im wesentlichen drei Kommandos: "Wieviele Mails sind da?", "Gib mir Mail Nummer xy" und "lösche Mail Nummer xy". Wer mit POP experimentieren mag, kann einfach eine Telnet-Verbindung zum Port 110 seines Mailservers aufbauen und loslegen; die nebenstehende Beispiel-Sitzung zeigt, wie"s geht. Solange man sich dabei den Löschbefehl DELE verkneift, geht keine Mail verloren. Notfalls kann man auf diese Weise sogar seine Mail lesen, wenn man etwa in einem Internet-Café sitzt und keinen richtigen Mail-Client zur Verfügung hat.

POP war ursprünglich nur dafür gedacht, Mail einfach vom Server abzuholen und dort zu löschen. Erst später kamen optionale Kommandos hinzu, mit denen der Client die Größe einer Mail ermitteln beziehungsweise nur den Header oder den Anfang einer Mail anfordern konnte. So kann man sich erst einen Überblick über die eingegangene Mail verschaffen und einzelne Mails gezielt zum Download auswählen.

Wesentlich mehr Möglichkeiten bietet das aufwendigere IMAP-Protokoll. Moderne Mail-Clients können verschiedene, auch ineinander geschachtelte Ordner verwalten sowie mit MIME-kodierten Attachments umgehen. Die Idee hinter IMAP ist es, den Mail-Client quasi mittendrin aufzutrennen in einen Client-Teil, der für die Kommunikation mit dem Benutzer zuständig ist und einen Server-Teil, der sich um die Verwaltung von Ordnern und Attachments kümmert. Beim Einsatz von IMAP bleiben die Mails also auf dem Server liegen. Das Protokoll ist so ausgelegt, daß der Client gezielt genau die Daten anfordern kann, die er benötigt, so daß möglichst wenig Übertragungszeit anfällt.

Ein Client kann beispielsweise nur die Ordnerliste anfordern, um sie in einer Baumstruktur anzuzeigen. Selektiert der Anwender einen Ordner, so holt der Client von den darin enthaltenen Mails beispielsweise nur Subject, Datum, Absender und Größe, um diese Informationen in einer Übersicht anzuzeigen. Der IMAP-Server versteht sogar die MIME-Struktur von Mails. öffnet der Anwender eine Mail, so kann der Client via IMAP nur den Textteil anfordern und die Attachments erst auf Anwenderwunsch gezielt herunterladen.

Für Internet-Provider ist IMAP nicht sonderlich interessant. Zum einen müßten sie deutlich mehr Plattenplatz bereitstellen, wenn jeder Kunde seine gesamte Mail auf dem Server lagern würde. Zum anderen wäre es auch für den Kunden unnötig teuer, jedes Mal eine Internet-Verbindung zum Server aufzubauen, wenn er in seine Mail schauen will.

Aufgrund der Möglichkeit, Attachments gezielt zum Download auszuwählen, eignet sich IMAP für den mobilen Einsatz, denn die Mobilfunknetze bieten derzeit nur geringe Übertragungsraten. Seine größte Stärke zeigt es jedoch im Intranet, wo quasi immer eine kostenlose und schnelle Standleitung zwischen Client und IMAP-Server besteht. Wer IMAP nutzt, kann von einem beliebigen Rechner aus auf seine Mail zugreifen. Auch ein Wechsel des Mail-Clients oder gar Betriebssystems geht ohne jegliche Konvertierungsarbeiten vonstatten, denn alle Mails bleiben einschließlich Ordnerstruktur auf demselben Server liegen. Wer eine Einwahlmöglichkeit ins Firmennetz hat, kann von zu Hause aus seine gesamte Mail verwalten. Von der dort geleisteten Arbeit, Mails in Ordner einzusortieren oder zu löschen, profitiert er somit auch anschließend im Büro.

Das IMAP-Protokoll ist allerdings wesentlich aufwendiger als POP. Das könnte dem Anwender eigentlich egal sein, hätte es nicht Konsequenzen für die EMail-Clients: Während POP-Clients weitgehend zuverlässig funktionieren, schlummern in den diversen IMAP-Implementierungen noch eine Menge kleinerer und größerer Fehler. Näheres dazu auf den folgenden Seiten in der c't 8/99. (bo)

[1] diverse Internet-Standards (RFC, Request For Comment), beispielsweise unter http://sunsite.auc.dk/RFC/. Hier relevant: RFC 822 (Format von Internet-Mails), RFC 821 (SMTP-Protokoll), RFC 2045 bis 2049 (MIME), RFC 974 (Mail-Routing und DNS), RFC 1939 und 2449 (POP3), RFC 2060 (IMAP4)

[2] CyberKit für Windows 9x

[#anfang Seitenanfang]


Mail
Vergrößern

Was in modernen Mail-Programmen so schön bunt aussieht, wird zum Transport aufwendig in ASCII-Zeichen verpackt.

  Received: from heise.de (dhcp27.ct.heise.de [193.96.28.197]) by   idgie.heise.de (8.8.5/8.7.3-mailhost_014) with ESMTP id KAA15218 for   ; Fri, 26 Mar 1999 10:23:03 +0100 (MET)  Message-ID: <36fb51bc.5e5807ab@heise.de>  Date: Fri, 26 Mar 1999 10:22:04 +0100  From: Harald Boegeholz   MIME-Version: 1.0  To: hwb@heise.de  Subject: Umlaute sind =?iso-8859-1?Q?ätzend?=  Content-Type: multipart/alternative;   boundary="------------81317658C4670F996C68CA45"      --------------81317658C4670F996C68CA45  Content-Type: text/plain; charset=iso-8859-1  Content-Transfer-Encoding: 8bit    So mancher, der sich über die Gestaltungsmöglichkeiten einer HTML-Mail  freut, ahnt nicht, wie seine Nachricht wirklich aussieht.
  --------------81317658C4670F996C68CA45  Content-Type: multipart/related;   boundary="------------D94F462B3CF64325769E2808"      --------------D94F462B3CF64325769E2808  Content-Type: text/html; charset=us-ascii  Content-Transfer-Encoding: 7bit          So mancher, der sich über die Gestaltungsmöglichkeiten  einer HTML-Mail freut, ahnt nicht, wie seine Nachricht wirklich  
  --------------D94F462B3CF64325769E2808  Content-Type: image/gif  Content-ID:   Content-Transfer-Encoding: base64  Content-Disposition: inline; filename="C:\TEMP\nsmailKQ.gif"    R0lGODlhZABkAPcAAM7OztbW1t7e3ufn5+/v7/f39///////////////////////////////  
    Z31JU5xr/hnem9LdKV5CAyiK4pIEDGDVpAJQelpDChIAlaWVdubpp6CGKuqopJZq6qmopqrq  qqy26uqrErDGKuustNZq66245qrrrgwFBAA7    --------------D94F462B3CF64325769E2808--    --------------81317658C4670F996C68CA45--  

[#anfang Seitenanfang]


  220 idgie.heise.de ESMTP Sendmail 8.8.5...  HELO texnix.ct.heise.de  250 idgie.heise.de Hello texnix.ct.heise.de ...  MAIL FROM: nobody@heise.de  250 nobody@heise.de... Sender ok  RCPT TO: hwb@heise.de  250 hwb@heise.de... Recipient ok  DATA  354 Enter mail, end with "." on a line by itself  From: Ingo Knito   To: Harald Boegeholz   Subject: SMTP-Demonstration    Das SMTP-Protkoll ist wirklich simpel.  .  250 TAA29844 Message accepted ...  QUIT  221 idgie.heise.de closing connection  

[#anfang Seitenanfang]


  +OK QPOP at idgie.heise.de starting. ...  user bo  +OK Password required for bo.  pass sagichnicht  +OK bo has 5 messages (6307 octets).  stat  +OK 5 6307  retr 1  +OK 683 octets  Received: from texnix.ct.heise.de ...  Received: (hwb@localhost) by ...  Date: Mon, 29 Mar 1999 09:43:30 +0200  Message-Id: <199973@texnix.ct.heise.de>  From: Harald Boegeholz   To: hwb@heise.de  Subject: Testmail  Status: RO    Dies ist ein Test. In mbox-Dateien ist  >From am Zeilenanfang verboten.  .  dele 1  +OK Message 1 has been deleted.  quit  +OK Pop server at idgie.heise.de signing off.  
Anzeige