5.4.0Wiadomość odrzucona za przekroczenie limitu przeskoków (ochrona przed pętlą routingu)

Wyłącznie dokładny dowód korpusowy umieszcza tu konkretny kod 5.4.0: jeden produkcyjny raport niedostarczenia, w którym system pocztowy odbiorcy użył cyfr 5.4.0 właśnie do zgłoszenia przerwania z powodu przekroczenia limitu przeskoków, a nie bliżej nieokreślonego problemu sieciowego w ogóle. Kod nakłada wzorzec rejestru X.4.0 na klasę 5. RFC 3463 umieszcza X.4.0 w tabeli bazowej jako ogólny, sieciowo-routingowy kod zbiorczy dla problemów, które nie pasują do żadnego bardziej szczegółowego kodu tego wzorca, ale Associated Basic Status Code przypisany przez IANA dla X.4.0 to „Not given” dla każdej klasy, a odwzorowanie rejestru IANA w tym katalogu traktuje wzorzec jako w pełni nierozstrzygnięty: żadna klasa nie jest tu mechanicznie potwierdzona, nawet odczytanie w klasie 4.

W odróżnieniu od sąsiadów takich jak X.4.1 (brak odpowiedzi od hosta, potwierdzone w klasie 4) czy X.4.3 (awaria serwera katalogowego, potwierdzone w klasach 4 i 5), IANA zapisuje dla X.4.0 Associated Basic Status Code jako „Not given” dla każdej klasy, a odwzorowanie rejestru IANA w tym katalogu pozostawia wzorzec w pełni nierozstrzygnięty. RFC 3463 (sekcja 3.4) definiuje klasę przedmiotową X.4 jako status sieciowo-routingowy i umieszcza w tabeli bazowej X.4.0 jako jej ogólny kod zbiorczy: coś poszło nie tak w warstwie sieciowej, ale nie jest jasne, na czym dokładnie polega problem, albo nie da się go dobrze opisać żadnym z pozostałych, bardziej szczegółowych kodów. Ani 4.4.0, ani 5.4.0 nie opiera się na potwierdzeniu klasy przez IANA. Konkretny kod 5.4.0 publikujemy na podstawie dokładnego dowodu korpusowego: raportu niedostarczenia z systemu pocztowego hostowanego przez Locaweb, w którym cyfry 5.4.0 towarzyszą przerwaniu z powodu przekroczenia limitu przeskoków na końcu fazy DATA, a nie ogólnemu ani bliżej nieokreślonemu problemowi sieciowemu.

Wiodąca cyfra 5 oznacza niepowodzenie trwałe dla tej wiadomości w bieżącym kontekście: ponowne wysłanie jej bez zmian się nie powiedzie, bo stan powodujący przerwanie z powodu limitu przeskoków — najczęściej pętla routingu albo przekierowań — odtworzy się identycznie na tej samej trasie. To samo w sobie nie oznacza, że adres odbiorcy jest nieprawidłowy — oznacza, że trasa, którą pokonała wiadomość, zapętliła się albo stała się zbyt długa, zanim do niego dotarła.

Klasa

Niepowodzenie trwałe

Ponowienie

Nie ponawiaj bez zmian

Supresja

Sprawdź pełny kontekst

Nie wysyłaj ponownie tej samej, niezmienionej wiadomości tą samą trasą. Ponowna wysyłka ma sens dopiero wtedy, gdy pętla zostanie faktycznie znaleziona i usunięta — poprawiona reguła przekierowania, naprawiona trasa przekaźnika albo smart hosta — a nie po prostu po upływie czasu. Jeśli ten sam kod 5.4.0 powtarza się na niezmienionej trasie, to potwierdza, że pętla nadal istnieje, a nie że to przejściowe przeciążenie.

Nie dodawaj adresu do listy wykluczeń wyłącznie na podstawie pojedynczego kodu 5.4.0. Ten stan opisuje trasę wiadomości, niekoniecznie sam adres; zanim uznasz adres za nieosiągalny, powiąż powtarzające się wystąpienia z rzeczywistą diagnozą routingu albo przekierowań, i wyklucz adres dopiero, gdy uzasadnia to polityka listy albo niezależny sygnał trwały.

• Pętla przekierowań na poziomie skrzynki: konto odbiorcy (albo lista mailingowa, do której należy) automatycznie przekierowuje pocztę po trasie, która wraca do tej samej wiadomości, dokładając kolejne przeskoki w nagłówkach Received:, aż limit skonfigurowany po stronie docelowej zostanie przekroczony.
• Błędnie skonfigurowany przekaźnik albo łańcuch routingu między dwoma lub więcej systemami pocztowymi — na przykład smart host albo bramka, której trasa wskazuje z powrotem na siebie, albo dwa systemy przekazujące sobie wiadomość nawzajem — co powoduje wielokrotne wstrzykiwanie tej samej wiadomości, aż zadziała zabezpieczenie liczby przeskoków.
• W zaakceptowanym przykładzie przekaźnik pocztowy Locaweb (balancer_haproxy.email.locaweb.com.br) egzekwuje ten limit przeskoków na końcu fazy DATA i zwraca 554 5.4.0 zamiast przyjąć wiadomość, którą uznaje za uwikłaną w pętlę — to udokumentowane zachowanie tej konkretnej platformy hostingowej, nie uniwersalna definicja kodu 5.4.0.

1. Pobierz pełny łańcuch nagłówków Received: z oryginalnej wiadomości (albo z kopii dołączonej do zwrotki, jeśli jest dostępna) i policz przeskoki; szukaj powtarzającej się nazwy hosta albo adresu — to wskazuje na pętlę, a nie zwykły, długi łańcuch przekaźników.
2. Potwierdź, że kod rozszerzony to dokładnie 5.4.0, a podstawowa odpowiedź to 554, i zwróć uwagę, że odrzucenie wraca na końcu fazy DATA — po przesłaniu całej treści wiadomości, a nie przy RCPT TO.
3. Sprawdź własną konfigurację przekierowań odbiorcy — reguły automatycznego przekierowania w poczcie webowej, przynależność do list mailingowych albo łańcuchy aliasów — pod kątem reguły, która odsyła wiadomość z powrotem w stronę nadawcy albo wielokrotnie przez ten sam przekaźnik.
4. Jeśli między nadawcą a odbiorcą znajduje się firmowy przekaźnik, smart host albo bramka, sprawdź jej tabelę routingu pod kątem trasy odwołującej się do samej siebie albo tworzącej cykl, i popraw ją, zanim poprosisz nadawcę o ponowną wysyłkę.