Blazalek.com

4.7.1Dostarczenie nieautoryzowane, wiadomość tymczasowo odrzucona

System odrzucił bieżącą próbę, ponieważ nadawca nie był uprawniony do wysłania wiadomości do wskazanego miejsca docelowego. Decyzja może wynikać z filtrowania na poziomie hosta lub odbiorcy. Pierwsza cyfra 4 oznacza niepowodzenie tymczasowe, dlatego dostarczenie można ponowić w kontrolowany sposób.

Kategoria
Bezpieczeństwo, uwierzytelnianie i polityka
Klasa
Niepowodzenie tymczasowe
Ponowienie
Kontrolowane ponowienie
Supresja
Sprawdź pełny kontekst

Co oznacza ten kod

System odrzucił bieżącą próbę, ponieważ nadawca nie był uprawniony do wysłania wiadomości do wskazanego miejsca docelowego. Decyzja może wynikać z filtrowania na poziomie hosta lub odbiorcy. Pierwsza cyfra 4 oznacza niepowodzenie tymczasowe, dlatego dostarczenie można ponowić w kontrolowany sposób.

Znaczenie techniczne

Wzorzec X.7.1 oznacza, że nadawca nie jest uprawniony do wysyłania do miejsca docelowego, więc wiadomość została odrzucona; przyczyną może być filtrowanie według hosta albo odbiorcy. Opis w RFC 3463 określa ten szczegół jako użyteczny tylko dla błędu trwałego, jednak obecny rejestr IANA wiąże X.7.1 zarówno z podstawowymi odpowiedziami klasy 4xx, jak i 5xx. W konkretnym kodzie 4.7.1 pierwsza cyfra przypisuje wynik do klasy przejściowej.

Status dostarczenia

Pierwsza cyfra 4 oznacza trwałe w czasie niepowodzenie przejściowe: bieżąca próba się nie udała, ale warunek może ustąpić. Kod wskazuje wynik dotyczący autoryzacji dostarczenia lub filtrowania, lecz sam nie identyfikuje konkretnej reguły, systemu, który ją zastosował, ani czasu trwania problemu i nie dowodzi, że adres odbiorcy jest nieprawidłowy.

Klasa
Niepowodzenie tymczasowe
Ponowienie
Kontrolowane ponowienie
Supresja
Sprawdź pełny kontekst

Decyzja o ponowieniu

Zalecenie operacyjne: przed każdą próbą sprawdź stan suppression, a następnie ponawiaj wysyłkę z backoffem, losowym rozproszeniem, idempotencją oraz limitem czasu lub prób. Zakończ ponawianie po sukcesie, po trwałym wyniku, po zmianie stanu suppression wykluczającej wysyłkę albo po osiągnięciu limitu; powtarzające się 4.7.1 skieruj do diagnozy zamiast ponawiać bez końca.

Decyzja o supresji

Zalecenie operacyjne: nie dodawaj adresu do listy wykluczeń wyłącznie na podstawie tymczasowego kodu 4.7.1. Sprawdź pełną odpowiedź, kontekst autoryzacji i filtrowania dostępny dla danej próby, historię ograniczonych ponowień oraz inne zdarzenia doręczenia; zastosuj suppression dopiero po niezależnym trwałym sygnale albo wtedy, gdy wymaga tego właściwa polityka.

Najczęstsze przyczyny

  • System raportujący uznał podczas bieżącej próby, że nadawca nie jest uprawniony do wysłania wiadomości do wskazanego miejsca docelowego.
  • Decyzję o odmowie mogło zwrócić filtrowanie stosowane na poziomie hosta lub konkretnego odbiorcy.

Kroki diagnostyczne

  1. Sprawdź surową odpowiedź SMTP lub raport doręczenia i potwierdź, że kod rozszerzony to dokładnie 4.7.1, a podstawowa odpowiedź należy do klasy 4xx; zachowaj pełne brzmienie odpowiedzi.
  2. Powiąż odpowiedź z właściwą wiadomością, czasem próby, etapem transakcji, użytym hostem i tożsamością nadawcy, miejscem docelowym oraz systemem, który zwrócił kod.
  3. W dostępnych logach autoryzacji i filtrowania sprawdź, czy decyzję zastosowano na poziomie hosta czy odbiorcy, i ustal konkretną regułę; nie wyprowadzaj jej treści ani właściciela z samego kodu 4.7.1.
  4. Przed kolejną próbą sprawdź suppression, porównaj wyniki ograniczonych ponowień i zakończ je po sukcesie, trwałym wyniku, zmianie kwalifikacji odbiorcy albo osiągnięciu ustalonego limitu.

Działania z podziałem na role

Nadawca

  • Potwierdź, że wysyłka była zamierzona, a nadawca i miejsce docelowe są właściwe; przekaż administratorowi nadawcy czas próby i pełną odpowiedź bez wielokrotnego ręcznego ponawiania.
  • Skoryguj wyłącznie potwierdzony błąd w wyborze nadawcy, miejsca docelowego lub wymaganej ścieżki wysyłki, a następnie zgłoś wynik nowej, kontrolowanej próby.

Administrator nadawcy

  • Zachowaj surową odpowiedź, czas, etap transakcji, użyty host i tożsamość nadawcy oraz system zwracający kod; sprawdź suppression i skieruj wiadomość do ograniczonego mechanizmu ponowień z backoffem oraz idempotencją.
  • Grupuj powtarzające się 4.7.1 według systemu docelowego, hosta lub odbiorcy i czasu; zweryfikuj konfigurację nadawczą, a po wyczerpaniu limitu przekaż zebrany kontekst administratorowi odbiorcy lub dostawcy bez wykluczania adresu na podstawie samego kodu.

Administrator odbiorcy

  • Jeżeli kod pochodzi z systemu odbiorczego, którym zarządzasz, sprawdź dla wskazanej próby decyzje autoryzacyjne i filtry hosta lub odbiorcy, aby zidentyfikować regułę, która odmówiła dostarczenia.
  • Jeżeli potwierdzony warunek jest tymczasowy albo reguła nie odpowiada zamierzonej polityce, usuń problem w zakresie swoich uprawnień i zweryfikuj wynik nowej, kontrolowanej próby.

Dostawca

  • Jeżeli obsługujesz system uczestniczący w próbie, sprawdź logi zarządzanej usługi i zastosowane reguły dla wskazanego czasu; ustal, czy decyzja dotyczyła hosta czy odbiorcy, bez przypisywania konkretnej przyczyny na podstawie samego kodu.
  • Usuń potwierdzony stan tymczasowy w zarządzanej warstwie i zachowaj w odpowiedzi dokładną klasę 4xx, kod 4.7.1 oraz bezpieczny kontekst potrzebny nadawcy do sterowania ponowieniami.

Źródła i weryfikacja

Kanoniczne znaczenie T0 wzorca X.7.1 oraz przypisanie klasy zweryfikowano w rejestrze IANA i dokumentach RFC 2034, RFC 3463 oraz RFC 5248 według stanu na 17 lipca 2026 r. RFC 3463 opisuje ten szczegół jako użyteczny tylko dla błędu trwałego, natomiast obecne skojarzenia podstawowych statusów w IANA potwierdzają również klasę 4; w kodzie 4.7.1 to pierwsza cyfra rozstrzyga o obsłudze tymczasowej. Wskazówki dotyczące ponowień, suppression, diagnostyki i działań właścicieli są oddzielnymi zaleceniami operacyjnymi; rekord nie zawiera praktyki konkretnego dostawcy.

  • Enumerated Status Codes / X.7.1

  • 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

  • rfc3463Źródło T0

    IANA registry reference for X.7.1

Ostatnia weryfikacja:

Wojtek Blazalek

Ekspert ds. dostarczalności e-mail

Utknąłeś na tym kodzie błędu? Pomagam zespołom usuwać przyczyny odrzuceń, naprawiać uwierzytelnianie i reputację — tak, żeby maile trafiały do skrzynki.

Praktyczna praca nad dostarczalnością dla firm wysyłających na dużą skalę.