Oceniaj ścieżkę, a nie dekoracyjny wynik wyszukiwania
SPF ocena zależy od łączącego adresu IP, odpowiedniej tożsamości SMTP i stanu DNS napotkanego na ocenianej ścieżce. Moduł sprawdzający, który wyświetla tylko statyczną liczbę widocznych terminów dołączanych, może pominąć zagnieżdżone zależności, wczesne dopasowania, błędy i zachowanie przekierowania. Przydatne wyniki powinny przedstawiać dane wejściowe, uporządkowaną ocenę i uzasadnienie wyniku, jednocześnie odróżniając zaobserwowany przebieg od hipotetycznej analizy najgorszego przypadku.
RFC 7208 definiuje SPF i jego ocenę check_host. W tym artykule zaproponowano wymagania dotyczące szachownicy i elementy defensywy. Nie twierdzi, że EmailAuth je implementuje ani że przetestowano prawdziwego nadawcę. Nie wykonano żadnych zapytań DNS domeny użytkownika, połączeń SMTP ani wiadomości testowych. Zachowanym standardem jest dowód z dokumentu, a nie protokół wykonania.
Zapisz dane wejściowe dotyczące tożsamości i połączenia
Arkusz powinien identyfikować dane wejściowe dotyczące adresu IP, domeny i nadawcy dostarczone do oceny, wraz z kontekstem SMTP niezbędnym do ich interpretacji. SPF ocenia odpowiednie POCZTA OD tożsamość i określił HELO zachowanie, w tym przypadek zerowej ścieżki odwrotnej. Nie weryfikuje bezpośrednio czytelnej dla człowieka wyświetlanej nazwy ani nie potwierdza autentyczności treści wiadomości. Zanim zinterpretujesz przepustkę jako szerszy sygnał zaufania, utrzymuj te granice w widocznym miejscu.
RFC 9989 dodaje wyrównanie związek z widoczną domeną From, gdy SPF wnosi swój wkład DMARC. Pomyślna ocena SPF dla innej domeny nie jest automatycznie dopasowaną przepustką DMARC . Moduł sprawdzający powinien zachować rzeczywistą ocenianą tożsamość, aby dalsza analiza mogła ocenić tę relację bez zgadywania. W tym manuskrypcie nie jest dostępna żadna próbka odebranej wiadomości, która umożliwiłaby ustalenie rzeczywistego wyniku dopasowania.
Pokaż uporządkowane mechanizmy i wyniki zależności
RFC 7208 ocenia mechanizmy w kolejności, a wynik zależy od dopasowań i błędów. Wczesne dopasowanie może oznaczać, że późniejsze mechanizmy nie będą oceniane pod kątem tych danych wejściowych. Osoba sprawdzająca powinna zatem wykazać, które warunki zostały osiągnięte, a które nie i dlaczego przetwarzanie zostało zakończone. Jeśli oblicza również inwentarz zależności lub możliwą niedopasowaną ścieżkę, oznacz to jako inną analizę, a nie przedstawiaj jako wykonaną ścieżkę.
Dołączenie to nie tylko tekst wklejony do rekordu nadrzędnego. Jego ocena referencyjna ma zdefiniowaną obsługę wyników: przebieg, do którego się odwołuje, tworzy dopasowanie do dołączania, podczas gdy inne wyniki są zgodne z mapowaniem standardu. Przekierowanie to modyfikator oceniany według własnych reguł, gdy żaden mechanizm nie pasuje, a każdy mechanizm all powoduje ignorowanie przekierowania. Te rozróżnienia mają znaczenie przy wyjaśnianiu, dlaczego dwa z pozoru podobne rekordy zachowują się inaczej.
Zastosuj precyzyjnie limit dziesięciu terminów
Sekcja 4.6.4 ogranicza całkowitą liczbę ocenionych terminów powodujących zapytania DNS do dziesięciu: include, a, mx, ptr, istnieje i przekierowanie to wymienione mechanizmy lub modyfikatory. Przekroczenie tego limitu wymaga permerror. Mechanizmy all, ip4 i ip6 oraz modyfikator exp nie podlegają temu samemu limitowi; exp może spowodować późniejsze wyszukiwanie. Limit nie jest prostą maksymalną liczbą Rekordy TXT lub surowe pakiety DNS zaobserwowane na kablu.
Zagnieżdżone ewaluacje wnoszą wkład w odpowiedni ogólny budżet ewaluacyjny. Dodatkowe ograniczenia dotyczą wyszukiwania adresów związanego z przetwarzaniem mx i ptr, przy innej zalecanej obsłudze. Osoba sprawdzająca powinna wdrożyć i zgłosić te szczegóły, zamiast spłaszczać je w niekwalifikowanym sloganie dziesięciu zapytań DNS . Należy także odróżnić buforowaną aktywność modułu rozpoznawania nazw od ocenianych terminów logicznych: mniejsza liczba pakietów sieciowych nie upoważnia do ignorowania limitów oceny protokołu.
Odróżnij puste odpowiedzi od tymczasowych niepowodzeń
RFC 7208 opisuje puste wyszukiwania jako pozytywne odpowiedzi DNS bez odpowiedzi lub odpowiedzi na błąd nazwy. Implementacje powinny ograniczać je do dwóch, mogą umożliwiać konfigurowanie limitu i zaleca się ustawienie domyślne na dwa, jeśli jest to konfigurowalne. Przekroczenie zastosowanego limitu pustki powoduje permerror . Jest to zalecenie na poziomie POWINNO z konfigurowalnym zachowaniem, a nie uniwersalne stwierdzenie, że każda implementacja zawsze wymusza identyczny stały limit.
Przekroczenie limitu czasu DNS lub awaria serwera nie jest po prostu kolejną nieważną odpowiedzią. Odpowiednie reguły błędów SPF mogą powodować temperror, podczas gdy stałe problemy z oceną powodują permerror . Zapisz rzeczywistą odpowiedź lub awarię DNS oraz regułę zastosowaną do jej interpretacji. Nie zamieniaj niedostępnej zależności w zgadnięty brak dopasowania lub czysty przebieg. Osoba sprawdzająca powinna ujawnić niepewność i zabezpieczyć wystarczające dowody, aby później odtworzyć rozróżnienie.
Uczciwie reprezentuj cykle i zniekształcone zapisy
Zależności cykliczne mogą wielokrotnie zużywać zasoby ewaluacyjne i osiągać określone limity; nie należy ich przedstawiać jako nieszkodliwego, zdeduplikowanego wykresu, który gwarantuje pomyślny wynik. Kontroler może wykryć i wyjaśnić cykl, ale raportowany wynik protokołu musi być zgodny z zaimplementowanym standardem i danymi wejściowymi. Zachowaj łańcuch nazw, do których istnieją odniesienia, oraz moment, w którym przetwarzanie zostało zatrzymane, bez wykonywania niekontrolowanych ponownych prób.
Wybór rekordu i kwestia składni przed oceną ścieżki. Wiele Rekordy SPF o tej samej tożsamości nie są prawidłowym sposobem łączenia nadawców i generowania permerror zgodnie ze standardem. Nieznane mechanizmy i nieznane modyfikatory wymagają innego leczenia; nieznany mechanizm nie jest bezpiecznie ignorowany tylko dlatego, że można zignorować nieznane modyfikatory. Plan testów powinien obejmować te rozróżnienia, a nie traktować każdy nieobsługiwany element jako jedno ogólne ostrzeżenie.
Arkusz ścieżki zależności
Utwórz arkusz z danymi wejściowymi oceny, wersją implementacji, czasem obserwacji DNS , wybranym rekordem SPF , uporządkowanymi terminami, zagnieżdżonymi zależnościami, budżetem terminów i liczbą pustych przestrzeni. Dla każdego kroku zapisz status odpowiedzi, dopasowanie lub brak dopasowania, mapowanie błędów i przyczynę zatrzymania. Dodaj osobną kolumnę dla nieocenionych zależności, aby czytelnik mógł odróżnić dowody rzeczywistej ścieżki od zapasów. Zachowaj kontekst mechanizmu rozpoznawania nazw i wszelkie konfigurowalne limity.
Proponowane urządzenia powinny obejmować reprezentatywną pasującą ścieżkę, niedopasowaną ścieżkę sięgającą późniejszych zależności, cykl, puste odpowiedzi i niedostępny DNS . Używaj kontrolowanych syntetycznych urządzeń DNS zamiast wysyłać zapytania do infrastruktury klienta bez autoryzacji. Oczekiwane wyniki powinny powoływać się na odpowiednią sekcję standardu i identyfikować zachowanie konfigurowalne w ramach implementacji. Nie uruchomiono tutaj żadnego urządzenia, więc arkusz zawiera wymagania, a nie sfabrykowane transkrypcje.
Fikcyjna diagnoza: krótki zapis z długą ścieżką
Fikcyjny operator widzi tylko kilka terminów w rekordzie najwyższego poziomu i zakłada, że budżet wyszukiwania jest bezpieczny. Proponowany przegląd urządzeń pokazuje, że każdy termin może prowadzić do dalszych zależności na niepasującej ścieżce. Inne dane wejściowe mogą pasować wcześnie i nigdy nie osiągnąć tych późniejszych terminów. Obie ścieżki mogą zatem zużywać różne budżety logiczne, mimo że opublikowany tekst najwyższego poziomu jest identyczny.
Przed zaleceniem zmiany zespół zachowałby faktyczne dane wejściowe i ścieżkę oceny. Nie spowodowałoby to ślepego spłaszczania rekordów dostawców w statycznych zakresach adresów IP, ponieważ może to spowodować przesunięcie odpowiedzialności za aktualizacje i stać się nieaktualne. Ten scenariusz jest fikcyjny: nie zapytano ani nie zmodyfikowano żadnej zależności od dostawcy, zakresu adresów ani prawdziwego rekordu. Ilustruje to, dlaczego kontroler musi wyjaśnić ścieżkę, a nie wyświetlać tylko liczbę.
Zachowaj zakres wniosków
Przydatny wynik mówi, która tożsamość i adres IP zostały ocenione, w jakim stanie DNS i zachowaniu implementacyjnym oraz dlaczego taki wynik wystąpił. Nie gwarantuje, że każdy nadawca przejdzie pozytywnie ani że przepustka potwierdza legalność biznesową. Inwentaryzacja zależności jest cenna, ale nie należy jej mylić z wykonaną oceną SPF .
Katalog wymaga reprezentatywnych przypadków pasujących, niedopasowanych, cyklicznych, nieważnych i niedostępnych DNS. Oryginalne terminarze i wyniki pozostają otwarte. Otwarte pozostają także przegląd specjalistów, możliwość zastosowania źródeł, trasy produkcji, dostępność i zezwolenie właściciela. Ta wersja robocza przedstawia proponowany model dowodów, a nie wykonane skany lub zweryfikowane zachowanie narzędzia.