Verschlüsselt, solange niemand stört
Wenn ein Mailanbieter eine Nachricht an einen anderen übergibt, sprechen zwei Server miteinander. Der empfangende meldet zu Beginn der Verbindung, ob er Verschlüsselung beherrscht. Meldet er es, schaltet der sendende um. Meldet er es nicht, stellt der sendende in der üblichen Einstellung trotzdem zu, dann im Klartext. Von sich aus geht bei E-Mail die Zustellung vor.
Diese Nachgiebigkeit ist die Lücke. Wer zwischen beiden Servern sitzt, kann die Meldung aus der Antwort entfernen, und beide Seiten merken nichts. Er kann auch ein eigenes Zertifikat vorzeigen, weil viele Server es bei dieser freiwilligen Verschlüsselung nicht prüfen. Oder er fälscht die DNS-Antwort, die den zuständigen Mailserver nennt, und bekommt die Mail gleich selbst.
MTA-STS und DANE schließen diese Lücke auf zwei Wegen. Beide beruhen auf derselben Idee: Die Domain des Empfängers sagt vorab und öffentlich zu, dass ihre Server verschlüsseln und sich ausweisen. Ein Sender, der diese Zusage kennt, lässt sich nicht mehr zum Klartext überreden.
Wer empfängt, sagt zu. Wer sendet, hält sich daran.
| Frage | MTA-STS (RFC 8461) | DANE für SMTP (RFC 7672) |
|---|---|---|
| Wo steht die Zusage? | TXT-Eintrag unter _mta-sts und eine Richtliniendatei, abrufbar per HTTPS | TLSA-Eintrag am Namen des Mailservers |
| Was sagt sie? | Namen der Mailserver, Modus, Gültigkeitsdauer | welchen Schlüssel der Server vorweisen muss |
| Wer bürgt dafür? | Zertifizierungsstellen | die DNSSEC-Signaturen der Zone |
| Braucht es DNSSEC? | nein | ja, auch für die Domain des Empfängers |
| Schutz beim ersten Kontakt? | nein, erst nach einem ungestörten Abruf der Richtlinie | ja |
Bei MTA-STS holt der Sender die Richtlinie und merkt sie sich für die angegebene Dauer. Im Modus enforce stellt er nur noch an die genannten Server zu, und nur, wenn deren Zertifikat gültig ist. Im Modus testing stellt er trotzdem zu und meldet den Fehler nur. Die Schwäche liegt am Anfang: Hat ein Sender die Richtlinie nie gesehen, kann ein Angreifer den Hinweis darauf unterdrücken.
Bei DANE ist die Zusage selbst signiert. Der Sender kann deshalb nicht nur prüfen, dass ein Eintrag echt ist, sondern auch, dass es wirklich keinen gibt. Ein Angreifer kann den Eintrag also nicht unbemerkt verschwinden lassen. Dafür muss die ganze Kette im DNS signiert sein.
TLS-RPT: erfahren, wenn es scheitert
Strenge hat eine unangenehme Eigenschaft: Was nicht zugestellt wird, taucht beim Empfänger nirgends auf. TLS-RPT (RFC 8460) macht solche Fehler sichtbar. Die Domain nennt im DNS eine Adresse, und teilnehmende Sender schicken dorthin täglich einen Bericht: wie viele Verbindungen gelangen, wie viele scheiterten und woran. Die Berichte decken beide Verfahren ab. Daraus folgt die Reihenfolge: erst Berichte sammeln, dann streng schalten.
Was der Domain Autopilot einrichtet
Bei E-Mail unter Ihrer eigenen Domain verteilt sich die Arbeit auf drei Stellen: den Domain Autopilot, die Mailserver von privymail.eu und Ihren DNS-Anbieter.
- MTA-STS. Der Autopilot richtet den Eintrag und die Richtlinie für Ihre Domain ein und überwacht beide.
- TLS-RPT. Er erzeugt den Eintrag, nimmt die Berichte an und wertet sie aus.
- DANE. Der TLSA-Eintrag steht am Namen des Mailservers, also bei privymail.eu. Der Autopilot überwacht, ob dieser Schutz auch für Ihre Domain greift.
- DNSSEC. Der Autopilot überwacht, ob Ihre Zone gültig signiert ist. Das Signieren selbst schaltet Ihr DNS-Anbieter ein; den DS-Eintrag hinterlegt der Registrar.
Die DNS-Einträge selbst tragen Sie bei Ihrem DNS-Anbieter ein. Der Autopilot zeigt sie an, prüft sie von außen und meldet Abweichungen; ändern kann er dort nichts. Den Stand je Domain zeigt ein Health-Dashboard.
Beim Versand ist privymail.eu der Sender. Für jede Empfängerdomain prüft der Server zuerst DANE, dann MTA-STS. Veröffentlicht die Domain keines von beiden, bleibt es bei der freiwilligen Verschlüsselung. Bevorzugt wird TLS 1.3, das Minimum ist TLS 1.2.
Der Preis: lieber gar nicht als im Klartext
Wer streng schaltet, tauscht einen stillen Fehler gegen einen lauten. Passt etwas nicht, kommt die Mail nicht unverschlüsselt an, sondern zunächst gar nicht: Der Sender versucht es weiter und gibt sie am Ende als unzustellbar zurück. Das ist gewollt, und es verlangt Sorgfalt.
Bei MTA-STS zählt die Reihenfolge. Ziehen die Mailserver um, ändert man zuerst die Richtliniendatei, dann die Kennung im TXT-Eintrag und erst danach die MX-Einträge. Bei DANE zählt der Schlüssel. Bekommt der Server einen neuen, muss der passende Eintrag vorher zusätzlich im DNS stehen. Und DNSSEC verzeiht wenig: Bleibt nach einem Wechsel des DNS-Anbieters ein alter DS-Eintrag stehen, verwerfen prüfende Resolver jede Antwort der Domain, nicht nur die für Mail.
Was beide nicht lösen
- Sie wirken nur, wenn die Gegenseite mitmacht. Ein Sender, der keines der Verfahren auswertet, stellt zu wie ohne sie. Und ausgehende Mail ist nur geschützt, wenn die Domain des Empfängers eine Zusage veröffentlicht.
- DANE braucht DNSSEC, und längst nicht jede Domain ist signiert. MTA-STS kommt ohne aus, stützt sich dafür auf Zertifizierungsstellen und schützt den ersten Kontakt nicht.
- Sie sichern den Weg, nicht den Inhalt. Jeder beteiligte Server kann die Mail lesen, wenn ihr Inhalt nicht zusätzlich verschlüsselt ist. Das ist keine Ende-zu-Ende-Verschlüsselung.
- Sie sagen nichts über den Absender. Ob eine Mail wirklich von der genannten Domain kommt, klären SPF, DKIM und DMARC.
- Sie betreffen nur den Weg zwischen Servern. Die Verbindung zwischen Ihrem eigenen Gerät und Ihrem Anbieter ist ein anderes Thema.
Weiterlesen
SPF, DKIM und DMARC erklärt zeigt alle Einträge mit Beispielen und typischen Fehlern. Eigene Domain beschreibt den Domain Autopilot und seine Grenzen bei einem fremden DNS-Anbieter, Sicherheit die Verschlüsselung beim Transport und bei der Speicherung. Die Bausteine des Dienstes und ihre Reihenfolge nennt die Roadmap.