Co oznacza ten kod
Wiadomość odebrano z wymaganiem REQUIRETLS, ale nie można było przekazać jej dalej, ponieważ żaden z docelowych serwerów SMTP nie zapewniał tej obsługi. Kod 5.7.30 oznacza trwałe niepowodzenie bieżącej próby.
Znaczenie techniczne
Standardowy wzorzec X.7.30 oznacza, że wiadomości odebranej z wymaganiem REQUIRETLS nie udało się przekazać, ponieważ żaden z serwerów SMTP, do których miała trafić dalej, nie obsługiwał REQUIRETLS. 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 suppression.
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 suppression 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 suppression, 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 suppression, 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 suppression na podstawie samego kodu.
Źródła i weryfikacja
Standardowe znaczenie wzorca X.7.30 i zastosowanie klasy 5 zweryfikowano w rejestrze IANA oraz dokumentach RFC 2034, RFC 5248 i RFC 8689 według stanu na 17 lipca 2026 r. Wskazówki dotyczące diagnostyki, naprawy, ponawiania i suppression są oddzielnymi zaleceniami operacyjnymi; rekord nie zawiera praktyki konkretnego dostawcy.
- iana-smtp-enhanced-status-codesŹródło T0
Enumerated Status Codes / X.7.30
- rfc5248Źródło T0
Section 2.1: registry fields and non-exclusive Associated Basic Status Code
- rfc2034Źródło T0
Section 4: enhanced status class agrees with SMTP reply class
- rfc8689Źródło T0
IANA registry reference for X.7.30
Ostatnia weryfikacja:
