Zusammenfassung

  • STARTTLS schützte eine SMTP-Verbindung, während die Nachricht nach deren Ende in Warteschlangen und weiteren Verbindungen fortlebte. RFC 8689 ließ eine einzelne Nachricht geprüfte TLS-Weitergabe fordern und diese Pflicht an den nächsten konformen Weiterleitungsserver überreichen.
  • Kann kein MX Identität, TLS und die geschützte REQUIRETLS-Anzeige belegen, darf der MTA nicht in Klartext senden. Er erzeugt eine ebenfalls geschützte Unzustellbarkeitsmeldung. Ende-zu-Ende-Verschlüsselung entsteht dadurch nicht; die beteiligten MTAs sehen den Inhalt.

Eine Warteschlange enthält zwei Nachrichten für dieselbe Domäne. Die Wegwahl liefert dieselben MX-Ziele, der bevorzugte Server zeigt dasselbe abgelaufene Zertifikat. Für die eine Nachricht kann lokale Richtlinie weiterhin Zustellung priorisieren. Bei der anderen löscht derselbe Befund die Sendebefugnis.

Von außen sehen beide Dateien beinahe gleich aus. Der Unterschied liegt in gespeichertem Kontrollzustand. Eine trägt die Pflicht, den nächsten Hop zu authentisieren, die Pflicht weiterzugeben und bei Unmöglichkeit sichtbar zu scheitern.

Diese Persistenz war nötig, weil SMTP keine durchgehende Leitung ist. Ein Server nimmt Post an, speichert sie, beendet die Sitzung und öffnet später als sendende Seite eine neue. Sicherheitswissen, das nur im ersten TLS-Kontext lebt, stirbt vor der Nachricht.

STARTTLS zog eine Grenze um genau eine Sitzung

RFC 2487 führte 1999 STARTTLS ein. Öffentliche Mailzustellung musste mit ungleich modernisierten MX-Servern funktionieren. Eine sofortige allgemeine TLS-Pflicht hätte Erreichbarkeit verloren, weshalb erfolgreiche Zustellung normalerweise Vorrang behielt.

RFC 3207 ersetzte die frühe Fassung 2002. Nach EHLO-Anzeige, STARTTLS-Befehl und 220 beginnt die TLS-Aushandlung. Danach verwerfen beide Seiten das in Klartext Gelernte; die sendende Seite übermittelt EHLO erneut. Die geschützte Fähigkeitstabelle darf von der ersten abweichen.

Dieser Neustart verhindert, dass veränderbare Vorbehauptungen die sichere Phase regieren. Er beantwortet aber nur, was zwei aktuelle Gegenstellen dürfen. Nach Annahme und Speicherung braucht die Nachricht eine neue Verbindung. Deren Rückfallentscheidung ist sonst unabhängig.

Empfängerdomains erhielten später dauerhafte Regeln. RFC 7672 bindet SMTP DANE an DNSSEC-validierte TLSA-Einträge. RFC 8461 definiert MTA-STS mit per HTTPS gelieferter, gespeicherter MX- und Zertifikatspolitik. Beide sprechen für die Empfängerseite. Sie geben dem Absender nicht automatisch eine andere Entscheidung für eine einzelne sensible Nachricht.

REQUIRETLS wurde Teil des Umschlags

Der 2019 veröffentlichte RFC 8689 definierte die EHLO-Fähigkeit REQUIRETLS. Kein neuer SMTP-Befehl kam hinzu. Stattdessen erhielt der bestehende Umschlagbefehl einen wertlosen Parameter:

MAIL FROM:<sender@example> REQUIRETLS

Er darf nur in einer TLS-geschützten Sitzung erscheinen, die weitere Bedingungen erfüllt. Die MX-Identität muss durch DNSSEC oder MTA-STS abgesichert sein. Das Zertifikat muss über eine akzeptierte Vertrauenskette oder DANE validieren. Nach STARTTLS muss der Server REQUIRETLS im zweiten, geschützten EHLO erneut anzeigen.

Eine Anzeige im Klartext reicht nicht. Erst die Antwort innerhalb des authentisierten Kanals beweist, dass genau dieser Peer die zusätzliche Aufbewahrungspflicht übernimmt.

Der empfangende MTA markiert die Nachricht intern. Ob Warteschlangendatei, Datenbank oder Speicherfeld, bleibt der Implementierung überlassen. Verbindlich ist die Wirkung: Beim nächsten Senden müssen die Prüfungen neu erfolgen und der Parameter wieder in MAIL FROM stehen.

Lokale Alias-Expansion darf die Pflicht nicht zufällig verteilen. Entstehen mehrere Empfängerinstanzen, tragen alle dieselbe Markierung.

Vier Belege statt eines grünen Schlosses

Der Weiterleitungsserver ermittelt den Zielserver nach RFC 5321. Fehlt DNSSEC-Authentisierung der MX-Antwort, begrenzt MTA-STS den zulässigen Namen. Die sendende Seite richtet TLS ein, prüft das Zertifikat und kontrolliert anschließend die geschützte REQUIRETLS-Anzeige.

Verschlüsselung schützt die Bytes. Zertifikat oder DANE bindet den Schlüssel an eine Identität. DNSSEC oder MTA-STS beschränkt, welcher Host die Domain vertreten darf. Die letzte Anzeige verspricht, dass der nächste Verwahrer die nachrichtenbezogene Regel versteht und weiterträgt.

„TLS benutzt“ vermischt diese Beweise. Eine verschlüsselte Verbindung zum eingeschleusten MX ist falsch. Ein korrektes Zertifikat auf einem Server ohne REQUIRETLS bewahrt die Pflicht nicht. Auch eine nur vor der TLS-Aushandlung gelesene Anzeige besitzt nicht dieselbe Herkunft.

Die MX-Liste endete vor dem Klartext

Erfüllt der bevorzugte MX die Bedingungen nicht, beendet die sendende Seite den Versuch und prüft die übrigen Server. Ungeschützte Nachrichten darf sie gegebenenfalls noch an denselben Server liefern. Die Grenze gehört nicht dauerhaft zur Domäne, sondern zur markierten Nachricht.

Sind alle Kandidaten verbraucht, darf die Nachricht nicht übertragen werden. RFC 8689 empfiehlt 5.7.30 bei fehlender REQUIRETLS-Unterstützung und 5.7.10, wenn die benötigte TLS-Sitzung nicht zustande kommt. Danach geht eine Unzustellbarkeitsmeldung an den Reverse-Path.

Das ist die eigentliche Umkehr. Bei opportunistischem TLS konnte ein Sicherheitsfehler den Weg zu schwächerer Zustellung öffnen. REQUIRETLS macht denselben Fehler zum Entzug der Sendebefugnis. Ein erklärtes Scheitern bewahrt die ursprüngliche Entscheidung besser als erfolgreiche Zustellung unter anderen Bedingungen.

Diese Wahl kostet Verfügbarkeit. Ein abgelaufenes Zertifikat, ein altes Ersatz-MX oder verlorene Richtliniendaten können erreichbare Post stoppen. Der Standard verbirgt den Konflikt nicht. Er weist dem Absender das Recht zu, für diese Nachricht Vertraulichkeit höher zu gewichten.

Auch die Fehlermeldung konnte Informationen verraten

Eine Unzustellbarkeitsmeldung enthält häufig Kopfzeilen der ursprünglichen Nachricht. Absender, Empfänger, Betreff und Wegdetails können darin erscheinen. Wäre nur der Hinweg geschützt, könnte der Diagnoseweg dieselben Daten offenlegen.

Deshalb müssen alle Unzustellbarkeitsmeldungen zu REQUIRETLS-Nachrichten selbst REQUIRETLS verwenden, auch wenn die ursprüngliche Ursache nicht TLS war. Der Inhalt wird begrenzt: Die Meldung verhält sich wie mit DSN RET=HDRS; RET=FULL wird verworfen.

Unzustellbarkeitsmeldungen nutzen einen leeren Rückweg, damit ihr eigenes Scheitern keine Endlosschleife erzeugt. Der Rückweg kann andere Fähigkeiten besitzen als der Hinweg. RFC 8689 warnt, dass eine geschützte Diagnose verloren gehen kann, und behandelt den leeren Rückweg besonders, wenn der nächste Übergang REQUIRETLS nicht anzeigt.

Keine Fehlermeldung bedeutet daher nicht erfolgreiche Zustellung. Die Originalnachricht kann korrekt gestoppt worden sein, während die Erklärung keinen zulässigen Rückweg fand.

Das negative Headerfeld verlangte keinen Klartext

TLS-Required: No bittet unterstützende Weiterleitungsserver, Empfängerpolitik aus DANE oder MTA-STS nicht zum Zustellhindernis zu machen. So lässt sich etwa ein defektes Zertifikat melden, obwohl gerade dieses Zertifikat sonst den Hinweis blockieren würde.

STARTTLS soll weiterhin versucht werden. No ändert die Reaktion auf Scheitern, nicht die bevorzugte Übertragung. Der Empfängerserver kann unverschlüsselte Sitzungen weiterhin ablehnen; Absenderpolitik zwingt ihn zu nichts.

Steht zugleich REQUIRETLS im Umschlag, gewinnt der Parameter und das Headerfeld wird für die Behandlung ignoriert. Mehrere TLS-Required-Felder sind verboten. Inhalt kann eine im geschützten Umschlag übernommene Pflicht nicht abschwächen.

Reorigination war mehr als Weiterleitung

Ein normaler Weiterleitungsserver bewahrt dieselbe Nachricht. Mailingliste, Sieve-Regel, Weiterleitungsdienst oder Abwesenheitsantwort kann eine neue erzeugen. Adressaten, Kopfzeilen und Verantwortung ändern sich. RFC 8689 fordert, die eingehende Wahl soweit möglich zu übernehmen.

Die Einschränkung ist real. Eine Liste kann Empfänger mit und ohne REQUIRETLS-Pfad enthalten. Konsequente Vererbung schließt einige aus. Ein benutzerseitiger Filter kennt die SMTP-Markierung womöglich überhaupt nicht.

Damit tritt eine organisatorische Grenze hervor: Ist der Vermittler noch Transporteur oder bereits neuer Absender? Das Protokoll kann ehrliche Weiterleitungsserver verpflichten, aber neue Autorschaft nicht vollständig automatisieren.

Die MTAs blieben Leser der Nachricht

REQUIRETLS schützt jeden Übergang einzeln, bietet aber keine Ende-zu-Ende-Inhaltsverschlüsselung. Jeder MTA beendet TLS, verarbeitet Klartext und baut eine neue Sitzung auf. Ein bösartiger Weiterleitungsserver kann Unterstützung vortäuschen oder die Markierung entfernen. Der RFC nimmt ihn aus dem Bedrohungsmodell, weil ihm der Inhalt ohnehin anvertraut wurde.

Die Erweiterung hilft gegen passives Mithören, entfernte STARTTLS-Anzeigen, falsche MX-Wege und unbeabsichtigten Rückfall zwischen konformen Systemen. Sie authentisiert nicht den menschlichen Autor, verschlüsselt keine gespeicherte Warteschlange und beweist keinen späteren Übergang.

Das SMTP-Register der IANA belegt Name und Spezifikationszuordnung von REQUIRETLS. Es belegt keine heutige Nutzung oder Einhaltung.

Die bleibende Leistung ist, eine Entscheidung länger leben zu lassen als ihre Verbindung. Die Nachricht nimmt nicht nur Daten, sondern eine Grenze mit: Kann der nächste Verwahrer sie nicht erhalten, endet seine Befugnis. Fehler wurde damit nicht zum Gegenteil von Sicherheit, sondern zu einer ihrer ausführbaren Formen.