MTA-STS (Strict Transport Security)

Es ist ja nicht so, dass es mit DANE, DMARC, STARTTLS, PGP, SMIME u.a. nicht schon genug SMTP-Abkürzungen geben würde. Aber Anfang 2016 haben ein paar große Provider (Microsoft, Google, Yahoo, Comcast, LinkedIn und 1&1) einen Vorschlag zur besseren Sicherung der Übertragung von Mails per SMTP beim IETF eingereicht.

RFC 8461 wurde verabschiedet: SMTP MTA Strict Transport Security (MTA-STS)
https://tools.ietf.org/html/rfc8461

Bei Exchange Online ist MTA-STS immer ausgehend aktiv
Verbessern des Nachrichtenflusses mit MTA-STS https://learn.microsoft.com/de-de/microsoft-365/compliance/enhancing-mail-flow-with-mta-sts?view=o365-worldwide
Eingehend müssen Sie selbst konfigurieren.

Das Problem: OpportunisticTLS

Die meisten Mailserver lauschen auf Port 25 um eingehende Mails anzunehmen. Der MX-Eintrag im DNS teilt der Welt mit, wo dieser Server zu suchen ist und der "Erstkontakt" findet immer erst einmal unverschlüsselt statt. Ein Absender, der im Prinzip Verschlüsselung per TLS unterstützt, erfragt dies durch eine "EHLO"-Anfrage und wertet die Antwort aus. Sie könne das einfach mit einem TELNET ausprobieren.

Da ich leider kein fließend TLS per Telnet spreche, komme ich hier erst mal nicht weiter aber ab dem Moment ist alles verschlüsselt. Aber die meisten Mailserver können durchaus TLS und unterstützen auch die Funktion "OpportunisticTLS". Wenn die Gegenseite TLS anbietet, dann kann der Sender diese auch nutzen und viele Nutzen dies auch. Exchange Online bietet z.B. STARTTLS an und über die Statistik können Sie einfach sehen, wie viele Hosts schon per TLS einliefern.

Allerdings ist das nur "freiwillig" und der Sender prüft in dem Fall auch nicht das Zertifikat des Empfänger. Getreu dem Motto: Besser per TLS mit einem beliebigen Zertifikat des Empfängers verschlüsseln als gleich im Klartext zu übertragen. Es schützt über nicht gegen die folgenden Probleme:

  • DNS-Spoofing und Verifikation des "Richtigen Server"
    Ein Angreifer könnte die DNS-Antworten an meinen Absende-Server verändern, so dass ich gar nicht an das richtige Ziel sondern mit einen anderen Server spreche und dort meine Mails ablegen. Der Server könnte sogar STARTTLS anbieten, muss es aber nicht. Auf jeden Fall hätte der Server meine unverschlüsselte Mail und kann sie mitlesen und an den richtigen Server weiterleiten. Wenn ich meine Domäne nicht per SPF, SenderID gesichert hätte, würde der Empfänger diese Mail auch von dem unautorisierten Relay annehmen und niemand würde etwas merken. Wer schaut schon die Header-Zeilen an und prüft den vorherigen Hop?
    Die DNS-Fälschungen kann man nur z.B. mit DNSSEC verhindern aber das ist eine andere Story.
  • Unterdrücken von STARTTLS
    Ein System, welches auf der Verbindung eingreifen kann, kann sowohl die EHLO Anfrage als auch die Klartext-Antwort auf die EHLO-Anfrage so ändern, dass der Absender gar nicht mitbekommt, dass die Gegenseite STARTTLS unterstützt. Er wird die Mail dann auch unterschlüsselt senden.
  • Opportunistisches TLS und falsches Zertifikat
    Die meisten Mailserver nutzen schon STARTTLS aber versäumen es dabei das Zertifikat zu verifizieren. Sehr viele Server haben gar kein "öffentliches" Zertifikat und selbst wenn, muss es nicht mit dem Namen des Mailservers übereinstimmen. Hier ist viel Unsicherheit zu finden aber Mailserver nutzen dennoch STARTTLS. Besser eine Mail ist auf dem Teilstück vielleicht unsicher verschlüsselt als gar nicht verschlüsselt. Aber sicher ist das nicht

Es sind noch weitere fortschrittlichere Angriffsszenarien denkbar aber belassen wir es dabei.

Natürlich könnte nun der Server des Absenders irgendwie versuchen, die TLS-Verschlüsselung zu erraten oder zu lernen aber zuverlässig wäre das nicht. Auch könnte der Empfänger z.B. TLS vorschreiben und gar keine unverschlüsselte Verbindung annehmen. Damit verhindert er aber eingehende Mails von alten Systemen, die kein TLS können oder nutzen wollen. Für eine sichere TLS-Nutzung sollte ich ja nicht nur ein Zertifikat anfordern sondern dieses auch hinsichtlich des Namens, Gültigkeitszeitraum, Aussteller und CRL prüfen. Das kann aber vielleicht nicht jeder Server und nur weil es in der Vergangenheit möglich war, muss es heute nicht auch noch funktionieren. Auch Mailserver und Provider werden migriert oder ersetzt.

Dies ist alles nicht mit HSTS (HTTP Strict Transport Security) zu vergleichen, bei dem ein Webserver innerhalb einer bereits verschlüsselten HTTPS-Verbindung über einen zusätzlichen Header den Browser anweist, zukünftig nur noch verschlüsselt mit diesem Host zu kommunizieren, was ein unbemerktes Downgrade einer Verbindung auf http verhindern soll.

MTA_STS zielt allein darauf ab die Verbindung zwischen zwei Mailservern zu härten, damit sich niemand anderes als Empfängerserver ausgeben kann. Auf dem Server selbst sind die Mails aber weiterhin unverschlüsselt. Es etabliert als auch keine Ende-zu-Ende Verschlüsselung

Funktionsweise

Die Lösung sieht nun so aus, dass der Empfänger ausreichend sicher veröffentlicht, dass er Mails per TLS annimmt und dabei auch das angebotene Zertifikat vorschreibt. Der Absender muss dann vor dem Versand einfach kurz nachschauen, ob der Empfänger ein entsprechendes Manifest bereitstellt.

Die Idee ist nicht neu denn unter dem Begriff DANE - DNS-Based Authentication of Named Entities gibt es schon einen Weg, bei dem ein Administrator diese Informationen samt Zertifikat im DNS hinterlegt. Voraussetzung ist dabei aber die Nutzung von DNSSEC, denn ansonsten könnte ein Angreifer über DNS-Manipulationen diese Informationen natürlich auch fälschen. DNSSEC ist aber bei weitem noch nicht überall verfügbar und viele Administratoren werden sich auch damit schwer tun, die Informationen im DNS einzutragen.

MTA-STS kombiniert daher DNS und HTTPS, um diese Informationen zu veröffentlichen. Das ist zwar nicht 100% sicher aber für einen Angreifer schon recht schwer zu überlisten. Wenn Sie MTA-STS einrichten, dann brauchen Sie einen Webserver, der auf den Namen "mta-sts.<maildomain>" mit einem öffentlichen Zertifikat, Wildcard ist auch ok, reagiert und unter "/.well-known/mta-sts.txt" eine Datei ähnlich der Folgenden bereit hält:

version: STSv1
mode: enforce 
mx: mail.msxfaq.de
mx: *.ionos.com 
max_age: 86400

Die Version muss immer "STSv1" lauten, während der Mode auch "testing" annehmen könnte. Ein oder mehrere MX- Zeilen geben die Zertifikatnamen vor, die legitime Zielserver vorweisen müssen. So können sich auch BackupMX ihres Providers oder einen Wechsel des Mailservers abbilden.

Eine besondere Bedeutung hat das Feld "max_age", welches in Sekunden die Dauer vorgibt, die ein Absender die einmal per HTTPS erhaltene Datei vorhalten soll. Die RFC empfiehlt hier eher Wochen, damit eben ein Angreifer nicht mal schnell dies verändern kann. Sehr lange Werte stören aber ihre eigene Flexibilität

Ein Sender kann aber nun nicht wegen jeder Mail an eine neue Domain einen HTTPS-Request starten. Daher kombiniert MTA-STS noch einen DNS-Record:

_mta-sts.msxfaq.dem text = "v=STSv1; id=20230331000000Z;"

Ein Mailserver macht also einfach eine "billige" DNS-Abfrage, wie er ansonsten auch MX-Records auflöst, um die ID zu erhalten. Nur wenn die DNS-Anfrage einen erfolgt hat und die ID sich seit dem letzten Mal geändert hat, holt der Mailserver per HTTPS die aktuelle Richtlinie. Für den Mailserver bedeutet das:

  • Neue ID -> Neue Richtlinie laden
    So kann de legitime Zonenbesitzer flexibel die Richtlinie im Rahmen des DNS-TTL anpassen. Sollte ein Angreifer die DNS-Zone gekapert haben, dann hilft das natürlich nichts
  • DNS-Anfrage unterdrückt oder Webserver blockiert
    Wenn ein Angreifer diese DNS-Abfragen per DoS o.ä. unterbindet, dann wird der Mailserver weiterhin die vorhandene Richtlinie aus dem Cache nutzen bis "max_age" abgelaufen ist. Nun verstehen Sie auch, dass max_age eher in Tagen oder Wochen denn Stunden oder Minuten sein sollte.

Die DNS-Anfrage hat laut RFC auch nicht die Funktion zwischen einem "Temporary Fail" und einem "permanent Fail" zu unterscheiden:

3.  A message delivery attempt MUST NOT be permanently failed until
       the sender has first checked for the presence of a new policy (as
       indicated by the "id" field in the "_mta-sts" TXT record).
Quelle: https://datatracker.ietf.org/doc/html/rfc8461#section-5.1

Wenn ein Server die Mail nicht zustellen kann, dann muss er zur Sicherheit noch einmal über eine DNS-Anfrage die ID prüfen, um ggfls. eine aktuellere Richtlinie zu besorgen, ehe er die Mail mit einem "PermanentFail" zurückgehen lässt.

Provider mit CNAME

Große Firmen haben ihren eigenen Mailserver und verwalten ihre Zertifikate eigenständig. Aber der überwiegende Teil der SMTP-Domänen werden über dem MX-Record entweder direkt zu einem Mailserver beim Provider oder einem gehosteten Spamdienstleister wie NoSpamProxy o.a. geleitet und dort habe Sie als Inhaber einer Domain keinen Zugriff. Natürlich könnten Sie nun einfach die Policy so umschreiben, dass die Zertifikate des Providers aufgeführt werden. Allerdings weiß ihr Provider ja nicht, ob sie MTA-STS konfiguriert haben und wenn der Provider dann den Namen der Mailserver und damit auch die Zertifikate ändert, bekommen Sie im schlimmsten Fall keine Mail mehr. Bei SPF, SenderID gibt es dazu eine "Include" oder "Redirect"-Statement. Bei MTA-STS ist ein CNAME:

The "_mta-sts" record MAY return a CNAME that points (directly or via other CNAMEs) to a TXT record, in which case senders MUST follow the CNAME pointers. This can be used for policy delegation, as described in Section 8.2.
Quelle: MTA-STS TXT Records https://datatracker.ietf.org/doc/html/rfc8461#section-3.1

First, the Policy Domain must point the "_mta-sts" record, via CNAME, to the "_mta-sts" record maintained by the provider. This allows the provider to control update signaling.
8.2. Policy Delegation https://datatracker.ietf.org/doc/html/rfc8461#section-8.2

Etwas kniffliger wird es aber bei der Policy. Hier können Sie nicht einfach einen A-Record oder CNAME auf den Provider leiten, weil dieser ja kein Zertifikat für "mta-sts.<maildomain>" hat. Sie müssen daher immer noch einen Webserver betreiben, der die passende Policy hat. Prüfen Sie doch mal, ob ihre offizielle Webseite "www.<maildomain>" ein Wildcard-Zertifikat hat. Dann könnten Sie dort die Url "/.well-known/mta-sts.txt über einen Reverse Proxy direkt vom Provider holen lassen.

Leider ist hier das Konzept von MTA-STS nicht gerade "Multi Tenant tauglich. Ich hätte mir schon gewünscht, dass ein CNAME für den mta-sts.<domaindomain> auf einen Provider vom MTA-STS-Client als Redirect aufgefasst worden wäre.

Test und Rückmeldung (TLSRPT)

Ehe sie nun voller Elan den DNS-Eintrag und die Webseite online schalten wollen, sollten Sie die Einführung planen. Es kann nämlich auch schief gehen, z.B. wenn Sie "max_age" viel zu hoch ansetzen und die Policy nicht 100% passt. Dann haben die Absender ganz lange eine falsche oder defekte Richtlinie. Zudem beschreibt MTA-STS auch ein Verfahren, mit dem Absender einen Statusreport, ähnlich zu DMARC liefern können. Sie legen dazu auch einen entsprechenden DNS-Eintrag an:

_smtp._tls TXT  "v=TLSRPTv1;rua=mailto:tlsrptdemo@msxfaq.de"

Damit werden die absendenden Mailserver angewiesen, einen TLS-Report an die hinterlegte Mailadresse zu senden. Alternativ können sie auch eine URL verwenden, zu der die Ergebnisse per HTTPS gesendet werden. Laut Microsoft sendet Exchange Online solche Mails.

Email services that send email to your domain and that support both MTA-STS and TLS-RPT send daily reports to the provided email address. Details about TLS-RPT are available in this RFC 8460. Microsoft has started sending TLS-RPT reports to domains that have requested them.
https://techcommunity.microsoft.com/t5/exchange-team-blog/introducing-mta-sts-for-exchange-online/ba-p/3106386

Wer nutzt es?

Da sie nun wissen, dass die Anfrage per DNS erfolgt und auch die Policy per HTTPS einfach heruntergeladen werden kann, können Sie einfach mal schauen, welche Hoster schon MTA-STS umgesetzt haben: (Stand Juli 2023)

Maildomain DNS _mta-sts MTA-STSPolicy _smtp._tls TLSRPT Policy

microsoft.com

 
"v=STSv1; id=20210331000000Z;"
 
version: STSv1
mode: enforce
mx: *.mail.protection.outlook.com
max_age: 604800
 
"v=TLSRPTv1;rua=https://tlsrpt.azurewebsites.net/report"

outlook.com

 
"v=STSv1; id=20190225000000Z;"
 
version: STSv1
mode: enforce
mx: *.olc.protection.outlook.com
max_age: 604800
 
"v=TLSRPTv1;rua=https://tlsrpt.azurewebsites.net/report"

<tenantname>.onmmicrosoft.com

Kein DNS-Eintrag

Keine Policy

 

gmail.com

 
"v=STSv1; id=20190429T010101;"
 
version: STSv1
mode: enforce
mx: gmail-smtp-in.l.google.com
mx: *.gmail-smtp-in.l.google.com
max_age: 86400
 
"v=TLSRPTv1;rua=mailto:sts-reports@google.com"

gmx.com

 
"v=STSv1;id=20190416142000Z;"
 
version: STSv1
mode: testing
mx: mx00.gmx.net
mx: mx01.gmx.net
max_age: 604800
 
"v=TLSRPTv1;rua=mailto:smtp-tlsrpt@1und1.de"

web.de

 
"v=STSv1;id=20180928194800Z;"
 
version: STSv1
mode: testing
mx: mx-ha02.web.de
mx: mx-ha03.web.de
max_age: 604800
 
"v=TLSRPTv1;rua=mailto:smtp-tlsrpt@1und1.de"

yahoo.com

 
"v=STSv1; id=20161109010200Z;"
 
version: STSv1
mode: testing
mx: *.am0.yahoodns.net
mx: *.mail.gm0.yahoodns.net
mx: *.mail.am0.yahoodns.net
max_age: 86400
 
"v=TLSRPTv1;rua=mailto:mta_sts.report@yahoo.com"

bsi.bund.de

na

na

na

Einrichten

Wenn Sie nun darüber nachdenken, MTA-STS einzurichten, dann sollten Sie folgende Reihenfolge vornehmen.

  • TLS prüfen
    Zuerst sollten sie alle Mailserver, die aus dem Internet per MX-Record auflösbar sind, auf eine korrekte TLS-Konfiguration prüfen und sicherstellen, dass dies auch zukünftig immer der Fall ist. MTA-STS erfordert TLS 1.2 oder TLS 1.3. und Server Name Indication (SNI) Öffentliche Zertifikate laufen in der Regel nach 1 Jahr aus und sind zu verlängern. MTA-STS prüfe den Namen des Zertifikats und natürlich muss es für den Absender "vertrauenswürdig" sein, d.h. Aussteller, Gültigkeitsdauer, Name, CLR müssen passen.
    Es gibt diverse Dienste wie https://www.checktls.com/TestReceiver, um solche ersten Tests zu machen. Sie sollten aber unabhängig davon die SMTP-Funktion in ihre eigenes Monitoring aufnehmen
  • Policy vorbereiten
    Dazu müssen sie ALLE Mailserver, die über den MX-Record erreicht werden, und deren Zertifikate ermitteln und in der Datei hinterlegen. Für den Anfang würde ich die Richtline auf "testing" setzen und auch max_age eher kurz, z.B. 30 Minuten setzen.
  • Policy per Webserver veröffentlichen
    Veröffentlichen Sie diese Datei dann über einen öffentlichen erreichbaren Webserver unter https://mta-sts.<maildomain>/.well-known/mta-sta.txt und prüfen Sie die Erreichbarkeit aus dem Internet einfach über einen Browser. Der WebServer liefert dann ein 200OK "Text/Plain"-Dokument aus, welches z.B. folgende Information enthält. Umleitungen (3xx) o.ä. sind  nicht erlaubt. Bei Google sieht das wie folgt aus:

Die Abfrage ist auch per PowerShell schnell ausgeführt:

PS C:\> (Invoke-WebRequest  "https://mta-sts.gmail.com/.well-known/mta-sts.txt").content
version: STSv1
mode: report
policy_id: 1503837332
mx: gmail-smtp-in.l.google.com
mx: .gmail-smtp-in.l.google.com
max_age: 86400

Die Einträge hinter dem "mx" sind die Namen der Mailserver, die in den Zertifikaten auftauchen. Damit der Absender aber überhaupt ein Zertifikat sieht, muss die Gegenseite natürlich STARTTLS unterstützen und der Absender auch STARTTLS anfordern und erzwingen. Der Mailserver muss dazu auch mindestens TLS 1.2 bereitstellen.

  • DNS-Eintrag
    Dann addieren Sie in ihrem DNS-Server einen entsprechenden DNS-Eintrag "_mta-sts.<maildomain> TXT "v=STSv1; id=20160707T010757Z;". Die ID muss einfach eine Zeichenkette sein, die bei jeder Änderung der Richtlinie geändert werden muss. Ein Hochzählen ist zwar nicht erforderlich, aber der klassische Zeitstempel wie bei einer DNS-Serial-Number hat sich hier eingebürgert.

Hinweis:
Der DNS-Eintrag lautet nicht mehr auf "_smtp_sts" sondern "_MTA-STS".

Auch diese Abfrage geht schnell per PowerShell am Beispiel von google.com

PS C:\> Resolve-DnsName -Type txt _mta-sts.google.com

Name                                     Type   TTL   Section    Strings
----                                     ----   ---   -------    -------
_mta-sts.google.com                      TXT    300   Answer     {v=STSv1; id=20210803T010101;}
  • Warten und überwachen
    Auf dem Mailserver sehen Sie erst einmal nicht viel. Alle Server, die bisher schon opportunisticStartTLS genutzt haben, nutzen auch weiter STARTTLS. Allerdings sollten Sie auf dem Webserver nun sehen, wie Mailserver die Richtlinie herunterladen. Zudem sollten Sie das Postfach überwachen, an welche die TLSRPT-Berichte gesendet werden
  • Policy scharf stellen
    Wenn sie einige Tage keine Probleme gesehen haben, dann können sie in der Policy den Wert  "mode: report" auf "mode: enforce" stellen und im DNS die ID ändern, damit alls MTA-STS-tauglichen Absender auf jeden Fall eine STARTTLS-Verbindung starten.

Denken Sie aber daran, dass sie mit MTA-STS nur den kompatiblen Gegenstellen vorgeben, sie mögen STARTTLS mit Zertifikatsprüfung machen. Andere Server können weiterhin opportunisticStartTLS nutzen oder ganz ohne TLS senden. Erzwingen können Sie dies eventuell auf ihrem Server für bestimmte wichtige Gegenstellen, z.B. über einen Exchange Online Partner Connector

MTA-STS und Exchange Online

Wie sie oben schon gesehen haben, hat Microsoft sehr wohl für ihre Domain MTA-STS mit "enforce" konfiguriert aber die für Office 365 Tenantdomains "<tenantname>.onmicrosoft.com" und "<tenantname>.mail.onmicrosoft.com" gibt es keine DNS-Einträge. Sie können diese aber problemlos setzen:

Allerdings rate ich ihnen generell von der Nutzung der "onmicrosoft.com"-Domains ab und empfehle immer den Einsatz eigener Domains. Exchange Online unterstützt ansonsten MTA-STS

Alle Nachrichten, die von Exchange Online ausgehend an MTA-STS-geschützte Empfänger gesendet werden, werden mit diesen zusätzlichen Sicherheitsüberprüfungen, die vom MTA-STS-Standard festgelegt sind, überprüft. Es gibt nichts, was Administratoren für die Anwendung tun müssen. Bei unserer ausgehenden Implementierung werden die Wünsche der Empfängerdomänenbesitzer durch ihre MTA-STS-Richtlinie geachtet. MTA-STS ist Teil der Sicherheitsinfrastruktur von Exchange Online und daher immer aktiviert (wie andere wichtige SMTP-Features).
https://learn.microsoft.com/de-de/microsoft-365/compliance/enhancing-mail-flow-with-mta-sts?view=o365-worldwide#outbound-protection

In die Gegenrichtung kann Exchange Online kaum was tun, denn TLS wird generell angeboten. Sie können aber natürlich für ihre Domains einen entsprechenden Webserver und DNS-Einträge beisteuern damit Mails an ihren Tenant auf jeden Fall per TLS am richtigen Server landen, sofern die Absender MTA-STS unterstützen.

Domänenbesitzer können Maßnahmen ergreifen, um E-Mails zu schützen, die mit MTA-STS an ihre Domänen gesendet werden, wenn ihr MX-Eintrag auf Exchange Online verweist
https://learn.microsoft.com/de-de/microsoft-365/compliance/enhancing-mail-flow-with-mta-sts?view=o365-worldwide#outbound-protection

Wenn Sie aber sicher sein wollen, dass von bestimmten oder sogar einliefernden Servern zumindest STARTTLS erzwungen wird, dann können Sie einen entsprechenden Partner-Connector für diese Domains oder "*" anlegen. Damit erzwingen Sie TLS aber der Angreifer kann sich immer noch davor schalten, wenn der Absender kein MTA-STS prüft.

Leider bietet Exchange Online aber keinen Webservice für TLSRPT-Meldungen an. Da dürfen Sie dann schon ein eigenes Postfach zur Auswertung oder einen externen Dienstleiter nutzen.

Unschärfen

Leider ist die RFC nicht in allen Belangen deutlich und so kann jeder absendende Mailserver eine leicht unterschiedliche Umsetzung wählen. Das fällt am ehesten auf, wenn Sie mit einer Testdomain eine falsche Policy anlegen, z.B. in der das Zertifikat nicht stimmt und eine sehr lang max_age hat. Das Ergebnis ist dann ja, dass sie keine Mails per von MTA-STS-Absendern bekommen, da diese die Policy auswerten, das falsche Zertifikat erkennen und die Zustellung stoppen. Mit aktiviertem TLSRPT - SMTP TLS Reporting können Sie dann die Fehler sogar als Empfänger nachvollziehen.

  • GMail:
    Bei GMAIL ist das Feld "max_age" anscheinend nicht das alleiniges Kriterium, wann eine Policy aktualisiert werden müsste. GMail holt auch zwischendurch mal die ID des DNS-Eintrags, um eine bei bedarf eine neue Policy zu ziehen. DAs macht ja auch sinn dass man nicht bis zum Ablauf von "max_age" wartet
  • Microsoft Exchange Online
    Microsoft scheint diese Update-Prüfungen deutlich seltener zu machen. Eine falsche Policy scheint längere Zeit zu wirken und auch nicht pauschal für die Domain sondern pro Empfänger genutzt zu werden. Anders kann ich mir kaum vorstellen, warum Mails an Empfänger1 weiter unterbunden sind, während nach Korrektur der Policy dann Mails an einen neuen Empfänger wieder ankommen.

Wer etwas mehr über die Arbeitsweise von SMTP-Servern diesbezüglich herausfinden will, kann ja das Logging auf DNS und dem Webserver aktivieren und damit sehen, welche SourceIP-Adresse wann und wie häufig auf die DNS-Einträge und Textdatei zugreifen.

Das wäre dann eine Thema für eine eigene Seite

Bei der Implementierung von MTA-STS sollten Sie aber auch immer an die bösen Teilnehmer denken. Stellen Sie sich vor, ich lege eine mta-sts.txt-Datei mit Datenmüll an oder einfach nur XXL-Bytes Größe. Bei der nächsten Mail an meine Domain prüft ihr SMTP-Server den DNS-Eintrag und zieht die Policy per HTTPS. Kann ich da eine "Out of memory"-Condition oder vielleicht sogar einen Speicherüberlauf provozieren? Rechnen Sie also mit dem schlimmsten.

Rückbau

Mit dem Wissen um die Funktion von MTA-STS können Sie auch einfach den Rückbau durchführen:

  • Update der Policy
    Zuerst sollen Sie die Richtlinie auf "mode=none" anpassen. Auch den Wert von "max_age" sollten Sie auf einen kleinen Wert legen, damit später die Gegenstellen den Eintrag zügig aus dem Cache entfernen.
  • DNS-Eintrag aktualisieren
    Dann ändern Sie wieder das Feld "id" im DNS-TXT-Eintrag, damit alle Clients die neue Richtlinie ziehen. Ein Client sollte ja mit dem TTL des DNS-Eintrags den wieder beziehen und damit erkennen, dass die Policy neu zu laden ist
  • Warten
    Dann müssen Sie abwarten, bis alle Gegenstellen irgendwann mal die neue Richtlinie gezogen haben. Eine DNS-Anfrage machen diese Server meist nur, wenn auch eine Mail an ihre Domain zu senden ist. Daher müssten sie mindestens solange warten, bis "max_age" der bisher gültigen Richtlinien abgelaufen sind

Danach können Sie dann den DNS-Eintrag löschen und die Bereitstellung der Policy über HTTPS deaktivieren.

Zwischenstand

Der Nutzen von MTA-STS hängt von der Einführung auf Mailservern ab. Cloud-Anbieter können das relativ schnell umsetzen aber bis die Millionen privater Mailserver eine MTA-STS-Prüfung machen und die noch mehr Domain auc MTA-STS-Einträge per DNS und eine Policy per HTTP bereitstellen, wird dauern. Aber auch bei der Entwicklung anderer Techniken wie TLS 1.2 Enforcement, Spam und UCE - Filter: SPF, SenderID, Spam und UCE - Filter: DKIM, DMARC und anderer RFCs dauert es manchmal Jahre, bis eine Wirkung erzielt wird.

Wenn ihr empfangender Server aber sauber TLS spricht, dann spricht nichts dagegen, dies über MTA-STS auch der Welt bekannt zu geben.

Weitere Links