Jeden Tag durchqueren über 300 Milliarden E-Mails das Internet. Sie reisen zwischen Servern, von denen du noch nie gehört hast, durch Netzwerke, die du nie sehen wirst, mit einem Protokoll, das 1982 entworfen wurde. Dieses Protokoll ist SMTP—Simple Mail Transfer Protocol—und trotz seines Alters bleibt es das Rückgrat der E-Mail-Kommunikation.
Die meisten Entwickler arbeiten mit E-Mail über High-Level-APIs, die die zugrunde liegende Mechanik abstrahieren. Du rufst eine Funktion auf, übergibst ein paar Parameter, und E-Mail passiert. Aber wenn etwas schiefgeht—and it will go wrong—macht das Verständnis dessen, was unter der Haube tatsächlich passiert, den Unterschied zwischen effektivem Debuggen und blindem Herumstochern.
Die SMTP-Konversation
SMTP ist ein textbasiertes Protokoll, was bedeutet, dass du wortwörtlich ein Gespräch mit einem Mail-Server über telnet oder netcat führen kannst. Das ist nicht nur eine Kuriosität—es ist eine mächtige Debugging-Technik. Schauen wir uns an, wie dieses Gespräch aussieht.
Wenn dein Mail-Server eine E-Mail senden will, ermittelt er zunächst den Mail-Server des Empfängers mithilfe von DNS MX-Records. Wenn du an [email protected] sendest, fragt er die MX-Records für example.com ab, um herauszufinden, welcher Server die Mail für diese Domain verarbeitet.
Dann öffnet er eine TCP-Verbindung zu diesem Server, typischerweise auf Port 25 (oder 587 für Submission, oder 465 für implizites TLS). Der empfangende Server antwortet mit einer Begrüßung—meist einem 220-Statuscode und einigen Identifikationsinformationen.
Dein Server stellt sich mit EHLO (oder dem älteren HELO) vor und teilt seinen Hostnamen mit. Der empfangende Server antwortet mit einer Liste der unterstützten Erweiterungen—Dinge wie STARTTLS für Verschlüsselung, AUTH für Authentifizierung und SIZE-Limits.
Wenn beide Server STARTTLS unterstützen, verhandeln sie an dieser Stelle eine verschlüsselte Verbindung. Das ist opportunistische Verschlüsselung—schlägt sie fehl, fällt die Verbindung möglicherweise auf unverschlüsselte Übertragung zurück (es sei denn, eine Seite verlangt Verschlüsselung).
Jetzt folgt die eigentliche E-Mail-Übertragung. Dein Server sendet MAIL FROM mit der Envelope-Absenderadresse. Dann RCPT TO mit der Empfängeradresse (bei mehreren Empfängern entsprechend wiederholt). Der empfangende Server kann in jedem Schritt akzeptieren oder ablehnen—vielleicht existiert der Empfänger nicht, oder der Absender steht auf einer Blacklist.
Abschließend sendet dein Server DATA, gefolgt vom eigentlichen E-Mail-Inhalt (Header und Body), beendet durch eine Zeile, die nur einen Punkt enthält. Der empfangende Server akzeptiert die Nachricht (250 OK) oder lehnt sie mit einem Fehlercode ab.
Envelope vs. headers
Etwas, das viele Entwickler verwirrt: Die Adressen in der SMTP-Konversation (das 'Envelope') sind getrennt von den Adressen in den E-Mail-Headern. Sie können—und sind oft—unterschiedlich.
Die Envelope-Adressen (MAIL FROM und RCPT TO) werden fürs Routing verwendet. Sie bestimmen, wohin die E-Mail tatsächlich geht und wohin Bounces gesendet werden. Die Header-Adressen (From, To, Cc) sind das, was Empfänger in ihrem E-Mail-Client sehen.
Diese Trennung existiert aus legitimen Gründen. Mailinglisten nutzen sie: Der Envelope-Sender ist die Bounce-Adresse der Liste, während der Header From den ursprünglichen Autor zeigt. Weiterleitungen nutzen sie: Der Envelope ändert sich an jedem Hop, aber die Header bewahren den ursprünglichen Absender.
Aber diese Trennung ermöglicht auch Spoofing. Ein Angreifer kann den Header From auf jede beliebige Adresse setzen, während er für das Envelope seinen eigenen Server verwendet. Deshalb prüft SPF den Envelope-Sender, DKIM signiert die Header und DMARC verlangt eine Alignment zwischen beiden.
Relaying and smart hosts
In den frühen Tagen der E-Mail haben Server Nachrichten für jeden weitergeleitet. Du konntest dich mit jedem SMTP-Server verbinden und ihn bitten, Mail in deinem Namen zuzustellen. Dieses Open-Relay-Modell war bequem, wurde mit der Explosion von Spam aber untragbar.
Heute sind die meisten SMTP-Server so konfiguriert, dass sie nur für authentifizierte Nutzer oder bestimmte IP-Bereiche relayen. Wenn du versuchst, über einen Server zu senden, den du nicht benutzen darfst, bekommst du einen '550 relay not permitted'-Fehler.
Viele Organisationen verwenden eine 'smart host'-Konfiguration: Interne Systeme senden alle ausgehenden E-Mails an einen zentralen Server, der Authentifizierung, Queuing und die Zustellung ins Internet übernimmt. Das zentralisiert das E-Mail-Management und erleichtert die Umsetzung konsistenter Policies.
Cloud-E-Mail-Services funktionieren ähnlich. Wenn du eine API zum Senden von E-Mail verwendest, nutzt du ihre Server im Grunde als Smart Host. Sie übernehmen die SMTP-Komplexität, pflegen die IP-Reputation und kümmern sich um Zustellprobleme, damit du es nicht musst.
Error codes and what they mean
SMTP verwendet dreistellige Statuscodes, und sie zu verstehen hilft bei der Diagnose von Zustellproblemen.
Codes, die mit 2 beginnen, bedeuten Erfolg. 250 ist die standardmäßige 'OK'-Antwort. 251 bedeutet, der Nutzer ist nicht lokal, aber der Server wird die Nachricht weiterleiten.
Codes, die mit 4 beginnen, sind temporäre Fehler. 421 bedeutet, der Server ist vorübergehend nicht verfügbar. 450 bedeutet, das Postfach ist vorübergehend nicht verfügbar (vielleicht über Quota). 451 ist ein generisches 'try again later.' Dein Server sollte diese automatisch erneut versuchen.
Codes, die mit 5 beginnen, sind permanente Fehler. 550 ist die Sammelablehnung—Nutzer existiert nicht, relay denied, Policy-Ablehnung. 551 bedeutet, der Nutzer ist umgezogen. 552 bedeutet, die Nachricht ist zu groß. 553 bedeutet, die Adresssyntax ist ungültig. 554 ist ein generisches 'transaction failed.'
Die zweite Ziffer liefert mehr Kontext: x0x ist Syntax, x1x ist Information, x2x ist Verbindungen, x5x ist Mail-Systemstatus. In der Praxis ist der menschenlesbare Text hinter dem Code jedoch meistens informativer als der Code selbst.
Moderne Server enthalten oft erweiterte Statuscodes (wie 5.1.1 für 'bad destination mailbox address') und detaillierte Erklärungen. Beim Debuggen von Zustellproblemen solltest du immer die vollständige Fehlermeldung betrachten, nicht nur den Code.
SMTP in der modernen Welt
SMTP hat sich seit 1982 deutlich weiterentwickelt, auch wenn das Kernprotokoll wiederzuerkennen ist. Mehrere Erweiterungen sind für moderne E-Mail essenziell geworden.
STARTTLS ermöglicht Verschlüsselung für SMTP-Verbindungen. Es ist nicht perfekt—opportunistisch und anfällig für Downgrade-Angriffe—aber weit verbreitet und bietet einen sinnvollen Schutz gegen passives Mithören.
SMTP AUTH ermöglicht es Servern, Authentifizierung zu verlangen, bevor sie Mail zum Relay akzeptieren. So meldest du dich an, um E-Mails über die Server deines Providers zu senden.
CHUNKING und BINARYMIME ermöglichen eine effizientere Übertragung großer Nachrichten und binärer Inhalte, ohne den Overhead von base64-Encoding.
Trotz dieser Verbesserungen zeigt SMTP sein Alter. Es ist synchron und verbindungsorientiert, was schlecht skaliert. Es hat keine eingebaute Authentifizierung von Absendern (daher die Notwendigkeit von SPF/DKIM/DMARC). Es ist textbasiert, was fürs Debugging großartig, für große Volumina aber ineffizient ist.
Es gab Vorschläge, SMTP durch etwas Moderneres zu ersetzen, aber keiner hat Fuß gefasst. Die installierte Basis ist zu groß, die Interoperabilitätsanforderungen zu strikt. Auf absehbare Zeit bleibt SMTP die lingua franca der E-Mail.
Frequently asked questions
What's the difference between port 25, 465, and 587?
Port 25 ist für die Kommunikation zwischen Servern. Port 587 ist für Client-Submission (dein E-Mail-Client zu den Servern deines Providers) mit STARTTLS. Port 465 ist für implizites TLS (von Anfang an verschlüsselt). Die meisten Provider bevorzugen heute 587 oder 465 für Client-Verbindungen.
Why do my emails get rejected with 'relay denied'?
Der Server vertraut dir nicht, über ihn zu senden. Entweder bist du nicht authentifiziert, du versuchst an eine Domain zu senden, die der Server nicht verarbeitet, oder deine IP steht nicht auf der erlaubten Liste. Prüfe deine Authentifizierungseinstellungen.
Can I send email directly without using an email service?
Technisch ja, aber es ist unpraktisch. Du müsstest die IP-Reputation managen, Bounces handhaben, Authentifizierung implementieren, mit Rate Limiting umgehen und die Zustellbarkeit pflegen—alles Dinge, die E-Mail-Services für dich erledigen.
What happens if the recipient's server is down?
Dein Server stellt die Nachricht in eine Queue und versucht sie regelmäßig erneut zuzustellen. Die meisten Server versuchen es 4-5 Tage lang, bevor sie aufgeben und eine Bounce-Nachricht senden. Der Retry-Zeitplan variiert, beginnt aber typischerweise häufig und nimmt im Laufe der Zeit ab.