5.5.1SMTP 5.5.1: Nieprawidłowe polecenie protokołu

Polecenia transakcji pocztowej wydane poza kolejnością w bieżącym stanie albo nieobsługiwane przez drugą stronę trafiają pod wzorzec rejestru X.5.1 jako kod 5.5.1. Rozszerzony status umieszcza tę próbę w trwałej klasie 5. Sam status nie pokazuje, które polecenie zawiodło, czy chodziło o kolejność czy brak obsługi, ani po której stronie leży wada. Zanim przypiszesz przyczynę, przeanalizuj przebieg transakcji i zadeklarowane możliwości systemu. Zaakceptowane przykłady na tej stronie pochodzą w całości z dokumentacji jednego produktu i pokazują, jak ten produkt opisuje ten warunek.

Polecenia protokołu transakcji pocztowej wydane poza kolejnością albo nieobsługiwane są objęte wzorcem X.5.1. Opis rejestrowy wskazuje, że ten szczegół jest użyteczny tylko jako błąd trwały, a konkretny wariant 5.5.1 ma zgodną z tym klasę 5.

Pierwsza cyfra 5 oznacza trwałe niepowodzenie dla tej wiadomości w bieżącym kontekście. Sam kod nie rozstrzyga, czy polecenie było poza kolejnością, czy nieobsługiwane, ani po której stronie leży wada implementacji lub konfiguracji. Podstawowa odpowiedź, z którą kod przychodzi, wskazuje gałąź, ale jej nie dowodzi: RFC 5248 odnotowuje powiązany podstawowy kod statusu jako niewyłączny, a zaakceptowane przykłady dla 5.5.1 przychodzą z 502 i z 503.

Klasa

Niepowodzenie trwałe

Ponowienie

Nie ponawiaj bez zmian

Supresja

Sprawdź pełny kontekst

Zalecenie operacyjne: wstrzymaj automatyczne i ręczne ponowienia, dopóki nie zmieni się klient, warstwa pośrednia i kształt transakcji, ponieważ to samo polecenie wysłane w tym samym miejscu tej samej wymiany kończy się tą samą trwałą odmową. Warunkiem odblokowania jest wykazana zmiana w wymianie protokołu: poprawiona kolejność, usunięte nieobsługiwane polecenie albo zmieniony zestaw poleceń obsługiwanych przez system odbierający. Wysyłka na inny adres docelowy to nowa trasa i nowe uzgodnienie możliwości, a nie ponowienie tej próby; potraktuj ją jak pierwszą próbę i zastosuj idempotencję, żeby wiadomość nie została doręczona dwa razy.

Zalecenie operacyjne: nie dodawaj adresu do listy wykluczeń na podstawie 5.5.1. Kod opisuje stan wymiany protokołu między dwoma systemami i nie ocenia niczego w adresie odbiorcy: nie stwierdza, że skrzynka nie istnieje, jest pełna, wyłączona albo odmawia przyjmowania poczty, a ta sama odmowa spotkałaby w tej transakcji dowolnego odbiorcę. Wykluczaj wyłącznie na podstawie dowodu dotyczącego samej skrzynki, odczytanego z pełnej odpowiedzi, szerszej historii zdarzeń dla tego adresu i właściwej polityki.

• Polecenie transakcji pocztowej zostało wydane poza kolejnością właściwą dla bieżącego stanu transakcji, na przykład RCPT TO przed MAIL FROM albo DATA, zanim przyjęto jakiegokolwiek odbiorcę. Dokumentacja komunikatów błędów SMTP dla Gmaila opisuje tę gałąź jako „503 5.5.1 Bad sequence of commands.”
• Czasownik wysłany przez klienta nie jest zaimplementowany albo nie jest rozpoznawany przez system odbierający, więc zostaje odrzucony niezależnie od miejsca, w którym się pojawi, a nie tylko na jednym etapie transakcji. Dokumentacja Gmaila opisuje tę gałąź jako „502 5.5.1 Unimplemented command.” oraz „502 5.5.1 Unrecognized command.”, a dla powtarzających się nierozpoznanych poleceń w jednej sesji ma osobny wiersz: „502 5.5.1 Too many unrecognized commands, goodbye.”
• Klient pomieszał dwa wykluczające się sposoby przekazywania treści wiadomości i wydał DATA w transakcji, która wysyłała już porcje przez BDAT. Dokumentacja Gmaila opisuje tę gałąź jako „503 5.5.1 No DATA after BDAT. An email transaction protocol command was issued out of sequence.” i odsyła do RFC 3030, specyfikacji rozszerzenia CHUNKING, które definiuje BDAT i które serwer deklaruje w odpowiedzi na EHLO.

1. Sprawdź surową odpowiedź SMTP lub raport doręczenia i potwierdź, że kod rozszerzony to dokładnie 5.5.1, a następnie zanotuj podstawową odpowiedź, która go przyniosła. Zaakceptowane przykłady tego kodu przychodzą z 502 i z 503, a RFC 5248 traktuje przypisanie podstawowego kodu statusu jako niewyłączne, więc podstawowa odpowiedź zawęża gałąź, ale jej nie przesądza.
2. Ustal, który system odpowiedział, i skompletuj materiał dowodowy: czas próby, identyfikator wiadomości, dokładny wiersz polecenia wysłany przez klienta, przebieg transakcji od powitania oraz odpowiedź serwera na EHLO wraz z zadeklarowaną w niej listą możliwości.
3. Rozdziel gałęzie na podstawie tego materiału. Porównaj odrzucony czasownik z podstawowym zestawem poleceń RFC 5321 oraz z rozszerzeniami zadeklarowanymi przez serwer w odpowiedzi na EHLO, a potem zanotuj, w którym miejscu transakcji został wysłany. Kryterium jest takie: czasownik, którego nie ma ani w podstawowym zestawie poleceń, ani wśród zadeklarowanych możliwości, i który system odrzuca niezależnie od miejsca wysłania, to polecenie nieobsługiwane; czasownik podstawowy albo zadeklarowany, który ten sam system przyjmuje w innym punkcie sesji, jest obsługiwany, lecz wydany poza kolejnością właściwą dla stanu, w jakim go wysłano. DATA wydane w transakcji, która używała już BDAT, należy do gałęzi kolejności, choć oba czasowniki są obsługiwane.
4. Zatrzymaj niezmienione ponowienia. Nową wysyłkę dopuszcza jeden warunek: klient nie wydaje już tego polecenia w tym miejscu transakcji — bo kolejność została poprawiona, bo nieobsługiwane polecenie zostało usunięte albo bo transakcja używa teraz jednej metody przekazywania treści. Przed tą wysyłką ponownie sprawdź stan wykluczenia.