Läs rapportens kuvert, policyomfattning och sessionssammanfattningar innan du tolkar enskilda transportfel. Använd den här guiden för att förbereda och tolka bevis innan du ändrar en mottagande tjänst. Det arbetade exemplet är uttryckligen syntetiskt och kontrollerna förblir åtskilda från alla beslut om produktionsacceptans.
Börja med kuvertet
Referenser: RFC 8460 §4.1, RFC 8460 §4.4, RFC 8460 §5.6.
A TLS-RPT dokument är ett samlad rapport, inte ett SMTP transkript. Läs först organisationsnamn, rapport-id, kontaktinformation och datumintervall. Lagra start- och slutögonblicken med deras tidszon istället för att tilldela varje observation till dagen då bilagan kom. Rapportering täcker normalt en UTC-dag och kan medvetet komma fram timmar senare. Fältet organisationsnamn är ett anspråk i ett dokument; intag måste behålla den autentiserade transportkontexten separat. Dessa distinktioner förhindrar att en försenad rapport förväxlas med ett nytt avbrott.
Håll varje policypost intakt
Referenser: RFC 8460 §4, RFC 8460 §4.4.
Policymedlemmen är en array även när endast en policy rapporteras. Varje post innehåller policy, sammanfattning och eventuella feldetaljer. Inspektera policy-typ, policy-domän, policy-string och mx-host innan du kombinerar poster. En STS-post beskriver policyn som observerats av reportern, som kan skilja sig från dagens publicerade policy eftersom cachning och ändringar ingriper. Bevara de ursprungliga strängarna som bevis. Ersätt dem inte med en aktuell DNS uppslagning och hävda sedan att den nya uppslagningen förklarar den historiska sessionen.
Beräkna ett avgränsat exempel
Referenser: RFC 8460 §4, RFC 8460 §4.2.
Använd en syntetisk post med totalt antal framgångsrika sessioner 240 och totalt antal misslyckade sessioner 60. Felandelen är 60 / (240 + 60), eller 20 procent för denna rapportör, policy och rapporteringsperiod. Anta att feldetaljer inkluderar 40 observationer som har löpt ut och 30 observationer som inte är betrodda med certifikat. Deras summa på 70 motbevisar inte sammanfattningen: kategorier kan överlappa varandra när ett försök har flera fel. Märk inte om 70 som unika misslyckade sessioner. Om båda sammanfattningarna är noll, visa förhållandet som otillgängligt istället för att dividera med noll eller antyda perfekt service.
Led kategorin till rätt utredning
Referenser: RFC 8460 §4.3.
starttls-not-supported pekar på SMTP kapacitet; certifikat-värd-mismatch pekar mot identitetsvalidering; certificate-not-trusted behöver den tillgängliga felanledningskoden och certifikatkedjan. sts-policy-fetch-error handlar om att hämta policyn, medan sts-webpki-invalid handlar om autentisering av den HTTPS-ändpunkten. Ett generiskt valideringsfel är inte en diagnos av en föråldrad TLS version. Bevara okända kategorier och märk dem oklassificerade istället för att tyst slänga dem. RFC 8460 förutser en utökning av resultatvokabulären.
Bygg en säker läsare snarare än en pålitlig renderare
Referenser: RFC 8460 §7.
Validera JSON-struktur, numeriska räkningar och datumanalys före analys. Tillämpa inmatnings- och dekompressionsgränser, bevara det råa sammandraget och undvik strängar innan du visar dem i en instrumentpanel. Länkar med rapporttillhandahållen ytterligare information är opålitlig indata, inte instruktioner för att bläddra automatiskt. Behandla saknade slutpunktsfält som otillgängliga bevis. Para ihop det aggregerade resultatet med auktoriserade slutpunktskontroller innan du tilldelar rotorsak eller kundpåverkan. Den nyinspelade aritmetiska fixturen i detta paket är ett lokalt undervisningstest; ingen produktionsavsändare eller produktionsrapport testades.
Bevarade historiska bevis och kvarvarande omfattning
Följande beskriver bevarade observationer från 7 november 2026, inte ett nätverksexperiment som återupptas för denna recension. Nyligen utförda offlinekontroller registreras separat.
Det bevarade historiska tls_lab.py-skriptet och dess daterade infångning spelar in en SMTP hälsning i loopback, EHLO, STARTTLS och certifikatvaliderat TLS handslag. En positiv kontroll förhandlad TLSv1.3. Ett certifikat utfärdat för web.example .test misslyckad verifiering för mx1.example .test med OpenSSL verifieringskod 62. evidence/report_reader/annotated_lab_report.json innehåller en komplett manuellt författad rapport som representerar exakt dessa två observationer, med anteckningar som kartlägger dess misslyckande till det registrerade handslaget och det offentliga certifikatets fingeravtryck. Det genererades inte av en rapportering MTA, och dess STS-politiska sammanhang är illustrativt snarare än upptäckt. Detta är bevarat kontrollerat slutpunktsbevis, inte aktuell kundtelemetri eller en ny testkörning. Reproduktion kräver Python med kryptografi och lokala loopback-uttag. Nya körningar genererar nya nycklar och tidsstämplar, så jämför de förväntade resultaten istället för att kräva byte-identiska certifikatfingeravtryck.
Primär källa
Fältdefinitionerna, upptäcktsbeteendet och rapporteringsgränserna kommer från RFC 8460 , SMTP TLS -rapportering, avsnitt 3 och 4. Där STS-validering diskuteras, konsultera RFC 8461. De operativa rekommendationerna särskiljs från protokollkrav.