W skrócie
Trwała awaria przekazania: wiadomość z REQUIRETLS nie mogła iść dalej, bo żaden następny serwer tego nie obsługuje. Włącz REQUIRETLS na ścieżce albo zmień routing. Luki w polityce TLS blokują bezpieczne doręczenie i mogą szkodzić reputacji. Nie ponawiaj niezmienionej próby.
Co oznacza ten kod
Gdy żaden kwalifikujący się serwer SMTP następnego etapu nie ogłasza REQUIRETLS, wiadomości z wymaganiem REQUIRETLS nie da się przekazać dalej; wzorzec rejestru X.7.30 zwraca tę przerwę jako kod 5.7.30. Trwałe niepowodzenie wynika z pierwszej cyfry w rejestrze statusów rozszerzonych. Podkod opisuje przerwanie ciągłości polityki TLS na ścieżce przekazywania, a nie odrzucenie adresu odbiorcy. Sam kod nie wskazuje, który etap nie obsługuje REQUIRETLS, czy wymaga zmiany routingu czy konfiguracji serwera, ani czy wymaganie powinno pozostać na wiadomości.
Przykłady od dostawców
550 5.7.30 This message was blocked because it didn’t pass DKIM authentication. Gmail requires bulk email senders to authenticate their email with DKIM. Authentication results: DKIM = did not pass To set up DKIM for your sending domains, visit Set up DKIM. To learn more about Gmail requirements for bulk email senders, visit Email sender guidelines. - gsmtpZnaczenie techniczne
Wiadomości odebrane z wymaganiem REQUIRETLS, których nie udało się przekazać, bo żaden z serwerów SMTP, do których miały trafić dalej, nie obsługiwał REQUIRETLS, odpowiadają X.7.30. W kodzie 5.7.30 pierwsza cyfra przypisuje wynik do klasy trwałego niepowodzenia.
Status dostarczenia
Pierwsza cyfra 5 oznacza trwałe niepowodzenie bieżącej próby. Bez potwierdzonej zmiany obsługi lub trasy kolejna identyczna próba napotka ten sam brak obsługi REQUIRETLS.
- 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 wiadomości i trasy. Nową, kontrolowaną próbę rozważ dopiero po potwierdzeniu, że skorygowana ścieżka przekazania obsługuje REQUIRETLS, oraz po ponownym sprawdzeniu supresji.
Decyzja o supresji
Zalecenie operacyjne: nie wykluczaj automatycznie adresu ani domeny odbiorcy na podstawie samego 5.7.30. Sprawdź pełną odpowiedź, zakres zdarzenia, trasę przekazania i historię doręczeń, a decyzję o supresji oprzyj na potwierdzonej przyczynie i właściwej polityce.
Najczęstsze przyczyny
- Wiadomość miała wymaganie REQUIRETLS, a żaden z serwerów SMTP dostępnych do jej dalszego przekazania nie zapewniał tej obsługi.
Kroki diagnostyczne
- Sprawdź surową odpowiedź SMTP lub raport niedostarczenia, potwierdź dokładny kod 5.7.30 i podstawową odpowiedź klasy 5xx oraz zachowaj pełny tekst odpowiedzi.
- Powiąż odpowiedź z właściwą wiadomością, czasem i etapem próby, systemem zwracającym kod oraz planowanym kolejnym etapem przekazania.
- W logach i konfiguracji potwierdź, że wiadomość odebrano z wymaganiem REQUIRETLS, oraz sprawdź, czy serwery dostępne do dalszego przekazania rzeczywiście je obsługują; nie przypisuj konkretnej awarii dostawcy na podstawie samego kodu.
- Zatrzymaj niezmienione ponowienia. Po potwierdzonej korekcie trasy lub obsługi ponownie sprawdź REQUIRETLS i status supresji, a następnie wykonaj najwyżej jedną kontrolowaną próbę.
Działania z podziałem na role
Nadawca
- Nie ponawiaj ręcznie tej samej, niezmienionej wiadomości; potwierdź, że wymaganie ochrony pozostaje zamierzone, a pełną odpowiedź i czas próby przekaż administratorowi nadawcy.
Administrator nadawcy
- Zachowaj pełną odpowiedź, prześledź etap przekazania i w dostępnych logach oraz konfiguracji potwierdź wymaganie REQUIRETLS i obsługę tej funkcji przez możliwe serwery następnego etapu.
- Wprowadź wyłącznie potwierdzoną korektę trasy lub obsługi, ponownie sprawdź REQUIRETLS i status supresji, a wynik zweryfikuj jedną kontrolowaną próbą.
Administrator odbiorcy
- Jeżeli zarządzasz systemem zwracającym kod lub dalszym etapem odbiorczym, sprawdź wybór trasy i obsługę REQUIRETLS dla wskazanej próby; usuń potwierdzony problem albo bezpiecznie przekaż nadawcy kontekst potrzebny do korekty.
Dostawca
- Jeżeli obsługujesz zarządzaną warstwę przekazującą, sprawdź jej logi, wybór trasy i obsługę REQUIRETLS, usuń potwierdzony problem w tej warstwie albo przekaż właściwym administratorom dokładny kontekst diagnostyczny; 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 8689 — opcja SMTP Require TLS — Opcja SMTP wymagająca TLS przy dostarczaniu wiadomości.
- Błędy i kody SMTP Gmaila — Oficjalna tabela Gmail Help z komunikatami błędów SMTP i kodami statusu.
Ostatnia weryfikacja:
