Co oznacza ten kod
Wiadomość została trwale odrzucona z powodu problemu związanego z bezpieczeństwem, ale odpowiedź nie opisuje go dokładniej. Nie ponawiaj niezmienionej wysyłki.
Znaczenie techniczne
Wzorzec X.7.0 oznacza, że wiadomość została zwrócona z powodu stanu związanego z bezpieczeństwem, którego nie da się właściwie wyrazić żadnym innym dostępnym kodem szczegółowym. Kod może być również użyty, gdy obowiązująca polityka bezpieczeństwa nie pozwala opisać warunku dokładniej. W konkretnym kodzie 5.7.0 pierwsza cyfra przypisuje wynik do trwałej klasy 5.
Status dostarczenia
Pierwsza cyfra 5 oznacza trwałe niepowodzenie bieżącej próby. Sam kod nie wskazuje konkretnego mechanizmu bezpieczeństwa, reguły polityki ani strony odpowiedzialnej i nie dowodzi, że adres odbiorcy jest nieprawidłowy.
- 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 wysyłki. Nową wysyłkę rozważ dopiero po ustaleniu przyczyny z pełnego kontekstu i potwierdzeniu istotnej zmiany warunku lub konfiguracji.
Decyzja o supresji
Zalecenie operacyjne: nie wykluczaj automatycznie adresu na podstawie samego ogólnego kodu 5.7.0. Sprawdź pełną odpowiedź, kontekst bezpieczeństwa, historię doręczenia i inne trwałe sygnały; decyzję o suppression podejmij dopiero zgodnie z ustaloną przyczyną i właściwą polityką.
Najczęstsze przyczyny
- Trwały stan związany z bezpieczeństwem spowodował zwrócenie wiadomości, ale system raportujący nie mógł opisać go dokładniejszym dostępnym kodem.
- Obowiązująca polityka bezpieczeństwa mogła uniemożliwić systemowi ujawnienie dokładniejszego opisu warunku.
Kroki diagnostyczne
- Sprawdź surową odpowiedź SMTP lub raport doręczenia i potwierdź, że kod rozszerzony to dokładnie 5.7.0, a podstawowa odpowiedź należy do klasy 5xx.
- Powiąż odpowiedź z właściwą wiadomością, czasem próby, etapem transakcji i systemem, który zwrócił kod; zachowaj pełny tekst odpowiedzi i dostępny kontekst bezpieczeństwa, ponieważ sam kod jest ogólny.
- W dostępnych logach sprawdź, czy system odnotował dokładniejszy stan z rodziny X.7.x albo ograniczył szczegół zgodnie z polityką bezpieczeństwa; nie przypisuj konkretnej przyczyny na podstawie samego 5.7.0.
- Zatrzymaj niezmienione ponowienia; przed ewentualną nową wysyłką potwierdź istotną zmianę i ponownie sprawdź stan suppression.
Działania z podziałem na role
Nadawca
- Potwierdź, że wysyłka była zamierzona i że odbiorca nadal powinien otrzymać wiadomość; przekaż administratorowi nadawcy czas próby oraz pełny dostępny kontekst bez ręcznego ponawiania niezmienionej wysyłki.
- Nie zmieniaj danych uwierzytelniających ani ustawień bezpieczeństwa na podstawie samego kodu; zastosuj wyłącznie potwierdzoną instrukcję administratora.
Administrator nadawcy
- Zatrzymaj ponowienia niezmienionej wysyłki oraz zachowaj surową odpowiedź, czas, etap transakcji i system zwracający kod; sprawdź stan suppression i dostępne logi bez zakładania konkretnej przyczyny.
- Przekaż zebrany kontekst administratorowi odbiorcy lub dostawcy, jeśli przyczyna pozostaje niejasna; dopuść nową wysyłkę dopiero po potwierdzonej istotnej zmianie i ponownym sprawdzeniu suppression.
Administrator odbiorcy
- Jeżeli kod pochodzi z systemu odbiorczego, którym zarządzasz, sprawdź jego logi bezpieczeństwa i polityki dla wskazanego czasu oraz próby, aby ustalić dokładniejszy stan, o ile polityka pozwala go ujawnić.
- Skoryguj potwierdzony warunek w zakresie swoich uprawnień, jeśli dostarczenie powinno być dozwolone; w przeciwnym razie przekaż dozwolony kontekst i, gdy jest to bezpieczne, zwróć dokładniejszy kod statusu.
Dostawca
- Jeżeli obsługujesz system uczestniczący w próbie, sprawdź logi zarządzanej usługi oraz zastosowane reguły bezpieczeństwa dla wskazanego czasu; nie przypisuj konkretnej przyczyny na podstawie samego kodu.
- Skoryguj potwierdzony problem w zarządzanej warstwie albo zachowaj zamierzoną regułę polityki; gdy polityka na to pozwala, zwracaj dokładniejszy kod X.7.x zamiast ogólnego 5.7.0.
Zweryfikowane przykłady dostawców
Poniżej znajdują się zweryfikowane przykłady odpowiedzi dla 5.7.0 od: Rackspace Email. Pokazują one rzeczywistą praktykę dla tej odpowiedzi i nie zmieniają standardowego znaczenia 5.7.0 ani nie obejmują wszystkich wystąpień.
Dokładna odpowiedź SMTP
550 5.7.0 [blocked file] - File attachment is not allowed because they can be used to exploit Winzip (G1C)Dokładna odpowiedź SMTP
550 5.7.0 [blocked file] - Your message has been rejected because it contains a banned file attachment (G1A)Źródła i weryfikacja
Kanoniczne znaczenie T0 wzorca X.7.0 i przypisanie klasy zweryfikowano w rejestrze IANA oraz dokumentach RFC 2034, RFC 3463 i RFC 5248 według stanu na 17 lipca 2026 r. Wskazówki dotyczące ponowień, suppression, diagnostyki i działań właścicieli są oddzielnymi zaleceniami operacyjnymi; rekord nie zawiera praktyki konkretnego dostawcy.
- iana-smtp-enhanced-status-codesŹródło T0
Enumerated Status Codes / X.7.0
- 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.0
- ext-src-rackspace-5-7-0-01Źródło T1
docs.rackspace.com/docs/common-email-bounces > 'SMTP error' table, row WinZip-exploit (G1C)
- ext-src-rackspace-5-7-0-02Źródło T1
docs.rackspace.com/docs/common-email-bounces > 'SMTP error' table, row banned-attachment (G1A)
Ostatnia weryfikacja:

