Was bedeuten SMTP-, IMAP- und POP3-Serverantworten im Klartext – und wie leite ich daraus eine belastbare Fehlerdiagnose ab?

SMTP-Statuscodes und Servertexte im Kontext: von 220/250 bis 4xx/5xx, inklusive STARTTLS, AUTH und Zustellpfad

SMTP-Serverantworten bestehen aus einem dreistelligen Statuscode und einem optionalen Text. Der Code steuert den Dialogzustand und ist für automatisierte Auswertung maßgeblich; der Text liefert Hinweise zur konkreten Implementierung, Policy-Entscheidungen und zur betroffenen Protokollphase. Relevant ist zudem die syntaktische Form: Eine Zeile XYZ (Code plus Leerzeichen) beendet die Antwort, während XYZ- mehrzeilige Antworten fortsetzt. Viele Server ergänzen erweiterte Statuscodes nach RFC 3463 (z. B. 5.7.1), die die Fehlerklasse feiner auflösen.

2xx im Verbindungs- und Transaktionsfluss: 220, 250 und 221 korrekt einordnen

Der Dialog beginnt typischerweise mit 220 beim Verbindungsaufbau: Der Server signalisiert Bereitschaft, oft mit Hostname, Softwarekennung oder Policy-Hinweisen. Danach folgt der Client mit EHLO (oder HELO), worauf eine 250-Antwort die erfolgreichen Fähigkeiten verhandelt. In der Praxis sind die nachfolgenden 250--Zeilen entscheidend, weil sie Features wie SIZE, STARTTLS, AUTH, 8BITMIME oder SMTPUTF8 ankündigen. Der Abschluss der Sitzung erfolgt mit QUIT und 221.

Die Bedeutung von 250 hängt stark von der Phase ab: Als Antwort auf MAIL FROM bestätigt sie die Akzeptanz des Envelope-Senders; auf RCPT TO entscheidet sie über Empfängerzulassung, Routing und Policy; nach DATA bestätigt 250 die Annahme zur Zustellung in die Queue. Ein häufiger Analysefehler besteht darin, nur den finalen 250-Text zu betrachten: Für Zustellprobleme ist die erste Ablehnung im Pfad entscheidend, oft bereits bei RCPT TO (Policy, Reputation, Existenzprüfung) oder bei Übergang in TLS/Authentifizierung.

STARTTLS (220 Ready to start TLS): typische Textvarianten und Fehlersignaturen

Nach EHLO und dem Capability-Hinweis 250-STARTTLS initiiert der Client das Upgrade mit STARTTLS. Ein konformes System antwortet mit 220 (häufiger Text: „Ready to start TLS“). Ab diesem Punkt ist der alte SMTP-Dialogzustand verworfen; RFC-konform folgt nach erfolgreichem TLS-Handshake ein erneutes EHLO, weil Capabilities und Auth-Mechanismen unter TLS abweichen können. Fehlinterpretationen entstehen, wenn Clients nach STARTTLS ohne erneutes EHLO fortfahren oder wenn Server STARTTLS nur für bestimmte IP-Bereiche anbieten.

• STARTTLS angeboten, aber Handshake bricht ab: In Protokollmitschnitten zeigen sich oft 220 2.0.0 Ready to start TLS gefolgt von TLS-Alerts; Ursachen sind Zertifikatskette, SNI/Hostname-Mismatch, inkompatible Cipher-Suites oder erzwungenes TLS-Minimum (z. B. TLS 1.2/1.3).
• STARTTLS nicht angeboten: Fehlt 250-STARTTLS in der EHLO-Antwort, liegt häufig ein falscher Submission-Port (statt 587 ein Relay-Port) oder eine Policy je nach Quellnetz vor; die Analyse sollte mit identischem EHLO-Namen und aus dem betroffenen Netz erfolgen.
• STARTTLS abgelehnt: Antworten wie 454 4.7.0 TLS not available oder 454 4.3.0 Try again later deuten auf temporäre TLS-Deaktivierung, Ressourcenprobleme oder Wartung; bei wiederkehrender Ablehnung sind Serverzustand, Zertifikatsablauf und TLS-Konfiguration zu prüfen.

AUTH und 535/534/530: Authentifizierung vs. Autorisierung sauber trennen

Authentifizierung wird in der Regel erst nach EHLO über 250-AUTH ... angekündigt. Mechanismen wie PLAIN und LOGIN werden weiterhin unterstützt, gelten aber im Submission-Kontext typischerweise nur unter TLS als zulässig; moderne Umgebungen bevorzugen SASL-Mechanismen wie SCRAM-SHA-256 oder OAUTHBEARER, sofern Server und Client sie anbieten. Eine 535-Antwort signalisiert meist „Authentication credentials invalid“, während 534 häufig auf zusätzliche Anforderungen hinweist (z. B. „Authentication mechanism is too weak“ oder policybasierte Einschränkungen). 530 steht typischerweise für „Authentication required“, wenn der Server vor dem Relay oder vor bestimmten Kommandos eine Anmeldung verlangt.

Wichtig ist die Unterscheidung zwischen Authentifizierung (Wer ist der Absender?) und Autorisierung (Was darf er?). Ein Benutzer kann erfolgreich authentifizieren (235 2.7.0 Authentication successful) und dennoch beim Relay scheitern, etwa bei MAIL FROM/RCPT TO mit 550 5.7.1 Relaying denied. Servertexte variieren stark: Einige nennen explizit „Client was not authenticated“, andere referenzieren interne Policies, Tenant-IDs oder RBL/Rate-Limit-Gründe. Für belastbare Diagnose sollten Code, Enhanced Status Code (z. B. 5.7.1) und die exakte Kommandosequenz gemeinsam ausgewertet werden.

4xx vs. 5xx entlang des Zustellpfads: temporär, permanent und „fail fast“

SMTP trennt temporäre Fehler (4xx) von permanenten Fehlern (5xx). Temporär bedeutet: erneuter Zustellversuch ist sinnvoll, typischerweise durch Warteschlange und Retry-Strategie des sendenden MTA. Permanent bedeutet: erneutes Zustellen mit identischen Parametern wird voraussichtlich nicht erfolgreich sein. In der Praxis implementieren MTAs „fail fast“-Strategien: Bei klarer Policy-Verletzung wird schon bei RCPT TO mit 550/554 abgelehnt, um Backscatter zu vermeiden; bei Content-Scans oder DKIM/DMARC-Entscheidungen erfolgt die Ablehnung mitunter erst nach DATA, was die Zuordnung zu Inhalt oder Headern erleichtert, aber den Sender bereits mehr Daten übertragen lässt.

Implementierungsunterschiede: warum Servertexte täuschen können

Servertexte sind nicht normiert. Postfix, Exim, Microsoft Exchange, Haraka, OpenSMTPD sowie Cloud-Gateways und Security-Appliances formulieren Ablehnungen unterschiedlich und hängen teils interne Ereignis-IDs, Connector-Namen oder Richtlinienlabels an. Manche Systeme verschleiern bewusst Details (z. B. bei Empfängerexistenz), liefern aber dennoch saubere Enhanced Status Codes. Für forensische Auswertung ist der kombinierte Blick auf Codeklasse (2xx/3xx/4xx/5xx), Enhanced Status Code (x.y.z), Protokollphase (welches Kommando) und Kontext (TLS aktiv, Auth-Status, Peer-IP, EHLO-Name) belastbarer als der reine Text. Mehrzeilige 250--Capability-Listen sollten als Teil der „Serverantwort im Wortlaut“ gesichert werden, weil sie erklären, warum ein Client etwa keinen passenden AUTH-Mechanismus auswählt oder warum ein Relay nur unter TLS gestattet ist.

IMAP- und POP3-Antworten präzise einordnen: Tagged/Untaged, OK/NO/BAD, CAPABILITY, LOGIN/AUTHENTICATE, SELECT/UID FETCH sowie POP3 +OK/-ERR

IMAP und POP3 liefern Serverantworten, die auf den ersten Blick ähnlich wirken, technisch jedoch sehr unterschiedlich strukturiert sind. IMAP arbeitet mit zeilenorientierten Antworten, die oft aus mehreren Zeilen bestehen und durch Tags eindeutig einem Client-Kommando zugeordnet werden. POP3 verwendet dagegen eine klarere Zweiteilung: eine Statuszeile mit +OK oder -ERR und, je nach Befehl, optionale mehrzeilige Daten. Für die Fehleranalyse ist die präzise Zuordnung zur Protokollphase entscheidend: Verbindungsaufbau und Begrüßung, Aushandlung der Fähigkeiten, Authentifizierung, Mailbox- bzw. Nachrichtenoperationen und abschließendes Beenden der Sitzung.

IMAP-Grundlogik: Tagged vs. Untagged, Continuation und Status

IMAP-Clients kennzeichnen jedes Kommando mit einem frei gewählten Tag wie A001. Der Server antwortet häufig zunächst mit untagged Zeilen, erkennbar am führenden *, die Daten oder Zwischenstände liefern. Das finale Ergebnis eines Kommandos erscheint als tagged Statuszeile und enthält das ursprüngliche Tag. Zusätzlich existiert die Continuation-Antwort +, die signalisiert, dass der Client weitere Daten senden soll (typisch bei AUTHENTICATE oder bei Literal-Daten mit {n}). Für die Einordnung von Störungen gilt: Untagged Zeilen sind nicht automatisch Fehlerindikatoren; relevant für Erfolg oder Scheitern ist die abschließende tagged Statuszeile.

• Untagged Daten/Status: * OK [CAPABILITY IMAP4rev1 STARTTLS AUTH=PLAIN] Server ready
• Finale tagged Statuszeile: A001 OK CAPABILITY completed
• Continuation (weitere Clientdaten erwartet): + Continue

CAPABILITY: Fähigkeiten lesen, Implementierungsunterschiede erkennen

CAPABILITY steuert, welche IMAP-Erweiterungen und Authentifizierungsmechanismen tatsächlich angeboten werden. Viele Server senden CAPABILITY bereits in der Begrüßung als untagged Response; andere liefern sie erst auf Nachfrage. Nach STARTTLS ist eine erneute CAPABILITY-Abfrage üblich, weil Server erst nach der TLS-Aushandlung stärkere SASL-Mechanismen oder zusätzliche Features deklarieren. Abweichungen zwischen Implementierungen sind häufig: Einige Produkte werben z. B. mit IMAP4rev1 und listen zusätzlich Erweiterungen wie IDLE, UIDPLUS oder LITERAL+; andere reduzieren die Liste abhängig von Mandant, Policy oder Netzsegment.

• Begrüßung mit Fähigkeiten (serverabhängig): * OK [CAPABILITY IMAP4rev1 UIDPLUS IDLE] ready
• Explizite Abfrage: A001 CAPABILITY
* CAPABILITY IMAP4rev1 STARTTLS AUTH=PLAIN
A001 OK CAPABILITY completed
• Nach TLS erneut prüfen: A002 STARTTLS
A003 CAPABILITY

LOGIN vs. AUTHENTICATE: Antwortmuster und Fehlersignaturen

LOGIN überträgt Benutzername und Passwort im IMAP-Protokoll (bei Klartext nur sinnvoll innerhalb von TLS). AUTHENTICATE nutzt SASL und verläuft oft mehrstufig über + Continuation. Typische Fehlerbilder unterscheiden sich: NO bei LOGIN deutet häufig auf ungültige Zugangsdaten oder Policy hin; bei AUTHENTICATE treten zusätzlich Mechanismus- und Tokenprobleme auf. Viele Server ergänzen Statuszeilen um bracketed response codes wie [AUTHENTICATIONFAILED], [ALERT] oder [UNAVAILABLE]; deren Wortlaut ist nicht standardisiert, die Codes sind jedoch für die Klassifikation wertvoll.

• LOGIN erfolgreich: A010 LOGIN "user" "secret"
A010 OK [CAPABILITY ...] Logged in
• LOGIN abgelehnt: A010 NO [AUTHENTICATIONFAILED] Authentication failed
• AUTHENTICATE mehrstufig: A011 AUTHENTICATE PLAIN
+
A011 OK Authentication succeeded

Mailbox-Phase: SELECT und die Bedeutung untagged Statusdaten

SELECT oder EXAMINE wechselt in den Zustand “selected” und löst regelmäßig mehrere untagged Antworten aus: Anzahl vorhandener Nachrichten (EXISTS), Anzahl recent (RECENT, heute selten sinnvoll), Flags und permanente Flags (FLAGS, PERMANENTFLAGS), UIDVALIDITY und oft die nächste UID (UIDNEXT). Diese Werte sind Kernbestandteile einer robusten Diagnose, weil sie erklären, warum UIDs “springen”, warum ein Client Resync erzwingt oder warum Flag-Änderungen nicht persistieren. Die finale tagged Zeile bestätigt erst, dass die Mailbox tatsächlich selektiert wurde; ein NO kann sowohl Rechteprobleme als auch einen nicht existierenden Ordner abbilden.

UID FETCH: Datenlieferung, Feldnamen und häufige Stolpersteine

UID FETCH liefert Nachrichtendaten in untagged * n FETCH (...)-Zeilen, während die tagged Abschlusszeile den Gesamtstatus markiert. Unterschiede zwischen Servern betreffen vor allem Details: Ob BODY[] oder BODY.PEEK[] eine \Seen-Markierung auslöst, wie INTERNALDATE formatiert wird, oder wie Header-Felder normalisiert werden. Fehlerdiagnostisch wichtig ist die Trennung von Transport und Semantik: Ein OK kann dennoch unvollständige Nutzdaten bedeuten, wenn der Client eine falsche Sektion anfordert oder der Server aus Policygründen Inhalte reduziert (z. B. durch Größenlimits bei bestimmten Abrufen). BAD bei FETCH deutet häufig auf fehlerhafte Klammerung, ungültige Daten-Items oder nicht unterstützte Erweiterungen hin.

• Typische FETCH-Datenzeile: * 7 FETCH (UID 10455 FLAGS (\Seen) RFC822.SIZE 34567 BODY[HEADER.FIELDS (FROM TO SUBJECT DATE)] {123} ...)
• Erfolg bestätigt (tagged): A301 OK UID FETCH completed
• Syntax/Item-Problem (BAD): A301 BAD Error in IMAP command received by server

POP3-Antworten: +OK/-ERR, Multi-Line und Dot-Stuffing

POP3 ist zustandsbasiert (Authorization, Transaction, Update) und signalisiert Erfolg oder Fehler über die erste Antwortzeile. +OK bestätigt den Befehl, -ERR weist ihn zurück. Einige Befehle liefern bei Erfolg zusätzliche Datenzeilen, deren Ende durch eine einzelne Zeile mit Punkt (.) markiert wird; Server “dot-stuffen” dabei Zeilen, die mit einem Punkt beginnen, durch Voranstellen eines zusätzlichen Punkts. Für Analysen sind klare Zuordnungen möglich: Authentifizierungsfehler zeigen sich typischerweise bei USER/PASS oder AUTH, Zugriff auf Nachrichten im Transaction-State über STAT, LIST, RETR, TOP und Löschmarkierungen via DELE. Wortlaute variieren stark, die Statuspräfixe sind jedoch verlässlich.

• Begrüßung: +OK POP3 server ready
• Auth erfolgreich: USER alice
+OK
PASS ********
+OK Mailbox locked and ready
• Auth fehlgeschlagen: -ERR invalid login
• Mehrzeilige Daten (LIST/RETR): LIST
+OK 2 messages
1 1200
2 3400
.

In der Praxis entstehen Fehlinterpretationen häufig durch fehlende Zustandsprüfung: POP3-Kommandos im falschen State führen konsequent zu -ERR, IMAP-Kommandos ohne selektierte Mailbox werden mit NO oder BAD quittiert, abhängig von Implementierung und Kommando. Für eine belastbare Einordnung sollten Antworten daher stets zusammen mit dem unmittelbar vorhergehenden Kommando, dem aktuellen Protokollzustand und den vom Server gemeldeten Capabilities bewertet werden.

Protokollanalyse in der Praxis: Telnet/OpenSSL-Sessions, Log-Korrelation, typische Implementierungsunterschiede und wiederholbare Troubleshooting-Checks

Interaktive Sessions: klarer Beweis statt Vermutung

Interaktive Protokollsessions liefern eine belastbare Sicht auf den tatsächlichen Dialog zwischen Client und Server: Banner, Capability-Aushandlung, Authentifizierungsmechanismen, TLS-Upgrade und die konkrete Fehlermeldung im Wortlaut. Für SMTP lässt sich ein Großteil des Handshakes und der Kommandofolge mit einfachen Terminalmitteln nachvollziehen. Für IMAP und POP3 gilt dasselbe, wobei die Protokolle stärker zustandsbehaftet sind (IMAP) oder sehr strikt in der Reihenfolge (POP3).

Bei verschlüsselten Ports oder STARTTLS ist der Blick „auf die Leitung“ mit openssl s_client meist zielführender als reines Telnet, weil Zertifikatskette, SNI und die Aushandlung der Cipher-Suites unmittelbar sichtbar werden. Gleichzeitig bleibt die Applikationsschicht lesbar, wenn nach dem TLS-Handshake Protokollkommandos gesendet werden. Für reproduzierbare Ergebnisse empfiehlt sich eine feste Dokumentation: Zielhost, Port, IP-Auflösung, Zeitpunkt, Quellnetz und der komplette Serverwortlaut inklusive Zeilenumbrüchen.

Kommandosequenzen, die in der Praxis schnell Klarheit schaffen

Die Aussagekraft hängt weniger vom Tool als von der Protokolldisziplin ab: korrekte Reihenfolge, eindeutige Identifikatoren (IMAP-Tags), vollständige Auswertung der Mehrzeilenantworten und sauberes Beenden. Für SMTP gilt: erst den Serverbanner 220 abwarten, dann EHLO senden, bei Bedarf STARTTLS, erneut EHLO, anschließend Authentifizierung und erst danach MAIL FROM/RCPT TO/DATA. IMAP verlangt eindeutige Tags wie a001, und bei POP3 wird typischerweise nach USER/PASS oder AUTH in den TRANSACTION-Zustand gewechselt.

• SMTP-Handshake inkl. STARTTLS: openssl s_client -starttls smtp -connect mail.example:587 -servername mail.example
EHLO client.example
STARTTLS
EHLO client.example
• SMTP-Transporttest bis RCPT: MAIL FROM:<sender@example>
RCPT TO:<empfaenger@example>
RSET
QUIT
• IMAP-Capabilities und Login: openssl s_client -connect imap.example:993 -servername imap.example
a001 CAPABILITY
a002 LOGIN user@example "passwort"
a003 LIST "" "*"
a004 LOGOUT
• POP3-Basistest: openssl s_client -connect pop.example:995 -servername pop.example
USER user@example
PASS passwort
STAT
QUIT

Bei SMTP ist die korrekte Interpretation von Mehrzeilenantworten entscheidend: Fortsetzungszeilen sind am Code plus Bindestrich erkennbar (z. B. 250-), die letzte Zeile nutzt denselben Code mit Leerzeichen (z. B. 250 ). Wird hier zu früh „abgeschnitten“, entstehen Scheinergebnisse, etwa fehlende AUTH-Mechanismen oder nicht erkannte Größenlimits (SIZE).

Log-Korrelation: Dialogzeilen dem richtigen Zeitpunkt zuordnen

Interaktive Tests sind nur die eine Hälfte. Die belastbare Fehleranalyse entsteht durch Korrelation mit Serverlogs und ggf. vorgelagerten Komponenten wie Load-Balancern, SMTP-Proxys, Anti-Spam-Gateways oder DLP-Systemen. Voraussetzung ist eine konsistente Zeitsynchronisation (NTP) über alle beteiligten Systeme; schon geringe Drift erschwert die Zuordnung von 4xx-Zwischenergebnissen oder von TLS-Handshake-Fehlern.

Für SMTP sind Queue-IDs, Message-IDs und Session-IDs typische Anker. Viele MTAs protokollieren je Verbindung eine eindeutige ID, an der sich die Ereigniskette (Connect, EHLO, TLS, Auth, Policy-Checks, Zustellung/Defer/Bounce) entlanghangeln lässt. Bei IMAP/POP3 ist das verbindungsbezogene Korrelat häufig die Quell-IP plus Zeitpunkt plus Benutzername; ergänzend helfen Auth-Logs (SASL, PAM, LDAP/AD) und TLS-Logs (SNI, Zertifikatsvalidierung). Wo NAT oder Proxying im Spiel ist, gewinnt die Auswertung von X-Forwarded-For-Äquivalenten oder PROXY-Protocol-Informationen an Bedeutung, sofern die Infrastruktur dies nutzt und serverseitig korrekt konfiguriert ist.

Typische Implementierungsunterschiede: gleicher Code, anderer Kontext

Serverantworten sind formal standardisiert, die Semantik bleibt jedoch häufig implementierungs- und policyabhängig. Ein SMTP-421 kann eine lokale Ressourcenknappheit, eine gezielte Abwehrmaßnahme gegen verdächtigen Traffic oder ein Upstream-Problem hinter einem Proxy bedeuten. Ebenso kann ein 550 sowohl „Mailbox does not exist“ als auch „policy rejection“ abbilden; der unterscheidende Faktor ist fast immer der Wortlaut sowie die Stelle im Ablauf (nach RCPT TO versus nach DATA).

Bei IMAP fällt die Variabilität stärker über CAPABILITY und Erweiterungen auf. Manche Implementierungen liefern sehr detaillierte [ALERT]-Texte, andere bleiben knapp. Zudem unterscheidet sich, ob ein Server vor STARTTLS bereits Authentifizierung erlaubt oder dies strikt unterbindet, und ob ein Login bei fehlender TLS-Verschlüsselung nur mit LOGINDISABLED oder mit einem generischen NO quittiert wird. POP3-Server variieren häufig bei Locking- und Quota-Fehlern; manche geben klare Ursachen an, andere nur -ERR ohne Zusatz. Deshalb sollten Troubleshooting-Checks immer die Capability-/Bannerphase mit erfassen und nicht erst beim eigentlichen Fehler beginnen.

Wiederholbare Troubleshooting-Checks: kontrollierte Variationen statt Aktionismus

Reproduzierbarkeit entsteht durch kontrollierte Variationen eines Basistests. Dazu gehört, Parameter gezielt zu ändern: Port (Submission vs. SMTPS), TLS-Modus (STARTTLS vs. implicit), SNI, Absenderdomain, Empfängerdomain, Auth-Mechanismus, sowie die Quell-IP (z. B. Test aus einem anderen Netzsegment). Jede Variation sollte nur eine Variable ändern, andernfalls wird die Ursache kaum trennbar.

• DNS-Realität festhalten: dig +short MX example
dig +short A mail.example
dig +short AAAA mail.example
• TCP-Erreichbarkeit prüfen (ohne Protokollinterpretation): nc -vz mail.example 587
nc -vz mail.example 465
nc -vz imap.example 993
• TLS-Parameter deterministisch testen: openssl s_client -connect mail.example:465 -servername mail.example -verify_return_error
openssl s_client -starttls smtp -connect mail.example:587 -servername mail.example -verify_return_error
• SMTP-Policy isolieren: EHLO client.example
MAIL FROM:<probe@eigene-domain.example>
RCPT TO:<probe@ziel.example>
• IMAP/POP3-Capability gegen Erwartung spiegeln: a001 CAPABILITY
STLS
• Log-Korrelation erzwingen: MAIL FROM:<probe+ticket123@example> (Plus-Addressing, sofern akzeptiert)

Bei allen Checks gilt: Eine „grüne“ TLS-Verbindung garantiert keinen erfolgreichen Mailfluss. Erst die Kombination aus TLS-Aushandlung, Capability-Liste, Authentifizierungsantwort und den Policy-Entscheidungen entlang MAIL FROM/RCPT TO/DATA zeigt, ob das Problem im Transport, in der Identität (Auth), in Inhalts- oder Reputationsfiltern oder in nachgelagerten Zustellpfaden liegt. Wer Protokollwortlaut und Logevent an derselben Kante des Zustandsautomaten verankert, reduziert Fehlinterpretationen deutlich.