MTA-STS für den eigenen E-Mail-Server einrichten

MTA-STS lässt sich bereits mit wenigen Handgriffen einrichten, wenn der E-Mail-Server verschlüsselte Verbindungen beherrscht (beispielsweise per TLS). Dann können andere E-Mail-Server prüfen, ob der eigene E-Mail-Server berechtigt ist, E-Mails über die jeweilige Domain zu versenden oder nicht.

Insgesamt bestehen die Handgriffe aus dreien mit anschließendem Test. Dazu muss zum einen eine bestimmte Datei unter einer bestimmten Subdomain angelegt sowie ein DNS-Eintrag hinzugefügt werden.

Servereinstellungen

Bei MTA-STS wird immer eine bestimmte URL geprüft, nämlich folgende:
https://mta-sts.kittmedia.com/.well-known/mta-sts.txt

Daher muss diese Subdomain erst einmal eingerichtet werden. Je nach verwendetem Webserver bzw. Serverkontrollsystem funktioniert das unterschiedlich. Anbei meine Konfiguration für nginx:

server {
	listen 80;
	listen [::]:80;
	server_name mta-sts.kittmedia.com;
	return 301 https://$server_name$request_uri;
}

server {
	listen 443 ssl http2;
	listen [::]:443 ssl http2;

	##
	# General settings
	##

	root /var/www/kittmedia/mta-sts;
	server_name mta-sts.kittmedia.com;

	access_log /var/log/nginx/mta-sts.kittmedia.com-access.log;
	error_log /var/log/nginx/mta-sts.kittmedia.com-error.log;

	location / {
		try_files $uri $uri/ /index.php?$uri&$args;
	}
	
	##
	# SSL include
	##
	
	include /etc/nginx/letsencrypt.conf;
	include /etc/nginx/ssl-kittmedia.conf;

	##
	# Include parameters
	##

	include /etc/nginx/default_params;
	include /etc/nginx/fastcgi_params;
}

Wichtig ist hierbei insbesondere, dass diese Subdomain über ein gültiges SSL-Zertifikat verfügt und darüber auch aufrufbar ist.

mta-sts.txt

Wie man an der URL sieht, wird eine bestimmte Textdatei angefordert. Die muss unter der Subdomain genau mit diesem Dateinamen, also mta-sts.txt im Unterordner .well-known zur Verfügung stehen.

Meine sieht hierbei folgendermaßen aus:

version: STSv1
mode: enforce
mx: dagobah.kittmedia.com
mx: mail.kittmedia.com
max_age: 604800

In Zeile 1 wird die Version von MTA-STS angegeben, die man verwendet. Hier Version 1.

Der Modus in Zeile 2 ist entweder enforce, testing oder none. Während letzterer dazu führt, dass MTA-STS ignoriert wird, schaltet enforce die Verifizierung via MTA-STS scharf. testing bedeutet, dass die Verifizierung auch fehlschlagen darf und (sofern aktiviert) per TLS Reporting gemeldet wird.

Daraufhin folgen die MX-Einträge, die auch per DNS hinterlegt sind, wie in den Zeilen 3–4 zu sehen.

max_age gibt das maximale Alter der Gültigkeit dieser Datei in Sekunden an. Der Maximalwert beträgt hier 31557600 (1 Jahr). Der empfohlene Minimalwert beträgt mehrere Wochen.

DNS

Wann immer sich Daten in der mta-sts.txt ändern, muss auch der zur MTA-STS zugehörige DNS-Eintrag geändert werden. Dieser sieht bei mir wie folgt aus:
_mta-sts IN TXT "v=STSv1; id=kme4e61kj52s1e2u;"

Dabei wird ebenfalls, wie in der mta-sts.txt selbst, die Version angegeben (auch hier wieder Version 1) sowie eine eindeutige ID. Dies kann ein beliebiger alphanumerischer Wert sein. Wichtig dabei ist jedoch, dass er nicht fortlaufend sein soll. Andernfalls können Angreifer darauf spekulieren, beispielsweise dass im oben genannten Beispiel die nächste Version lediglich ein v statt eines u als letztes Zeichen in der ID bekäme. Stattdessen ändere ich aber auch noch mehrere andere Stellen beliebig ab, wenn ich etwas an der mta-sts.txt verändere.

Test

Nach der erfolgreichen Konfiguration folgt der Test. Dafür gibt es mehrere Online-Werkzeuge, die dafür verwendet werden. Relativ praktisch erwies sich mir der unter folgender URL:
https://aykevl.nl/apps/mta-sts/

Was ich erst spät bemerkte: Dieser Test speichert DNS-Angaben zwischen. D. h. bei anfänglicher falscher Konfiguration sollte man unbedingt einige Zeit warten, bis dieser Zwischenspeicher gelöscht wurde.

Fazit

Bereits mit wenigen Handgriffen kann man seinen E-Mail-Versand etwas besser absichern. Gerade wegen des geringen Aufwands sollte man das meiner Meinung nach auch tun.

4 Kommentare zu “MTA-STS für den eigenen E-Mail-Server einrichten

  1. Es reicht aus, wenn bei jedem Update von mta-sts.txt eine neue (nicht im bisherigen max-age-Zeitraum verwendete) ID für den DNS-Eintrag verwendet wird. Eine fortlaufende Zahl oder ein kodiertes Datum sind hier ausreichend, RFC8641 gibt hier keine Anforderungen an die Komplexität vor.

    Der DNS-Eintrag dient nur dazu, damit ein MTA sehr „günstig“ feststellen kann, ob eine MTA-STS entweder initial zu laden ist oder eine ggf. bereits lokal gecachete Policy vor Ablauf von max-age aktualisiert werden muss.

    Dadurch kann der max-age-Wert im mta-sts.txt sehr hoch gesetzt werden: der MTA kann so die mta-sts.txt für sehr lange cachen und auch anwenden, falls etwa mal der DNS-Eintrag (z.B. durch einen Angreifer oder einen Konfigurationsfehler) fehlen sollte. Verändert ein Angreifer den DNS-Eintrag, löst das „nur“ einen Update-Versuch aus: misslingt dieser (z.B. wegen einem fehlerhaften Zertifikat), wird bis zum Ablauf von max-age weiterhin das bereits gecachte mta-sts.txt verwendet.

    Will man aber die mta-sts.txt legitimerweise vor dem Ablauf von max-age austauschen, muss ein MTA auch davon zeitnah erfahren können – und genau dafür nutzt man eine Änderung im DNS-Eintrag, natürlich mit einer akzeptabel niedrigen TTL für den DNS-Eintrag.

    1. Es ist dennoch eine potenzielle Quelle für Probleme, wenn ein Angreifer davon ausgehen kann, dass die Zeichenkette fortlaufend ist. Das allein ist natürlich noch keine Sicherheitslücke, aber es wäre nicht das erste Mal, dass ein erster kleiner Schritt in einer ganzen Reihe an Fehlern dazu führen kann, dass Angreifer erfolgreich sind. Daher: sicher ist sicher. Und es ist praktisch kein Aufwand, keine fortlaufende Nummerierung zu nutzen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.