Etykieta wyniku nie jest diagnozą
Błąd trwały oznacza trwały błąd w SPF oceny, ale nie identyfikuje unikalnej wady. Źle sformułowane wybrane zasady, można zastosować wiele zasad Rekordy SPF, brakująca polityka rekurencyjna lub przekroczony limit oceny może dawać taki wynik na podstawie różnych reguł. Odpowiedź pomocy technicznej, która tłumaczy każdy permerror na „zbyt wiele wyszukiwań DNS ”, może skierować administratora do błędnej naprawy i potencjalnie uszkodzić ważną autoryzację nadawcy.
Zacznij od zachowania tożsamości i danych wejściowych używanych do oceny. Zapisz adres połączenia, HELO Lub POCZTA OD kontekst, oceniana domena, argument nadawcy i czas. Następnie zachowaj rzeczywistą odpowiedź DNS i wybraną politykę SPF . Bez tych danych wejściowych dwa różne raporty mogą dotyczyć różnych tożsamości lub różnych migawek, a nie niezgody co do tej samej polityki. RFC 7208 , sekcja 2.3, 2.4 i 8.7
Najpierw sprawdź wybór rekordu i składnię
Wybór zasad SPF podlega określonym zasadom. Wiele wybranych rekordów SPF powoduje permerror ; nie są one łączone w większą politykę i nie należy ich traktować jako wygodnego sposobu na podzielenie dostawców. Ciągi znaków TXT w jednym rekordzie to inna sprawa niż wiele niezależnych rekordów. Zachowaj granice rekordów, aby recenzent mógł odróżnić szczegóły prezentacji od prawdziwego problemu selekcji.
Składnia również wymaga pełnego przeglądu zasad. RFC 7208 wymaga sprawdzenia składni przed oceną mechanizmu; nieprawidłowy mechanizm może zatem mieć znaczenie, nawet jeśli ktoś spodziewa się, że wcześniejszy mechanizm będzie pasował. Nierozpoznane mechanizmy i zignorowane, nierozpoznane modyfikatory nie są kategoriami wymiennymi. Unikaj niejasnych wskazówek, jak usunąć każdy nieznany token. Przed podjęciem decyzji, czy jest to błąd, należy określić jego rolę gramatyczną i sposób obsługi standardu. RFC 7208 , sekcja 3.2, 4.5, 4.6 i 6
Następnie klasyfikuj niepowodzenia w zakresie oceny i budżetu
Aby uzyskać ogólny budżet okresu powodującego DNS, uwzględnij, a, mx, ptr, istnieje i liczbę przekierowań podczas oceny. Limit wynosi dziesięć, a przekroczenie go musi spowodować permerror . Nie jest to po prostu liczba pakietów DNS , liczba pakietów najwyższego poziomu czy liczba unikalnych dostawców. Rekurencja dzieli budżet, a buforowanie nie usuwa terminów ocenionych logicznie.
Inne limity wymagają własnych etykiet. Odpowiedzi nieważne mają limit na poziomie POWINIEN wynoszący dwa, z dozwoloną konfiguracją i zalecaną wartością domyślną wynoszącą dwa, jeśli jest to konfigurowalne; przekroczenie obowiązującego limitu powoduje permerror . Przetwarzanie MX ma dodatkowe obowiązkowe ograniczenia. Stwierdzenie, że „rekord zawiera tylko dziewięć wpisów” nie wyklucza tych innych przyczyn, a wysoka nieprzetworzona liczba pakietów sama w sobie nie dowodzi przekroczenia ogólnego limitu dziesięciu okresów. RFC 7208 , sekcja 4.6.4
Oddziel wyniki błędów od wyników autoryzacji
Fail potwierdza, że klient nie jest autoryzowany do ocenianej tożsamości. Permerror oznacza, że ocena nie mogła dać zamierzonego wyniku autoryzacji z powodu trwałego błędu. Temperror oznacza błąd przejściowy. Brak jest również odrębnym wynikiem, ze specjalnym mapowaniem w przypadku napotkania poprzez włączenie lub przekierowanie. Etykiety te nie powinny być zwijane w jednym wiadrze „Niepowodzenie SPF ” podczas wyjaśniania działań naprawczych.
Odbiorca nadal decyduje, jak postępować z wynikami w ramach własnej polityki. Odrzucona wiadomość nie pozwala ustalić, która wada SPF spowodowała odrzucenie, chyba że dowody potwierdzają to powiązanie. Podobnie zaakceptowana poczta nie dowodzi, że polisa była ważna. Trzymaj diagnozę uwierzytelnienia i dyspozycję dostarczenia w oddzielnych polach i unikaj obietnic, że jedna naprawa DNS rozwiąże każdy problem z dostawą. RFC 7208 , sekcja 5.2, 6.1 i 8
Arkusz segregacji z wyraźnymi przyczynami zatrzymania
Skorzystaj z arkusza podzielonego na selekcję, analizę i ocenę. Przy wyborze zachowaj nazwę zapytania, odpowiedź, Rekord TXT granice i liczba wybranych rekordów SPF . Podczas analizowania zachowaj dokładny, połączony tekst rekordu, wersję analizatora, token naruszający, jeśli taki istnieje, oraz naruszoną regułę. Nie normalizuj błędu przed zachowaniem oryginalnych dowodów.
Podczas oceny zapisz każdy osiągnięty mechanizm lub modyfikator, bieżącą domenę, rozszerzony cel, skumulowaną liczbę terminów, klasyfikację odpowiedzi, rekurencyjny wynik potomny i decyzję o kontynuacji. Zachowaj odrębność sumy pustych wartości i limitów dodatkowych. Zaznacz pierwszy obsługiwany powód zatrzymania. Jeśli parser odrzucił politykę przed oceną, nie wymyślaj ścieżki, której oceniający nigdy nie wykonał, jedynie po to, aby zademonstrować inny możliwy problem.
Proponowana korekta powinna zawierać nazwę wady, której dotyczy, właściciela potwierdzającego zamierzone zezwolenie oraz trasy, które muszą nadal działać. Nierozwiązane wtórne ustalenia należy rejestrować oddzielnie. Źle sformułowana polityka może również zawierać wykres nadmiernej zależności, ale badacz powinien wyjaśnić, który wniosek został zaobserwowany, a który pozostaje kwestią statyczną do czasu prawidłowej oceny.
Fikcyjna diagnoza: dwie identyczne etykiety, różne naprawy
W fikcyjnym przypadku A domena publikuje dwa oddzielne rekordy TXT , które kwalifikują się jako zasady SPF . Przydatną diagnozą jest błąd w wyborze rekordu, a nie nadmierna liczba wyszukiwań. Proponowana naprawa wymagałaby uzgodnienia zamierzonej autoryzacji w jedną obsługiwaną politykę, po potwierdzeniu wszystkich legalnych tras. Usunięcie dowolnego rekordu może dyskretnie usunąć wymaganą usługę. W tym przypadku nie zebrano żadnej prawdziwej odpowiedzi ani korekty DNS .
W fikcyjnym przypadku B jedna zasada o prawidłowej składni podąża zagnieżdżoną trasą, która przed jakimkolwiek dopasowaniem próbuje zastosować jedenasty termin powodujący DNS. Przydatną diagnozą jest przekroczony budżet całkowity. Łączenie ciągów TXT nie rozwiązałoby tego problemu, ponieważ zasada obejmuje już jeden wybrany rekord. Zamiast tego recenzja wymaga dokładnej ścieżki zależności i obsługiwanego przeprojektowania, które chroni zasięg nadawcy.
Trzeci fikcyjny raport mówi tylko o „ permerror ” i nie zawiera migawki ani śladu rekordu. Prawidłowym wynikiem jest niewystarczający dowód, a nie domysł między A i B. Poproś o minimalny pakiet diagnostyczny za pośrednictwem autoryzowanego kanału, z wyłączeniem treści prywatnych wiadomości i niepotrzebnych adresów. Scenariusze te obejmują porównania koncepcyjne, a nie wykonane spotkania, wyniki odbiorników lub dowody na to, że określony dostawca jest źle skonfigurowany.
Kryteria akceptacji i zwolnienia
Roszczenie dotyczące naprawy powinno być węższe niż „Naprawiono SPF ”. Określ, czy poprawiono wybór rekordów, składnię, konkretną ścieżkę oceny lub konkretną zależność od dostawcy i jakie dowody potwierdzają to twierdzenie. Sprawdź, czy proponowana zmiana nie autoryzuje niezamierzonych nadawców ani nie wyklucza legalnych nadawców. Pozostaw ostateczny wynik dostawy odbiorcy poza roszczeniem, chyba że określono inaczej.
W przypadku tej wersji roboczej wymagana ścieżka z adnotacjami pokazująca każdy zliczony termin i dokładną gałąź, która uległa awarii, pozostaje nierozstrzygnięta. Jeśli faktycznym problemem jest analiza lub selekcja, zachowaj również ten podstawowy dowód i uzyskaj weryfikację przez człowieka, czy spełnia on zamierzony zakres artykułu. Nie twórz ocenianej ścieżki dla błędu, który zatrzymuje się przed przetworzeniem mechanizmów.
Nie przeprowadzono tutaj żadnych skanów, uruchomień parsera, modyfikacji DNS ani testów wiadomości. Oryginalne dowody, weryfikacja przez człowieka, zastosowanie źródła, trasy produkcji, dostępność wizualna i zezwolenie właściciela pozostają otwarte. Manuskrypt zapewnia ramy segregacji pacjentów i fikcyjne przykłady rozumowania, jednocześnie wyraźnie wstrzymując się od jakichkolwiek twierdzeń o ukończonej diagnozie operacyjnej.