Jetzt werden wir den Informationsfluß beschreiben, der üblicherweise
stattfindet, wenn zwei Personen per E-Mail kommunizieren.
Unterstellen wir, daß Alice von ihrem Computer wunderland.com
eine E-Mail an Bob auf seinen Computer dobbs.com schicken will.
Beide Maschinen sind mit dem Internet verbunden.
Hilfreich zu wissen ist dabei, daß eine Internet E-Mail Nachricht aus zwei Teilen besteht: dem E-Mail Header und dem E-Mail Body, geteilt durch eine leere Zeile. Die E-Mail Header enthalten die Quelle und das Ziel der E-Mail, eine benutzerbestimmte Subjekt Zeile, das Sendedatum und verschiedene anderen Arten von nützlichen Informationen. Der Body ist der aktuelle Inhalt der Nachricht. Hier ein Beispiel:
From: "Alice" <alice@wonderland.com>
Message-Id: <199711131704.MAA18447@wonderland.com>
Subject: Hast du mein weißes Kaninchen gesehen?
To: bob@dobbs.org (Bob)
Date: Thu, 13 Nov 1997 12:04:05 -0500 (EST)
Content-Type: text
--
>>alice>>
Die Anordnung und die Bedeutung der Internet E-Mail Header sind durch einen Internet Standard, genannt RFC 822, definiert.
Hier ist ein Diagramm des gesamten Vorgangs - die Etappen und die Terminologie werde ich unten erläutern.
+---------+ +-------+
+-------+ tippt | sendet | ruft auf |sendet |
| Alice |--------->| MUA |--------->| MTA |::::>::::
+-------+ | | | | :: auf der
+---------+ +-------+ :: sendenden
:: Maschine
.......................................................................
SMTP ::
::::::::::::::::::::::::::::<::::::::::::::::::::::::::::
::
:: +---------+ +-----+ +-------+
:: |empfängt |ruft auf | | stellt zu an | Bobs |
::::>| MTA |--------->| LDA |===============>|Mailbox| auf der
| | | | | | empfangenden
+---------+ +-----+ +-------+ Maschine
| |
| |
+----------------<-------------+ |
| |
+----------------+ +-------+ |
| Bobs | | Bobs |<----------+
|Benachrichtigung| | MUA |
+----------------+ +-------+
| |
| +-----+ |
+----->| Bob |<----+
+-----+
Um eine E-Mail zu schicken, wird Alice ein Programm aufrufen, den »E-Mail User Agent« (oder »Mail User Agent«, Abkürzung: MUA). Der MUA ist das, was die Benutzer oft als »das E-Mail Programm« ansehen; es unterstützt Sie bei der Erstellung der Nachricht, gewöhnlich durch den Aufruf eines Texteditors eigener Wahl. Wenn Sie den »Senden« Button drücken, ist Ihr Teil der Arbeit getan. Später in dieser HOWTO werden wir einen Überblick über populäre MUAs geben.
Der MUA, den Sie benutzen, übergibt ihre Nachricht sofort an ein Programm, das
»E-Mail Transport Agent« (oder »Mail Transport Agent«, Abkürzung: MTA) genannt wird. Dieses
Programm wird normalerweise sendmail sein, obwohl noch einige
alternative MTAs an Popularität gewonnen haben und in zukünftigen Linux
Distributionen auftauchen werden. Später in dieser HOWTO werden wir auch über
die MTAs einen Überblick geben.
Die Aufgabe des MTA ist die Übertragung der E-Mail an den MTA auf Bobs Maschine.
Es ermittelt Bobs Maschine durch die Analyse des »To: «-Header und entdeckt das
dobbs.com auf der rechten Seite von Bobs Adresse. Es benutzt
diese Adresse, um eine Internet Verbindung zu Bobs Maschine zu öffnen. Die
Mechanismen der Erstellung dieser Verbindung sind aber eine ganz andere
Sache; für diese Erläuterung reicht es zu wissen, daß diese Verbindung für
den MTA von Alice ein Weg ist, Textbefehle an Bobs Maschine zu senden und
Antworten auf diese Befehle zu empfangen.
Die Befehle des MTA gehen nicht an eine Shell. Statt dessen gehen sie an einen Sevice Port auf Alices Maschine. Ein Service Port ist eine Art Treffpunkt, ein bekannter Platz, an dem Internet Service Programme auf eintreffende Anfragen lauschen. Service Ports sind nummeriert und Alices MTA weiß, daß es mit Port 25 auf Bobs Maschine kommunizieren muß, damit die E-Mail durchgelassen wird.
An Port 25 hat Bobs Maschine einen eigenen MTA, der auf Befehle lauscht (womöglich eine weitere Kopie von sendmail). Alices MTA arbeitet einen Dialog mit dem MTA vom Bob ab, indem es das Simple Mail Transport Protocol (einfaches E-Mail Protokoll, Abkürzung: SMTP) benutzt. So sieht ein SMTP Dialog aus. Zeilen, die von Alice's Maschine gesendet werden, sind mit einem »S:« markiert, Antworten von Bobs Maschine zeigen ein »R:«.
S: MAIL FROM:<alice@wunderland.com>
R: 250 OK
S: RCPT TO:<bob@dobbs.com>
R: 250 OK
S: DATA
R: 354 Start mail input; end with <CRLF>.<CRLF>
S: From: "Alice" <alice@wunderland.com>
S: Message-Id: <199711131704.MAA18447@wunderland.com>
S: Subject: Hast du mein weißes Kaninchen gesehen?
S: To: bob@dobbs.org (Bob)
S: Date: Thu, 13 Nov 1997 12:04:05 -0500 (EST)
S: Content-Type: text
S:
S: Ich bin beunruhigt. Ich befürchte, er könnte ich ein Loch gefallen
sein.
S: --
S: >>alice>>
S: .
R: 250 OK
Gewöhnlich besteht ein SMTP Befehl aus einer einzigen Textzeile und ebenso seine Antwort. Der »DATA« Befehl ist eine Ausnahme; nachdem dieser erkannt wurde, akzeptiert der SMTP Listener Nachrichtenzeilen bis ein Punkt für sich allein in einer Zeile steht. SMTP wird durch den Internet Standard RFC 821 definiert.
Jetzt hat Bobs MTA die Nachricht von Alice. Er fügt einen Kopf an die Nachricht, der so oder ähnlich aussieht:
Received: (from alice@wonderland.com)
by mail.dobbs.com (8.8.5/8.8.5) id MAA18447
for bob@dobbs.com; Thu, 13 Nov 2001 12:04:05 -0500
Das geschieht für Zwecke der Zurückverfolgung, für den Fall von E-Mail Fehlern
(manchmal muß eine Nachricht durch mehr als eine Maschine übertragen werden
und wird mehrere davon haben). Bobs MTA übergibt die veränderte Nachricht an
einen »Local Delivery Agent« (lokaler E-Mail Zusteller, Abkürzung: LDA). Auf Linux
Systemen ist der LDA gewöhnlich ein Programm namens procmail, obwohl
es auch andere gibt.
Die Aufgabe des LDA ist es, die Nachricht an Bobs Mailbox anzuhängen. Er ist vom MTA getrennt, so daß beide Programme einfacher gehalten sein können und der MTA sich darauf konzentrieren kann, seine »Internet-Dinge« zu tun, ohne sich um lokale Details zu kümmern, etwa wo die Mailboxen des Benutzers sind.
Bobs Mailbox wird normalerweise eine Datei namens /usr/spool/mail/bob
oder /var/mail/bob sein. Wenn er seine E-Mails liest, startet er seinen
eigenen MUA, um in diese Datei zu sehen und sie zu editieren.
Es gibt noch eine weitere Programmart, die in der E-Mail Kette wichtig ist, obwohl diese selbst weder E-Mails liest noch übermittelt. Es ist ein »Mail Notifier«, ein Programm, das Ihren E-Mail Eingangskorb auf Aktivität überwacht und Ihnen signalisiert, wenn eine neue E-Mail ankommt.
Die ursprüngliche Benachrichtigung fand durch ein Paar von Unix Programmen,
genannt biff(1) und comsat(8), statt. Das Programm
biff ist ein Frontend oder eine Bedienoberfläche, welche Ihnen erlaubt,
den comsat Dienst einzuschalten. Wenn dieser Service aktiviert ist,
wird der Kopf einer neuen Nachricht an Ihr Terminal ausgegeben, sobald sie
eintrifft. Diese Möglichkeit war für Leute gedacht, die zeilenorientierte
Programme auf Textkonsolen nutzen; in heutigen Umgebungen ist es keine
wirklich gute Idee.
Die meisten Unix Shells haben eine eingebaute Prüfungsmöglichkeit für E-Mails, die
es ihnen erlaubt, eine Benachrichtigung in viel weniger aufdringlicher Art und
Weise durchzuführen (durch Ausgabe einer Nachricht direkt vor dem Prompt, wenn
neue E-Mails entdeckt werden). Typischerweise können Sie dies durch das Setzen von
Umgebungsvariablen einschalten, die auf der Manual Page der Shell dokumentiert
sind. Für Shells der sh/ksh/bash Familie sehen Sie unter
den Variablen »MAIL« und »MAILPATH« nach.
Systeme mit X11 Unterstützung haben eines von mehreren kleinen Desktop Tools,
die regelmäßig nach neuen E-Mails sehen und Ihnen sowohl optisch als auch
akustisch anzeigen, wenn es neue E-Mails gibt. Das älteste und am häufigsten
verwendetste dieser Tools ist xbiff. Falls Ihr Linux ein
vorkonfiguriertes X-Desktop Setup hat, ist xbiff vermutlich installiert.
Sehen Sie in der xbiff(1) Manual Page nach Details.
Falls Sie aufmerksam gelesen haben, wird Ihnen aufgefallen sein, daß der von uns beschriebene Informationsfluß davon abhängt, daß Alices Computer sofort mit Bobs Computer kommunizieren kann. Was passiert, wenn Bobs Computer abgeschaltet ist oder eingeschaltet ist, aber keine Internetverbindung besteht?
Falls der MTA von Alice den von Bob nicht sofort erreichen kann, wird Alices
Nachricht in einer E-Mail Warteschlange auf wunderland.com abgelegt.
Er wird dann in regelmäßigen Abständen versuchen, die Nachricht erneut zu versenden, bis
eine Ablaufzeit erreicht ist; an diesem Punkt wird Alice durch eine Rückmeldung
von dem Mißerfolg informiert. In der Grundeinstellung des am meisten
verbreitetsten MTA (sendmail) beträgt die Zeit erneuter Versuche
15 Minuten und der Ablaufzeitraum 4 Tage.
Viele Linux Nutzer sind heutzutage über ISPs (Internet Service Provider) mit dem Internet verbunden und haben keine eigene Internetdomain. Statt dessen haben sie Benutzerkonten auf einer ISP Maschine. Ihre E-Mails werden an eine Mailbox auf diesem ISP Computer zugestellt. Aber üblicherweise wollen diese Benutzer ihre E-Mails mit ihren eigenen Computern lesen und beantworten, die zeitweise mit dem ISP verbunden sind, unter Benutzung von SLIP oder PPP. Linux unterstützt dafür Fern-E-Mail Protokolle.
Beachten Sie den Unterschied zu dem Szenario, das wir im letzten Abschnitt besprochen haben. E-Mails, die in einer Warteschlange sitzen und eine erneute Übertragung abwarten, sind nicht das selbe wie E-Mails, die an eine Server Mailbox gesendet werden. E-Mails in einer Warteschlange können nicht als versendet angesehen werden und unterliegen der Verfallzeit. Dagegen sind an eine ISP Mailbox verschickte E-Mails als »ausgeliefert« anzusehen und können dort auf unbestimmte Zeit bleiben.
Ein Fern-E-Mail Protokoll erlaubt, daß E-Mails von einem Server über eine Netzwerkverbindung durch ein Client-Programm gezogen werden (das ist das Gegenstück der normalen Auslieferung, wobei ein MTA die E-Mails an den empfangenden MTA schickt). Es gibt zwei gebräuchliche Fern-E-Mail Protokolle: POP3 (wird durch den Internet-Standard RFC 1939 definiert) und IMAP (wird durch den Internet-Standard RFC 2060 definiert). Tatsächlich unterstützen alle ISPs POP3, eine steigende Zahl unterstützt IMAP, welches mächtiger ist.
Es folgt ein Beispiel, wie eine POP3 Sitzung aussieht:
S: <client connects to service port 110>
R: +OK POP3 server ready <1896.697170952@mailgate.dobbs.org>
S: USER bob
R: +OK bob
S: PASS redqueen
R: +OK bob's maildrop has 2 messages (320 octets)
S: STAT
R: +OK 2 320
S: LIST
R: +OK 2 messages (320 octets)
R: 1 120
R: 2 200
R: .
S: RETR 1
R: +OK 120 octets
R: <the POP3 server sends message 1>
R: .
S: DELE 1
R: +OK message 1 deleted
S: RETR 2
R: +OK 200 octets
R: <the POP3 server sends message 2>
R: .
S: DELE 2
R: +OK message 2 deleted
S: QUIT
R: +OK dewey POP3 server signing off (maildrop empty)
S: <client hangs up>
Eine IMAP Sitzung verwendet davon verschiedene Befehle und Antworten, aber es ist von der Logik her recht ähnlich.
Um die Vorteile von POP3 oder IMAP zu genießen, benötigen Sie ein E-Mail Client Programm, um die E-Mails zu erhalten. Einige MUA haben Client-Fähigkeiten eingebaut (welche unterstützt werden, ist unten aufgelistet). Die E-Mail Fähigkeit des Netscape Browsers unterstützt sowohl POP als auch IMAP von Hause aus.
Der Hauptnachteil von POP Clients, die in MUAs eingebaut
sind, ist, daß man dem Mailprogramm explizit befehlen muß, den Server
anzuwählen; man wird nicht von xbiff(1) oder ähnlichem
benachrichtigt, ebensowenig wie für E-Mails, die entweder lokal oder durch
eine konventionelle SMTP »push«-Verbindung ausgeliefert werden. Außerdem
sind natürlich nicht alle MUAs POP/IMAP-fähig, so daß Sie für sich
selbst wegen anderer Features Kompromisse finden können.
Ihr Linux kommt wahrscheinlich mit einem Programm genannt fetchmail,
das speziell dafür geschaffen wurde, um mit entfernten E-Mail Servern zu
kommunizieren, E-Mails abzuholen und diese in Ihren Standard E-Mail
Zustellpfad zuzustellen, indem es über SMTP mit Ihrem »listener« spricht.
fetchmail ist unter folgender Adresse zu finden:
http://www.tuxedo.org/~esr/fetchmail/Bis auf die Fälle, in denen die E-Mails auf dem Server verbleiben sollen,
weil z.B. mehrere Rechner zum Lesen der E-Mails verwendet werden, ist
fetchmail möglicherweise eine bessere Lösung als die POP/IMAP
Funktionen, die Ihr E-Mail Programm bietet. fetchmail kann
aufgefordert werden, im Hintergrund zu laufen und periodisch auf den
Server zuzugreifen, so daß xbiff(1) oder ein anderes E-Mail
Benachrichtigungprogramm wie für SMTP E-Mails arbeiten können. Zudem
ist fetchmail weit nachsichtiger gegenüber verschiedenen
Eigenheiten und nicht standardisierten Server Launen als die Clients
in MUAs und hat eine bessere Fehlerkorrektur.
Das Diagramm zeigt, wie beide Fälle (mit und ohne fetchmail)
arbeiten:
+---------+ +---------+
+-------+ tippt |sendender| ruft auf |sendenden|
| Alice |--------->| MUA |--------->| MTA |::>::::
+-------+ | | | | ::
+---------+ +---------+ :: auf der
:: sendenden
SMTP :: Maschine
::::::::::::::::::::::::::::<::::::::::::::::::::::::::::
::
.::.......................................................................
::
:: +------------+ +-----+ +-------+
:: |empfangender|ruft auf| | stellt zu | Bobs |
::::>| MTA |------->| LDA |============>|Server |:::>::::
| | | | an |Mailbox| :: auf dem
+------------+ +-----+ +-------+ :: Mail
:: Server
POP oder IMAP ::
::::::::::::::::::::::::::::<:::::::::::::::::::::::::::::::::::
::
.::.......................................................................
.
::
:: +-----------+
:: | |
:::::::>::::::::::::| fetchmail |:::::::: auf der
:: | | :: empfangenden
:: +-----------+ :: Maschine,
:: :: mit fetchmail
:: ::::::::::::::::<:::::::::::::::::::
:: ::
:: :: +------------+ +-----+ +-------+
:: :: |empfangender| ruft auf | | stellt zu an | Bobs |
:: ::::>| MTA |--------->| LDA |===============>|Mailbox|
:: | | | | | |
:: +------------+ +-----+ +-------+
:: | |
:: | |
:: +----------------<----------------+ |
:: | |
:: +---------------+ +-------+ |
:: | Bobs | | Bobs |<-------------+
:: | Notifier | | MUA |
:: +---------------+ +-------+
:: | |
.::.......................................................................
.
:: . | |
:: ohne . | |
:: fetchmail . | |
:: . | +-----+ |
:: +----------+ . +----->| |<----+
:: | Bobs | . | Bob |
:::::| POP/IMAP |----.--------->| |
| MUA | . +-----+
+----------+ .
Wenn eingehende E-Mails an eine Mailbox angefügt werden, obliegt es dem MTA, einige Arten von Begrenzungszeichen anzubieten, die mitteilen, wo eine Nachricht endet und die nächste beginnt.
Unter Unix nutzen nahezu alle E-Mail Programme die Konvention, daß in jede Zeile, die mit einem »From « beginnt (das Leerzeichen ist entscheidend), eine neue Nachricht anfängt. Wenn »From « am Beginn einer Zeile im Text erscheint, wird ein UNIX MTA sie normalerweise mit einem »größer-als« Zeichen signieren, so daß sie dann so aussieht: »>From «. RFC 822 Header folgen dieser »From« Zeile (welche gewöhnlich den Namen des Sendenden und das Empfangsdatum enthält).
Diese Konvention entstammt der Unix Version 7, weshalb diese Art Mailbox als »V7 Mailbox« bezeichnet wird; manchmal heißt es auch »mbox Format«. Soweit nicht anders vermerkt, erwarten alle in dieser HOWTO erwähnten Programme dieses Format. Es ist nicht direkt universell, und Hilfsprogramme erwarten und erstellen verschieden Formate, so daß sie sich gegenseitig sehr verwirren können.
Die vier anderen Formate, die bekannt sein sollten und vor denen man
sich hüten sollte, sind BABYL, MMDF, MH und qmail maildir
(E-Mail Verzeichnisse von qmail). Von diesen ist MMDF das
einfachste. Es verwendet eine Begrenzungslinie, die aus vier Control-As
(ASCII 001) gefolgt von einem Zeilenumbruch (CR-LF) besteht. MMDF war ein
früher und recht primitiver Internet E-Mail Transport. Ein Nachfolger ist
immer noch auf SCO Systemen in Benutzung.
BABYL ist ein weiteres Überbleibsel eines frühen E-Mail Systems des MIT
(Massachusetts Institute of Technology). Es wird immer noch von
emacs im E-Mail Lesemodus verwendet.
MH und qmail maildir sind »Mailbox« Formate, die jede Mailbox in ein
Verzeichnis aus Dateien stürzen, eine pro Nachricht. Wenn grep
auf so eine »Mailbox« angewendet wird, erhält man nichts, da alles, was
grep zu sehen bekommt, Verzeichnisbits sind.
Microsoft Outlock Express .mbx Mailboxen können in ein RFC 822
Format mittels des Programms mbx2mbox umgewandelt werden.