Lista kodów zwrotnych serwera SMTP

To jest lista kodów stanu odpowiedzi SMTP ( Simple Mail Transfer Protocol ). Kody stanu są wydawane przez serwer w odpowiedzi na żądanie klienta skierowane do serwera.

  O ile nie określono inaczej, wszystkie opisane tutaj kody stanu są częścią bieżącego standardu SMTP RFC 5321 . Przedstawione frazy komunikatu są typowe, ale można podać dowolną alternatywę czytelną dla człowieka.

Podstawowy kod stanu

Odpowiedź SMTP „Podstawowy kod statusu” składa się z trzycyfrowego numeru (przesyłanego jako trzy znaki numeryczne), po którym następuje tekst. Liczba jest używana przez automaty (np. klientów poczty e-mail) w celu określenia, w jaki stan wejść jako następny; tekst („Część tekstowa”) jest przeznaczony dla użytkownika.

Pierwsza cyfra oznacza, czy odpowiedź jest dobra, zła czy niepełna:

  • 2yz (Pozytywna odpowiedź dotycząca zakończenia): Żądana akcja została pomyślnie zakończona.
  • 3yz (Pozytywna odpowiedź pośrednia): Polecenie zostało przyjęte, ale żądane działanie zostało wstrzymane do czasu otrzymania dalszych informacji.
  • 4yz (przejściowa negatywna odpowiedź na zakończenie): Polecenie nie zostało zaakceptowane, a żądane działanie nie zostało wykonane. Jednak stan błędu jest tymczasowy i może zostać ponownie zażądana akcja.
  • 5yz (trwała negatywna odpowiedź na zakończenie): Polecenie nie zostało zaakceptowane, a żądana akcja nie została wykonana. Klient SMTP NIE POWINIEN powtarzać dokładnego żądania (w tej samej kolejności).

Druga cyfra koduje odpowiedzi w określonych kategoriach:

  • x0z (Składnia): Te odpowiedzi odnoszą się do błędów składniowych, poprawnych składniowo poleceń, które nie pasują do żadnej kategorii funkcjonalnej, oraz niezaimplementowanych lub zbędnych poleceń.
  • x1z (Informacje): Są to odpowiedzi na prośby o informacje.
  • x2z (Połączenia): Są to odpowiedzi odnoszące się do kanału transmisji.
  • x3z : Nieokreślony.
  • x4z : Nieokreślony.
  • x5z (system poczty): Te odpowiedzi wskazują stan systemu poczty odbiorcy.

Ulepszony kod stanu

   Podstawowe kody statusu były w SMTP od samego początku, wraz z RFC 821 w 1982 r., ale zostały rozszerzone dość obszernie i przypadkowo, tak że do 2003 r. RFC 3463 raczej zrzędliwie zauważył, że: „ SMTP nosi pewne blizny z historii, w szczególności niefortunne szkody do mechanizmu rozszerzenia kodu odpowiedzi poprzez niekontrolowane użycie ” .

  RFC 3463 definiuje oddzielną serię ulepszonych kodów stanu systemu poczty, która ma mieć lepszą strukturę i składa się z trzech pól numerycznych oddzielonych znakiem „.”, jak następuje: 

klasa "." temat "." klasa szczegółowa = „2” / „4” / „5” temat = od 1 do 3 cyfr szczegół = od 1 do 3 cyfr

Klasy są zdefiniowane w następujący sposób :

  • 2.XXX.XXX Sukces: Raport pozytywnej akcji dostawy.
  • 4.XXX.XXX Trwała przejściowa awaria: Wiadomość w takiej postaci, w jakiej została wysłana, jest ważna, ale utrzymywanie się pewnych tymczasowych warunków spowodowało porzucenie lub opóźnienie.
  • 5.XXX.XXX Trwała awaria: prawdopodobnie nie zostanie rozwiązana przez ponowne wysłanie wiadomości w obecnej formie.

Zasadniczo identyfikator klasy MUSI być zgodny z pierwszą cyfrą podstawowego kodu statusu, do którego się odnosi.

Przedmioty definiuje się w następujący sposób :

  • X.0.XXX Inny lub nieokreślony status
  • X.1.XXX Stan adresowania
  • X.2.XXX Stan skrzynki pocztowej
  • X.3.XXX Status systemu pocztowego
  • X.4.XXX Stan sieci i routingu
  • Stan protokołu dostarczania poczty X.5.XXX
  • X.6.XXX Treść wiadomości lub stan nośnika
  • X.7.XXX Stan zabezpieczeń lub polityki

  Znaczenie pola „szczegóły” zależy od klasy i przedmiotu i jest wymienione w dokumentach RFC 3463 i RFC 5248 .

Serwer, który może odpowiedzieć za pomocą Rozszerzonego kodu stanu MUSI poprzedzić (wstawić) część tekstową odpowiedzi Serwera SMTP za pomocą Rozszerzonego kodu stanu, po którym następuje jedna lub więcej spacji. Na przykład odpowiedź „221 Bye” (po poleceniu QUIT) MUSI zostać wysłana jako „221 2.0.0 Bye”.

Internet Assigned Numbers Authority (IANA) prowadzi oficjalny rejestr tych ulepszonych kodów statusu.

Typowe kody statusu

W tej sekcji wymieniono niektóre z najczęściej spotykanych kodów stanu SMTP. Ta lista nie jest wyczerpująca, a rzeczywista wiadomość tekstowa (poza 3-polowym rozszerzonym kodem stanu) może być inna.

— 2yz Pozytywne zakończenie

211 Stan systemu lub odpowiedź pomocy systemu
214 Komunikat pomocy (odpowiedź na polecenie HELP)
220 <domena> Usługa gotowa
221 <domena> Usługa zamyka kanał transmisji
221 2.0.0 Do widzenia
235 2.7.0 Uwierzytelnienie zakończone pomyślnie
240 WYJDŹ
250 Żądana akcja pocztowa OK, zakończone
251 Użytkownik nie jest lokalny; przekaże dalej
252 Nie można zweryfikować użytkownika, ale mimo to spróbuje dostarczyć wiadomość

— 3yz Pozytywny średniozaawansowany

334 (Wyzwanie serwera — część tekstowa zawiera wyzwanie zakodowane w standardzie Base64)
354 Rozpocznij wprowadzanie poczty

— 4yz Przejściowe zakończenie negatywne

„Przejściowa ujemna” oznacza, że ​​stan błędu jest tymczasowy i można ponownie zażądać działania. Nadawca powinien powrócić do początku sekwencji poleceń (jeśli istnieje).

Dokładne znaczenie słowa „przejściowy” musi zostać uzgodnione między dwiema różnymi witrynami (odbiorca i nadawca agentów SMTP) muszą uzgodnić interpretację. Każda odpowiedź w tej kategorii może mieć inną wartość czasu, ale klient SMTP POWINIEN spróbować ponownie.

421 Usługa niedostępna, zamykanie kanału transmisji (Może to być odpowiedź na dowolne polecenie, jeśli usługa wie, że musi zostać wyłączona)
432 4.7.12 Konieczna zmiana hasła
450 Żądana akcja pocztowa nie została wykonana: skrzynka pocztowa niedostępna (np. skrzynka pocztowa zajęta lub tymczasowo zablokowane z powodów zasad)
451 Żądane działanie przerwane: lokalny błąd przetwarzania
451 4.4.1 Serwer IMAP niedostępny
452 Żądane działanie nie zostało wykonane: niewystarczająca pamięć systemowa
454 4.7.0 Tymczasowy błąd uwierzytelnienia
455 Serwer nie może pomieścić parametrów

— 5yz Trwałe negatywne uzupełnienie

Klient SMTP NIE POWINIEN powtarzać dokładnego żądania (w tej samej kolejności). Nawet niektóre „stałe” warunki błędów można poprawić, więc użytkownik może chcieć nakazać klientowi SMTP ponowne zainicjowanie sekwencji poleceń przez bezpośrednie działanie w pewnym momencie w przyszłości.

500 Błąd składni, polecenie nierozpoznane (Może to obejmować błędy, takie jak zbyt długa linia poleceń)
500 5.5.6 Uwierzytelnianie Linia wymiany jest za długa
501 Błąd składni parametrów lub argumentów
501 5.5.2 Nie można zdekodować Base64 Odpowiedzi klienta
501 5.7.0 Klient zainicjowana wymiana uwierzytelnienia (tylko gdy mechanizm SASL określił, że klient nie rozpoczyna wymiany uwierzytelnienia)
502 Komenda nie zaimplementowana
503 Zła sekwencja komend
504 Parametr komendy nie jest zaimplementowany
504 5.5.4 Nierozpoznany typ uwierzytelniania
521 Serwer nie przyjmuje poczty
523 Wymagane szyfrowanie
530 5.7.0 Wymagane uwierzytelnianie
534 5.7.9 Mechanizm uwierzytelniania jest za słaby
535 5.7.8 Nieprawidłowe dane uwierzytelniające
538 5.7.11 Wymagane szyfrowanie dla żądanego mechanizmu uwierzytelniania
550 Żądane akcja nie została podjęta: skrzynka pocztowa jest niedostępna (np. skrzynka pocztowa nie została znaleziona, brak dostępu lub polecenie odrzucone z powodu polityki)
551 Użytkownik nie jest lokalny; spróbuj <forward-path>
552 Żądana czynność e-mail została przerwana: przekroczono przydział pamięci
553 Żądana czynność nie została podjęta: nazwa skrzynki pocztowej jest niedozwolona
554 Transakcja nie powiodła się (lub w przypadku odpowiedzi otwarcia połączenia „Brak usługi SMTP”)
554 5.3.4 Wiadomość za duża dla system
556 Domena nie przyjmuje poczty

Przykład

Poniżej znajduje się przykładowe połączenie SMTP, w którym klient „C” wysyła do serwera „S”:

 S: 220 smtp.example.com ESMTP Postfix  C: HELO relay.example.com  S: 250 smtp.example.com, miło mi cię poznać  C: MAIL FROM:<[email protected]>  S: 250 OK  C : RCPT TO:<[email protected]>  S: 250 OK  C: RCPT TO:<[email protected]>  S: 250 OK  C: DATA  S: 354 Zakończ dane za pomocą <CR><LF>.<CR> <LF>  C: Od: „Przykład Boba” <[email protected]> C: Do: Alicja Przykład <[email protected]> C: DW: [email protected] C: Data: Wt, 15 stycznia 2008 r., 16:02: 43 -0500 C: Temat: Wiadomość testowa C: C: Witaj Alicjo. C: To jest wiadomość testowa z 5 polami nagłówka i 4 wierszami w treści wiadomości.  C: Twój przyjaciel, C: Bob C: .   S: 250 Ok: w kolejce jako 12345  C: WYJDŹ  S: 221 Pa  {Serwer zamyka połączenie}

  Poniżej znajduje się przykład połączenia SMTP, w którym serwer SMTP obsługuje rozszerzony kod stanu, zaczerpnięty z dokumentu RFC 2034 : 

 S: 220 dbc.mtview.ca.us Usługa SMTP gotowa  C: EHLO ymir.claremont.edu  S: 250-dbc.mtview.ca.us wita  S: 250 ROZSZERZONE KODY  STATUSU C: POCZTA OD:<[email protected]. edu>  S: 250 2.1.0 Nadawca <[email protected]> ok  C: RCPT TO:<[email protected]>  S: 250 2.1.5 Odbiorca <[email protected] .us> ok  C: RCPT TO:<[email protected]>  S: 550 5.1.1 Skrzynka pocztowa "nosuchuser" nie istnieje  C: RCPT TO:<[email protected]>  S: 551-5.7 .1 Przekazywanie do zdalnych hostów wyłączone 
 S: 551 5.7.1 Wybierz innego hosta, który będzie pełnił funkcję przekierowania  C: DATA  S: 354 Wyślij wiadomość, kończącą się na CRLF.CRLF.  ... C: .  S: 250 2.6.0 Wiadomość przyjęta  C: WYJDŹ  S: 221 2.0.0 Do widzenia  {Serwer zamyka połączenie}

Pobrano z „ https://en.wikipedia.org/w/index.php?title=List_of_SMTP_server_return_codes&oldid=1124136793 ”