Przed dokonaniem interpretacji poszczególnych awarii transportowych zapoznaj się z kopertą raportu, zakresem polityki i podsumowaniami sesji. Skorzystaj z tego przewodnika, aby przygotować i zinterpretować dowody przed zmianą usługi przyjmującej. Przepracowany przykład jest wyraźnie syntetyczny, a kontrole pozostają niezależne od jakiejkolwiek decyzji o przyjęciu do produkcji.
Zacznij od koperty
Referencje: RFC 8460 §4.1, RFC 8460 §4.4, RFC 8460 §5.6.
A TLS-RPT dokument jest raport zbiorczy, a nie transkrypcja SMTP . Najpierw przeczytaj nazwę organizacji, identyfikator raportu, dane kontaktowe i zakres dat. Zamiast przypisywać każdą obserwację do dnia otrzymania załącznika, przechowuj momenty początkowe i końcowe wraz z ich strefą czasową. Zgłaszanie zwykle obejmuje dzień UTC i może celowo dotrzeć kilka godzin później. Pole nazwa-organizacji jest oświadczeniem znajdującym się w dokumencie; przetwarzanie musi oddzielnie zachować uwierzytelniony kontekst transportowy. Dzięki tym rozróżnieniom opóźniony raport nie zostanie pomylony z nową awarią.
Zachowaj każdy wpis zasad w nienaruszonym stanie
Referencje: RFC 8460 §4, RFC 8460 §4.4.
Element zasad jest tablicą nawet wtedy, gdy zgłoszona jest tylko jedna zasada. Każdy wpis zawiera zasady, podsumowanie i szczegóły potencjalnych błędów. Przed połączeniem wpisów sprawdź typ polityki, domenę zasad, ciąg zasad i mx-host. Wpis STS opisuje politykę zaobserwowaną przez osobę zgłaszającą, która może różnić się od dzisiaj opublikowanej polityki ze względu na buforowanie i zmiany. Zachowaj oryginalne struny jako dowód. Nie zastępuj ich bieżącym wyszukiwaniem DNS , a następnie nie twierdz, że nowe wyszukiwanie wyjaśnia sesję historyczną.
Oblicz jeden ograniczony przykład
Referencje: RFC 8460 §4, RFC 8460 §4.2.
Użyj wpisu syntetycznego o łącznej liczbie sesji zakończonych sukcesem 240 i liczbie sesji zakończonych całkowitymi niepowodzeniami wynoszącej 60. Udział niepowodzeń wynosi 60 / (240 + 60), czyli 20 procent dla tego podmiotu zgłaszającego, zasady i okresu raportowania. Załóżmy, że szczegóły niepowodzenia obejmują 40 obserwacji, których certyfikat wygasł, i 30 obserwacji, które nie są zaufane. Ich suma 70 nie podważa podsumowania: kategorie mogą się nakładać, jeśli próba zawiera wiele błędów. Nie oznaczaj ponownie 70 jako unikalnych sesji zakończonych niepowodzeniem. Jeśli oba sumaryczne liczniki wynoszą zero, pokaż stosunek jako niedostępny, zamiast dzielić przez zero lub sugerować doskonałą obsługę.
Skieruj kategorię do odpowiedniego śledztwa
Referencje: RFC 8460 §4.3.
starttls-not-supported wskazuje na możliwość SMTP ; niedopasowanie certyfikatu do hosta wskazuje na weryfikację tożsamości; certyfikat-niezaufany wymaga dostępnego kodu przyczyny błędu i łańcucha certyfikatów. sts-policy-fetch-error dotyczy pobierania polityki, podczas gdy sts-webpki-invalid dotyczy uwierzytelniania tego punktu końcowego HTTPS. Ogólny błąd sprawdzania poprawności nie jest diagnozą przestarzałej wersji TLS . Zachowaj nieznane kategorie i oznacz je jako niesklasyfikowane, zamiast po cichu je odrzucać. RFC 8460 przewiduje rozszerzenie słownictwa wyników.
Zbuduj bezpieczny czytnik, a nie zaufany moduł renderujący
Referencje: RFC 8460 §7.
Przed analizą zweryfikuj strukturę JSON, liczniki liczbowe i analizę dat. Zastosuj limity wejściowe i dekompresyjne, zachowaj surowe podsumowanie i ciągi znaków ucieczki przed wyświetleniem ich na pulpicie nawigacyjnym. Dostarczone w raporcie łącza do dodatkowych informacji stanowią niezaufane dane wejściowe, a nie instrukcje automatycznego przeglądania. Traktuj brakujące pola dotyczące parametrów końcowych jako niedostępny dowód. Połącz zagregowany wynik z autoryzowanymi kontrolami punktów końcowych przed przypisaniem pierwotnej przyczyny lub wpływu na klienta. Nowo zapisane urządzenie arytmetyczne w tym pakiecie to lokalny test nauczania; nie testowano żadnego nadawcy produkcyjnego ani raportu produkcyjnego.
Zachowane dowody historyczne i pozostały zakres
Poniżej opisano zachowane obserwacje z 7 listopada 2026 r., a nie powtórzony eksperyment sieciowy na potrzeby tego przeglądu. Nowo wykonane kontrole offline są rejestrowane osobno.
Zachowany historyczny skrypt tls_lab.py i jego datowane przechwycenie rejestrują powitanie SMTP w pętli zwrotnej, EHLO, STARTTLS i potwierdzony certyfikatem uścisk dłoni TLS . Pozytywna kontrola wynegocjowana TLSv1.3. Certyfikat wydany dla web.example .test nie przeszedł weryfikacji dla mx1.example .test z kodem weryfikacyjnym OpenSSL 62. dowód/czytnik_reportu/annotated_lab_report.json zawiera kompletny, ręcznie stworzony raport reprezentujący dokładnie te dwie obserwacje, z adnotacjami odnoszącymi się do niepowodzenia zarejestrowanego uścisku dłoni i odcisku palca certyfikatu publicznego. Nie został on wygenerowany w drodze raportowania MTA, a kontekst polityki STS ma raczej charakter ilustracyjny niż odkryty. Są to zachowane kontrolowane dowody dotyczące punktu końcowego, a nie bieżąca telemetria klienta lub nowy przebieg testu. Reprodukcja wymaga Pythona z kryptografią i lokalnymi gniazdami pętli zwrotnej. Świeże przebiegi generują nowe klucze i znaczniki czasu, dlatego należy porównać oczekiwane wyniki, zamiast wymagać identycznych bajtów odcisków palców certyfikatów.
Baza pierwotnego źródła
Z tego źródła pochodzą definicje pól, zachowanie przy wykrywaniu i limity raportowania RFC 8460 , Raportowanie SMTP TLS, sekcje 3 i 4. Jeżeli omawiana jest walidacja STS, należy skonsultować się RFC 8461. Zalecenia operacyjne odróżnia się od wymagań protokołu.