Ulepszony kod stanu to ustrukturyzowana wskazówka, a nie pełny raport o zdarzeniu. „5.7.1” może zawęzić badanie do kwestii bezpieczeństwa lub zasad, ale nie może samodzielnie zidentyfikować właściciela polityki, trasy, której dotyczy problem, ani skorygować zmiany konfiguracji. Zachowaj pełną diagnostykę obok kodu podczas rozwiązywania problemów.
Przeczytaj wszystkie trzy elementy
RFC 3463 definiuje ulepszone kody stanu zawierające komponenty klasy, tematu i szczegółów. Klasa rozróżnia sukces, trwałą awarię przejściową i trwałą awarię. Kategorie tematyczne rozróżniają obszary takie jak adresowanie, stan skrzynki pocztowej, routing i bezpieczeństwo lub polityka. Szczegół zawęża warunek w tym temacie. Zwykła trzycyfrowa odpowiedź SMTP pozostaje częścią dowodu. RFC 3463.
Nie traktuj liczby końcowej jako globalnego identyfikatora błędu. Znaczenie zależy od pełnego ulepszonego kodu i obowiązującej dokumentacji rejestracyjnej lub dostawcy. System odbierający może również zwrócić użyteczną prozę bez ulepszonego kodu. Jeśli klasy podstawowe i rozszerzone wydają się niespójne, zachowaj dokładne bajty i sprawdź zachowanie dostawcy, zamiast po cichu przepisywać dziennik.
Oddziel odpowiedzi SMTP od raportów doręczenia
Podczas rozmowy następuje odpowiedź SMTP . Powiadomienie o stanie dostarczenia może później raportować wyniki i może opisywać wielu odbiorców. RFC 3464 definiuje pola obejmujące odbiorcę końcowego, akcję, stan, zdalny-MTA i kod diagnostyczny. Niezależnie czytaj bloki poszczególnych odbiorców; jedna porażka nie oznacza, że każdy odbiorca poniósł porażkę. RFC 3464 sekcja 2.
Akcja i Stan odpowiadają na różne pytania. Akcja: niepowodzenie oznacza zgłoszenie MTA przerwał próby dla tego odbiorcy. Status: 4.2.2 może nadal opisywać przejściową przyczynę zapełnienia skrzynki pocztowej po wyczerpaniu się liczby prób; nie powiodło się, a w DSN jest ważny status 4.xx, a nie niespójna odpowiedź SMTP . Na przykład wygasły element zawierający te pola nie zostanie automatycznie wznowiony tylko dlatego, że powróci pojemność. Przed autoryzowaniem jakiejkolwiek wymiany sprawdź rzeczywistą kolejkę. Widzieć RFC 3464 sekcja 2.3.3.
Temat odbicia czytelny dla człowieka jest przydatny do segregacji, ale może pominąć decydujące pola. Jeśli to możliwe, uzyskaj raport do odczytu maszynowego lub dziennik wysyłania. Trzymaj serwer raportowania oddzielnie od serwera zdalnego i odróżniaj sygnaturę czasową raportu od sygnatury czasowej nieudanego polecenia SMTP .
Przeczytaj hipotetyczny blok odbiorcy
Załóżmy, że dziennik wysyłania rejestruje RCPT TO dla missing@example.test , po którym następuje 550 5.1.1. Przykładowy blok odbiorcy DSN może zawierać odbiorcę końcowego: rfc822; missing@example.test , Akcja: nie powiodła się, Stan: 5.1.1, Remote-MTA: dns; mx.example .test i kod diagnostyczny: smtp; 550 5.1.1 Brak takiego użytkownika. Są to wymyślone wartości pól, a nie wykonana transakcja lub pełny raport MIME .
Nieudana akcja jest dla tego odbiorcy ostateczna, natomiast diagnostyka wskazuje na adresowanie. Nie ustala, dlaczego adres jest niedostępny ani co stało się z innymi odbiorcami. Uzyskaj te odpowiedzi z własnych bloków i zaufanych dzienników. Pola Odbiorca końcowy, Akcja i Stan są wymagane dla każdego odbiorcy; Remote-MTA i Diagnostic-Code są warunkowe lub opcjonalne. Ich brak nie oznacza pozwolenia na wymyślenie odrzucającego hosta lub tekstu błędu.
W przypadku nieznanych zarejestrowanych danych należy zapoznać się z aktualnym Udoskonalony rejestr statusu IANA i przytoczoną specyfikację, następnie aktualne wyjaśnienie dostawcy. RFC 3463 dostarcza frameworka, a nie wyczerpującej listy każdego późniejszego kodu.
Zamień kod w sprawdzalną hipotezę
Aby uzyskać kod adresowania, potwierdź zamierzony adres i zachowanie systemu odbiorczego. Aby uzyskać kod routingu, sprawdź nieudaną konfigurację następnego przeskoku i trasy. W przypadku kodu zabezpieczającego lub zasady zidentyfikuj nazwane wymaganie i jego właściciela. Unikaj zaczynania od preferowanej zmiany DNS , a następnie interpretowania każdej odpowiedzi jako jej wsparcia.
Zapisz jedną hipotezę, przewidywane przez nią dowody i najmniejszy autoryzowany test. Poprawioną wiadomość należy porównać z oryginałem na odpowiedniej trasie i klasie odbiorcy. Zachowaj sprzeczny wynik jako użyteczny dowód, zamiast narzucać go w oryginalnym wyjaśnieniu. Pakiety eskalacyjne powinny zawierać znaczniki czasu, dokładną odpowiedź, zakres, którego dotyczy problem, oraz zmiany już przetestowane, przy czym treść wiadomości i dane osobowe powinny być zminimalizowane. Sprawdzenie kodu to początek diagnozy, a nie jej zakończenie.
Zbuduj użyteczny pakiet eskalacyjny
- Tożsamość: zachowaj identyfikatory wiadomości i kolejek, odbiorcę koperty, którego dotyczy problem, i zakres, którego to dotyczy.
- Oś czasu: przesłanie rekordu, nieudana próba i osobne zgłoszenie przybycia.
- Diagnoza: uwzględnij dokładną odpowiedź SMTP , etap polecenia i pola DSN każdego odbiorcy.
- Własność: odróżnij system raportowania od systemu odrzucającego, przedstawiając dowody dla każdego z nich.
- Następny krok: podaj jedną sprawdzalną przyczynę, najmniejszą autoryzowaną kontrolę i wszelkie sprzeczne dowody. Minimalizuj dane osobowe.