Zusammenfassung

  • RFC 5383 beschreibt, dass Hotels und andere Netze ausgehende Verbindungen zu Port 25 ungeachtet des Zielhosts abfingen und vertrauliche Kommunikation an einen unbekannten Drittserver lenken konnten.
  • Port 587 schafft eine prüfbare Zuständigkeitsgrenze für Message Submission. Er beweist allein weder Serveridentität noch TLS, Berechtigung, Queue-Übernahme, Weiterleitung oder Zustellung.

Eine Zuständigkeitsgrenze, die im Pfad verschwand

Der Benutzer hatte einen Hostnamen konfiguriert. DNS lieferte eine Adresse. TCP kam zustande und ein SMTP-Server begrüßte den Client. Im Monitoring erschien die Verbindung als erfolgreich. Genau dieses Ergebnis konnte laut RFC 5383 irreführend sein: Das Zugangsnetz konnte Port 25 abfangen und einen anderen Server antworten lassen.

Das Dokument von 2008 belegt keine heutige Verbreitung, kein bestimmtes Hotel und keinen konkreten Datendiebstahl. Es belegt eine technische Möglichkeit mit klarer Verantwortungswirkung. Transporterfolg und Zieltreue sind verschiedene Tatsachen.

Ein Netz, das nur sperrt, bleibt eine sichtbare Kontrollstelle. Ein Netz, das einen SMTP-Gegenpart ersetzt, übernimmt eine Anwendungsrolle. Ohne Offenlegung entscheidet es, wer Metadaten, möglicherweise Zugangsdaten und Nachrichteninhalt erhält. Die Macht erweitert sich, ohne dass Identität und Haftung im selben Maß sichtbar werden.

Einlieferung braucht einen eigenen Dienst

Internet-Mail besteht aus mehreren Aufträgen. Ein User Agent erstellt eine Nachricht und liefert sie ein. Der Submission-Dienst authentisiert gegebenenfalls den Benutzer, wendet Richtlinien an und übernimmt oder verweigert die Nachricht. Transfer Agents leiten weiter; das Zielsystem legt ab; ein Mensch liest vielleicht später.

RFC 2476 trennte Message Submission vom gewöhnlichen SMTP-Transfer. RFC 4409 überarbeitete das Modell, RFC 6409 ist die aktuelle Nachfolgerin. Port 587 kennzeichnet die Einlieferung durch den Benutzer, Port 25 primär den Transfer. RFC 5383 verlangte deshalb Erreichbarkeit von 587 und empfahl dessen Standardnutzung für Lemonade-Clients.

Diese Trennung ist eine Verwaltungsarchitektur. Authentisierung, unterstützte Erweiterungen, Limits und Annahmebelege können einem verantwortlichen Dienst zugeordnet werden. Firewalls können die beabsichtigte Funktion ausdrücklich erlauben.

Die Nummer authentisiert den Betreiber jedoch nicht. Sie benennt eine erwartete Dienstklasse. Auch ein falscher Prozess kann dort lauschen. Aus der IANA-Konvention folgt keine Vollmacht für jeden Antwortenden.

Eine Beweiskette statt eines Verfügbarkeitsbits

Der Client wählt einen Namen. DNS liefert Adressen. Die Verbindung erreicht einen beobachteten Peer. TLS kann den Kanal schützen und eine Referenzidentität validieren. SMTP AUTH kann ein Konto gegenüber der Richtlinie des antwortenden Servers feststellen. Eine positive Antwort kann die Übernahme der Transaktion bedeuten. Danach folgen Transfer und Zustellung.

RFC 8314 empfahl später TLS für Mailzugriff und -einlieferung und dokumentierte submissions auf Port 465, neben dem etablierten STARTTLS-Pfad auf 587. Diese Entwicklung widerlegt die Gleichung „587 = sicher“. Schutz entsteht erst durch korrekt ausgehandeltes TLS, passende Zertifikatsprüfung und ein Scheitern ohne stilles Downgrade.

Ein prüffähiger Datensatz hält Soll-Hostname, DNS-Antwort, Ist-Peer, Port, TLS-Modus, Zertifikatsidentität, Prüfresultat, SMTP-Banner und Fähigkeiten, Authentisierungsverfahren, Principal, Antworten, Queue-ID und Zeiten getrennt. Wer alles auf „verbunden“ reduziert, vernichtet den Nachweis der Substitution.

Explizites Blockieren ist beherrschbarer als fremde Annahme

Provider dürfen Port 25 aus Gründen der Spam- und Schadsoftwareabwehr einschränken. Die normative Frage lautet nicht, ob eine Sicherheitsentscheidung erlaubt ist, sondern ob sie als Ablehnung erkennbar bleibt oder sich als fremder Dienst tarnt.

Bei einer Sperre kann der Client den vorgesehenen Submission-Dienst verwenden, den Benutzer informieren oder eskalieren. Bei Interception entsteht falsche Kontinuität. Der nicht gewählte Server erhält Daten; der erwartete Provider hat keinen Vorgang; der Client meldet dennoch Erfolg.

Anwendungsfirewalls können zusätzlich nur Teile von SMTP-Erweiterungen verstehen. Dann sieht eine Seite eine Aushandlung, die andere erhält einen veränderten Zustand, und der Fehler erscheint später. Dieser Beitrag übernimmt nicht die allgemeine Firewall-These der RFC 2979 und nicht die HTTP-Tunnel-These der RFC 3093. Er behandelt ausschließlich die Nachweisbarkeit des Submission-Gegenübers.

Annahme und Zustellung bleiben getrennt

Auch der richtige, authentisierte Submission-Server kann nur seinen Schritt bescheinigen. Ein 2xx-Code oder eine Queue-ID kann Annahme unter einer Richtlinie beweisen. Er beweist nicht jeden Relay-Hop, die Mailbox-Ablage, Anzeige oder Lektüre.

Im Incident werden begrenzte Belege verbunden: gewünschtes Ziel, beobachteter Peer, Kanalidentität, Konto, Umschlag und Inhalt, Queue-Custody, Relay-Versuche und Zielantwort. Nach einer Interception gehört die Queue-ID womöglich allein zum Ersatzsystem. Ihre Genauigkeit schafft keine Beziehung zum ursprünglich gewählten Dienst.

Ein Abnahmetest verbindet sich aus Unternehmens-, Mobil-, Heim- und Gastnetzen mit einem kontrollierten Dienst. Er erzwingt falsche Zertifikate, fehlendes STARTTLS, veränderte Capabilities, fremde Banner und klare Blocks. Zulässig sind nachgewiesene Zielidentität oder ein zurechenbarer Fehler, nicht ein stilles Herabstufen zugunsten einer grünen Anzeige.

Quellen