6.4.2. Simple Mail Transfer Protocol (SMTP)

Ein MTA kann sowohl Server als auch Klient sein, wobei der Sender-MTA als Klient und der Empfänger-MTA als Server fungiert. Für die Kommunikation zwischen beiden wird wie bei Telnet und FTP auch der Zeichensatz NVT ASCII verwendet.

SMTP ist ein recht einfaches Protokoll, das dem FTP sehr ähnlich ist. Der Klient sendet Kommandos an den Server:

Kommando Parameter Beschreibung
HELO Hostname bzw. IP-Adresse Mit diesem Kommando stellt sich der Klient beim Server vor.
MAIL FROM: <Mailadresse des Absenders> Festlegung des Absenders der E-Mail
RCPT TO: <Mailadresse des Empfängers> Festlegung des Empfängers der E-Mail
DATA   Auf dieses Kommando folgt der Text der E-Mail (body). Dieser ist mit einem Punkt auf einer freien Zeile zu beenden.
QUIT   Absenden (vorausgesetzt, die ersten vier Kommandos waren erfolgreich) der E-Mail und Beenden der Verbindung
VRFY <Mailadresse des Empfängers> Überprüfung der Empfänger-Mailadresse, ohne die E-Mail zu senden
EXPN <Mailadresse des Empfängers> Dieses Kommando dient dazu, Mailing-Listen zu expandieren, ohne die E-Mail an die Liste zu senden. In vielen Implementationen verbirgt sich dahinter allerdings nur das VRFY-Kommando.

Der Server bestätigt die Kommandos des Klienten mit einem dreistelligen numerischen Reply-Code sowie mit einer optionalen Textinformation für den Nutzer. Die Reply-Codes sind nach demselben Prinzip wie bei FTP aufgebaut:

Reply-Code Beschreibung
1-- Positive Preliminary reply
2-- Positive Completion reply
3-- Positive Intermediate reply
4-- Transient Negative Completion reply
5-- Permanent Negative Completion reply
-0- Syntax
-1- Information
-2- Connections
-3- Unspecified
-4- Unspecified
-5- Mail system: Angaben zum Status des Empfänger-MTAs bzgl. der angeforderten Übertragung oder Aktion

Die folgende Tabelle zeigt ausgewählte Reply-Codes:

Reply-Code Beschreibung
214 Hilfetext über Kommandos und deren Benutzung
220 MTA bereit, Service verfügbar
221 MTA schließt den Übertragungskanal
250 Kommando erfolgreich ausgeführt
354 die Eingabe des Mailtextes kann erfolgen (nach DATA)
421 Service nicht verfügbar
452 nicht genügend Speicherplatz vorhanden
500 Syntaxerror, ungültiges Kommando
501 Syntaxerror in den Parametern oder Argumenten
502 Kommando nicht implementiert
503 falsche Kommandoreihenfolge (z.B. mehrfaches HELO)
554 Übertragung fehlgeschlagen

Nach so viel notwendiger Theorie wollen wir uns nun einmal mit einem MTA "unterhalten", indem wir selber SMTP "sprechen". Zu diesem Zweck übernehmen wir die Rolle des Sender-MTAs und schicken uns selbst eine E-Mail, indem wir uns mittels TELNET an den SMTP-Port 25 wenden:

caliban: telnet mailbox.hrz.tu-chemnitz.de 25
Trying 134.109.132.25...
Connected to mailbox.hrz.tu-chemnitz.de.
Escape character is '^]'.
220 mailbox.hrz.tu-chemnitz.de ESMTP Sendmail 8.8.3/8.8.3; Thu, 9 Jan 1997 12:37:41 +0100 (MET)
Der MTA zeigt uns daraufhin seine Bereitschaft an, und wir können nun Kommandos eingeben. Als erstes stellen wir uns dem MTA vor:
HELO caliban.informatik.tu-chemnitz.de
250 mailbox.hrz.tu-chemnitz.de Hello caliban.informatik.tu-chemnitz.de [134.109.192.189], pleased to meet you
Danach spezifizieren wir Absender und Empfänger, die natürlich in diesem Beispiel identisch sind (aber bitte verwenden Sie bei Experimenten Ihre eigene Mailadresse):
MAIL FROM:<hgu@informatik.tu-chemnitz.de>
250 <hgu@informatik.tu-chemnitz.de>... Sender ok
RCPT TO:<hgu@informatik.tu-chemnitz.de>
250 <hgu@informatik.tu-chemnitz.de>... Recipient ok
Als letztes formulieren wir noch die Nachricht und schicken die E-Mail ab:
DATA
354 Enter mail, end with "." on a line by itself
Das ist die gesendete Nachricht (body).
.
250 MAA28846 Message accepted for delivery
QUIT
221 mailbox.hrz.tu-chemnitz.de closing connection
Connection closed by foreign host.
Die E-Mail sollte nun nach geringer zeitlicher Verzögerung beim Empfänger - also uns selbst - angekommen sein.

Anmerkung:

Die oben versandte Mail enthält keinen Header und wird daher nicht von allen SMTP-Servern (MUAs) entgegengenommen. Manche MTAs fordern zumindest einen minimalen Header, wobei dessen obligatorische Felder von der Implementierung abhängen. So kann es sein, daß das Feld Date: bereits ausreicht.

Sofern ein Header existiert, erscheint er immer vor dem Body und ist von diesem durch eine Leerzeile, d.h. durch CRLF (Carriage Return/Line Feed) abzutrennen. Laut RFC 822 (STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES) soll ein Header mindestens die Felder Date: und From: sowie wenigstens eine Ziel-Adresse enthalten. Zur Angabe unterschiedlicher Ziel-Adressen dienen die Felder To:, Resent-To:, cc:, Resent-cc:, bcc: sowie Resent-bcc:.

Der nachfolgende Dialog zeigt einen möglichen Ablauf beim Versenden einer Mail mit Header:

hot@kirke 5 > telnet mailhost.hrz.tu-chemnitz.de 25
Trying 134.109.132.51...
Connected to mailhost.tu-chemnitz.de.
Escape character is '^]'.
220 saturn.hrz.tu-chemnitz.de IC 131 PP 131 Here - Pleased to meet you (Complaints/bugs to: TU Chemnitz Postmaster <postmaster@hrz.tu-chemnitz.de>)
HELO kirke.informatik.tu-chemnitz.de
250 saturn.hrz.tu-chemnitz.de: kirke.informatik.tu-chemnitz.de looks good to me
MAIL FROM:<hot@informatik.tu-chemnitz.de>
250 OK
RCPT TO:<hot@informatik.tu-chemnitz.de>
250 Recipient OK.
DATA
354 Enter Mail, end by a line with only '.'
Date: 1 Jul 1998 13:07:50
From: <hot@informatik.tu-chemnitz.de>
To: <hot@informatik.tu-chemnitz.de>
Subject: Mail mit Header

Das ist eine Mail mit Header.
.
250 Submitted & queued (msg.25032-0)
QUIT
221 saturn.hrz.tu-chemnitz.de says goodbye to kirke.informatik.tu-chemnitz.de at Wed Jul  1 13:07:54.
Connection closed by foreign host.

Im obigen Beispiel haben wir gesehen, daß wir eine Absenderadresse angeben müssen. Was passiert eigentlich, wenn wir dort irgendeine Mailadresse eintragen, vielleicht sogar eine ungültige? Die Antwort mag ein wenig erschrecken, aber SMTP unterstützt keinerlei Möglichkeiten einer Authentifizierung, d.h., es ist nicht möglich zu überprüfen, ob Sie auch derjenige sind, der vorgibt, die E-Mail abgeschickt zu haben. Sie sollten also nicht unbedingt mittels E-Mail Bestellungen aufgeben, womöglich noch unter Angabe Ihrer Kreditkartennummer. Im Abschnitt 8 werden Sie dann sehen, wie man mit Hilfe von Kryptosystemen dafür sorgen kann, daß niemand außer Ihnen selbst diese E-Mail generieren kann.

Erweiterungen zu SMTP (Extended SMTP, ESMTP)

Das SMTP-Protokoll kann man zu den Oldtimern im Internet zählen (der RFC stammt aus dem Jahre 1982). Wünsche nach Erweiterung der Funktionalität und entsprechende Vorschläge gibt es schon lange. Wie aber können diese in einer etablierten und sich weiter vergrößernden Mail-Infrastruktur durchgesetzt werden, ohne daß es zu Inkompatibilitäten kommt?

Eine Lösung wurde mit Extended SMTP gefunden, einer Art Baukastensystem für Erweiterungen (sog. SMTP Service Extensions). Dazu wurde ein neues Kommando eingeführt:

Kommando Parameter Beschreibung
EHLO Hostname bzw. IP-Adresse Der Klient stellt sich vor und fragt an, ob der Server ESMTP unterstützt. Wenn ja, erfragt er die konkret verfügbaren Erweiterungen.

Wenn der Server kein ESMTP versteht, wird er das unbekannte Kommando abweisen. Bei einer älteren Installation des MTAs namens PP sah das so aus:

220 obelix.hrz.tu-chemnitz.de PP Here - I was just dreaming of you...
EHLO saturn.hrz.tu-chemnitz.de
500 Unknown or unimplemented command
Damit weiß der Klient, daß er keine ESMTP-Erweiterungen nutzen kann. Er sollte sich nochmal mit HELO melden.

Trifft er auf einen ESMTP-fähigen Server, wird dieser ihm seine Fähigkeiten mitteilen. Hier zwei Beispiele mit neueren MTA-Versionen:

  1. MTA Sendmail
    220 mailbox.hrz.tu-chemnitz.de ESMTP Sendmail 8.8.8/8.8.3; Wed, 1 Jul 1998 13:33:13 +0200 (MET DST)
    EHLO kirke.informatik.tu-chemnitz.de
    250-mailbox.hrz.tu-chemnitz.de Hello kirke.informatik.tu-chemnitz.de [134.109.192.39], pleased to meet you
    250-EXPN
    250-VERB
    250-8BITMIME
    250-SIZE
    250-DSN
    250-ONEX
    250-ETRN
    250-XUSR
    250 HELP
    
  2. MTA PP
    220 obelix.hrz.tu-chemnitz.de IC 131 PP 131 Here - Pleased to meet you (Complaints/bugs to:  TU Chemnitz Postmaster )
    EHLO kirke.informatik.tu-chemnitz.de
    250-obelix.hrz.tu-chemnitz.de: kirke.informatik.tu-chemnitz.de looks good to me
    250-VRFY
    250-SIZE
    250 HELP
    
Betrachten wir einige Erweiterungen im einzelnen:

SchlüsselwortServiceErläuterung
SIZE=BytesMessage Size DeclarationDer Klient übermittelt die Größe der zu sendenden Nachricht. Der Server entscheidet, ob er sie momentan annehmen kann (freier Speicherplatz) oder generell ablehnt (administratives Limit, z.B. um Übertragungszeiten zu beschränken).
BODY=8BITMIME8bit-MIME TransportDer Klient fragt, ob er Mails mit Nicht-ASCII-Zeichen (z.B. Umlaute) senden darf. Die Zeilenstruktur muß erhalten bleiben, es können also keine reinen Binärdaten gesendet werden.
DSNDelivery Status NotificationsRückmeldungen über Erfolg/Mißerfolg der Nachrichtenübermittlung.
ETRNRemote Message Queue StartingDer Klient kann einen Server veranlassen, angestaute Mail für eine Domain abzuarbeiten.

Des weiteren gibt es Erweiterungsvorschläge für die Übertragung großer Binärdaten, für Checkpoints (Aufsetzen auf abgebrochene Übertragungen) und für erweiterte Fehlerkodes.

Es ist nicht zwingend, daß ein MTA alle Erweiterungen beherrscht. Er muß deshalb zu Beginn der "Session" mitteilen, welche er unterstützt. In unserem obigen Beispiel sind das bei Sendmail also die in der Tabelle dargestellten Erweiterungen, die SMTP-Features EXPN und HELP sowie einige "private" Möglichkeiten (XUSR, ONEX).

Betrachten wir ein Anwendungszenario, in dem wir eine überlange Mail absenden möchten:

220 ultra.informatik.tu-chemnitz.de Sendmail ready ...
EHLO saturn.hrz.tu-chemnitz.de
250-ultra.informatik.tu-chemnitz.de Hello saturn.hrz.tu-chemnitz.de ...
250-EXPN
250-SIZE
250 HELP
MAIL FROM: <fri@hrz.tu-chemnitz.de>; SIZE=100000000
452 <fri@hrz.tu-chemnitz.de>... Insufficient disk space; try again later
QUIT
Wir sehen, daß die Größe als Parameter des Kommandos MAIL FROM: angegeben wird. Erwartungsgemäß lehnt der MTA ab, er hat wohl keine 100 MB für unsere (fiktive) Nachricht frei. Allerdings besteht Hoffnung, da ein temporärer Fehler gemeldet wurde (Reply-Code 452). Der Klient kann also weiter versuchen, die Mail zuzustellen.


Frage 6.4.2.1:

Die meisten MTAs reagieren recht lustig auf Fehleingaben (was vom Humor der Systemadministratoren zeugt). Wenn beispielsweise das HELO-Kommando mit dem falschen Hostnamen ausgeführt wird, passiert beim mailhost.tu-chemnitz.de folgendes:

HELO jupiter.hrz.tu-chemnitz.de
250 obelix.hrz.tu-chemnitz.de: You are bluffing - `caliban.informatik.tu-chemnitz.de` expected
Wie erkennt der MTA, daß angegebener und tatsächlicher Host nicht übereinstimmen?


Frage 6.4.2.2:

Für welche Anwendungsfälle ist die ESMTP-Erweiterung "Remote Message Queue Starting" sinnvoll?


Frage 6.4.2.3:

Wenn ein MTA bei der Übertragung einen schweren Fehler (Reply-Code >= 500) erhält, wird er die Nachricht an den Absender zurückschicken. Wird ein temporärer Fehler gemeldet, versucht er wieder, die Mail zu versenden. Nennen Sie Beispiele für beide Fehlertypen!


Frage 6.4.2.4:

Die maximale Zeit, in der ein MTA die temporär fehlgeschlagene Auslieferung versucht, ist häufig konfigurierbar. Wie lang sollte diese Dauer sein? Was sind die Vor- und Nachteile einer langen Dauer?


Vertiefung:


© Uwe Hübner, Heino Gutschmidt, Holger Trapp, 1.7.1998