SMTP – Die stille Sprache der Maschinen: Wie ein Protokoll aus den 1980ern die E-Mail revolutionierte (und bis heute trägt)

Autor: DerSchneider

Einleitung

Jeden Tag rasen über 300 Milliarden E-Mails um den Globus. Wir klicken auf „Senden“ und erwarten, dass die Nachricht Sekunden später – über Kontinente und Rechenzentren hinweg – im Postfach des Empfängers landet. Dass dieser digitale Wunderakt überhaupt funktioniert, verdanken wir einem unscheinbaren, fast unsichtbaren Protokoll: dem Simple Mail Transfer Protocol (SMTP).

„Simple“ (einfach) ist dabei eine fast schon ironische Untertreibung. Hinter der Einfachheit des Befehlszeilen-Dialogs verbirgt sich ein hochrobustes, jahrzehntealtes System aus Servern, Warteschlangen, Weiterleitungen und Fehlerbehandlungen. Dieser Artikel nimmt Sie mit auf eine Reise durch die Entstehung, Funktionsweise, Schwächen und Zukunft des Protokolls, das die Welt der elektronischen Post erst möglich gemacht hat. Wir zerlegen SMTP in seine Bestandteile, schauen auf seine historischen Wurzeln im Arpanet und wagen einen Blick auf seine Rolle im Zeitalter von Verschlüsselung, Spam und alternativen Messengern.

Hauptteil

1. Historische Entwicklung: Vom Arpanet zum Weltstandard

Die Geburtsstunde von SMTP fällt in das Jahr 1981. Der Bedarf für ein standardisiertes Verfahren zum Austausch von Nachrichten zwischen verschiedenen Rechnern war im Arpanet, dem Vorläufer des Internets, längst erkennbar. Vorläufer wie MAIL und MLFL waren jedoch an spezifische Systeme gebunden.

Jonathan B. Postel, einer der Gründerväter des Internets, veröffentlichte den RFC 788 (Simple Mail Transfer Protocol). Zwei Jahre später folgte der bis heute grundlegende RFC 821 (1982). Postels Geniestreich war es, ein Protokoll zu entwerfen, das:

• textbasiert ist (menschenlesbare Befehle),
• asynchron arbeitet (Nachrichten können zwischengespeichert werden),
• push-orientiert ist (der sendende Server drückt die Nachricht zum empfangenden),
• keine zentrale Instanz benötigt (dezentrales Routing).

Die eigentliche Explosion des E-Mail-Verkehrs kam jedoch erst mit der breiten Internetnutzung in den 1990ern. SMTP musste erweitert werden: ESMTP (Extended SMTP, RFC 1869) brachte Befehle für Authentifizierung (AUTH), Verschlüsselung (STARTTLS) und größere Anhänge (SIZE). Heute ist SMTP in Versionen wie SMTP-LM (Local Mail) und SMTP-Submission (Port 587) differenziert, doch der Kern ist derselbe geblieben.

Wichtigste historische Meilensteine:

• 1971: Ray Tomlinson sendet erste Netzwerk-E-Mail (noch ohne SMTP)
• 1981: RFC 788 (erstes SMTP)
• 1982: RFC 821 (klassisches SMTP)
• 1995: RFC 1869 (ESMTP mit Erweiterungen)
• 1998: STARTTLS als Erweiterung (RFC 2487)

2. Funktionsweise im Detail: Der Dialog der Server

SMTP ist ein zustandsloses, textbasiertes Protokoll der Anwendungsschicht (OSI-Schicht 7). Es nutzt standardmäßig Port 25 für Server-zu-Server-Kommunikation, während Clients heute über Port 587 (Message Submission) mit Authentifizierung senden. Der ältere Port 465 (SMTPS mit implizitem TLS) gilt als veraltet, wird aber noch mancherorts unterstützt.

Ein typischer SMTP-Dialog läuft nach folgendem Schema ab (stark vereinfacht):

Jede Serverantwort enthält einen dreistelligen Statuscode (ähnlich HTTP):

• 2xx → Erfolg (z. B. 250 OK)
• 3xx → Zusätzliche Information nötig (z. B. 354 für DATA)
• 4xx → Temporärer Fehler (z. B. 450 Mailbox busy)
• 5xx → Permanenter Fehler (z. B. 550 Mailbox not found)

2.1 Das Relay-Prinzip

SMTP ist als Store-and-Forward-System konzipiert. Eine E-Mail wird nicht direkt vom Absender-PC zum Empfänger-PC geschickt, sondern über mehrere Mailserver weitergeleitet. Der sendende Server fragt über DNS-MX-Einträge den zuständigen Mailserver der Empfänger-Domain ab und übergibt die Nachricht dorthin. Ist der Empfänger-Server gerade nicht erreichbar, speichert der sendende Server die Nachricht zwischen und wiederholt die Zustellung später (Queueing). Nach spätestens 4–7 Tagen scheitert die Zustellung endgültig – der Absender erhält eine Bounce Message (z. B. 550 User unknown).

2.2 Verschlüsselung: STARTTLS vs. SMTPS

SMTP selbst ist unverschlüsselt – alle Befehle, Adressen und der Nachrichteninhalt fließen als Klartext. Das ist für ein modernes Sicherheitsverständnis ein Skandal. Deshalb wurde STARTTLS (RFC 3207) eingeführt: Ein Befehl innerhalb einer bestehenden SMTP-Sitzung, der eine TLS-Verschlüsselung aushandelt.

Praktische Konsequenz: Wenn Ihr E-Mail-Client auf Port 587 mit STARTTLS verbindet, ist die Übertragung zwischen Client und Server verschlüsselt. Die Server-zu-Server-Strecke nutzt dagegen oft kein STARTTLS, weil viele Administratoren es nicht zwingend konfigurieren. Ihre E-Mail fliegt also möglicherweise unverschlüsselt über das Internet.

3. Schwachstellen, Kontroversen und Gegenmaßnahmen

SMTP ist ein Produkt seiner Zeit – einer Zeit, in der das Internet aus vertrauenswürdigen Forschungseinrichtungen bestand. Diese Naivität rächt sich bis heute.

3.1 Fehlende Authentizität (E-Mail-Spoofing)

SMTP bietet keine eingebaute Möglichkeit, die Identität des Absenders zu prüfen. Jeder kann im MAIL FROM-Befehl eine beliebige Adresse angeben. Das ermöglicht Phishing, Spam und Betrug.

Gegenmaßnahmen (auf Protokoll-Ebene nachgerüstet):

• SPF (Sender Policy Framework, RFC 7208): Der Empfänger-Server prüft, ob der sendende Server im DNS der Absender-Domain als autorisiert eingetragen ist.
• DKIM (DomainKeys Identified Mail, RFC 6376): Der sendende Server signiert die E-Mail kryptografisch; der Empfänger prüft die Signatur per DNS.
• DMARC (RFC 7489): Legt fest, wie ein Empfänger mit Mails umgehen soll, die SPF/DKIM nicht bestehen (z. B. ablehnen oder in Spam-Ordner verschieben).

Trotzdem: Diese Techniken sind optional und werden nicht von allen Domains konsequent eingesetzt. SMTP selbst ist nach wie vor „gutgläubig“.

3.2 Spam und Missbrauch

Die niedrigen Kosten für den Versand einer E-Mail (fast null) und die fehlende Authentifizierung haben eine regelrechte Spam-Industrie entstehen lassen. Schätzungen zufolge sind über 45 % des gesamten E-Mail-Verkehrs Spam (Stand 2024). Das hat zu aufwändigen Filtern (z. B. Bayes-Filtern, RBLs – Real-time Blackhole Lists) geführt, die wiederum False Positives produzieren – wichtige Mails landen im Spam-Ordner.

3.3 Größenbeschränkungen und Anhänge

Ursprünglich war SMTP für reinen 7-Bit-ASCII-Text ausgelegt. Binäre Anhänge (Bilder, PDFs) sind nicht direkt übertragbar. Die Lösung heißt MIME (Multipurpose Internet Mail Extensions, RFC 2045-2049). MIME kodiert Binärdaten in Text (z.‒B. Base64) und fügt spezielle Header (Content-Type, Content-Transfer-Encoding) hinzu. Der Mail-Client dekodiert dies beim Empfang. Das ist ineffizient (ca. 33 % Datenaufblähung) und war jahrelang eine Quelle von Inkompatibilitäten.

4. SMTP vs. Moderne Messenger

Angesichts von WhatsApp, Signal, Telegram und Co. stellt sich die Frage: Ist SMTP noch zeitgemäß?

Die Stärke von SMTP ist seine absolute Offenheit und Dezentralität. Jeder kann einen eigenen Mailserver betreiben (auch wenn das aufgrund von Spam-Filtern heute schwer ist). Keine Firma kontrolliert das gesamte System. Diese Eigenschaft ist aus Sicht der Internetfreiheit unschätzbar wertvoll. Die Schwäche ist die fehlende Ende-zu-Ende-Verschlüsselung von Haus aus.

5. Zukunft von SMTP

SMTP wird nicht sterben. Dazu ist es zu tief in der Infrastruktur verwurzelt. Aber es wird sich weiter verändern:

• MTA-STS (RFC 8461): Erzwingt STARTTLS für bestimmte Domains und verhindert STRIPTLS-Angriffe.
• DANE (DNS-based Authentication of Named Entities, RFC 7672): Nutzt DNSSEC, um TLS-Zertifikate von Mailservern zu authentifizieren.
• SMTP Strict Transport Security: Ein Framework, um verschlüsselte Verbindungen zwischen Servern zu erzwingen.
• Alternativen wie JMAP (JSON Meta Application Protocol, RFC 8620): Moderneres Protokoll für E-Mail (Synchronisation, Push), aber SMTP bleibt für die Übertragung zwischen Servern bestehen.

Die Zukunft wird also nicht „SMTP abschaffen“, sondern „SMTP sicherer machen“. Die Grundlagen aus den 1980ern bleiben – nur mit immer dickeren Sicherheitsschichten überzogen.

Fazit und Ausblick

SMTP ist ein Paradebeispiel für die Genialität und die Naivität des frühen Internets. Ein Protokoll, das so simpel ist, dass es auf jedem Rechner implementiert werden kann – und so unsicher, dass Jahrzehnte an Erweiterungen nötig waren, um es in einer feindseligen Umgebung (dem heutigen Internet) überlebensfähig zu machen.

Was SMTP auszeichnet, ist seine Resilienz: Es akzeptiert temporäre Fehler, speichert Nachrichten zwischen und gibt niemals auf, bevor eine E-Mail endgültig zugestellt oder als unzustellbar zurückgewiesen wurde. Diese Philosophie der „besten Bemühungen“ ist das genaue Gegenteil von modernen Echtzeit-Protokollen – aber sie ist genau richtig für ein System, das auf globaler Skala zuverlässig Nachrichten transportieren muss.

Für den Nutzer bleibt SMTP unsichtbar. Das ist auch gut so. Wir sollten uns jedoch bewusst sein: Jedes Mal, wenn wir auf „Senden“ klicken, vertrauen wir auf ein Protokoll, das älter ist als die meisten heutigen Programmierer. Ein Protokoll, das seine Kinderkrankheiten nie ganz abgelegt hat, aber durch kluge Erweiterungen und Community-Pflege immer wieder fit gemacht wurde. SMTP wird uns noch lange begleiten – still, robust und manchmal auch etwas störrisch. So wie ein guter Postbote.

Quellen

1. Postel, J. (1982). RFC 821: Simple Mail Transfer Protocol. IETF. https://datatracker.ietf.org/doc/html/rfc821
2. Klensin, J. (2001). RFC 2821: Simple Mail Transfer Protocol. IETF. (Aktualisiert RFC 821)
3. Hoffman, P. (2007). RFC 5321: Simple Mail Transfer Protocol. IETF. (Aktualisiert RFC 2821)
4. Freed, N. (1996). RFC 1869: SMTP Service Extensions. IETF.
5. Crocker, D. (2008). RFC 5322: Internet Message Format. IETF.
6. Freed, N., Borenstein, N. (1996). RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One.
7. Kitterman, S. (2014). RFC 7208: Sender Policy Framework (SPF).
8. Internet Society. (2023). Email Security: A Historical Perspective. ISOC Briefing Paper.
9. Statista. (2024). Annual number of spam emails per day worldwide. https://www.statista.com
10. Eckert, C. (2021). IT-Sicherheit: Konzepte – Verfahren – Protokolle. De Gruyter Oldenbourg. (Kapitel zu Mail-Protokollen)