4.3.0SMTP 4.3.0: Nieokreślony tymczasowy status systemu pocztowego

X.3.0 to status systemu pocztowego oznaczający inny lub nieokreślony warunek; 4.3.0 nadaje mu klasę tymczasową i obejmuje warunki systemu docelowego, których nie opisuje żaden dokładniejszy status w tej klasie.

Docelowy system zwykle istnieje, lecz nienazwany warunek systemowy wygenerował ten status dostarczenia. X.3.0 jest wpisem zbiorczym klasy systemu pocztowego, więc sam nie niesie żadnego szczegółu i nie zastępuje dokładniejszego statusu X.3, jeśli system docelowy ma taki do zwrócenia. Zaakceptowane odpowiedzi zapisane pod 4.3.0 sięgają od ogólnego tymczasowego problemu systemowego, przez tymczasowe niepowodzenie odpytania, które system docelowy wykonuje, po limit nałożony przez ten system na ruch wysyłkowy albo na kształt transakcji.

Klasa 4 oznacza, że warunek może ustąpić; nie dowodzi trwałej awarii ani nieprawidłowego adresu. RFC 2034 wymaga zgodności klasy statusu rozszerzonego z klasą odpowiedzi SMTP, a RFC 5248 zapisuje powiązany podstawowy kod odpowiedzi jako niewyłączny, dlatego zaakceptowane przykłady 4.3.0 występują raz po odpowiedzi 451, a raz po 421, bez zmiany znaczenia samego statusu rozszerzonego. Zmienia się natomiast stan sesji: 421 to odpowiedź zwracana wtedy, gdy system zamyka kanał transmisyjny, a 451 odrzuca wewnątrz sesji, która pozostaje otwarta, więc ten sam status dociera do nadawcy przy dwóch różnych stanach połączenia.

Klasa

Niepowodzenie tymczasowe

Ponowienie

Kontrolowane ponowienie

Supresja

Sprawdź pełny kontekst

Ustaw ograniczone ponowienia z backoffem, jitterem, kluczami idempotencji oraz limitem prób lub czasu i grupuj próby po systemie docelowym, adresie IP połączenia i czasie, aby warunek jednego systemu nie sterował niepowiązanymi trasami. Przy każdej próbie zapisuj, która odpowiedź podstawowa niosła ten status, bo obie zostawiają połączenie w innym stanie: 421 zamyka kanał transmisyjny, więc nic więcej nie zostaje na nim zaproponowane, a kolejna próba musi otworzyć nowe połączenie, natomiast 451 odrzuca wewnątrz sesji, która pozostaje otwarta, więc pozostałych odbiorców i pozostałe wiadomości można w niej jeszcze zaproponować. Próby trwają tylko dopóki ten cel zwraca klasę tymczasową i limit nie jest wyczerpany; wyczerpanie limitu kończy ponawianie i uruchamia eskalację, a nie nowy cykl ponowień. Jeśli treść odpowiedzi nazwała warunek po stronie nadawcy, popraw ten warunek przed kolejną próbą, bo niezmieniona transakcja odtwarza ten sam wynik. Inny system docelowy to nowa trasa, a nie ciąg dalszy tej sekwencji.

Nie wykluczaj na podstawie samego 4.3.0. Kod opisuje warunek systemu pocztowego i nie ocenia, czy adres odbiorcy istnieje, czy jest poprawnie zapisany, ani czy przyjmuje pocztę, a zaakceptowane przykłady przypisują te same cyfry systemowi docelowemu, odpytaniu, od którego on zależy, oraz ruchowi samego serwera wysyłającego. Wykluczaj wyłącznie na niezależnym trwałym dowodzie albo na udokumentowanej polityce zastosowanej po przejrzeniu pełnej historii odpowiedzi.

• Ogólny tymczasowy warunek wewnątrz docelowego systemu pocztowego, którego serwer nie nazywa. Tabela błędów SMTP Google dokumentuje odpowiedź 421 zaczynającą się od „Temporary System Problem. Try again later.” oraz odpowiedź 451 zaczynającą się od „Email server has temporarily rejected this message.”, obie kontynuowane odsyłaczem do dokumentacji Google i znacznikiem gsmtp.
• Tymczasowe niepowodzenie odpytania, które system docelowy wykonuje, zanim może przyjąć wiadomość. Dokumentacja odbić hostowanej poczty Rackspace wymienia wiersz 451 4.3.0 o treści „Temporary lookup failure”, poprzedzony tokenem adresu w nawiasach ostrych, który serwer wypełnia w momencie odrzucenia.
• Limit nałożony przez system docelowy na ruch albo na transakcję, a nie na odbiorcę. Rackspace dokumentuje wiersz 451 4.3.0 o treści „Client host rejected: Throttled - Too much spam from your mail server. Try again later.”, poprzedzony tokenem serwera i adresu wypełnianym w momencie odrzucenia, a Google dokumentuje wiersz 451 4.3.0 zaczynający się od „Multiple destination domains per transaction is unsupported. Please try again.” z odwołaniem do RFC 5321.

1. Potwierdź, że odpowiedź niesie dokładnie rozszerzony status 4.3.0, i zapisz, z którą podstawową odpowiedzią wystąpiła. Zaakceptowane przykłady łączą go z 451 i z 421, a RFC 5248 zapisuje powiązany podstawowy kod odpowiedzi jako niewyłączny, więc sama podstawowa odpowiedź nie identyfikuje warunku. Rozstrzyga natomiast, jak skończyła się sesja, i po to się ją zapisuje: 421 zamknęło kanał transmisyjny, a 451 nie.
2. Ustal, który system zwrócił ten status, i zachowaj komplet dowodów: surowy wiersz odpowiedzi, etap SMTP, system docelowy, adres IP połączenia, identyfikator wiadomości i znacznik czasu. Porównaj logi nadawcy i systemu docelowego tam, gdzie dostępne są oba.
3. Przeczytaj pełną treść odpowiedzi, aby rozdzielić możliwe przyczyny, bo same cyfry są ogólne. Sformułowanie o tymczasowym problemie systemowym lub tymczasowym odrzuceniu wskazuje na system docelowy, sformułowanie o niepowodzeniu odpytania wskazuje na zależność, którą ten system odpytuje, a sformułowanie o ograniczeniu ruchu lub o nieobsługiwanej transakcji wskazuje na ruch wysyłkowy albo na kształt transakcji.
4. Zanim wyślesz kolejną próbę, nazwij warunek, który ją dopuszcza: cel nadal zwraca klasę tymczasową, ustalony limit nie jest wyczerpany, a warunek po stronie nadawcy nazwany w odpowiedzi został poprawiony.