Mail-Transportsicherheit

MTA-STS, TLS-RPT und DANE: Mail-Transportsicherheit in Schichten

MTA-STS und DANE lösen dasselbe Problem aus zwei verschiedenen Vertrauenswurzeln — und decken gegenseitig ihre blinden Flecken ab. Die Domains, die beides publizieren und TLS-RPT für die Sicht dazu, erfahren von Problemen aus einem Report statt von einem Nutzer.

Ein Problem, zwei Vertrauenswurzeln

Beide Mechanismen adressieren dasselbe Downgrade-Szenario: SMTP-TLS zwischen Servern ist opportunistisch — ein Angreifer im Pfad kann STARTTLS ausfiltern und Klartext erzwingen oder ein gefälschtes Zertifikat präsentieren, das ein opportunistischer Sender nie verifiziert. Die Frage ist, woher ein Sender die vertrauenswürdige Aussage bekommt, dass deine Domain verifiziertes TLS erwartet.

DANE verankert diese Aussage in DNSSEC: ein TLSA-Record unter dem MX-Hostnamen, gültig nur bei validierender DNSSEC-Kette. MTA-STS verankert sie in der Web-PKI: eine Policy-Datei, per HTTPS von mta-sts.deine-domain geholt, geschützt durch ein normales Browser-Zertifikat. Dasselbe Versprechen, verschiedene Vertrauenswurzeln — und verschiedene Sender-Populationen. Manche großen Sender validieren DANE, andere holen MTA-STS-Policies, und die Überschneidung ist unvollständig genug, dass nur eines von beiden echte Sender auf dem Weg zu dir ungeschützt lässt.

Die Mechanismen scheitern auch unterschiedlich — das stärkste Argument fürs Schichten. DANE erbt jedes DNSSEC-Fehlerbild; eine Bogus-Zone legt es komplett still. MTA-STS erbt Web-Infrastruktur-Fehlerbilder: ein abgelaufenes Zertifikat auf dem Policy-Host oder ein kaputter Redirect deaktiviert die Durchsetzung für Policy-holende Sender — leise. Es ist gut möglich, das eine zu brechen, während das andere weiterschützt. Sofern es beide gibt.

Die Details richtig machen

MTA-STS besteht aus zwei gekoppelten Teilen: dem DNS-TXT-Record _mta-sts.deine-domain, der die Policy-Version ankündigt, und der Policy-Datei unter https://mta-sts.deine-domain/.well-known/mta-sts.txt mit MX-Liste und Modus. Der subtile Vertrag steckt im id-Feld des TXT-Records: Sender cachen Policies aggressiv und holen erst neu, wenn sich die id ändert. Jede Policy-Änderung muss also die id ändern — sonst setzt die Welt deine alte Policy so lange durch, wie max_age es erlaubt. Und die MX-Liste der Policy muss jeden Host deines MX-Sets abdecken: Ein vergessener Backup-MX bei mode: enforce heißt, dass Failover-Mail von policy-treuen Sendern abgelehnt wird — genau dann, wenn dein Primärer down ist.

Validiere das Gesamtkonstrukt — TXT-Record, Policy-Erreichbarkeit, MX-Abdeckung, Modus — mit dem MTA-STS-Prüfer/Generator und quergeprüft mit dem SMTP-TLS-Handshake / Mail-Domain-Empfangsbereitschaft für das Live-Transportbild. Läuft zusätzlich DANE, deckt der DANE-Validator diese Hälfte ab. Die Mechanismen koexistieren, doch ein DANE-Validierungsfehler wird nicht von einem erfolgreichen MTA-STS-Check überschrieben; ein Sender wendet die unterstützten Trust-Regeln an, ohne mit einer grünen Schicht den Fehler einer anderen zu löschen.

TLS-RPT: der Rückkanal, den alle vergessen

Durchsetzung ohne Sicht ist eine Falle: Transportsicherheits-Fehler passieren auf fremder Infrastruktur, in Sende-Queues, die du nicht siehst — und das Default-Symptom ist Mail, die leise nicht ankommt. TLS-RPT liefert die fehlende Hälfte. Ein einzelner TXT-Record — _smtp._tls.deine-domain mit einer rua-Adresse — bittet Sender, dir täglich JSON-Zusammenfassungen ihrer TLS-Ergebnisse Richtung deiner Domain zu schicken: wie viele Sessions erfolgreich waren und was woran scheiterte — vom Zertifikats-Mismatch über Policy-Fetch-Fehler bis zu nicht verfügbarem STARTTLS.

Die Reports sind klein im Volumen und im Incident Gold wert: Sie unterscheiden einen fehlkonfigurierten Sender von einer kaputten Policy auf deiner Seite von einem aktiven Downgrade in irgendeinem Netzpfad — Unterscheidungen, die aus den eigenen Logs kaum zu treffen sind, weil die Fehler passieren, bevor die Verbindung dich erreicht. Prüfe mit dem TLS-RPT-Prüfer/Generator den einzelnen Record und die Syntax seiner rua-URIs; ob das Ziel Reports annimmt und verarbeitet, muss separat verifiziert werden, denn eine gültige URI beweist weder Annahme noch Zustellung. Behandle einen plötzlichen Anstieg an Fehler-Reports als das Frühwarnsignal, das er ist. Die Kombination — DANE und MTA-STS für die Durchsetzung, TLS-RPT für die Augen — ist der aktuelle Stand der Kunst für jede Domain, deren Mail zählt.