SMTP - Versenden von Mails
Willemers Informatik-Ecke
Auf dieser Seite wird das Protokoll SMTP (Simple Mail Transfer Protocol) zur Versendung von Mails behandelt. Als implementierender Server wird häufig Postfix verwendet, dessen Installatino und Konfiguration auf folgender Seite beschrieben wird.

Geschichtliches

Mails sind vermutlich die älteste Internet-Anwendung. Es ist verhältnismäßig einfach zu bedienen, wird aber komplizierter, wenn man die dahinterliegenden Server betrachtet.

Der zentrale Großrechner

Die historische Betrachtung macht es vielleicht einfacher zu verstehen. Als die Computer noch Räume oder Etagen füllten, hatte eine Firma oder Hochschule bestenfalls einen Computer, auf dem alle Teilnehmer per Terminal angeschlossen waren. Jeder hatte seinen Account.

Es gab die Möglichkeiten, Nachrichten im Haus zu versenden, die mehr oder weniger darin bestanden, dass die Mail in einer lokalen Datei des Empfängers landete.

Netzwerkverbindung unter Großrechnern

Als die Großrechner per Telefon oder anderer WAN-Techniken verbunden wurden, insbesondere in den Anfängen des Internets, wurde es interessant, Mails auch zwischen den Computern zu versenden. Um deutlich zu machen, dass der Empfänger nicht lokal ist, wurde ein @-Zeichen und der Name des Zielrechners an den Benutzernamen angehängt.

Für den Austausch der Nachrichten zwischen den Großrechnern wurde das Protokoll SMTP (Simple Mail Transport Protocol) geschaffen.

Dezentrale Verarbeitung mit PCs

Die Situation veränderte sich noch einmal mit der Verbreitung der Personal Computer. Die PCs waren nicht dauerhaft eingeschaltet und schon gar nicht dauernd mit dem Internet verbunden. Die Mails mussten also geholt werden, was SMTP nicht konnte.

Als Flatrates noch nicht Allgemeingut waren, wurden die Internetkosten nach Zeit abgerechnet. Darauf ist das Protokoll POP3 spezialisiert. Es holt alle neuen Mails auf dem Server und schließt dann die Verbindung. Die Nachrichten können auf dem lokalen PC bearbeitet werden.

Inzwischen ist die Verbindung zum Internet kein Kostenfaktor mehr. Vor allem ist die Dauer für die meisten Benutzer uninteressant. Inzwischen haben aber viele Benutzer zwei oder mehr Geräte, auf denen sie ihre Mails bearbeiten wollen. Und natürlich sollte der Bearbeitungszustand auf allen Geräten gleich sein.

Dieses Ziel führt dazu, dass die Mails nicht mehr lokal auf dem PC, sondern wieder zentral auf dem Server liegen müssen. Das Protokoll IMAP holt die Mails also nicht ab, sondern regelt die Bearbeitung der Mails auf dem zentralen Mailserver.

Übersicht der Protokolle

SMTP
beschreibt das Senden der Mails an einen Mail-Server, der ständig zur Verfügung steht. Dieser kann die Mails entweder an einen anderen Mail-Server weitersenden oder, falls er der Zielserver ist, die Mails an seine User verteilen.
POP3
Mit dem Aufkommen von PCs ist der Empfänger nicht rund um die Uhr erreichbar. Der PC holt sich die angefallene Mail vom Server ab und speichert sie lokal. Für diesen Austausch wurde POP3 geschaffen, das auf dem Hintergrund von Internetverbindungen geschaffen wurden, die nach Zeit bezahlt wurden. Es gilt also, die Post in einem Schub zu holen und zu versenden, um dann die Verbindung schnell wieder schließen zu können.
IMAP
Mit dem Aufkommen der Flatrates spielt die Verbindungszeit keine Rolle. Außerdem hat ein Benutzer mehr als nur einen Mail-Client (PC, Laptop, Smartphone) und will, dass seine Mail von allen Geräten gleich aussehen. Darum werden diese auf dem Mail-Server gehalten und dort bearbeitet.

Simple Mail Transfer Protocol (SMTP)

Protokolleigenschaften

SMTP (Simple Mail Transfer Protocol) ist das Protokoll für das Versenden von Mails.

Ports und Sicherheit

Der Port 465 wurde ursprünglich inoffiziell in Betrieb genommen. Darüber wird typischerweise mit TLS verschlüsselt. Port 587 wurde offiziell mit STARTTLS in RFC 2476 standardisiert. Zu diesem Zeitpunkt wurde von Port 465 abgeraten. Mit der RFC 8314 wurde wiederum der Port 465 mit TLS empfohlen.

Hintergrund SMTPS in Wikipedia

Der Client sendet

Das Protokoll zwischen Client und Server ist verbindungsorientiert. Der Client authentifiziert sich (nicht zwingend in SMTP 1.0).

Die SMTP-Kommandos

Dem Client stehen unter anderem die folgenden Kommandos zur Verfügung:

Nachrichteninhalt hinter DATA

Die eigentliche Nachricht, also das, was den Benutzer wirklich interessiert, folgt nach dem Kommando DATA. Dieser Teil besitzt zunächst einen Header. Hier können die folgenden Einträge stehen: Der Header endet durch eine Leerzeile. Anschließend folgt der Nachrichtentext. Dessen Ende wir durch eine Zeile, die nur einen Punkt enthält, gekennzeichnet.
DATA
Subject: Lobhudelei
Date: Sat, 20 Oct 2023 12:13:09 +0200
From: Herzallerliebst <hugo@hs-flensburg.de>
To: Sausack vom Campus <ruepel@uni-gintoft.de>

Du mich auch!
.
Es ist zunächst verwirrend, dass mit To: und From: offenbar im Header der DATA-Sektion die Einträge von RCPT TO: und MAIL FROM: wiederholt werden.

Der Unterschied liegt darin, dass MAIL FROM: als technische Adresse verstanden wird. Die Mail wurde also tatsächlich von dieser Adresse gesandt. Dagegen ist der Eintrag From: ein Teil des Dateninhalts der Mail. Man könnte es boshaft als den dekorativen Teil der Adresse beschreiben, die dam Empfänger von seinem Mail-Client vorgegaukelt wird.

Gleiches gilt für den Empfänger, den Betreff und das Datum. All diese Daten können gefälscht sein, ohne dass sich der Mail-Server daran stört.

Noch kritischer sind die Adressen in Smartphone-Clients. Hier wird bei einem Absender Dein treuer Freund<angreifer@mafia.ru> oft die E-Mail-Adresse in spitzen Klammern, hier angreifer@mafia.ru weggelassen, um Oma Puvogel nicht mit technischen Details zu erschrecken. Die glaubt dann, dass der Absender ihr treuer Freund ist. Dabei ist der Text neben der E-Mail-Adresse in jedem besseren Mail-Client leicht veränderbar.

Beispielsweise bei Thunderbird lässt sich der komplette Rohtext der empfangenen Mail mit der Buchstabenkombination [Strg]+[U] ansehen. Damit können offensichtliche Täuschungen erkannt werden.

Die Status-Antworten des Servers

Auf jede Anfrage des Clients liefert der Server eine Statusmeldung ab, die dem Client mitteilt, ob alles klar ist. Diese ist eine dreistellige Zahl mit einem kurzen erklärenden Text.

Die erste Ziffer sagt etwas über den Charakter des Status aus.

Code Bedeutung
1xx Die Anforderung ist akzeptiert, aber noch nicht verarbeitet. Bestätigung erforderlich.
2xx Die Anforderung wurde erfolgreich ausgeführt.
3xx Die Anforderung ist verstanden, benötigt aber weitere Informationen.
4xx Temporärer Fehler. Kann nach Wiederholung möglicherweise erfolgreich abgeschlossen werden.
5xx Fataler Fehler.

Beispiele für Statusmeldungen

Das Versenden einer Mail auf Protokollebene

Das folgende Beispiel zeigt die Unterhaltung zwischen Client und Server:

S: 220 hamburger.edu 
C: HELO crepes.fr 
S: 250 Hello crepes.fr, pleased to meet you 
C: MAIL FROM: <alice@crepes.fr> 
S: 250 alice@crepes.fr... Sender ok 
C: RCPT TO: <bob@hamburger.edu> 
S: 250 bob@hamburger.edu ... Recipient ok 
C: DATA 
S: 354 Enter mail, end with "." on a line by itself 
C: Do you like ketchup? 
C: How about pickles? 
C: . 
S: 250 Message accepted for delivery 
C: QUIT 
S: 221 hamburger.edu closing connection
Quelle: www.cs.umd.edu/~shankar...

SMTP ist ein textorientiertes Protokoll. Solange unverschlüsselt über den Port 25 kommuniziert wird, kann man mit dem SMTP-Server direkt von der Tastatur sprechen. Dazu benötigt man einen Telnet-Client, dem als erster Parameter die Adresse des Servers und danach die Nummer des Ports angegeben wird.

telnet mailserver 25
Hier ein paar Beispielbefehle für eine SMTP-Sitzung per telnet:

HELO, EHLO und OLHE
Der Client sendet HELO, EHLO oder OLHE gefolgt vom FQHN (Fully Qualified Host Name), also dem Hostname inklusive Domain, um eine Sitzung zu eröffnen. Als Antwort erhält er 220, als Zeichen der Zufriedenheit des Servers. OLHE führt dazu, dass der Server eine Liste seiner Befehle ausgibt und einige Statusmeldungen liefert.
MAIL From: donald@duck.de
Mit dem MAIL-From-Kommando gibt der Client an, wer der Absender ist. Dieser Absender wird von den meisten ISPs geprüft. Trifft man auf einen SMTP-Server, der beliebige Absender-Adressen akzeptiert, lassen sich so beliebige Absender fälschen.
RCPT To: alice@wunderland.de
Mit diesem Befehl wird die Empfängeradresse übergeben.
DATA
Auf die Sendung von DATA reagiert der Server mit der Antwort 354 und erwartet das Senden des Datenbereichs der Mail.

Im DATA-Bereich werden im Headerbereicht Betreff, Absender und Empfänger genannt. Diese Angaben werden nicht vom SMTP-Server ausgewertet, sondern vom Client angezeigt. Darum ist es relativ einfach, diese zu fälschen.

Subject: Was Du schon immer wissen wolltest
Date: Wed, 17 Apr 2019-17:13:09 +0200
From: alice@sender.com
To: bob@receiver.com
Es folgt nach einer Leerzeile der eigentliche E-Mail-Inhalt. Der Datenbereich wird mit CR-LF Punkt CR-LF abgeschlossen. Dies beantwortet der Server mit 250.
QUIT
Der Client beendet die Sitzung mit dem Befehl QUIT, was der Server mit 221 beantwortet. Die Verbindung wird beendet.

Multipurpose Mail Extension (MIME)

Der eigentliche Mail-Text war von vornherein auf druckbare ASCII-Zeichen beschränkt, da es ja eigentlich nur um einfache Nachrichten im Telegrammstil ging. Es war nicht einmal vorgesehen, internationale Sonderzeichen zu verwenden, geschweige denn Bilder, Videos oder Dokumente als Anhang.

Base64-Kodierung

Um binäre Daten, insbeondere Anhänge zu versenden, müssen die binären Daten, die 256 unterschiedliche Werte in einem Byte darstellen können, in druckbare Zeichen umzuwandeln. Dazu werden aus je drei Bytes vier 6-Bit-Blöcke aufgeteilt. Das bedeutet, dass Anhänge für den Transport noch einmal nicht unerheblich "aufgeblasen" werden.

Mit dieser Umkodierung, die man Base64 nennt, ist es möglich, binäre Daten innerhalb eines Mail-Inhalts zu versenden.

Der MIME-Typ

Das einfache Versenden binärer Daten müssen aber mit der Information begleitet sein, ob es sich bei den Daten um ein Bild, ein Video oder ein Office-Dokument handelt. Selbst bei einfachen Texten ist es wichtig zu wissen, wie diese interpretiert werden sollen, also beispielsweise HTML, XML oder JSON.

MIME definiert neben diesen Datentypen auch die Anwendungen, die mit den Datentypen umgehen können. Hier einige Beispiele:

Im Mail-Header wird der MIME-Block angekündigt.
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Type: image/jpeg
Wenn mehrere MIME-Typen versendet werden sollen, wird ein Multipart Header verwendet.
MIME-Version: 1.0
Content-Type: multipart/mixed;
    boundary="0001labelanhang"

--0001labelanhang
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.=
w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
...
</body>
</html>
--0001labelanhang--

--0003nochnlabel
Content-Type: application/pdf;
    name="Protokoll vom 12 06 2019.pdf"
Content-Description: Protokoll vom 12 06 2019.pdf
Content-Disposition: attachment;
	filename="Protokoll vom 12 06 2019.pdf"; size=286845;
	creation-date="Fri, 21 Jun 2019 07:15:54 GMT";
	modification-date="Fri, 21 Jun 2019 07:17:58 GMT"
Content-Transfer-Encoding: base64

4zqhfm9Kss+ke2QsrlZ7jPzWX1iklCNSYgcf5hOSiRpmclDudo/8DT31FS4y6kt9j0rW+InCxaN4
+R9pGlkc0hjtawwqmm4UBzzXFiUTueyW57gyUDbqGNujAwPOgg4eu3Z8/CnycIbjQhMT1c1kKlZN
...
jy8X8xwt83EechMnNmzAZRmBzT7pcyc1JyhnB6+7R1crPmEBEw86ekFSrDAkMNTNXXvRTxge4oMM

--0003nochnlabel--

Sicherheit

Spätestens seit Edward Snowdons Veröffentlichungen im Jahre 2013 sollte man sich Gedanken machen, dass Geheimdienste aller Staaten ihren und noch mehr fremden Bürgern hinterherschnüffeln und diese Informationen beliebig missbrauchen.

Verschlüsselte Übertragung

SMTP sendet in seiner ursprünglichen Form alle Daten im Klartext unverschlüsselt über die Leitung.

Die Erweiterungen des SMTP verwenden für die Übertragung eine Verschlüsselung. Wie oben beim Thema Ports schon ausgeführt, werden dazu die Ports 465 bzw. 587 verwendet.

Eine solch verschlüsselte Übertragung macht es schwierig bis unmöglich, die Daten auf dem DENIC-Knoten oder über einen öffentlichen WLAN-Hotspot abzufischen.

Die verschlüsselte Übertragung bedeutet aber nicht, dass die Nachrichten selbst verschlüsselt sind. Wer den Zugriff auf einen Mail-Server bekommt, kann die Nachrichten dort immer noch lesen.

Verschlüsseln von Mails

Um zu unterbinden, dass Mails auf Ziel- oder Zwischenservern einfach im Klartext gelesen werden können, muss dafür sorgen, dass der Mail-Inhalt selbst verschlüsselt wird. Man spricht auch von einer Ende-zu-Ende-Verschlüsselung.

Für die Verschlüsselung von Mails wurde bereits zu Zeiten des Kalten Kriegs PGP bzw. später dessen Open-Source-Implementierung GnuPG entwickelt.

Das Grundprinzip basiert auf der Verwendung eines Schlüsselpaares (asymetrische Verschlüsselung). Der eine Teil des Schlüsselpaares kann nur das entschlüsseln, was der andere verschlüsselt hat. Bei der Verwendung wird ein Teil des Paares als privater Schlüssel geheim verwahrt. Der andere Teil dagegen wird als öffentlicher Schlüssel an alle potentiellen Kommunikationspartner verteilt, beispielsweise durch Download auf der eigenen Homepage oder in öffentlichen Schlüsselservern.

Verschlüsseln

Habe ich einen öffentlichen Schlüssel einer Person, kann ich eine Mail oder Datei mit diesem Schlüssel verschlüsseln. Diese kann mit dem öffentlichen Schlüssel nicht entschlüsselt werden, sondern nur mit dem privaten Schlüssel. Hat der Partner diesen Schlüssel nicht herausgegeben, kann nur er diese Nachricht entschlüsseln.

Signieren

Auch als digitale Unterschrift kann solch ein Schlüsselpaar verwendet werden. Dazu wird eine Prüfsumme (bspw CRC) über den Mailinhalt errechnet und diese mit dem privaten Schlüssel verschlüsselt und angehängt. Nun kann jeder, der Zugriff auf den öffentlichen Schlüssel hat, die Prüfsumme entschlüsseln und weiß zunächst, dass der Absender im Besitz des privaten Schlüssels sein muss. Daneben kann er mit der Prüfsumme nachprüfen, ob der E-Mail-Inhalt seit der Signierung manipuliert wurde. Dann nämlich stimmt die Prüfsumme nicht mehr.

Schlüsselerzeugung

Thunderbird bringt mit seiner Erweiterung Enigmail ein Tool mit, um das Ver- und Entschlüsseln sowie das Signieren von Mails umzusetzen. Er stellt auch ein Tool zur Erstellung solcher Schlüssel zu Verfügung, die es auch Anfängern ermöglichen solche Schlüssel zu erzeugen und zu verwalten.

Es ist aber auch mit Open-Source-Produkten möglich, solche asymmetrische Schlüssel zu erzeugen. Damit lassen sich dann auch einzelne Dateien verschlüsseln und beispielsweise als Anhang versenden.

MIME-Unterstützung

Bei allen verschlüsselten Texten oder sonstigen Daten ergeben sich natürlich binäre Datenstrukturen, die wie bekannt nicht von Standard-Mails übertragen werden können. Darum werden sie automatisch als MIME-Anhänge versandt. Damit der Empfänger weiß, womit er zu tun hat, gibt es die MIME-Typen multipart/encrypted und multipart/signed.

Relay und Spam

Da Mails billig und schnell sind, werden sie gern für Werbung missbraucht. Das Problem ist nicht nur für den Empfänger lästig, sondern vor allem für die Provider, da diese inzwischen einen erheblichen Teil der Internetlast einnehmen.

Der einfachste Weg, dies auszutrocknen, wäre, niemals auf eine unaufgefordert zugesante Mail zu reagieren. Leider reicht bereits ein Promillesatz an willigen Opfern, damit sich Spams rechnen.

Ein weiteres Feld neben der Werbung ist der Versand von Trojanern, die bei unsicheren Betriebssystemen und unaufmerksamen Benutzern schnell dazu führen, dass ein LAN von außen angreifbar macht.

Authentifizierung

Bei der Einführung von Mails ging man davon aus, dass ein öffentlicher Briefkasten ja auch kein Schloss benötigte und führte darum keine Authentifizierung ein. Ein SMTP-Server sollte kollegial anderen SMTP-Servern beim Austragen der Post helfen.

Mit dem Aufkommen von unerwünscht versendeten Werbemails (Spam) wurden solche offenen Zugänge (Relay) aber von Mail-Versendern missbraucht, die die Herkunft ihrer Mails verschleiern wollten.

Um die Flut der unerwünschten Mails in den Griff zu bekommen, werden heute eigentlich bei jedem Server Benutzerkennung und Passwort verlangt.

Relay-Server

Ein Relay-Server ist ein Server, der von einem anderen Server Mails entgegen nimmt und an andere Mail-Server weiterleitet.

Ein solcher Relay-Server wird benötigt, wenn ein Programm Mails versenden möchte, aber keinen eigenen Mailserver zur Verfügung hat.

Ein Relay-Server sollte so eingerichtet sein, dass er für die Mails des Senders oder des Empfängers zuständig ist. Wird dies nicht überprüft, wird von einem Open-Relay gesprochen. Solche Server können von Spam-Versendern missbraucht werden, um die Herkunft der Mail zu verschleiern.

Blacklists und Spamfilter

Es gibt ein großes Interesse, SMTP-Server auszuschalten, deren Konfiguration es den Spammern ermöglicht, ihre Werbung und ihre Attacken zu verteilen.

Wird ein offenes Relay oder ein Server ohne Authentifizierung entdeckt, landet er schnell in einer Blacklist. Oftmals wird der Betreiber des Servers darüber nicht informiert.

Die Adressen, die in der Blacklist gesammelt werden, dienen dann als Quelle für Spamfilter. Das führt dazu, dass Mails von dem verdächtigen Server nicht direkt ausgeliefert werden, sondern im Spamfiltern des Empfängers landen.

Dadurch wird die Auslieferung erheblich verzögert oder sogar ganz verhindert, wenn der Benutzer von seinem Mailserver nicht zeitnah informiert wird, welche Mails im Spamfilter gelandet sind.

Gerade kleinere Firmen sind manchmal nicht mit dem Knowhow ausgestattet, um Fehler in ihrer Konfiguration zu erkennen. Für sie ist die Auflistung in einer Blacklist häufig spät erkennbar und die Ursache manchmal schwer verständlich. Das Freischalten aus der Blacklist wird meist mit Gebühren belegt. Ist nach der Freischaltung die Konfiguration immer noch nicht ganz sauber, landet der Server erneut auf der Blacklist. Das erklärt manch verzweifeltem Administrator die begriffliche Nähe von Blacklist zu Blackmail.