4.4.0Tymczasowa awaria z nieokreślonej przyczyny sieciowej lub routingowej (inny/nieokreślony status sieci)

W klasie przedmiotowej X.4 (Network and Routing Status) RFC 3463 definiuje X.4.0 jako ogólny wpis „inny lub nieokreślony” dla stanów sieciowych, które nie pasują do żadnego innego kodu szczegółowego tej klasy; kod 4.4.0 przypisuje ten wzorzec rejestru do klasy tymczasowej. Odwzorowanie rejestru IANA w tym katalogu oznacza X.4.0 jako całkowicie nierozstrzygnięty: żadna klasa, ani 4, ani 5, nigdy nie dostała potwierdzonego wpisu rejestrowego dla tego wzorca (lista concreteCodes jest pusta). To luka dowodowa silniejsza niż samo niepotwierdzenie jednej klasy. Istnienie i znaczenie tego konkretnego kodu opierają się wyłącznie na dokładnym dowodzie produkcyjnym zebranym w korpusie (odpowiedzi Outlooka i Rackspace poniżej), a nie na potwierdzeniu z rejestru IANA. Status opisuje ogólny, nieokreślony tymczasowy stan warstwy sieci lub routingu w tej próbie, a nie jeden z bardziej szczegółowych stanów tej rodziny ani błąd skrzynki czy adresowania.

X.4.0 to własny wpis „inny lub nieokreślony” klasy przedmiotowej X.4 „Network and Routing Status”. RFC 3463, sekcja 3.4, definiuje tę klasę (X.4.0–X.4.7) dla niepowodzeń związanych z drogą sieciową lub routingiem wiadomości, a nie ze skrzynką czy samym adresem, i rezerwuje X.4.0 dla stanów sieciowych lub routingowych, które nie pasują do żadnego z bardziej szczegółowych kodów (X.4.1 brak odpowiedzi od hosta, X.4.2 nieprawidłowe połączenie, X.4.3 awaria serwera katalogowego, X.4.4 nie można wyznaczyć trasy, X.4.5 przeciążenie systemu pocztowego, X.4.6 wykryto pętlę routingu, X.4.7 upłynął czas doręczenia). Jako jawny kod zbiorczy RFC 3463 nie wiąże X.4.0 z jednym konkretnym stanem produkcyjnym, a odwzorowanie rejestru IANA w tym katalogu nie potwierdza dla tego wzorca żadnej klasy. Konkretny kod 4.4.0 (klasa 4) publikujemy tu na podstawie dokładnego dowodu korpusowego obejmującego dwa strukturalnie różne, rzeczywiste stany pod tymi samymi cyframi kodu zbiorczego: awarię replikacji wiadomości w zapleczu Outlooka między serwerami zapasowymi skrzynek oraz tymczasową awarię wyszukiwania DNS dla polityki DMARC u Rackspace, a nie na potwierdzeniu z rejestru IANA dla tej klasy.

Pierwsza cyfra 4 oznacza uporczywe niepowodzenie przejściowe: w chwili tej próby jakiś warunek na poziomie sieci lub routingu zablokował dostarczenie, ale może on ustąpić, gdy podstawowy stan się wyjaśni — serwer zapasowy ponownie stanie się dostępny albo wyszukiwanie DNS powiedzie się przy kolejnej próbie. Nie myl odpowiedzi 4.4.0 z bardziej szczegółowymi kodami tej rodziny (4.4.1 brak odpowiedzi od hosta, 4.4.5 przeciążenie systemu pocztowego i inne): jeśli odpowiedź niesie zamiast tego jeden z tamtych kodów, kieruj się jego bardziej szczegółowymi wskazówkami zamiast tych ogólnych.

Klasa

Niepowodzenie tymczasowe

Ponowienie

Kontrolowane ponowienie

Supresja

Sprawdź pełny kontekst

Ponawiaj wysyłkę z backoffem, losowym rozproszeniem i limitem prób lub czasu. Zakończ ponawianie po sukcesie, po otrzymaniu kodu trwałego albo po wyczerpaniu limitu; nie traktuj pojedynczego 4.4.0 jako podstawy, by natychmiast przerwać ponawianie, ponieważ oba zaakceptowane przykłady opisują warunki (replikacja w zapleczu, wyszukiwanie DNS), które zwykle ustępują same.

Nie dodawaj adresu do listy wykluczeń wyłącznie na podstawie kodu 4.4.0. Dowody zebrane w tym katalogu dla tego kodu wskazują na warunki infrastrukturalne lub związane z DNS po stronie odbiorcy, niezwiązane z ważnością adresu odbiorcy; sprawdź pełną odpowiedź i dokumentację dostawcy, a wyklucz adres dopiero po niezależnym sygnale trwałym albo gdy uzasadnia to obowiązująca polityka listy.

• W zaakceptowanym przykładzie Outlooka zawiódł własny, wewnętrzny krok replikacji po stronie systemu odbiorcy: w chwili próby nie był dostępny żaden zdrowy serwer zapasowy, który mógłby przyjąć replikę wiadomości — to warunek dostępności infrastruktury skrzynek dostawcy, nie problem adresu czy skrzynki.
• W zaakceptowanym przykładzie Rackspace tymczasowa awaria wyszukiwania w DNS polityki DMARC nadawcy spowodowała odrzucenie; ponowienie po tym, jak wyszukiwanie DNS się powiedzie, zwykle usuwa ten warunek.
• Ponieważ wzorzec rejestru jest jawnym kodem zbiorczym, dostawcy ponownie wykorzystują te same cyfry 4.4.0 dla strukturalnie różnych warunków na poziomie sieci lub routingu; same cyfry nie wskazują, który z nich wystąpił — przeczytaj towarzyszący tekst odpowiedzi.

1. Sprawdź surową odpowiedź SMTP i potwierdź, że kod rozszerzony to dokładnie 4.4.0, a podstawowa odpowiedź należy do klasy 4xx (451 w zaakceptowanym przykładzie Outlooka, 450 w zaakceptowanym przykładzie Rackspace).
2. Zidentyfikuj, który dostawca zwrócił odpowiedź, i uważnie przeczytaj jego własny tekst opisu: rzeczywista przyczyna różni się między dostawcami dzielącymi te same cyfry 4.4.0 (awaria replikacji w zapleczu u Outlooka, awaria wyszukiwania DNS u Rackspace).
3. Powiąż odpowiedź z konkretną wiadomością, czasem próby i domeną odbiorcy; zachowaj pełny tekst odpowiedzi, w tym ewentualną domenę w nawiasie albo wewnętrzny kod dostawcy (u Outlooka „[outlook.com]”, u Rackspace „(G1E)”).
4. Ponawiaj w sposób ograniczony, z backoffem, i zakończ po sukcesie, po otrzymaniu kodu trwałego albo po osiągnięciu limitu prób; jeśli stan utrzymuje się znacznie dłużej niż rozsądne okno, eskaluj sprawę kanałem postmaster dostawcy odbierającego.