MTA-STS erklärt: Was es ist, TLS-RPT und ob Sie es brauchen

Mit MTA-STS (RFC 8461) kann eine Domain sendenden Mailservern mitteilen: „Liefere E-Mails an mich nur über TLS, nur mit einem gültigen Zertifikat und nur an diese MX-Hosts.“ Ohne MTA-STS ist die Verschlüsselung zwischen Mailservern opportunistisch, und jeder, der auf dem Übertragungsweg sitzt, kann sie entfernen. MTA-STS besteht aus einem TXT-Record, einer kleinen Textdatei, die über HTTPS ausgeliefert wird, und idealerweise einem zweiten TXT-Record (TLS-RPT, RFC 8460), über den Sie täglich Berichte darüber erhalten, was Absender bei der Zustellung erlebt haben. Liegt Ihre E-Mail bei einem großen Anbieter, kostet die Einrichtung einen Nachmittag. Wenn Sie irgendetwas Vertrauliches per E-Mail empfangen, lohnt sich dieser Aufwand.

Das Problem: STARTTLS ist opportunistisch

SMTP zwischen Servern beginnt im Klartext. Der empfangende Server bietet STARTTLS an, der Absender wertet die Verbindung auf, und der Rest läuft verschlüsselt. Zwei Schwächen sind dabei eingebaut:

• Downgrade. Ein Angreifer auf dem Übertragungsweg kann die Zeile STARTTLS aus der Antwort des Servers streichen. Der Absender schließt daraus, dass TLS nicht angeboten wird, und liefert im Klartext.
• Keine Authentifizierung. Absender prüfen das vorgelegte Zertifikat in der Regel nicht, weil viele Mailserver jahrzehntelang selbstsignierte oder nicht passende Zertifikate hatten. Wer die Antwort auf Ihre MX-Abfrage fälschen oder die Verbindung abfangen kann, kann ein beliebiges Zertifikat vorlegen.

Die drei Bestandteile

1. Der TXT-Record unter _mta-sts

$ dig +short TXT _mta-sts.example.com
"v=STSv1; id=20260921000000"

id ist eine beliebige Zeichenkette aus bis zu 32 Buchstaben und Ziffern. Ihre einzige Aufgabe ist es, sich bei jeder Änderung der Richtlinie ebenfalls zu ändern, damit Absender wissen, dass sie die Datei neu laden müssen.

2. Die Policy-Datei

Sie wird unter einer festen URL auf dem festen Hostnamen mta-sts ausgeliefert:

$ curl https://mta-sts.example.com/.well-known/mta-sts.txt
version: STSv1
mode: testing
mx: mx1.mail.example.net
mx: mx2.mail.example.net
max_age: 86400

Feld	Bedeutung
version	Immer STSv1
mode	enforce, testing oder none
mx	Eine Zeile je erlaubtem MX-Host. Ein Platzhalter wie *.mail.example.net ist zulässig und steht für genau ein Label ganz links
max_age	Wie lange Absender die Richtlinie zwischenspeichern dürfen, in Sekunden. Höchstens 31557600 (etwa ein Jahr)

Der HTTPS-Server muss ein öffentlich vertrauenswürdiges Zertifikat vorlegen, das für mta-sts.example.com gültig ist. Absender folgen beim Abruf der Richtlinie keinen HTTP-Weiterleitungen, die Datei muss also genau unter dieser URL liegen.

3. MX-Hosts, die die Prüfung bestehen

Jeder aufgeführte Host muss STARTTLS mit einem Zertifikat anbieten, das nicht abgelaufen ist, zu einer Zertifizierungsstelle führt, der der Absender vertraut, und zum MX-Hostnamen passt.

$ openssl s_client -starttls smtp -connect mail.example.com:25 \
    -servername mail.example.com </dev/null 2>/dev/null \
    | openssl x509 -noout -subject -enddate -ext subjectAltName

Ist das Zertifikat auf Ihrem eigenen MX abgelaufen, beheben Sie das zuerst. Die Verlängerung beschreibt der Beitrag SSL-Zertifikat abgelaufen: Was tun.

Wie ein Absender die Richtlinie anwendet

1. Vor der Zustellung an example.com fragt der Absender _mta-sts.example.com ab.
2. Hat er keine Richtlinie im Cache, oder weicht die id von der zwischengespeicherten ab, lädt er die Policy-Datei über HTTPS.
3. Er speichert die Richtlinie für max_age Sekunden zwischen.
4. Er löst die MX-Records wie gewohnt auf, verwirft dann jeden MX-Host, der zu keiner mx:-Zeile passt, und verlangt für die übrigen gültiges TLS.

Was bei einem Fehler geschieht, hängt vom Modus ab:

Modus	Bei einem TLS-Fehler oder einem nicht passenden MX
testing	Die Nachricht wird trotzdem zugestellt; der Fehler wird über TLS-RPT gemeldet
enforce	Der Absender liefert nicht an den fehlerhaften Host. Besteht kein Host die Prüfung, bleibt die Nachricht in der Warteschlange, wird erneut versucht und geht schließlich als unzustellbar zurück
none	Die Domain erklärt, keine aktive Richtlinie zu haben. Dient zum Zurückziehen

Seine Stärke bezieht MTA-STS aus dem Cache. Ein Angreifer, der heute die TXT-Abfrage oder den HTTPS-Abruf blockiert, kann einen Absender nicht dazu bringen, eine Richtlinie zu vergessen, die er letzte Woche zwischengespeichert hat. Der schwache Moment ist der allererste Abruf, bevor irgendetwas im Cache liegt.

TLS-RPT: erfahren, was Absender sehen

$ dig +short TXT _smtp._tls.example.com
"v=TLSRPTv1; rua=mailto:tlsrpt@example.com"

rua nimmt eine mailto:-Adresse oder eine https:-URI entgegen. Teilnehmende Absender schicken pro Tag einen zusammengefassten JSON-Bericht: wie viele Sitzungen zu Ihrer Domain erfolgreich waren, wie viele fehlgeschlagen sind und warum (abgelaufenes Zertifikat, nicht passender Hostname, kein STARTTLS angeboten, MX nicht in der Richtlinie). Die Berichte decken sowohl MTA-STS als auch DANE ab. Ohne sie testet der Modus testing nichts, weil Ihnen niemand das Ergebnis mitteilt.

Reihenfolge der Einführung

• Stellen Sie sicher, dass jeder MX-Host ein gültiges, passendes und öffentlich vertrauenswürdiges Zertifikat hat (Befehl oben).
• Veröffentlichen Sie zuerst den TLS-RPT-Record und lassen Sie die Berichte eintreffen.
• Legen Sie die Policy-Datei mit mode: testing und einem kurzen max_age wie 86400 ab.
• Veröffentlichen Sie den TXT-Record unter _mta-sts.
• Lesen Sie die Berichte einige Wochen lang. Achten Sie auf Fehler bei legitimen Absendern und auf MX-Hosts, die in der Richtlinie fehlen.
• Wechseln Sie zu mode: enforce, ändern Sie die id und halten Sie max_age in den ersten Tagen kurz.
• Erhöhen Sie max_age auf einige Wochen, sobald Ruhe eingekehrt ist.
• Nehmen Sie das Zertifikat des mta-sts-Hosts und die MX-Zertifikate in die Ablaufüberwachung auf.

Den veröffentlichten _mta-sts-Record und die Richtlinie einer Domain zeigt der MTA-STS-Check, den Berichts-Record der TLS-RPT-Check.

E-Mail beim Anbieter

Zeigen Ihre MX-Records auf einen E-Mail-Anbieter, sind die Zertifikate dessen Aufgabe, und große Anbieter haben sie in Ordnung. Ihr Anteil:

• Tragen Sie die MX-Namen des Anbieters genau so in die Richtlinie ein, wie sie in Ihren MX-Records stehen, oder in der Platzhalterform, die der Anbieter dokumentiert.
• Legen Sie die Policy-Datei selbst unter mta-sts.example.com ab. Ein Host für statische Seiten genügt.

Wechsel des E-Mail-Anbieters

Sobald Sie in enforce sind, kommt es auf die Reihenfolge an. Absender halten eine zwischengespeicherte Richtlinie, die nur die alten MX-Hosts aufführt. Wenn Sie zuerst die MX-Records umstellen, sehen diese Absender neue Hosts, die die Richtlinie nicht erlaubt, und verweigern die Zustellung.

1. Nehmen Sie die MX-Namen des neuen Anbieters in die Policy-Datei auf (die alten bleiben stehen) und ändern Sie die id.
2. Geben Sie Absendern Zeit, die neue id zu bemerken und die Richtlinie neu zu laden; einige Tage sind ein vorsichtiger Puffer.
3. Stellen Sie die MX-Records um.
4. Entfernen Sie später die alten Namen aus der Richtlinie und ändern Sie die id erneut.

Das ist auch der Grund, nicht zu früh auf ein max_age von einem Jahr zu gehen.

Eine Richtlinie zurückziehen

TXT-Record und Datei zu löschen ist kein Zurückziehen. Absender mit einer zwischengespeicherten enforce-Richtlinie setzen sie weiter durch, bis ihr Cache abläuft. Der saubere Weg: Veröffentlichen Sie mode: none mit einer neuen id, lassen Sie Record und Datei stehen, bis das bisherige max_age vollständig abgelaufen ist, und entfernen Sie beides erst dann.

MTA-STS und DANE

DANE für SMTP (RFC 7672) löst dasselbe Problem auf anderem Weg: Das Zertifikat oder der Schlüssel des MX-Hosts wird in einem TLSA-Record festgeschrieben, und diesem Record wird vertraut, weil die Zone mit DNSSEC signiert ist.

	MTA-STS	DANE für SMTP
Vertrauensanker	Web-PKI (öffentliche CAs) plus HTTPS	DNSSEC-Kette
Braucht DNSSEC	Nein	Ja: Die TLSA-Records der MX-Hosts müssen in einer signierten Zone liegen
Schwäche beim Erstkontakt	Ja, bis die Richtlinie im Cache liegt	Nein

Beide können nebeneinander bestehen, und TLS-RPT berichtet über beide. Bei E-Mail beim Anbieter hängt DANE davon ab, ob der Anbieter seine MX-Zone signiert; MTA-STS liegt in Ihrer eigenen Hand. Mehr dazu unter DNSSEC erklärt.

Was MTA-STS nicht leistet

• Es schützt nur eingehende E-Mails an Ihre Domain. Ihre ausgehenden E-Mails schützen die Richtlinien der Empfänger, sofern Ihr sendender Server MTA-STS beachtet.
• Es wirkt nur bei Absendern, die es umsetzen. Alle anderen liefern weiterhin opportunistisch.
• Es ist Transportverschlüsselung von Hop zu Hop, keine Ende-zu-Ende-Verschlüsselung. Auf jedem Server, den die E-Mail durchläuft, ist sie lesbar.
• Es sagt nichts über Spam, Spoofing oder Absenderauthentifizierung aus. Dafür sind SPF, DKIM und DMARC zuständig: siehe MX, SPF, DKIM und DMARC erklärt.

Brauchen Sie es?

• Domain bei einem großen E-Mail-Anbieter: geringer Aufwand, geringes Risiko. Die Zertifikate des Anbieters werden gepflegt; Sie ergänzen zwei TXT-Records und eine statische Datei.
• Domain, die vertrauliche E-Mails empfängt (Verträge, Gesundheit, Finanzen, Zurücksetzen von Zugängen): lohnend, auch wenn Sie den MX selbst betreiben, sofern Sie die Zertifikate überwachen.
• Noch nicht bereit für eine Festlegung: Der Modus testing plus TLS-RPT bringt kein Zustellrisiko mit sich und zeigt Ihnen, ob enforce Schaden anrichten würde.

Häufige Fehler

• Direkt auf enforce gehen, ohne TLS-RPT, und von Fehlern erst durch Leute erfahren, deren E-Mails zurückkamen.
• Die Policy-Datei bearbeiten und die id unverändert lassen. Absender behalten die alte Richtlinie, bis max_age abgelaufen ist.
• In der mx:-Zeile die Domain (example.com) eintragen statt der MX-Hostnamen.
• Eine Policy-Datei, die nur über eine Weiterleitung erreichbar ist oder unter einem Zertifikat liegt, das mta-sts.example.com nicht abdeckt.
• Das Zertifikat des mta-sts-Hosts ablaufen lassen: Neue Absender können die Richtlinie nicht mehr abrufen.
• MX-Records umstellen, bevor die Richtlinie aktualisiert ist, oder alles auf einmal löschen, um es „abzuschalten“.

Mit OrbitProbe prüfen

Beginnen Sie mit der MX-Abfrage von OrbitProbe: Sie listet die MX-Hosts einer Domain mit ihren Prioritäten auf, zusammen mit den SPF- und DMARC-Records. Die dort gezeigten Hostnamen sind diejenigen, zu denen Ihre mx:-Zeilen Zeichen für Zeichen passen müssen. Führen Sie die Abfrage also aus, bevor Sie die Richtlinie schreiben, und noch einmal nach jedem Wechsel des E-Mail-Anbieters. Eine DNS-Abfrage zeigt, was jetzt veröffentlicht ist; ob Absender tatsächlich TLS aushandeln konnten, zeigen die TLS-RPT-Berichte. Lesen Sie diese also auch nach dem Wechsel zu enforce weiter.