4.4.6Wykryto pętlę routingu między systemami pocztowymi

Własny opis IANA dla wzorca rejestru X.4.6 („Wykryto pętlę routingu”) nazywa go „przydatnym wyłącznie jako uporczywe niepowodzenie przejściowe”, a kod 4.4.6 nadaje temu wzorcowi klasę tymczasową: wiadomość była przekazywana między systemami pocztowymi zbyt wiele razy i nie docierała do celu, więc system obsługujący ją przerwał próbę zamiast przekazywać ją w nieskończoność. Podstawowy kod powiązany w rejestrze dla X.4.6 to „Not given”. Ten wpis nie ustala mechanicznie klasy 4 ani klasy 5, a kanoniczne odwzorowanie rejestru IANA w tym katalogu zostawia status rozstrzygnięcia klasy dla tego wzorca jako nierozstrzygnięty i nie zamienia opisu w potwierdzenie klasy. Ten konkretny kod klasy 4 publikujemy wyłącznie na podstawie dokładnego dowodu produkcyjnego zebranego w korpusie (odpowiedź Rackspace 450 4.4.6 poniżej), a nie na podstawie potwierdzenia klasy przez IANA.

Wzorzec X.4.6 nazywa pętlę routingu. Wiadomość była przekazywana między systemami pocztowymi zbyt wiele razy z powodu nieprawidłowych tabel routingu albo reguły przekierowania, która odesłała ją z powrotem na ścieżkę, którą już przebyła. RFC 3463 (sekcja 3.4) definiuje ten wzorzec w ramach przedmiotu stanu sieciowo-routingowego i opisuje go jako przydatny wyłącznie jako uporczywe niepowodzenie przejściowe, bez formalnego potwierdzenia żadnej klasy. Podstawowy kod powiązany w rejestrze dla X.4.6 to „Not given”, a kanoniczne odwzorowanie rejestru IANA w tym katalogu zapisuje status rozstrzygnięcia klasy jako nierozstrzygnięty (podstawa: iana_missing_class_evidence), bo opisowy tekst nie staje się tu potwierdzeniem klasy. Konkretny kod 4.4.6 (klasa 4) publikujemy na podstawie dokładnego dowodu korpusowego: Rackspace/emailsrvr.com zwraca „450 4.4.6 Routing loop detected (G16)”, gdy jego system wykryje niedostarczalną pętlę pocztową, dołączając własny wewnętrzny kod referencyjny (G16) obok kodu rozszerzonego. W praktyce ten sam wzorzec rejestru nie jest zarezerwowany dla klasy 4 ani dla jednego kodu odpowiedzi. Klauzula RFC 5248 o tym, że lista Associated Basic Status Code nie ma charakteru wyłącznego, oznacza, że inny dostawca mógłby równie dobrze odrzucić albo odbić wiadomość z powodu pętli routingu w innej klasie lub trybie doręczenia. Zawsze potwierdzaj dokładną klasę i tekst odpowiedzi zamiast zakładać jedno uniwersalne traktowanie X.4.6.

Wiodąca cyfra 4 oznacza niepowodzenie tymczasowe: sam zaakceptowany przykład zaleca ponowienie próby za kilka minut, licząc na to, że osoba zarządzająca regułą przekierowania albo tabelą routingu odpowiedzialną za pętlę ją naprawi, albo że pętla po prostu nie powtórzy się przy kolejnej próbie inną ścieżką. Różni się to od hipotetycznego użycia tego samego szczegółu X.4.6 w klasie 5, które traktowałoby pętlę jako nieodwracalną przez ponawianie. Ten katalog publikuje wprawdzie konkretny kod klasy 5 pod tym samym wzorcem X.4.6 (5.4.6), ale jego dowód korpusowy to odrzucenie za przekroczony limit u Titana, a nie pętla routingu — żaden dostępny dowód nie potwierdza więc odczytania pętli routingu jako niepowodzenia trwałego.

Klasa

Niepowodzenie tymczasowe

Ponowienie

Kontrolowane ponowienie

Supresja

Sprawdź pełny kontekst

Ponawiaj z ograniczoną liczbą prób i backoffem, ponieważ sama wskazówka systemu odbiorcy traktuje ten stan jako potencjalnie przejściowy. Nie ponawiaj w nieskończoność: pętla routingu spowodowana nieaktualną regułą przekierowania albo uszkodzoną tabelą routingu nie ustąpi sama, niezależnie od liczby prób, więc zatrzymaj ponawianie po rozsądnym oknie czasowym — sam zaakceptowany przykład wskazuje eskalację, jeśli stan się nie poprawi — i przekaż problem osobie administrującej odpowiednim przepływem poczty, zamiast dalej ponawiać próby na ścieżce, która wciąż się zapętla.

Nie wykluczaj adresu odbiorcy wyłącznie na podstawie kodu 4.4.6: ten stan opisuje błędną konfigurację routingu lub przekierowania gdzieś na ścieżce, a nie nieprawidłowy czy nieosiągalny adres. Wyklucz adres dopiero wtedy, gdy po naprawieniu pętli pojawi się niezależny, właściwy dla tego adresu sygnał trwały, a wiadomości nadal nie da się dostarczyć.

• Reguła przekierowania po stronie odbiorcy odsyła wiadomość z powrotem do systemu, który już ją obsłużył. Na przykład adres przekierowuje na inny adres, który bezpośrednio albo przez kolejną regułę kieruje wiadomość z powrotem na ścieżkę tej samej domeny — tak powstaje cykl, który warstwa routingu w końcu przerywa.
• Błędnie skonfigurowana tabela routingu, rekord MX albo łańcuch przekaźników pocztowych odsyła wiadomość między systemami, nigdy nie docierając do celu, i przekracza dopuszczalny limit przeskoków, zanim dostarczenie się zakończy.
• W zaakceptowanym przykładzie Rackspace/emailsrvr.com system dostawcy wykrył pętlę i odrzucił wiadomość, zamiast przekazywać ją w nieskończoność, dołączając własny kod referencyjny (G16) i kierując nadawcę do ponowienia próby później albo kontaktu z postmaster@emailsrvr.com, jeśli stan się nie poprawi — to udokumentowane zachowanie tego konkretnego dostawcy, nie ogólna definicja kodu 4.4.6 u wszystkich dostawców.

1. Sprawdź surową odpowiedź SMTP i potwierdź, że kod rozszerzony to dokładnie 4.4.6 przy podstawowej odpowiedzi klasy 4xx (w zaakceptowanym przykładzie: 450); zwróć uwagę na ewentualny wewnętrzny kod referencyjny dostawcy zawarty w odpowiedzi (w zaakceptowanym przykładzie: G16), bo może przyspieszyć rozmowę z pomocą techniczną tego dostawcy.
2. Prześledź ścieżkę wiadomości w dziennikach przepływu poczty albo w nagłówkach Received:, aby ustalić, który przeskok odsyła wiadomość z powrotem na ścieżkę, którą już przebyła; sprawdź zwłaszcza reguły przekierowania po stronie odbiorcy oraz wpisy przekaźników czy tabel routingu dotyczące tej domeny lub adresu.
3. Zapytaj osobę administrującą daną skrzynką lub domeną, czy niedawno dodano lub zmieniono regułę przekierowania oraz czy w okresie, gdy zaczęła się pętla, zmieniono jakąś tabelę routingu, przekaźnik pocztowy albo konfigurację MX.
4. Ponawiaj z ograniczoną liczbą prób i zatrzymaj się, gdy pętla zostanie naprawiona i dostarczenie się powiedzie, albo gdy wyczerpie się okno prób; jeśli stan utrzymuje się dłużej, eskaluj sprawę bezpośrednio do dostawcy odbiorcy (w zaakceptowanym przykładzie wskazany jest postmaster@emailsrvr.com), zamiast dalej ponawiać.