Osoba sprawdzająca transport może wykryć prawdziwy problem bez sprawdzania bezpieczeństwa każdej wiadomości wysyłanej lub odbieranej przez Twoją organizację. Większość kontroli obserwuje wybrany punkt końcowy w określonym czasie przy użyciu określonego modułu rozpoznawania nazw i metody sprawdzania poprawności. Wynik możliwy do obrony obejmuje zatem zakres i brakujące pokrycie, a nie tylko odznakę przepustki.
Zdefiniuj zapasy trasy dostawy
Referencje: RFC 8461 §3.4, RFC 8461 §5.1, RFC 7672 §2.2.
Lista domen odbiorców, nazw hostów MX , priorytetów, adresów IPv4 i IPv6 , hostowanych bram i tras przełączania awaryjnego. Zwróć uwagę, czy test przebiega według zwykłego routingu MX , czy jawnie skonfigurowanego inteligentnego hosta. Zapisz implementację nadawcy i informację, czy obsługuje MTA-STS, DANE lub lokalna obowiązkowa polityka TLS. Różne systemy wysyłające mogą podejmować różne decyzje dla tej samej domeny odbierającej.
Następnie zdefiniuj roszczenie, które może obsłużyć każdy czek. Publiczne żądanie HTTPS może ustalić dostępność zasad z tego punktu widzenia. Sonda TLS może obserwować przedstawiony certyfikat pod wybranym adresem. Sprawdzające zapytanie DNS może dostarczyć dowodów na temat DNSSEC status w ramach określonego modelu zaufania mechanizmu rozpoznawania nazw. Żaden sam nie udowadnia, że jest to prawdziwe posłanie MTA wykorzystał te same dane i egzekwował oczekiwaną politykę dostaw.
Uchwyć stan, a nie tylko wyniki
Referencje: RFC 8461 §3.3, RFC 8461 §4, RFC 7672 §3.
W przypadku MTA-STS zachowaj rekord wykrywania, dokładne bajty zasad HTTPS, czas pobierania, tryb, czas życia i stan pamięci podręcznej nadawcy. W przypadku DANE zachowaj MX i TLSA odpowiedzi, stan walidacji i porównanie skojarzeń. Dla każdego połączenia SMTP przechwyć wybranego hosta i adres IP, STARTTLS negocjacje, wynik weryfikacji wzajemnej i decyzja o dostawie. RFC 8461 sekcje 3–5, RFC 7672 sekcje 2–3.
Uszkodzona sonda powinna zarejestrować swój etap awarii. Limit czasu DNS , limit czasu TCP, brak STARTTLS , błąd uzgadniania i niezgodność certyfikatu nie są wymiennymi ustaleniami. Pomyślny uścisk dłoni nie oznacza również, że nadawca odmówi przyszłego połączenia o obniżonej jakości. Uwzględnij kontrolowane przypadki negatywne, jeśli jest to dozwolone, zwłaszcza przed wprowadzeniem rygorystycznych wymogów dotyczących transportu.
Pracuj nad luką w zasięgu
W tym przykładzie syntetycznego spisu mx1.example.net ma trasy IPv4 i IPv6 , a mx2.example.net jest kopią zapasową. Przykładowa obserwacja obejmuje tylko adres IPv4 mx1. W inwentarzu należy oznaczyć trasy IPv6 i trasy zapasowe jako nieprzetestowane, a nie propagować sukces we wszystkich trzech. Obserwacja jest wyraźnie syntetyczna i nie niesie ze sobą żadnych roszczeń co do rzeczywistego związku.
Dodaj wiersz akceptacji po stronie nadawcy dla pomocniczego MTA przy użyciu prawidłowych zasad egzekwowania, kolejny z pustą pamięcią podręczną i nadawcą obsługującym DANE ze zweryfikowaną metodą TLSA. Te wiersze pozostają oczekujące do czasu przechwycenia rzeczywistych dzienników. Dzięki temu plan akceptacji jest użyteczny bez przedstawiania oczekiwanych wyników w postaci pomiarów. Pozwala także osobie reagującej na incydent sprawdzić, czy trasa, która uległa awarii, została kiedykolwiek wykorzystana.
Uzgodnij raporty i dowody operacyjne
Referencje: RFC 8460 §4.1, RFC 8460 §4.2.
TLS-RPT raporty mogą ujawniać awarie zaobserwowane przez uczestniczących nadawców w okresie raportowania, co stanowi uzupełnienie badań punktowych. Liczba sesji nie jest liczbą unikalnych wiadomości, a ich zasięg nie jest uniwersalny. Cichy okres raportowania nie oznacza, że wszystkie trasy powiodły się, a powtarzające się próby mogą komplikować szacunki wpływu na działalność biznesową. RFC 8460 sekcja 4.4.
Zachowaj nieprzetworzony wynik, sygnaturę czasową, wersję narzędzia lub polecenie oraz węższe wnioski, jakie z nich wyciągnąłeś. Przetestuj ponownie po odnowieniu certyfikatu, migracji MX , zmianach DNSSEC i aktualizacjach zasad. Pakiet przeglądowy zawiera siedem zachowanych transkryptów pętli zwrotnej z 7 listopada 2026 r. wraz z bajtami certyfikatów równorzędnych dla czterech sesji, które osiągnęły przechwycenie certyfikatu. Obejmują lokalnego klienta/serwer IPv4 Python na wygenerowanych portach z jawnie skonfigurowanymi danymi wejściowymi zaufania i zasad, a nie internetowy SMTP , łańcuch walidacji DNSSEC , produkcyjne kolejki MTA lub pełną zgodność z profilem certyfikatu MTA-STS . Sesje historyczne zostały sprawdzone, ale nie zostały tutaj powtórzone. Przykładowe internetowe IPv4 , IPv6 i ścieżki zapasowe pozostają niesprawdzone; nikt nie dziedziczy przepustki lokalnej. Nowo wykonany model zasięgu offline sprawdza jedynie, czy jedna zaobserwowana syntetycznie trasa pozostawia inne wymienione trasy nietestowane. Przechwyć zamierzone obserwacje MTA i routingu przed zażądaniem gwarancji wdrożenia.