MTA-STS (SMTP MTA Strict Transport Security, RFC 8461) ist ein Verfahren, mit dem eine E-Mail-Domain verbindlich erklärt, dass ihr Mailserver ausschließlich über verschlüsselte Verbindungen erreichbar ist. Wer eine Nachricht an diese Domain schickt, muss TLS mit einem gültigen Zertifikat aushandeln — ein stilles Zurückfallen auf Klartext ist nicht erlaubt.
Das Problem: STARTTLS ist nur ein Angebot
SMTP transportiert E-Mails zwischen Mailservern ursprünglich im Klartext. Erst der Befehl STARTTLS wertet eine bereits laufende Verbindung nachträglich zur verschlüsselten Verbindung auf. Weil dieser Schritt optional ist, kann ein Angreifer auf dem Transportweg das Angebot entfernen und die Übertragung auf Klartext zurückstufen — ein Downgrade-Angriff, bekannt als STARTTLS-Stripping. Der Absender bemerkt davon nichts.
Das verwandte DANE löst dasselbe Problem über signierte DNS-Einträge und setzt dafür DNSSEC voraus. MTA-STS ist die Alternative für Domains, die kein DNSSEC einsetzen wollen oder können: Die Richtlinie wird nicht im DNS, sondern als Datei über HTTPS veröffentlicht.
Zwei Bausteine: DNS-Eintrag und Policy-Datei
Der DNS-Eintrag kündigt lediglich an, dass überhaupt eine Richtlinie existiert:
_mta-sts.example.com. IN TXT "v=STSv1; id=20160831085700Z;"Der Parameter id ist eine kurze Zeichenkette, die bei jeder Richtlinienänderung mitwächst. Sie dient allein dazu, dass ein sendender Server eine geänderte Richtlinie erkennt. Der Eintrag darf DNSSEC-signiert sein, muss es aber nicht — ohne DNSSEC ist das Verfahren gegen DNS-Spoofing anfällig.
Die eigentliche Richtlinie liegt unter der festen Adresse https://mta-sts.example.com/.well-known/mta-sts.txt und verwendet ein einfaches Schlüssel-Wert-Format:
version: STSv1
mode: enforce
mx: mail.example.com
mx: *.example.net
max_age: 604800Die drei Modi
- enforce: Der sendende Server darf nur mit gültigem TLS und passendem Zertifikat zustellen. Schlägt das fehl, wird die Nachricht abgelehnt und nicht im Klartext verschickt.
- testing: Die Verbindung wird weiterhin zugestellt, auch wenn TLS fehlschlägt — die Fehler werden aber gemeldet. Dieser Modus dient der gefahrlosen Einführung.
- none: Signalisiert ausdrücklich, dass keine Richtlinie gilt.
Die übliche Vorgehensweise ist deshalb die schrittweise Aktivierung: erst none, dann testing samt Fehlerauswertung, und erst wenn die Meldungen sauber sind, enforce.
Technische Anforderungen
- TLS in Version 1.2 oder höher ist Pflicht.
- Das Zertifikat des Mailservers muss auf den Hostnamen aus dem MX-Record ausgestellt sein; dazu zählt auch ein passender Platzhalter-Eintrag.
- Es muss sich um ein Zertifikat einer anerkannten Zertifizierungsstelle handeln — selbst ausgestellte Zertifikate sind im Gegensatz zu DANE nicht möglich.
- Die Policy-Datei wird über HTTPS geladen, weshalb ein Web-Server für die Domain erreichbar sein muss.
Verhältnis zu DANE und zur Berichterstattung
MTA-STS und DANE können parallel betrieben werden. Die Spezifikation ist dabei so ausgelegt, dass eine fehlgeschlagene DANE-Prüfung nicht durch MTA-STS außer Kraft gesetzt wird — der stärkere Mechanismus gewinnt. Über Erfolge und Fehler des verschlüsselten Transports informiert TLS-RPT, das passende Berichtswesen. Wo eine Weiterleitung das Problem ist und nicht der Transport, hilft ARC, das die Authentifizierungsergebnisse über Zwischenstationen hinweg erhält.
Die Abstimmung mit SPF, DKIM und DMARC ist sinnvoll: Jene Verfahren weisen nach, wer senden darf, MTA-STS schützt zusätzlich den Weg dorthin. Ein typischer Fehlerbild-Punkt ist ein nicht erreichbares Policy-Dokument — dann bleibt eine bereits zwischengespeicherte Richtlinie bis zum Ablauf von max_age in Kraft, und Fehler erscheinen erst verzögert.
Verwandte Grundlagen: DNS, TLS-Handshake, TLS 1.3, Zertifizierungsstelle.