W skrócie
Trwała odmowa AUTH: wybrany mechanizm wolno używać tylko przez szyfrowane połączenie SMTP. Najpierw ustanów połączenie TLS, potem ponów AUTH. To problem konfiguracji transportu, który blokuje wysyłkę i może pośrednio obniżyć dostarczalność. Nie ponawiaj niezmienionej próby.
Co oznacza ten kod
Historyczna odpowiedź AUTH ze wzorca rejestru X.7.11 wraca w klasie 5 jako kod 5.7.11: wybrany mechanizm wolno stosować tylko wtedy, gdy bazowa sesja SMTP ma już wystarczająco silną warstwę szyfrowania. We współczesnej praktyce serwer nie powinien reklamować takiego mechanizmu bez aktywnej ochrony. Klasa 5 oznacza trwałą odmowę dla tego stanu połączenia. Rozszerzony kod sygnalizuje wymóg szyfrowania dla mechanizmu, a nie błędne dane logowania, nieistniejącą skrzynkę ani dokładną politykę szyfrów narzuconą przez serwer.
Przykłady od dostawców
501 5.7.11 Syntax error (no parameters allowed). For more information, go to About SMTP error messages and review RFC 3207 specifications. - gsmtpZnaczenie techniczne
Jako historyczna odpowiedź na AUTH wzorzec X.7.11 stanowi, że wybrany mechanizm uwierzytelniania może działać tylko wtedy, gdy bazowe połączenie SMTP chroni warstwa szyfrowania o wystarczającej sile. Współczesna implementacja nie powinna reklamować takiego mechanizmu bez aktywnej, wystarczającej warstwy szyfrowania. Kod 5.7.11 stosuje ten szczegół w klasie 5.
Status dostarczenia
Pierwsza cyfra 5 oznacza trwałe niepowodzenie bieżącej próby. Powtórzenie AUTH w tym samym stanie połączenia nie usuwa wskazanej przeszkody; sam kod nie określa wymaganej konfiguracji szyfrowania ani nie dowodzi, że dane uwierzytelniające lub adres odbiorcy są nieprawidłowe.
- Klasa
- Niepowodzenie trwałe
- Ponowienie
- Nie ponawiaj bez zmian
- Supresja
- Sprawdź pełny kontekst
Decyzja o ponowieniu
Zalecenie operacyjne: zatrzymaj automatyczne i ręczne ponowienia tej samej, niezmienionej próby. Nową, kontrolowaną próbę rozważ dopiero po potwierdzeniu wystarczającego szyfrowania połączenia albo wyborze mechanizmu dozwolonego w aktualnym stanie; przed próbą ponownie sprawdź status supresji.
Decyzja o supresji
Zalecenie operacyjne: nie dodawaj automatycznie adresu ani domeny do listy wykluczeń na podstawie samego 5.7.11. Sprawdź pełną odpowiedź, stan szyfrowania, mechanizm AUTH, historię zdarzeń i właściwą politykę, a decyzję o supresji podejmij dopiero w tym kontekście.
Najczęstsze przyczyny
- Klient wybrał mechanizm AUTH, który wymaga szyfrowania, gdy bazowe połączenie SMTP nie miało wystarczającej warstwy szyfrowania.
- Serwer zareklamował mechanizm niedozwolony w aktualnym stanie szyfrowania, mimo że współczesne implementacje nie powinny tego robić.
Kroki diagnostyczne
- Sprawdź surową odpowiedź SMTP i potwierdź, że kod rozszerzony to dokładnie 5.7.11, podstawowa odpowiedź należy do klasy 5xx, a kod został zwrócony na polecenie AUTH; zachowaj pełne brzmienie odpowiedzi.
- Powiąż odpowiedź z czasem próby, klientem, punktem końcowym serwera, wybranym mechanizmem AUTH oraz stanem i siłą warstwy szyfrowania; ustal te dane z konfiguracji i bezpiecznych logów, zamiast wyprowadzać je z samego kodu.
- Zatrzymaj niezmienione ponowienia; przed kontrolowaną nową próbą potwierdź wystarczające szyfrowanie lub dozwolony mechanizm, ponownie sprawdź status supresji i porównaj wynik.
Działania z podziałem na role
Nadawca
- Nie ponawiaj ręcznie tej samej próby; przekaż administratorowi pełną odpowiedź, czas próby i używane konto bez ujawniania danych uwierzytelniających.
Administrator nadawcy
- Sprawdź konfigurację klienta, punkt końcowy, mechanizm AUTH oraz stan i siłę szyfrowania dla wskazanej próby.
- Po potwierdzonej korekcie szyfrowania lub mechanizmu ponownie sprawdź status supresji i wykonaj jedną kontrolowaną próbę zamiast powtarzać niezmienione AUTH.
Administrator odbiorcy
- Jeżeli zarządzasz serwerem zwracającym kod, sprawdź jego logi, politykę AUTH i mechanizmy reklamowane w stanie szyfrowania właściwym dla wskazanej próby.
- Skoryguj potwierdzoną niespójność między reklamowanymi mechanizmami a polityką szyfrowania albo przekaż administratorowi nadawcy bezpieczną informację o wymaganym sposobie połączenia.
Dostawca
- Jeżeli obsługujesz usługę uczestniczącą w próbie, sprawdź logi szyfrowania i AUTH oraz przekaż administratorowi bezpieczny kontekst potrzebny do ustalenia wymaganej korekty.
- Usuń potwierdzony problem w zarządzanej konfiguracji albo wskaż właściciela korekty; nie uruchamiaj automatycznej supresji na podstawie samego kodu.
Źródła
Poniższe źródła określają znaczenie tego kodu rozszerzonego — przede wszystkim rejestr IANA i powiązane RFC. Jeśli na stronie są przykłady od dostawców, pochodzą z ich opublikowanej dokumentacji. Otwórz link, żeby zobaczyć oryginalne brzmienie w kontekście.
- SMTP Enhanced Status Codes — Rejestr IANA rozszerzonych kodów statusu poczty.
- RFC 5248 — rejestr rozszerzonych kodów statusu SMTP — Tworzy i reguluje rejestr IANA rozszerzonych kodów statusu.
- RFC 2034 — rozszerzenie SMTP dla rozszerzonych kodów błędów — Definiuje, jak SMTP zwraca klientom rozszerzone kody statusu.
- RFC 4954 — rozszerzenie SMTP Authentication — Rozszerzenie SMTP AUTH oraz powiązane kody odpowiedzi.
- Błędy i kody SMTP Gmaila — Oficjalna tabela Gmail Help z komunikatami błędów SMTP i kodami statusu.
Ostatnia weryfikacja:
