TLS-RPT (SMTP TLS Reporting) Record-Prüfer
Ruft den _smtp._tls TXT-Eintrag einer Domain ab, um zu prüfen, ob das Berichtsziel (rua) für fehlgeschlagene TLS-Verbindungen gemäß RFC 8460 korrekt konfiguriert ist. Nützlich in Kombination mit MTA-STS/DANE.
Tipps
- TLS-RPT wird von der empfangenden Domain deklariert, aber von den sendenden Mailservern ausgewertet, die dadurch erfahren, wohin sie Statistiken schicken sollen, wenn eine TLS-Verbindung zu Ihrer Domain fehlschlägt.
- Im rua-Feld können eine mailto:-Adresse, ein https:-Endpunkt oder beides, durch Kommas getrennt, angegeben werden, sodass Berichte gleichzeitig an ein Postfach und einen automatisierten Sammler gesendet werden können.
- Berichte kommen im JSON-Format (application/tlsrpt+json, häufig gzip-komprimiert) an, daher lohnt es sich, einen eigenen Parser oder ein eigenes Postfach einzurichten, statt sie manuell lesen zu wollen.
- Direkt nach der Einführung von MTA-STS oder DANE sollten Sie die TLS-RPT-Berichte eine Zeit lang im Auge behalten, um übersehene Fehlkonfigurationen zu erkennen.
- Große Mailanbieter wie Google, Microsoft und Yahoo senden alle TLS-RPT-Berichte, sodass Domains mit viel Mailverkehr zu diesen Anbietern am meisten von der Einführung profitieren.
Häufige Fragen
Übrigens – Die Lücke der „stillen Störung“, die TLS-RPT geschlossen hat
TLS-RPT (TLS Reporting, RFC 8460) wurde 2018 veröffentlicht, fast zeitgleich mit MTA-STS (RFC 8461). Beide wurden in derselben Arbeitsgruppe entwickelt und haben viele Gemeinsamkeiten – beide bauen auf einem DNS-TXT-Eintrag auf, und beide wurden gemeinsam von Google, Microsoft, Yahoo und anderen vorangetrieben –, spielen aber sehr unterschiedliche Rollen. MTA-STS ist die Durchsetzungsebene, die TLS erzwingt; TLS-RPT ist die Beobachtungsebene, die zeigt, was danach tatsächlich passiert ist.
Bevor es TLS-RPT gab, wurde ein fehlgeschlagener TLS-Handshake bei der SMTP-Zustellung in den meisten Fällen nur auf dem sendenden Server protokolliert und dem Administrator der empfangenden Domain überhaupt nicht mitgeteilt. Ein abgelaufenes Zertifikat oder eine falsch konfigurierte MTA-STS-Richtlinie konnte die Mailzustellung lautlos stören, und niemand bemerkte es, bis tatsächlich keine Mails mehr ankamen – ein echter blinder Fleck im Betrieb.
Mit TLS-RPT wird täglich ein zusammengefasster Bericht an das in rua angegebene Ziel gesendet. Der Bericht ist strukturiertes JSON (application/tlsrpt+json, häufig gzip-komprimiert) mit Erfolgs- und Fehlerzahlen sowie, im Fehlerfall, der zugrunde liegenden Ursache (Zertifikatsabweichung, fehlgeschlagene STARTTLS-Aushandlung usw.) – gedacht zur Verarbeitung durch Monitoring-Tools, nicht zum Lesen durch Menschen.
In der Praxis wird TLS-RPT meist zusammen mit MTA-STS oder DANE eingerichtet. Wird nur die Durchsetzung eingeführt, gibt es keine Möglichkeit zu erkennen, ob eine Fehlkonfiguration lautlos legitime Mails blockiert; die Beobachtung der TLS-RPT-Berichte erlaubt es, die Durchsetzung sicher auszurollen.