SMTP: Transport, Queue und Zustellverantwortung

Das Simple Mail Transfer Protocol (SMTP) bringt eine Nachricht von einem Mailprozess zum nächsten. Der Client verbindet sich mit einem Server, fragt dessen Fähigkeiten ab, nennt Envelope-Absender und Empfänger und überträgt erst danach den Nachrichteninhalt. Der Server beantwortet jeden Schritt mit einem numerischen Code. Aus dieser scheinbar einfachen Folge entstehen Routing, Queueing, Wiederholungen und die entscheidende Frage, welcher Server gerade die Verantwortung für die Nachricht trägt (RFC 5321, Abschnitte 1 und 2).

Für Messaging-Administratoren liegt die entscheidende Eigenschaft in der Zuständigkeitsübergabe. Ein erfolgreicher TCP-Aufbau bedeutet nur, dass ein Listener erreichbar ist. Ein akzeptiertes RCPT TO reserviert einen Empfänger innerhalb der laufenden Transaktion. Erst ein positiver Abschluss nach dem vollständigen Nachrichteninhalt überträgt dem empfangenden SMTP-System die Verantwortung, die Nachricht zuzustellen oder einen späteren Fehler an den Envelope-Absender zu melden (RFC 5321, Abschnitte 4.1.1.4 und 6.1). Queue-ID, Antwortcode, Remote-MTA, Empfängerstatus und Received-Spur sind deshalb keine beiläufigen Logdetails, sondern die Beweiskette einer Zustellung.

Die Erklärung folgt einer Nachricht vom einliefernden Client über SMTP-Sitzung, Envelope und Queue bis zum nächsten Mailserver oder Postfach. DNS, Retry, Statuscodes, Sicherheit und Diagnose werden jeweils dort vertieft, wo sie den Weg beeinflussen.

Rollen und Zuständigkeiten

SMTP kennt zunächst nur Client und Server. In einer realen Zustellkette wechseln diese Rollen bei jedem Hop: Ein Mail Transfer Agent nimmt als Server eine Nachricht an, speichert sie in seiner Queue und wird beim nächsten Zustellversuch selbst zum Client. Erst aus diesem Rollenwechsel lassen sich Logs und Zuständigkeiten richtig lesen (RFC 5321, Abschnitt 2.3.3, RFC 5598, Abschnitt 4, RFC 6409, Abschnitt 2.1).

Der MSA ist nicht bloss ein MTA auf einem anderen Port. Message Submission trennt die kontrollierte Einlieferung neuer Nachrichten vom offenen Transfer zwischen Maildomänen. Ein MSA darf unter anderem Absenderrechte prüfen, fehlende Pflichtfelder ergänzen und Nachrichten an lokale Regeln anpassen; ein nachgelagerter MTA soll fertigen Nachrichteninhalt grundsätzlich nicht beliebig verändern (RFC 6409, Abschnitte 1, 6 und 8). Diese Grenze ist besonders relevant für DKIM-Signaturen: Jede nachträgliche Änderung signierter Header oder des Bodys kann die Signatur ungültig machen.

Die Grafik zeigt logische Grenzen. MSA, ausgehender MTA, Gateway und eingehender MTA können als getrennte Dienste laufen, auf einem System zusammenfallen oder durch einen Cloudanbieter verborgen werden. Die Standards schreiben keine Prozessarchitektur vor. Administrativ bleibt die Trennung trotzdem notwendig, weil jede angenommene Übergabe eine neue Queue, einen neuen Retry-Zustand und einen neuen Verantwortlichen erzeugen kann.

Envelope und Nachrichteninhalt

Bevor der Dialog im Detail betrachtet wird, müssen zwei Datenbereiche getrennt werden: der Envelope für den Transport und der Nachrichteninhalt für Empfänger und Mailprogramme. Der Envelope besteht aus einem Reverse Path aus MAIL FROM und einem oder mehreren Forward Paths aus RCPT TO. Der Inhalt folgt nach DATA und enthält einen Headerbereich nach Internet Message Format sowie den Body, häufig mit MIME-Struktur (RFC 5321, Abschnitt 2.3.1, RFC 5322, Abschnitt 2.1).

SMTP-Server dürfen die endgültige Route nicht aus To:, Cc: oder From: ableiten. Umgekehrt müssen Envelope-Adressen nicht im Nachrichtenheader erscheinen. Daher funktionieren Bcc, Mailinglisten, Weiterleitungen, SRS und getrennte Bounce-Adressen. Die Trennung erklärt auch, weshalb eine Nachricht im Client optisch von ceo@example.ch stammen kann, während ihr Envelope-Absender eine andere Domain verwendet. SPF betrachtet den SMTP-Pfad; DMARC stellt zusätzlich einen Bezug zum sichtbaren From: her. Die Details dieser Prüfungen gehören in Mail-Authentifizierung (RFC 5321, Anhang C, RFC 5322, Abschnitt 3.6).

Ein leerer Reverse Path wird als MAIL FROM:<> übertragen. Er verhindert Fehlerberichtsschleifen und ist für Delivery Status Notifications vorgeschrieben. Ein Server, der leere Absender pauschal abweist, beschädigt deshalb den Rückmeldepfad des Mailsystems (RFC 5321, Abschnitt 3.6.3).

SMTP-Sitzung und Transaktion

Auf einer TCP-Verbindung läuft eine SMTP-Sitzung; darin können mehrere Nachrichten als getrennte Mailtransaktionen folgen. Der Server beginnt mit einem 220-Greeting; der Client identifiziert sich mit EHLO und erhält eine sitzungsbezogene Liste von ESMTP-Fähigkeiten. Danach besteht eine Transaktion aus MAIL, mindestens einem akzeptierten RCPT und DATA oder einem ausgehandelten Ersatz wie BDAT (RFC 5321, Abschnitte 3.1 und 4.1).

1. Verbindung und Greeting: Der Client verbindet sich; der Server antwortet mit 220. Verzögert oder verweigert er bereits hier, existiert noch keine Mailtransaktion.
2. Fähigkeitsaushandlung: EHLO client.example setzt beide Seiten in den Initialzustand und liefert Erweiterungen wie SIZE, STARTTLS, PIPELINING oder SMTPUTF8. Ein Client darf nicht annehmen, dass ein anderer Clusterknoten oder eine spätere Sitzung dieselben Fähigkeiten anbietet.
3. Optionales TLS-Upgrade: Nach erfolgreichem STARTTLS werden SMTP-Zustand und zuvor gelernte Fähigkeiten verworfen. Der Client sendet innerhalb des geschützten Kanals erneut EHLO (RFC 3207, Abschnitt 4).
4. Envelope-Absender: MAIL FROM eröffnet eine Transaktion und leert frühere Envelope- und Datenpuffer. ESMTP-Parameter wie SIZE, BODY oder SMTPUTF8 hängen an diesem Kommando.
5. Empfänger: Jeder RCPT TO wird einzeln beantwortet. Ein Server kann zwei Empfänger akzeptieren und einen dritten permanent ablehnen; der Client sendet den Inhalt dann für die akzeptierte Teilmenge.
6. Inhalt: Auf DATA folgt bei Bereitschaft 354. Der Client überträgt Header und Body als CRLF-beendete Zeilen, maskiert am Zeilenanfang stehende Punkte und beendet mit einer Zeile, die nur aus . besteht.
7. Abschluss: Die Antwort nach diesem End-of-Data-Marker entscheidet, ob der Server die Nachricht als Ganzes für die zuvor akzeptierten Empfänger übernimmt. RSET verwirft die laufende Transaktion, ohne die Sitzung zu beenden; QUIT schliesst sie geordnet.

SMTP ist lockstep-orientiert, ESMTP-PIPELINING darf jedoch erlaubte Kommandogruppen senden, ohne jede einzelne Antwort abzuwarten. Die Antworten bleiben in Eingangsreihenfolge und müssen weiterhin jedem Kommando korrekt zugeordnet werden (RFC 2920). Ein Paketmitschnitt mit mehreren unmittelbar aufeinanderfolgenden MAIL-/RCPT-Zeilen ist daher nicht automatisch ein Protokollverstoss.

Der Dialog ist damit vollständig, aber die Zustellverantwortung noch nicht geklärt. Sie wechselt erst mit einer ganz bestimmten Antwort des empfangenden Servers.

Annahmegrenze: 250 nach End-of-Data

Die wichtigste SMTP-Grenze liegt hinter dem Nachrichteninhalt. Ein 250 auf MAIL FROM akzeptiert nur den Reverse Path. Ein 250 auf RCPT TO akzeptiert einen Empfänger für die laufende Transaktion. Erst ein 250 nach dem End-of-Data-Marker bedeutet, dass der Server die Verantwortung für die Nachricht übernommen hat. Ein korrektes System muss sie danach entweder zustellen oder bei einem später erkannten Fehler einen Nichtzustellbericht erzeugen; der sendende Client darf seine lokale Kopie aus der aktiven Zustellverantwortung entfernen (RFC 5321, Abschnitte 4.1.1.4 und 6.1).

Diese Semantik macht den letzten Dialogteil kritisch. Bricht die Verbindung nach dem Punkt, aber vor einer vollständig empfangenen Antwort ab, weiss der Client nicht sicher, ob der Server die Nachricht gespeichert hat. Er muss die Zustellung erneut versuchen können; dadurch sind Duplikate möglich. SMTP bietet keine globale Exactly-once-Garantie. Systeme benötigen deshalb idempotente Nachverfolgung über Queue-ID, Message-ID, Empfänger, Zeit, Grösse und gegebenenfalls einen proprietären Transaktionsbezug, ohne diese Kennungen miteinander gleichzusetzen.

Content-Filter, DLP, Malwareprüfung oder DKIM-Signierung sollten so in die Annahmepipeline eingebunden sein, dass der Server vor dem finalen positiven Reply weiss, ob er persistente Verantwortung übernehmen kann. Ein vorgeschalteter Proxy, der voreilig 250 meldet und die Nachricht danach intern verliert, kann den Fehler nicht mehr an den ursprünglichen SMTP-Client zurückgeben. Genau hier muss eine Architektur festlegen, ob Annahme erst nach durable write, nach Replikation, nach Scan oder bereits nach Übergabe an einen internen Broker bestätigt wird. Das ist eine Produkteigenschaft, keine Vorgabe des SMTP-Standards, und gehört aus Herstellerdokumentation sowie Fehler- und Restoretests belegt.

Nach der Annahme muss der MTA entscheiden, wohin er die Nachricht als Nächstes sendet. Bei Internetmail beginnt diese Entscheidung im DNS.

Routing über DNS und MX

Für direkte Internetzustellung bestimmt der sendende MTA aus der Domain des Envelope-Empfängers das nächste Ziel. Er fragt DNS nach MX-Records, sortiert Kandidaten nach aufsteigendem Preference-Wert und löst die ausgewählten Exchange-Namen zu A- oder AAAA-Adressen auf. Mehrere Ziele gleicher Preference bilden gleichwertige Kandidaten; ein Backup-MX mit höherem Wert ist keine Replik der Primärqueue, sondern ein eigenständiger SMTP-Empfänger mit eigener Policy und Zustellverantwortung (RFC 5321, Abschnitt 5).

Fehlt ein MX-RRset, behandelt SMTP die Domain historisch wie einen impliziten MX auf den Domainnamen selbst und versucht dessen Adressen. Ein expliziter Null MX mit Preference 0 und Exchange . erklärt dagegen, dass eine Domain keine E-Mail annimmt (RFC 7505). NXDOMAIN, NODATA, SERVFAIL, DNSSEC-Validierungsfehler und ein erreichbarer MX ohne funktionierenden SMTP-Dienst sind unterschiedliche Zustände und müssen im Queuegrund getrennt sichtbar bleiben.

Interne Mailwege verwenden häufig statische Next Hops, Smarthosts, Connectoren oder Routingtabellen statt öffentlicher MX-Auswahl. Der Envelope-Empfänger bleibt dennoch die Zustelladresse; die lokale Routingpolicy entscheidet nur, welchem nächsten System sie anvertraut wird. Bei jeder Diagnose sind deshalb drei Namen zu notieren: Empfängerdomain, ausgewählter Next-Hop-Name und tatsächlich verbundene IP-Adresse.

Kennt der MTA das Ziel, ist die Zustellung trotzdem nicht immer sofort möglich. Temporäre Fehler führen deshalb in die Queue statt zum Verlust der Nachricht.

Queue, Retry und DSN

Ein vollwertiger MTA ist ein Store-and-Forward-System. Kann er den nächsten Hop nicht sofort erreichen oder antwortet dieser temporär, hält der MTA Nachricht und Envelope in einer persistenten Queue, plant einen erneuten Versuch und verwaltet den Status pro Empfänger. RFC 5321 verlangt eine Retry-Strategie, schreibt aber keinen einzelnen Algorithmus für alle Produkte vor. Es empfiehlt verzögerte Wiederholungen, eine Benachrichtigung bei längerem Verzug und eine mehrtägige Aufbewahrung vor endgültiger Aufgabe (RFC 5321, Abschnitt 4.5.4). Produktwerte wie Backoff, maximale Queue-Lebensdauer, Parallelität und Destination Concurrency müssen daher aus der konkreten MTA-Konfiguration gelesen werden.

Ein sinnvoller Queue-Datensatz enthält mindestens:

• unveränderbaren Nachrichteninhalt oder einen referenzierten Blob;
• Envelope-Absender und Status jedes Envelope-Empfängers;
• Zeitpunkt der Annahme, nächsten Versuch und Ablaufgrenze;
• gewählten Transport, Next Hop, letzte Adresse und TLS-/Policyentscheidung;
• letzten SMTP- und Enhanced-Statuscode samt Remote-Text;
• lokale Queue-ID sowie korrelierbare IDs aus vorgelagerten oder nachgelagerten Hops;
• Zustände für aktiv, deferred, hold, delivered, bounced und quarantined;
• Replikations-, Dateisystem- oder Datenbankzustand, wenn Annahme hochverfügbar sein soll.

Temporäre Fehler werden normalerweise erneut versucht. Permanente Fehler vor der eigenen Annahme werden synchron an den sendenden SMTP-Client zurückgegeben. Permanente Fehler nach eigener Annahme führen zu einer Delivery Status Notification (DSN) an den Reverse Path. RFC 3464 definiert dafür eine maschinenlesbare multipart/report-Nachricht mit per-message- und per-recipient-Feldern wie Reporting-MTA, Final-Recipient, Action, Status und optional Remote-MTA oder Diagnostic-Code (RFC 3464).

Ein Bounce ist nicht automatisch vertrauenswürdig. DSNs können gefälscht werden, den ursprünglichen Inhalt preisgeben oder bei missbräuchlich gesetztem Envelope-Absender Backscatter erzeugen. Ein Gateway sollte ungültige Nachrichten möglichst während der ursprünglichen SMTP-Sitzung ablehnen, statt sie anzunehmen und später an eine möglicherweise gefälschte Adresse zurückzusenden.

Antwortcodes und Diagnosebedeutung

SMTP-Antworten besitzen einen dreistelligen Basiscode. Der erste Ziffernbereich beschreibt den unmittelbaren Zustand; der Text ist für Menschen bestimmt und kann produktspezifisch sein (RFC 5321, Abschnitt 4.2).

Enhanced Status Codes ergänzen das Format x.y.z. x ist Erfolg, temporär oder permanent; y bezeichnet die grobe Ausfallbereich und z das Detail. So gehört 5.1.1 zur Adressklasse und bezeichnet eine nicht vorhandene Zielmailbox, während 4.4.x Netzwerk- und Routingprobleme einordnet. Die registrierten Bedeutungen stehen im IANA-Register für Enhanced Status Codes; ein Herstellertext darf nicht gegen die numerische Semantik ausgewertet werden (RFC 3463, RFC 5248).

Der gleiche Code kann je nach Protokollphase etwas anderes betreffen. 550 auf MAIL FROM verwirft den Absender oder seine Berechtigung, auf RCPT TO einen konkreten Empfänger und nach dem Inhalt die vollständige Transaktion. Ein Ticket ohne Remote-Host, Zeit, Phase, Basiscodes, Enhanced Code und vollständigen Antworttext ist daher unvollständig.

ESMTP und Erweiterungen

Extended SMTP verwendet EHLO, um Fähigkeiten pro Verbindung auszuhandeln. Die IANA führt das verbindliche Register der SMTP Service Extensions. Ein Client darf eine Erweiterung nur einsetzen, wenn sie in der aktuellen Sitzung angeboten wurde; nach STARTTLS muss er die Liste neu abfragen.

Capability Drift zwischen Clusterknoten ist ein häufiges Betriebsproblem. Wenn nur einzelne Listener SMTPUTF8, denselben SIZE-Wert oder identische AUTH-Mechanismen anbieten, entstehen scheinbar zufällige Zustellfehler. Monitoring sollte daher nicht nur einen VIP, sondern jeden relevanten Backendpfad mit demselben SNI, EHLO-Namen und Quellnetz prüfen.

Bis hierhin ging es um den Transport zwischen Servern. Die Einreichung durch Benutzer und Anwendungen ist ein eigener Dienst mit anderen Ports, Identitäten und Missbrauchsrisiken.

Submission, Relay und Authentisierung

Port 25 dient dem MTA-zu-MTA-Transfer. Port 587 kennzeichnet Message Submission; Port 465 ist für Submission über von Beginn an aktives TLS als Dienst submissions registriert. Port 465 ist kein alternativer MX-Port: Öffentliche MX-Zustellung kennt keine Portangabe und verwendet Port 25 (RFC 6409, Abschnitte 1 und 3, RFC 8314, Abschnitt 7.3, IANA Service Name and Port Number Registry).

Ein Submission-Dienst verbindet Authentisierung mit Autorisierung. AUTH verwendet SASL und kann Mechanismen wie PLAIN über TLS oder OAuth-basierte Bearer-Token tragen. Die authentisierte Identität, die beantragte Autorisierungsidentität und der erlaubte Envelope-Absender sind verschiedene Grössen. Ein erfolgreicher Login berechtigt nicht automatisch dazu, jede Absenderdomain oder jeden Envelope-Absender zu verwenden (RFC 4422, Abschnitt 3.4, RFC 4954, RFC 7628).

Offenes Relay entsteht, wenn ein MTA Nachrichten von nicht autorisierten Quellen an nicht lokale Ziele weiterleitet. Eine sichere Konfiguration entscheidet deshalb getrennt über lokale Empfängerdomains, vertrauenswürdige Quellnetze, authentisierte Submission und explizite Connectoren. IP-Allowlisting ist eine Netzautorisierung und kein Ersatz für eine Benutzeridentität; bei NAT, Cloud-Egress oder gemeinsam genutzten Relays kann sie einen wesentlich grösseren Senderkreis freischalten als beabsichtigt.

Erst wenn Rolle und Port feststehen, lässt sich die passende TLS-Policy bestimmen: Submission soll geschützt und authentisiert sein, während der offene MTA-Transport zusätzliche Domainrichtlinien benötigt.

TLS-Policy bei SMTP

STARTTLS schützt die einzelne Verbindung, wenn beide Seiten das Upgrade durchführen. Beim offenen MTA-Transfer bleibt reines STARTTLS jedoch opportunistisch: Ein aktiver Angreifer kann das Angebot entfernen oder DNS-Ziele manipulieren, und ein Sender ohne zusätzliche Richtlinie kann auf Klartext zurückfallen. DANE für SMTP bindet TLSA-Daten über DNSSEC an die MX-Zielwahl. MTA-STS veröffentlicht über DNS und HTTPS eine PKIX-basierte MX- und TLS-Policy. TLS-RPT meldet aggregierte Fehler bei solchen Richtlinien. Kryptografische Details, Zertifikatspfade und Testverfahren behandelt der Artikel TLS.

Submission ist anders: Hier sind Client und Dienst administrativ zugeordnet, und der Benutzer darf nicht still auf Klartext zurückfallen. RFC 8314 empfiehlt implizites TLS für Mail Submission und Access und verlangt, dass Klartext als veraltet behandelt wird. SMTP AUTH mit Passwort- oder Bearer-Mechanismen benötigt einen angemessen geschützten Kanal; ein Server sollte schwache Mechanismen vor STARTTLS gar nicht erst anbieten (RFC 8314, Abschnitt 3, RFC 4954, Abschnitt 14).

Lokale Zustellung mit LMTP

Das Local Mail Transfer Protocol (LMTP) verwendet einen SMTP-ähnlichen Dialog für die Übergabe an ein System ohne eigene langfristige Mailqueue, beispielsweise einen Mailboxdienst. Der wesentliche Unterschied erscheint nach dem Nachrichteninhalt: LMTP liefert für jeden zuvor akzeptierten Empfänger eine eigene Endantwort. Damit kann der Mailstore einen Empfänger erfolgreich zustellen und einen anderen wegen Quota oder eines lokalen Fehlers ablehnen, ohne dass der vorgeschaltete MTA die gesamte Transaktion als einheitlich behandeln muss (RFC 2033, Abschnitt 4.2).

LMTP verschiebt die Verantwortung nicht aus dem System. Wenn der Mailstore einen Empfänger temporär ablehnt, muss der vorgeschaltete MTA diesen Empfänger weiter in seiner Queue halten. Bei Unix-Sockets entfällt zwar der IP-Netzpfad, nicht aber die Notwendigkeit, Socketberechtigungen, Backpressure, Timeouts, per-recipient Replies und die Persistenzgrenze zu beobachten.

Implementierungs- und Technologiestack

SMTP definiert das Drahtprotokoll, nicht die interne Softwarearchitektur. In der Praxis verbindet ein MTA mehrere technische Schichten:

Die Implementierungen setzen diese Schichten unterschiedlich um. Postfix zerlegt Empfang, Cleanup, Queue Manager und Zustellagenten in kooperierende Prozesse und trennt incoming, active und deferred als Queuezustände. Exim speichert Envelope/Headers und Body im Spool und lässt Queue-Runner fällige Zustellversuche bearbeiten. Apache James läuft auf der JVM und verbindet Protokollserver, Queue und eine Mailet-Pipeline mit austauschbaren Speicherbackends. Alle drei sprechen SMTP, aber ihre Prozess-, Queue-, Erweiterungs- und Recoverymodelle sind nicht austauschbar.

Programmiersprache und Runtime beeinflussen Packaging, Patchprozess, Speicherprofil und Erweiterbarkeit, nicht die Semantik des SMTP-Dialogs. Postfix wird mit einer nativen C-Toolchain für Unix-artige Systeme gebaut (Postfix INSTALL); die Exim-Dokumentation nennt ANSI C als Implementierungssprache. Apache James beschreibt sich dagegen als Java-/Scala-Plattform auf der JVM (Apache James). Ein Clouddienst kann dieselben RFC-Rollen über proprietäre Microservices, verteilte Queues und APIs abbilden. Für die Betriebsfreigabe sind deshalb nicht nur EHLO-Fähigkeiten, sondern auch Persistenzzusage, Retrymodell, Queueexport, Backup, Schlüsselverwaltung, Skalierungsgrenzen und Ausfallbereiche zu dokumentieren.

Aus dem Zustellablauf ergibt sich eine feste Fehlersuche: Ziel bestimmen, Verbindung und SMTP-Dialog prüfen, Antwort auswerten und danach Queue sowie nächsten Hop verfolgen.

Diagnose von DNS bis zur Queue

Eine zuverlässige SMTP-Diagnose folgt dem Zustellpfad und hält Beobachtungsebenen getrennt. Tests sollten mit Testdomains und autorisierten Empfängern erfolgen; fremde Server dürfen nicht für Relay-, Adressvalidierungs- oder Lasttests missbraucht werden.

MX-Ziel und Adressen bestimmen

Resolve-DnsName example.ch -Type MX -DnsOnly
Resolve-DnsName mx1.example.ch -Type A -DnsOnly
Resolve-DnsName mx1.example.ch -Type AAAA -DnsOnly

dig +noall +answer example.ch MX
dig +noall +answer mx1.example.ch A
dig +noall +answer mx1.example.ch AAAA

Resolve-DnsName und dig zeigen veröffentlichte DNS-Daten. Die Ausgabe muss auf Preference, Null MX, CNAME-Ketten, IPv4/IPv6 und den tatsächlich befragten Resolver geprüft werden. Eine DNS-Antwort belegt weder Listener- noch TLS-Funktion.

TCP-Erreichbarkeit des gewählten Hops prüfen

Test-NetConnection mx1.example.ch -Port 25 -InformationLevel Detailed
Test-NetConnection submit.example.ch -Port 587 -InformationLevel Detailed
Test-NetConnection submit.example.ch -Port 465 -InformationLevel Detailed

nc -vz -w 5 mx1.example.ch 25
nc -vz -w 5 submit.example.ch 587
nc -vz -w 5 submit.example.ch 465

Test-NetConnection und nc prüfen hier nur DNS-Auflösung und TCP-Aufbau. Ein Erfolg auf 25 sagt nicht, ob das SMTP-Greeting rechtzeitig kommt; ein Erfolg auf 587 oder 465 sagt nichts über TLS- und AUTH-Policy.

STARTTLS, EHLO und Zertifikat prüfen

openssl.exe s_client -connect mx1.example.ch:25 -starttls smtp `
  -name probe.example.net -servername mx1.example.ch `
  -verify_hostname mx1.example.ch -verify_return_error -brief

openssl s_client -connect mx1.example.ch:25 -starttls smtp \
  -name probe.example.net -servername mx1.example.ch \
  -verify_hostname mx1.example.ch -verify_return_error -brief

openssl s_client führt mit -starttls smtp den nötigen Klartextdialog aus, setzt mit -name den SMTP-EHLO-Namen und mit -servername SNI. -verify_hostname und -verify_return_error machen aus dem blossen Handshake einen expliziten PKIX-Namenstest. Das Resultat beschreibt OpenSSL mit dessen Truststore, nicht automatisch die Policy des produktiven MTA.

Envelope und Antwortphase kontrolliert testen

swaks.exe --server mx1.example.ch --port 25 --tls `
  --ehlo probe.example.net --from sender@example.net `
  --to test-recipient@example.ch --quit-after RCPT

swaks --server mx1.example.ch --port 25 --tls \
  --ehlo probe.example.net --from sender@example.net \
  --to test-recipient@example.ch --quit-after RCPT

swaks protokolliert SMTP-Kommandos und Antworten und kann den Test bewusst nach RCPT beenden, ohne Nachrichtendaten zu senden. Das Werkzeug ist unter Windows kein Systembestandteil; swaks.exe beziehungsweise eine Perl-Installation muss aus einer kontrollierten Quelle stammen. Ein RCPT-Test darf nur gegen eigene oder ausdrücklich freigegebene Systeme und Adressen erfolgen, weil er Policy, Verzeichnisse und Rate Limits auslöst.

Listener und Pakete auf dem Server untersuchen

Get-NetTCPConnection -State Listen -LocalPort 25,465,587
pktmon filter add SMTP25 -p 25
pktmon start --capture --pkt-size 0
pktmon stop
pktmon etl2pcap PktMon.etl --out smtp.pcapng

ss -ltnp '( sport = :25 or sport = :465 or sport = :587 )'
tcpdump -ni any -s 0 -w smtp.pcap 'tcp port 25 or tcp port 465 or tcp port 587'

Get-NetTCPConnection und ss ordnen Listener und TCP-Zustände lokalen Prozessen zu. pktmon und tcpdump erfassen Pakete; produktive Captures können Envelope-Adressen, unverschlüsselte Inhalte und Authentisierungsdaten enthalten und müssen entsprechend geschützt, begrenzt und gelöscht werden. Wireshark eignet sich zur Analyse von TCP, SMTP und TLS-Handshakes, ersetzt aber weder Queue- noch Policylogs.

Fehler einer Grenze zuordnen

Beobachtbarkeit und Betriebsmodell

Ein SMTP-Monitor sollte nicht nur eine Testmail senden. Er muss die einzelnen Zustände des Systems sichtbar machen:

• Greeting-, EHLO-, STARTTLS-, AUTH- und End-of-Data-Latenz getrennt;
• Verbindungen, Sessions, aktive Transaktionen und Ablehnungen pro Phase;
• angebotene ESMTP-Fähigkeiten pro Listener und Backend;
• Annahmerate, Empfängerzahl, Nachrichtengrösse und durable-write-Latenz;
• Queueumfang nach Alter, Ziel, Transport, Status und letztem Fehler;
• Retryrate, älteste Nachricht, ablaufende Zustellungen und DSN-Erzeugung;
• DNS-Ziel, verbundene IP, IPv4/IPv6, TLS-Modus, Cipher und Policyresultat;
• Antwortcodes als strukturierte Felder statt ausschliesslich als Freitext;
• Korrelation von Edge-ID, interner Queue-ID, Remote-Queue-ID, Message-ID und Empfänger;
• LMTP-/Mailboxstatus pro Empfänger sowie Quarantäne- und Releasepfade;
• Spoolkapazität, I/O-Latenz, Datenbank- oder Brokerzustand und Replikationsrückstand;
• Schutzgrenzen für Logs und Captures, weil Envelope, Header und Inhalte personenbezogene oder vertrauliche Daten enthalten.

Queue-Backups allein genügen nicht. Wiederherstellung muss Konfiguration, Routingtabellen, Zertifikate und Schlüssel, Queue-Metadaten, Nachrichtenblobs, Quarantäne, Signaturzustand und Idempotenz berücksichtigen. Nach einem Restore darf eine bereits zugestellte Empfängerkopie nicht unkontrolliert erneut versendet werden; gleichzeitig dürfen noch offene Empfänger einer teilweise zugestellten Nachricht nicht verloren gehen. RPO und RTO sind daher pro Zustandskomponente zu definieren und mit einer echten Queue samt mehreren Empfängern zu testen.

Technische Geschichte

SMTP entstand aus früheren ARPANET-Mailverfahren. Jon Postels RFC 821 standardisierte 1982 das bis heute erkennbare Modell aus Sender-SMTP, Receiver-SMTP, MAIL, RCPT, DATA und dreistelligen Antworten. Das Nachrichtenformat wurde im selben Jahr separat in RFC 822 beschrieben. Diese Trennung von Transferprotokoll und Nachrichtenformat blieb erhalten.

Mit MIME wuchs SMTP über reinen 7-Bit-Text hinaus. Das ESMTP-Framework führte EHLO, registrierte Fähigkeiten und Parameter an MAIL beziehungsweise RCPT ein; seine Fassung von 1995 stand in RFC 1869. Darauf aufbauende Erweiterungen wie SIZE, 8BITMIME, PIPELINING, AUTH, STARTTLS, CHUNKING, DSN und später SMTPUTF8 entwickelten das Protokoll inkrementell, ohne einen parallelen «SMTP 2»-Stack zu schaffen.

RFC 2821 konsolidierte SMTP 2001 und löste RFC 821 sowie mehrere ergänzende Dokumente ab. RFC 5321 folgte 2008 als weitere Konsolidierung; das passende Internet Message Format steht in RFC 5322. Message Submission wurde zunächst separat spezifiziert und in RFC 6409 konsolidiert. Die technische Evolution verlief damit über klarere Rollen, Erweiterungsregister, internationalisierte Adressen, Zustellberichte und Transport-Policy, während der grundlegende zustandsbehaftete Dialog kompatibel blieb.

Auch die Softwarearchitekturen entwickelten sich auseinander. Historische Sendmail-Kompatibilität prägte lokale Kommandozeilenschnittstellen; Postfix setzte auf kooperierende, privilegiengetrennte Prozesse und explizite Queues, Exim auf einen stark konfigurierbaren Router-/Transport- und Spoolansatz, und JVM-Systeme wie Apache James machten die Verarbeitung über Komponenten und Mailets erweiterbar. Cloudplattformen verteilen dieselben logischen Rollen auf Frontends, Broker, Policyservices und regionale Queues. Für Administratoren bleibt deshalb die RFC-Semantik der gemeinsame Nenner, während Persistenz, Skalierung und Recovery immer produktspezifisch belegt werden müssen.