MTA-STA-Policy

Zitat aus dem genannten Artikel (Hervorhebung von mir):

Im Falle einer Delegation kann dieses Label zu einem Server des Mailproviders auflösen oder per CNAME darauf verweisen. Eine Alternative besteht in einem unter dieser URL erreichbaren Reverse Proxy, der die Policy beim eigentlichen Mailboxprovider abruft.

Das Zertifikat dieses Abrufs muss in jedem Fall gültig sein. Sein Name muss zum Hostnamen der Ziel-Domain passen (und im Delegationsfall nicht nur zu der des Mailboxproviders) und es muss von einer CA ausgestellt sein, der der Einlieferer vertraut.

Eine gültige Delegation könnte daran scheitern, dass bei Verweisung per CNAME die Auslieferung der Policy mit einem SSL-Zertifikat von MBO erfolgt, das deine eigene Domain nicht einschließt.

Funktioniert aktuell auch leider nicht. Mal schauen, habe den Support angeschrieben. Wäre ja genial, wenn man das hinbekommt und wieder ein Merkmal von mailbox.org was kein anderer hat.

@Peer Heinlein - gibt es eigentlich schon eine Möglichkeit dies bei externen Domains einzusetzen?

Tja, leider kam vom Support eine enttäuschende Antwort:

Die gewünschte Konfiguration liegt leider außerhalb unseres Supportrahmens.

Sie könnten aber ohne Gewähr versuchen, einen Webserver mit dieser Policy einzurichten und dann den DNS Eintrag anzupassen.

Eigentlich ging es ja um die Nutzung des MTA-STS von mailbox.org, schade.

So jetzt endlich bin ich dazu gekommen MTA-STS für externe Domains bei mailbox.org umzusetzen und zwar wie folgt:

1. DNS TXT Eintrag: _mta-sts TXT v=STSv1; id=201812200v1 (Anmerkung: die id ist bis 32 Zeichen frei wählbar)

2. DNS TXT Eintrag: _smtp._tls TXT v=TLSRPTv1; rua=mailto:postmaster@domain.de

3. Subdomain mit mta-sts.domain.de die auf ein Verzeichnis zeigt, in welchem der Ordner .well-known mit der Datei mta-sts.txt liegt (also https://mta-sts.domain.de/.well-known/mta-sts.txt).

Wichtig dabei ist, dass die Domain mittels https gesichert ist und am besten noch einen CAA Eintrag für den Zertifikatsaussteller enthält (z.B. @ CAA 0 issuewild "letsencrypt.org"). In der Datei mta-sts.txt wird die Policy nach folgendendem Muster definiert:

1. version: STSv1
2. mode: testing
3. max_age: 103680
4. mx: *.mailbox.org
5. mx: mxext1.mailbox.org
6. mx: mxext2.mailbox.org
7. mx: mxext3.mailbox.org

Die Version ist aktuell vorgegeben, da es schlicht keine andere gibt. Mode sollte aktuell mit Testing laufen um eventuelle Fehler zu identifizieren. Und letztendlich wird mit MX der Mailserver definiert, der sowohl als Wildcard als auch fest definiert werden kann. Der erste Eintrag mit *.mailbox.org reicht eigentlich schon, da damit alle eingefangen werden. Bitte beachtet, dass eine Änderung der Policy auf eine Änderung der id im DNS Eintrag _mta-sts mit sich zieht, da diese id dem Caching dient.

(Achja, für das Verzeichnis wird ein kleines Webhosting, hier reicht auch etwas für ein paar Cent, benötigt. Es hat keine speziellen Anforderungen, außer vielleicht 1 MB Speicherplatz und ein möglichst kostenloses Zertifikat von beispielsweise lets encrypt.)

@derwebcode danke für deine mehr als ausführlichen Erklärungen, ich konnte damit die MTA-STS-Policy problemlos mit meiner eigenen Domain setzten.

Allerdings musste ich hierfür ein separates Hosting benutzten, dessen Kosten ich mir eigentlich gerne gespart hätte. Schön wäre hier in der Tat, wenn sich eine Delegation (_mta-sts.domain.de. IN CNAME _mta-sts.mailbox.org oder ähnliches) einrichten ließe.

Vielleicht ändert der Mailbox.org-Support seine Einstellung dazu in der Zukunft noch?

Das Problem ist nach meinem Überblick über das Thema (und meinem Verständnis der RFC 8461) weniger die Delegation des "_mta-sts"-Records, dies kann man auch derzeit bereits unproblematisch per CNAME erledigen.

Das Problem ist, dass wenn dem CNAME gefolgt wird, der Webserver, der unter https://mta-sts.mailbox.org/.well-known/mta-sts.txt die Policy ausliefert, dies

a) auch für andere Hostnamen tun muss (d. h. in diesem Fall muss der Webserver sich auf für deinen Hostnamen zuständig fühlen, denn CNAME auf DNS-Ebene führt ja keine Veränderung des Hostnamen im HTTPS-Request durch)

b) zu allem Übel er auch noch ein gültiges SSL-Zertifikat ausliefern muss, das deinen Hostnamen einschließt.

Ich kann durchaus verstehen, dass das etwas über das hinausgeht, was man als Provider unproblematisch für einen kleinen Teil sicherheitsbewusster Kunden leisten kann.

Schöner fände ich, wenn man eine vollwertige Delegation vornehmen könnte, die es (ähnlich wie bei SPF direkt im TXT-Record auf DNS-Ebene) erlaubt, sich eine fremde Policy vollständig zu eigen zu machen. Aber das sieht der Standard nach meinem Verständnis bislang leider nicht vor.

Ja, das Problem ist durchaus, das CNAME zwar grundsätzlich funktioniert, aber eine https Verbindung erforderlich ist. Und da scheitert es dann. Im Moment setzt Mailbox.org das ja auch testing ein, sodass es vielleicht mal in der Zukunft kommt. Das entsprechende RFC ist auch noch im Draft Status, also kann noch viel passieren.

Daher kann ich es nachvollziehen das es wünschenswert wäre das es per CNAME funktioniert (würde ich auch favorisieren), aber ich denke das hier keine Priorität gesehen wird (nachvollziehbar).

@derwebcode: Vielen Dank für deine Anleitung. Bin grade am Testen. Du hast ja im Eingangspost auf den Heise-Artikel verlinkt. Dort heißt es: "E-Mails sind vollständig mittels DKIM zu signieren – die Signatur darf sich also nicht nur auf einen Teil der Nachricht beziehen – und der Selektor muss vom Servicetyp tlsrpt sein"

Hast du deinen DKIM-Eintrag dahingehend angepasst oder funktioniert es auch so?

Das ist ein Zitat aus RFC 8461 und bezieht sich nach meinem Verständnis auf den Fall, dass du an SMTP TLS Reporting gemäß RFC 8460 teilnimmst und ausgehend Reports an fremde Mailserver verschickst. In dem Fall sollen solche Reports mit DKIM signiert sein und empfangende Mailserver darf solche Reports verwerfen, wenn sie nicht korrekt signiert sind – und dafür muss bei SMTP TLS Reporting der signierende Mailserver mit dem Selektor s=tlsrpt im DNS dazu besonders befugt sein.

Danke für die Info, habs wieder rausgenommen, da nach meinem Verständnis derartige Reporte maximal durch mailbox.org selbst versendet würden.

@Daniel: Vielen Dank!

Die Inhalte dieser Datei haben sich inzwischen geändert, d.h. die Hostnames sind anders, siehe https://mta-sts.mailbox.org/.well-known/mta-sts.txt . Das sollte (wie du oben schon beschreibst) kein Problem sein, ist aber vielleicht trotzdem interessant.

Wer das ganze Problem „perfekt“ lösen will, sollte vermutlich regelmäßig die Datei https://mta-sts.mailbox.org/.well-known/mta-sts.txt auf seine eigene Domain synchronisieren…

Eine Verständnisfrage, wenn ich, wie in der Hilfe beschrieben, nur die drei üblichen MX-Einträge im DNS meiner Domain eingetragen habe, brauche ich doch nicht alle anderen Einträge von mbo übernehmen? Oder sollte ich es 1:1 übernehmen?

Wenn es nur um die Nutzung der externen Domain als solches geht, dann brauchst Du die nicht setzen. Möchtest Du MTA-STS mit dieser nutzen dann muss alles gesetzt werden. Für eine mailbox.org Domain muss nichts gesetzt werden, das macht Mailbox.org für Dich.

Zwischenzeitlich ist die mta-sts.txt von mailbox.org leer. Weiß da jemand mehr zu?

hier scheint eine Fehlkonfiguration vorzuliegen. Ich lande bei Aufruf des hosts https://mta-sts.mailbox.org/ im XMPP-Panel des mailbox.org-Jabber-Servers.

Mir scheint, hier hat jemand meinen Kommentar gelesen … nachdem einige Tage dort nämlich nichts erschien, ist jetzt unter https://mta-sts.mailbox.org/.well-known/mta-sts.txt neuer Inhalt (längere Serverliste) zu sehen.

Da lohnt leider nicht, da hier für eine Domain das 10fache pro Monat von dem fällig ist, was ich aktuell bezahle und aktuell habe ich auch DNSSEC dabei. Und da ich einige Domains nutze wäre das schon einiges und für etwas was noch als Entwirf dasteht sehe ich keine Notwendigkeit. Zudem mit dem Hosting läuft es aktuell ja, also alles prima. Aber Danke für den Hinweis.

Nein. Protonmail beschreibt es verständlich (https://protonmail.com/blog/security-updates-2019/):

"

MTA-STS is HSTS for email. The sending mail server looks up and caches an MTA-STS policy, which tells it that the receiving mail server supports encryption. Once it has this information, it knows to refuse any attempts to downgrade its connection with the destination mail server. It relies on a long cache time to prevent transient attacks.

The downside, however, is that each mail server must maintain its own cache. That cache will also only contain policies for servers it has contacted recently. This works well for popular domains such as protonmail.com. It is not as effective between small domains with low email traffic. The policies for these domains are unlikely to be cached and can, therefore, be blocked by an attacker who can control DNS lookups. Our MTA-STS implementation works with most of the major email service providers.

DANE works via a different mechanism. With DANE, an email provider publishes DNS records which tell other mail servers that it supports TLS encryption. Even better, it tells the receiving server to expect a certain certificate when connecting to the sending server. This can foil attackers in possession of an otherwise valid TLS certificate for the mail server in question. It also works well for smaller email domains with low traffic because it does not rely on caching. However, it does rely on the security of the DNS system, which means it requires DNS Security Extensions (DNSSEC), and it has had limited adoption as a result.

"