Zusammenfassung

  • Die id eines MTA-STS-TXT-Records ist ein Hinweis zum erneuten Abruf. Sie enthält und signiert die Richtlinie nicht, belegt keinen Abruf durch alle Absender und widerruft ältere Caches nicht global. Für jeden unterstützenden Absender gilt ein bestimmter, über authentisiertes HTTPS bezogener Richtlinienkörper mit eigener Abrufzeit und noch gültigem max_age.
  • Eine reproduzierbare Durchsetzungsentscheidung verbindet Richtliniendomäne, PKIX-Prüfung des Richtlinienhosts, exakte Bytes, Cacheherkunft, MX-Reihenfolge, STARTTLS, Zertifikat, Warteschlangenstatus, Wiederholungen und Endergebnis. enforce ist eine Transportregel für ein sendendes MTA, kein Beleg für Zustellung, Ende-zu-Ende-Vertraulichkeit, Postfachidentität oder geschäftliche Vollmacht.

Zwei Absender dürfen zu verschiedenen Ergebnissen kommen

Der Einstieg ist ein konstruierter Test, kein Bericht über einen Vorfall. Der Empfänger hält die neue Richtlinie für aktuell, weil Webserver und TXT-Record geändert wurden. Absender A sieht die neue ID, authentisiert mta-sts.<Domäne>, lädt die Datei und beginnt ein neues Cacheintervall. Seine angewendete Liste enthält bereits den Ausweich-MX.

Bei Absender B misslingt die Aktualisierung. RFC 8461 verlangt nicht, eine noch gültige Richtlinie zu verwerfen, nur weil die Live-Abfrage ausfällt. Ist ein nicht abgelaufener Cache vorhanden, muss er angewendet werden. Der neu aufgelöste Ausweich-MX steht dort nicht; B behandelt ihn deshalb als ungültigen Kandidaten und stellt die Nachricht zurück.

Keine der Entscheidungen lässt sich allein aus dem gegenwärtigen DNS und der aktuellen Webseite des Empfängers prüfen. Maßgeblich ist der Zustand des Absenders zum Entscheidungszeitpunkt. Die richtige erste Frage lautet nicht „Welche Richtlinie gilt jetzt?“, sondern „Welche authentisierten Bytes durfte dieser Absender bei diesem Versuch anwenden?“.

Die ID meldet Änderung, trägt aber nicht die Regel

Der TXT-Record unter _mta-sts.<Richtliniendomäne> enthält v=STSv1 und eine id. Eine geänderte ID löst einen neuen Abruf aus, ist jedoch weder Hash der HTTPS-Datei noch MX-Liste noch globales Widerrufssignal. DNS-Beobachtung und erfolgreicher HTTPS-Abruf finden für jeden Absender zu unterschiedlichen Zeiten statt.

Ohne gültigen Cache führt ein korrekter TXT-Record bei fehlgeschlagenem Richtlinienabruf dazu, dass der Absender so handelt, als sei MTA-STS nicht eingeführt. Mit gültigem Cache hält derselbe Fehler die ältere Regel in Kraft. „Neue ID gesehen“ und „neue Richtlinie angewendet“ sind daher getrennte Ereignisse und müssen getrennt protokolliert werden.

Bevor ein Absender eine Nachricht unter enforce endgültig ablehnt, muss er auf eine aktualisierte Richtlinien-ID prüfen. Bis dahin bleibt das Problem vorübergehend und unterliegt den SMTP-Wiederholungen. Das verhindert eine endgültige Rückgabe aufgrund einer Regel, die der Empfänger bereits ersetzt hat.

HTTPS authentisiert einen bestimmten Richtlinienkörper

Die Datei liegt auf dem Richtlinienhost mta-sts.<Richtliniendomäne> am festen Pfad /.well-known/mta-sts.txt. Das Zertifikat gilt für diesen Host, muss zu einer vom Absender akzeptierten Wurzel führen, zeitlich gültig sein und eine passende DNS-ID tragen. Der Körper enthält version, mode, mx-Einträge und max_age; im Modus none dürfen MX-Einträge fehlen.

Für eine Prüfung reicht „HTTPS war erfolgreich“ nicht aus. Erforderlich sind URL, Zeitpunkt, Status, Inhaltstyp, endgültige Bytes, Zertifikatskette, Namensprüfung und Hash des ausgewerteten Körpers. Eine Änderung der Datei ohne neue ID oder eine neue ID ohne geänderte Datei ist eine betriebliche Abweichung, die sichtbar bleiben muss.

max_age erzeugt mehrere legitime Gegenwarten

Die Frist beginnt beim erfolgreichen Abruf jedes einzelnen Absenders, nicht bei der Veröffentlichung durch den Empfänger. Caches derselben Fassung laufen deshalb zu verschiedenen Zeiten ab. Eine gestörte Aktualisierung macht eine noch gültige Kopie nicht automatisch ungültig; frühzeitige Erneuerung verringert die Angriffs- und Fehlerwirkung.

Auch eine saubere Abschaltung muss diese Überlappung beachten. Der Betreiber veröffentlicht eine authentisierte none-Richtlinie mit kurzem max_age, ändert die ID und wartet das längste alte Cachefenster ab, bevor TXT und HTTPS-Endpunkt verschwinden. Werden die Reparaturwege zuerst entfernt, können fremde Absender an einem alten enforce festhalten, ohne es noch ersetzen zu können.

Geprüft wird ein MX in einer konkreten Verbindung

Unter enforce muss ein Kandidat zu einem mx-Muster passen. Ein Platzhalter deckt nur die vollständige äußerste linke Bezeichnung ab, nicht die Stammdomäne und nicht mehrere Ebenen. Der Absender durchläuft weiter die normale MX-Priorität und behandelt ungültige Kandidaten wie vorübergehend unerreichbare. Ein fehlender Ausweich-MX kann bis zum Ausfall des primären Hosts unbemerkt bleiben.

Der gewählte Host muss STARTTLS anbieten. Sein gültiges PKIX-Zertifikat muss zu einer akzeptierten Wurzel führen und zum MX-Namen passen. Beim HTTPS-Abruf trägt SNI den Richtlinienhost; in der SMTP-Verbindung trägt es den ausgewählten MX. Wer diese Namen in der Untersuchung vertauscht, verbindet Beweise, die zu verschiedenen Prüfschritten gehören.

Ein Erfolg beweist nur einen akzeptierten TLS-Pfad von einem MTA zu einem erlaubten MX bei einem Versuch. Er beweist weder Ankunft im Postfach noch spätere Verschlüsselung, richtigen Leser, ungefährlichen Inhalt oder die Berechtigung zu einer Zahlung, Routenänderung oder sonstigen Geschäftsentscheidung.

Die Warteschlange verleiht der Richtlinie Wirkung

Erst der SMTP-Warteschlangenstatus macht aus einer Richtlinie eine Folge. Aufzuzeichnen sind Queue-ID, versuchter MX, vorübergehende oder endgültige Einstufung, Wiederholungsplan, ID-Prüfung vor endgültigem Fehler und Abschlussstatus. Ohne diese Zeitlinie zeigt ein Bericht Symptome, aber keinen belastbaren Zusammenhang.

Geeignete Prüffälle sind: neue ID mit erfolgreichem Abruf; alter, gültiger Cache bei gestörter Aktualisierung; abgelaufener Cache ohne Ersatz; Ausweichen auf einen Reserve-MX; und Abschaltung über none. Verglichen wird der tatsächlich angewendete Hash, nicht bloß die aktuelle Empfängerkonfiguration.

TLSRPT ist aggregiertes Zeugnis

Die Richtlinie _smtp._tls nach RFC 8460 fordert Berichte mit erkannten Richtlinien, aggregierten Zählwerten und Fehlerbeispielen an. Damit lassen sich Fehlkonfiguration, mögliche Störung, Regionen und Absenderimplementierungen vergleichen. Microsoft und Google dokumentieren gegenwärtige Produktoberflächen für MTA-STS und Berichte; das belegt ihre erklärten Produktschnittstellen, nicht das Verhalten aller MTAs.

Ein Bericht gehört zu seinem Erzeuger und Zeitraum. Keine Fehler können geschützten Verkehr, lückenhafte Abdeckung oder fehlenden relevanten Verkehr bedeuten. Aggregierte Zahlen sind keine Quittung für eine einzelne Nachricht und belegen weder Zustellung noch Lesen oder Vertraulichkeit. Erzeuger, Zeitraum, Reichweite und Stichproben müssen erhalten bleiben.

DANE und REQUIRETLS markieren benachbarte Grenzen

MTA-STS authentisiert die Richtlinie über HTTPS und PKIX und setzt DNSSEC nicht voraus. Die erste Entdeckung kann daher unterdrückt werden. DANE verankert eine andere Herabstufungsgrenze in DNSSEC. Eine fehlgeschlagene DANE-Prüfung darf nicht durch ein bequemeres MTA-STS-Ergebnis überstimmt werden.

REQUIRETLS nach RFC 8689 übermittelt die Absicht des Urhebers für eine einzelne Nachricht über unterstützende Relays. MTA-STS äußert die Transportvorgabe einer Empfängerdomäne gegenüber unterstützenden Absendern. Richtliniendomäne, nachrichtenbezogene Absicht und Verbindungsbeweis sind getrennte Autoritätsobjekte.

Eine Entscheidung muss wiederholbar sein

Der Mindestnachweis verbindet Richtliniendomäne; Resolver, Zeit, TXT-Bytes, TTL, DNSSEC-Zustand und ID; URL, Zeit, Ergebnis, Bytes und Zertifikatsprüfung des HTTPS-Abrufs; geparste Version, Modus, MX, max_age, Hash und Ablauf; Hash und Gültigkeit des alten Caches; MX-RRset und Reihenfolge; Host, Adresse, SNI, STARTTLS und PKIX-Ergebnis; Warteschlange, Wiederholungen und Abschluss; anwendbares DANE-Ergebnis; sowie TLSRPT-Aussage.

Damit kann ein Dritter die tatsächlich verfügbare Autorität für den betreffenden Zeitpunkt rekonstruieren. Ohne diese Daten wird der heutige DNS-Zustand fälschlich zur Erklärung einer früheren Entscheidung.

Quellen