5.5.2SMTP 5.5.2: Błąd składni polecenia protokołu

Gdy host odbierający odrzuca polecenie transakcji pocztowej jako niemożliwe do zinterpretowania, wzorzec rejestru X.5.2 występuje jako kod 5.5.2: składnia wiersza jest nieprawidłowa albo komenda nie jest rozpoznawana przez ten system. Klasa trwała 5 jest tym, co rejestr rozszerzonych statusów zapisuje dla tej próby. Szczegół statusu nie podaje dokładnego wiersza polecenia, nie rozróżnia błędu składni od nieobsługiwanego czasownika ani nie wskazuje, po której stronie leży błąd. Zawężenie przyczyny wymaga pełnej odpowiedzi SMTP oraz śladu transakcji poprzedzającego odrzucone polecenie. Przykłady zaakceptowane dla tej strony pochodzą z dokumentacji dwóch produktów i pokazują, jakim językiem oba nazywają ten warunek.

Polecenie protokołu transakcji pocztowej, którego nie można było zinterpretować z powodu błędnej składni lub nierozpoznanego polecenia, to X.5.2. Opis w rejestrze wskazuje, że ten szczegół jest użyteczny wyłącznie jako błąd trwały, a konkretny wariant 5.5.2 ma odpowiadającą mu klasę 5.

Wiodąca cyfra 5 oznacza trwałe niepowodzenie tej wiadomości w bieżącym kontekście. Sam kod nie wskazuje ani dokładnego polecenia, ani jego błędnej części, nie rozstrzyga, czy przyczyną była nieprawidłowa składnia, nierozpoznane polecenie, czy dane, których system nie umiał zdekodować, i nie ustala, po której stronie jest problem. Podstawowa odpowiedź zawęża gałąź wyłącznie jako poszlaka: w RFC 5248 powiązanie z podstawowym kodem statusu jest niewyłączne, a zaakceptowane przykłady 5.5.2 rozkładają się na 501, 504, 554 i 555.

Klasa

Niepowodzenie trwałe

Ponowienie

Nie ponawiaj bez zmian

Supresja

Sprawdź pełny kontekst

Zalecenie operacyjne: zatrzymaj automatyczne i ręczne ponawianie tego samego polecenia w niezmienionym kontekście, bo system, który nie zdołał zinterpretować danych wejściowych, nie zinterpretuje tych samych danych przy kolejnej próbie. Warunkiem odblokowania jest wykazana zmiana w tym, co wysyła klient, albo w tym, jak obsługuje to system odbierający: poprawiona składnia, zastąpione polecenie, poprawiona postać adresu albo zmieniony parser po stronie odbierającej. Wysyłka do innego celu jest osobną trasą i osobną wymianą, nie powtórzeniem tej próby; policz ją jako pierwszą próbę i nadaj jej klucz idempotencji, aby żaden odbiorca nie dostał wiadomości dwukrotnie.

Zalecenie operacyjne: 5.5.2 nie jest podstawą do dodania adresu na listę wykluczeń. Kod mówi, że jakiś system nie zdołał zinterpretować fragmentu wymiany, i nie ocenia skrzynki stojącej za adresem: nie rozstrzyga, czy skrzynka istnieje, czy jest pełna, czy została wyłączona ani czy odmawia przyjmowania poczty. Jeden z zaakceptowanych przykładów odrzuca wręcz adres nadawcy z powodu jego postaci, a więc w ogóle nie ocenia odbiorcy. Wykluczenie wymaga osobnego sygnału o samej skrzynce, wziętego z właściwej polityki wraz z pełną odpowiedzią i historią zdarzeń zapisaną dla tego adresu.

• Wiersz polecenia transakcji pocztowej był zniekształcony i system odbierający nie zdołał go zinterpretować. Dokumentacja komunikatów błędów SMTP dla Gmaila zgłasza to z podstawową odpowiedzią 555 jako „555 5.5.2 Syntax error.” oraz „555 5.5.2 Syntax error, goodbye.”
• System odbierający nie zdołał zdekodować odpowiedzi, którą otrzymał w trakcie wymiany. To awaria odpowiedzi wewnątrz sesji, a nie czasownika polecenia, i formatowanie poleceń po stronie klienta może być całkowicie poprawne. Dokumentacja Gmaila zgłasza to z podstawową odpowiedzią 501 jako „501 5.5.2 Syntax error, cannot decode response.”
• Adres podany przez klienta nie miał postaci przyjmowanej przez system odbierający — na przykład adres nadawcy bez w pełni kwalifikowanej domeny. Dokumentacja typowych odbić Rackspace zgłasza to z podstawową odpowiedzią 504 jako „504 5.5.2 <user@nonqualifieddomain>: Sender address rejected: need fully-qualified address”; token w nawiasach ostrokątnych jest w tej dokumentacji zaślepką, którą serwer wypełnia odrzuconym adresem w chwili odrzucenia.

1. Potwierdź na surowej odpowiedzi SMTP albo raporcie dostarczenia, że rozszerzony kod to dokładnie 5.5.2, i zanotuj, która podstawowa odpowiedź go przyniosła. Zaakceptowane przykłady niosą go na 501, 504, 554 i 555 — rozrzut na tyle szeroki, że sama podstawowa odpowiedź niczego nie rozstrzyga, skoro RFC 5248 uznaje to powiązanie za niewyłączne.
2. Powiąż odpowiedź z zamierzoną wiadomością, czasem próby, systemem, który zwrócił kod, oraz dokładnym poleceniem; zachowaj też poprzedzający ślad transakcji.
3. Zamiast wybierać między składnią błędną a poleceniem nierozpoznanym, rozdziel warunki opisane przez zaakceptowane odpowiedzi: wiersz polecenia, którego system odbierający nie zdołał sparsować; odpowiedź wewnątrz wymiany, której nie umiał zdekodować, a która wcale nie jest awarią polecenia; oraz przekazany mu adres w postaci, której nie przyjmuje, na przykład adres nadawcy bez w pełni kwalifikowanej domeny. Niektóre systemy zwracają 5.5.2 także dla treści wiadomości, której nie zdołały sparsować. Nie przypisuj wady klientowi ani serwerowi, dopóki ślad i pełny tekst odpowiedzi tego nie potwierdzą.
4. Zatrzymaj ponawianie bez zmian; przed nową wysyłką potwierdź istotną korektę albo zmianę obsługi po stronie systemu odbierającego i ponownie sprawdź stan wykluczenia.