TLS-RPT-Prüfer/Generator
Validiert Reporting-Record, RUA-Ziele und Provider-Kontext, die Report-Zustellung erst ermöglichen.
E-Mail-SicherheitTLS-RPT-Reports in der Praxis lesen
TLS-RPT liefert keine Folge einzelner Bounce-Meldungen. Es ist aggregierte Evidenz darüber, welche sendenden Systeme deine SMTP-Transport-Policy erfüllen konnten — brauchbar wird sie erst mit Volumen-, Policy-, Routen- und Zeitkontext.
Lies den Umschlag vor den Fehlern
Ein Report ist JSON und kommt häufig als komprimierter Mail-Anhang oder per HTTPS. Auf der obersten Ebene stehen meldende Organisation, Kontakt, Report-ID und ein UTC-Zeitfenster. Behandle Organisation, ID und Intervall gemeinsam als Deduplizierungsschlüssel: Große Sender wiederholen Zustellversuche, und derselbe Report zweimal erzeugt einen erfundenen Vorfall. Prüfe vor dem Entpacken Größenlimits und Dateityp, weil ein öffentliches RUA-Ziel grundsätzlich nicht nur wohlgeformte Berichte erhält. Kaputte Dokumente gehören in eine Quarantäne-Queue, nicht still verworfen und ebenso wenig halb geparst in eine Zeitreihe.
Der eigentliche Inhalt steckt im Array policies. Jeder Eintrag nennt Policy-Domain, Typ wie sts, tlsa oder no-policy-found, relevante Policy-Strings beziehungsweise MX-Hosts, eine Zusammenfassung erfolgreicher und fehlgeschlagener Sessions und optionale failure-details. Ein Dokument kann damit mehrere ausgewertete Policies enthalten. Prüfe, ob das Zeitfenster vollständig und plausibel ist, bevor du den Datensatz in Tages- oder Wochenreihen einordnest. Summiere nicht zuerst den ganzen Report und frage später: Policy-Eintrag, Domain, MX-Kontext und meldender Sender müssen zusammenbleiben.
Die Summary liefert den Nenner
total-successful-session-count und total-failure-session-count beschreiben die vom Reporter im Intervall beobachtete Population. Berechne immer Fehlerzahl und Fehlerquote. Zehn Ausfälle bei zwölf Sessions verlangen eine andere Reaktion als zehn bei zwölf Millionen. Auch ein Report ohne Fehler ist wertvoll: Er belegt, dass Ingestion funktioniert und dieser Sender die Policy erfolgreich genutzt hat. Wer nur Fehlerdokumente speichert, zerstört den Grundpegel für vernünftige Alarme.
Sessions sind keine Nachrichten, und Reports bilden nicht den gesamten Mailverkehr ab. Ein Sender kann viele Nachrichten über eine Verbindung zustellen, TLS-RPT gar nicht implementieren oder anders aggregieren als ein anderer Betreiber. Leite aus den Summen keine exakte Zahl verlorener Mails ab. Kennzeichne außerdem fehlende Reports nicht automatisch als fehlerfreie Tage; oft ist nur die Reporting-Pipeline selbst unterbrochen. Vergleiche dieselbe Reporter-Population über die Zeit und korreliere Sprünge mit MX-Logs, Zertifikats-Rollouts, DNS-Änderungen und Queue-Ereignissen. Der Report beschreibt eine Beobachtung des Senders, nicht die Zustellung einer bestimmten Nachricht.
Failure-Details machen aus Zahlen Hypothesen
Ein Detail enthält üblicherweise result-type, Anzahl fehlgeschlagener Sessions und einige aus Sender-IP, empfangenem MX-Hostname, Ziel-IP, empfangenem HELO, Reason-Code oder Zusatz-URI. Gruppiere zuerst nach Policy-Domain, Ergebnistyp und Empfangsendpunkt. So bleibt die betriebliche Frage erhalten: Scheiterten alle Sender an einem MX, ein Sender an allen MX-Hosts oder nur eine Adressfamilie an einem abweichenden Server? Freie Reason-Strings sind Begleitevidenz, keine stabile Taxonomie; normalisiere vorsichtig und bewahre das Original.
Misstraue falscher Genauigkeit. Reporter füllen optionale Felder unterschiedlich; eine fehlende Ziel-IP beweist nicht, dass DNS nie aufgelöst wurde. Failure-Details sind Aggregate, keine Packet-Captures. Ein Ergebnistyp bestimmt den nächsten Test, schließt aber keinen Incident. Halte Sender-IP-Daten als Betriebsmetadaten mit passender Aufbewahrungsfrist und Zugriffskontrolle, nicht als frei verfügbares Analysefutter. Prüfe den aktuellen Weg mit der SMTP-TLS-Handshake / Mail-Domain-Empfangsbereitschaft und ziehe für das Report-Intervall historische Serverdaten heran. Der Live-Check sieht jetzt, TLS-RPT sah damals. Abweichung bedeutet oft: transient oder bereits zurückgerollt.
Was typische Klassen über deine Infrastruktur sagen
starttls-not-supported bedeutet meist, dass der gewählte Exchanger STARTTLS nicht angeboten hat: altes Backup, Klartext-Listener, Middlebox oder falsches Service-Binding. Fehler bei Zertifikatshostname, Vertrauen, Ablauf und Validierung führen zum TLS-Terminator und seinem Deployment. Beginnen sie direkt nach einem Renewal, prüfe zuerst falsches Zertifikat, fehlendes Intermediate, einen alten Clusterknoten oder Namens-Mismatch. Die Konzentration auf eine einzige Empfangs-IP ist besonders starke Evidenz für Fleet-Drift.
Fehler beim Laden oder Validieren von MTA-STS betreffen die feste HTTPS-Policy-Fläche, ihr Zertifikat, ihren Inhalt, DNS oder Verfügbarkeit. Ein MX-Mismatch heißt, dass Policy und Routing auseinanderliegen — typisch für eine unkoordinierte Migration. Prüfe bei CDN- oder Hostingwechseln, ob einzelne Regionen noch eine alte Policy oder eine abweichende Zertifikatskette ausliefern. TLSA- und DNSSEC-Fehler gehören zur DANE-Bindung: falscher Ownername, bogus DNSSEC, alter Association-Wert oder Zertifikats-/Keywechsel vor dem DNS-Rollover. Mit dem MTA-STS-Prüfer/Generator vergleichst du STS-Flächen; DANE wird separat validiert, statt jeden „TLS“-Fehler in denselben Topf zu werfen.
Trends schlagen Anekdoten — mit zwei Ausnahmen
Eine fehlgeschlagene Session eines Reporters kann Internetwetter sein: Timeout, Resolverproblem beim Sender oder eine kurze Deployment-Kante. Halte einen rollierenden Grundpegel pro Reporter, Policy, Ergebnistyp und Empfangsendpunkt. Eskaliere, wenn eine Klasse in aufeinanderfolgenden Tagesreports bleibt, bei mehreren unabhängigen großen Sendern erscheint oder sich auf eigene Infrastruktur konzentriert. Vergleiche Wochenquoten und absolute Zahlen; sonst springen kleine Domains wild, während große Tausende Fehler hinter einem winzigen Prozentsatz verstecken.
Zwei Befunde verdienen auch einzeln sofortige Aufmerksamkeit: Eine erzwungene Policy lässt jede beobachtete Session scheitern, oder direkt nach deinem Change beginnt ein deterministischer Validierungsfehler. Auf einen Trend zu warten sammelt nur weitere Fehlzustellungen. Lege für besonders wichtige Partner eigene Mindestvolumen fest; deren kleine Zahlen können geschäftlich relevanter sein als der Durchschnitt. Umgekehrt ist ein neuer Reporter allein kein Alarm; auch no-policy-found ist dort normal, wo absichtlich keine strikte Policy existiert. Schwellen brauchen ein Inventar des erwarteten Zustands. Sonst kann Monitoring Nicht-Einführung und Regression nicht auseinanderhalten.
Schwellen nach Blast Radius bauen
Ein Page-Alarm passt bei vollständiger oder nahezu vollständiger Fehlerquote eines relevanten Senders, Zertifikats- oder STARTTLS-Fehlern auf einem bevorzugten MX, derselben eigenen Fehlerklasse bei mehreren Reportern oder einem Sprung direkt nach Deployment. Ein Ticket reicht bei niedrigen, aber dauerhaften Quoten, auf Backups begrenzten Fehlern und wiederkehrenden Policy-Fetch-Problemen ohne bekannte Zustellwirkung. Unterdrücke isoliertes Kleinrauschen nur mit Ablaufdatum; in ewigen Suppressions verstecken sich tote Backup-MX-Hosts.
Speichere Rohreport, normalisierte Zeilen, Ingestion-Fehler und den im Intervall gültigen Policy-Snapshot. Versioniere Parser und Normalisierungsregeln, damit ein Softwareupdate nicht wie eine plötzliche Änderung der Infrastruktur aussieht. Teste das Reporting-Ziel selbst und validiere den publizierten _smtp._tls-Record mit dem TLS-RPT-Prüfer/Generator; er prüft Syntax und Ziele, nicht Report-Inhalte. Verknüpfe Changes mit der Zeitachse. TLS-RPT wird dann eindeutig, wenn der Graph „Zertifikats-Rollout 09:10, Hostname-Mismatch von drei Reportern ab 09:15“ sagt — nicht wenn fünf unverbundene JSON-Dateien im Postfach liegen.