ESMTP, SMTP AUTH und TLS einfach erklärt
Von Lukas Beeler (lb auf trash.net)
ESMTP Einführung
ESMTP ist heute einer der integralen Bestandteile von E-Mail. Via SMTP gelangen die Mails vom Sender (ein MTA oder MUA) bis zum MTA des Empfängers. Dort werden sie gespeichert, und können dort entweder lokal betrachtet werden, oder mit IMAP/POP3 heruntergeladen werden. ESMTP ist eine Erweiterung (Extension) von SMTP. Wenn man heutzutage von SMTP spricht, meint man meistens ESMTP. Dieser Text soll eine kleine Einführung in die grosse und vielfältige Welt von E-Mail geben.
Wie sieht ESMTP aus ?
ESMTP ist ein sehr leichtverständliches Protokoll. Der Aufbau ist logisch, und übersichtlich. Eine einfache, ohne Features ausgestatte SMTP Konversation sieht in ungefähr so aus:
<<< 220 a.mx.projectdream.org NO UCE/UBE ESMTP >>> ehlo mail.trash.net
Der Server meldet seine Bereitschaft, und wir melden zurück, das wir ESMTP unterstützen (ehlo statt helo bei SMTP), zudem geben wir unseren Hostnamen an.
<<< 250-a.mx.projectdream.org NO UCE/UBE <<< 250-PIPELINING <<< 250 8BITMIME
Der Server meldet uns zurück, welche ESMTP Features er unterstützt.
>>> mail from: <lb@trash.net> <<< 250 ok
Wir geben an, wer Bounce-Nachrichten (Fehlermeldungen) für diese Mail bekommen soll. Dieser Envelope Sender muss nichts mit dem From: Header weiter unten zu tun haben.
>>> rcpt to: <lb@projectdream.org> <<< 250 ok
Hier geben wir an, an wen diese Mail verschickt werden soll. Auch der Envelope Receiver muss nichts mit dem To: Header zu tun haben (Beispiel: Mailinglisten).
>>> data <<< 354 go ahead
Wir geben an, das wir jetzt damit anfangen, die eigentliche Mail zu senden. Diese besteht meistens aus einem Header nach RFC 822 (TODO: verlinken), und der eigentlichen Nachricht. Unsere Beispielnachricht ist text/plain, 7bit. MIME und verschiedene Content Encodings würden den Rahmen dieser Einführung sprengen.
>>> From: Lukas Beeler <lb@trash.net> >>> To: Lukas Beeler <lb@projectdream.org> >>> Subject: Test >>> Message-ID: <5e94c0cccf8c884c074279cd9a8d2e76@trash.net> >>>
Dies ist ein verkürzter Header ( Details: RFC 822, 2045 und 2046 ), der unvollständig ist, aber zum Verständnis ausreichend. In unserem Beispiel entsprechen die From: und To: Header den Envelope Sender bzw. Receiver.
>>> Dies ist eine Testnachricht >>> . <<< 250 ok 1014504830 qp 2850
Dies ist die eigentliche Nachricht. Sie wird mit einem alleinstehenden Punkt auf einer Linie abgeschlossen, und der Server bestätigt uns den erfolgreichen Empfang, und trägt von nunan die Verantwortung über die Auslieferung dieser Mail.
>>> quit <<< 221 a.mx.projectdream.org NO UCE/UBE
Wir senden den Befehl quit, und teilen damit dem Server mit, das wir gerne die Verbindung beenden würden. Dieser bestätigt das, und beendet die Verbindung.
Dies war ein eher kleiner Überblick über SMTP. Ich möchte noch genauer auf SMTP AUTH und TLS eingehen. Wer sich zum Thema SMTP noch intensiver informieren möchte, dem empfehle ich einen Blick ins RFC ( 2821 und 2822 )
SMTP AUTH
Die technischen Details von SMTP AUTH sind zu kompliziert, um hier komplett erklärt zu werden. Für den technisch interessierten empfehle ich auch hier wieder einen Blick ins RFC ( 2554 ).
Die Aufgabe von SMTP AUTH ist es, dem eigentlich benutzerlosen Protokoll SMTP eine Möglichkeit der Authentifizierung hinzuzufügen. Der wichtigste Grund ist es Benutzern mit dynamischen IP Adressen eine Möglichkeit zur Identifikation gegenüber dem MTA zu geben. SMTP AUTH wurde geschaffen, um Bastellösungen wie SMTP-after-POP3 überflüssig zu machen. Dies wurde durch die Einführung des neuen Befehls "auth" ermöglicht. Nun bieten sich hier mehrere Möglichkeiten, das Passwort zu übermitteln. Der wohl einfachste weg ist auth plain, bei dem das Passwort als plaintext übermittelt wird. Dies ist im heutigen Internetzeitalter nicht mehr zumutbar. Deswegen existieren Möglichkeiten, das Passwort verschlüsselt zu übermitteln, z.B. mit CRAM-MD5. Bei der Benutzung von TLS kann man jedoch auch gefahrlos auth plain benutzen.
TLS/SSL
TLS bzw. SSL ist eine Möglichkeit Traffic auf Layer 3 zu verschlüsseln. Auch andere Protokolle nutzen TLS. TLSv1 basiert auf SSLv3, welches ursprünglich von Netscape entwickelt wurde. https ist nichts anderes als normales http über eine mit TLS gesicherte Verbindung. Auch bei SMTP wird TLS benutzt. Dies geschieht nach dem ehlo Kommando durch das senden von starttls. Damit wird die SSL geschützte SMTP Verbindung initialisiert, und von diesem Moment an ist die gesamte Verbindung verschlüsselt, und damit mehr oder weniger sicher. Jetzt kann auch auth plain gefahrlos verwendet werden. Wichtig ist jedoch, das TLS Software wie PGP in keinster weise ersetzt. Sie sichert nur die Verbindung zwischen zwei Mailservern ab, und bietet nur einen Schutz für die Authentikationsdaten, aber nicht für den Inhalt der Mail selbst. Auch hier empfiehlt sich für den technisch Interessierten einen Blick in die entsprechenden RFC's ( 2246 und 2487 ).