Blazalek.com

5.7.18SMTP 5.7.18: Zmienił się właściciel domeny

System odbiorczy trwale odrzucił wiadomość i wskazał, że właściciel domeny odbiorcy zmienił się od czasu podanego przez mechanizm RRVS. Nie ponawiaj tej samej, niezmienionej próby. Ta strona wyjaśnia konkretny wynik 5.7.18. Brzmienie odpowiedzi i polityki dostawcy mogą dodać kontekst, ale nie redefiniują rozszerzonego kodu statusu.

Kategoria
Bezpieczeństwo, uwierzytelnianie i polityka
Klasa
Niepowodzenie trwałe
Ponowienie
Nie ponawiaj bez zmian
Supresja
Sprawdź pełny kontekst

W skrócie

Trwały sygnał RRVS: właściciel domeny odbiorcy zmienił się od wskazanego czasu. Potwierdź odbiorcę i kontekst domeny przed ponowną wysyłką. Zmiana właściciela to alert polityki i bezpieczeństwa, nie proste twarde odbicie. Nie ponawiaj niezmienionej próby.

Co oznacza ten kod

Gdy własność domeny zmieniła się po znaczniku czasu RRVS, kod 5.7.18 zapisuje to ujawnienie pod wzorcem rejestru X.7.18 dla wiadomości z Require-Recipient-Valid-Since lub danymi RRVS. Klasa 5 przypisuje trwałe niepowodzenie, choć sygnał to ujawnienie polityki RRVS, a nie werdykt o istnieniu skrzynki. Status oddziela zmianę własności na poziomie domeny od wyników RRVS dotyczących skrzynki, takich jak 5.7.17. Sam kod nie identyfikuje poprzedniego ani obecnego właściciela domeny i nie wyjaśnia, dlaczego własność się zmieniła.

Znaczenie techniczne

Zmiana właściciela domeny od wskazanego czasu, ujawniana gdy wiadomość niesie Require-Recipient-Valid-Since lub rozszerzenie RRVS, to X.7.18. Strona odbierająca używa tego wzorca do raportowania dryfu własności na poziomie domeny; w kodzie 5.7.18 pierwsza cyfra przypisuje wynik do klasy trwałej.

Status dostarczenia

Pierwsza cyfra 5 oznacza trwałe niepowodzenie bieżącej próby. Sam kod nie identyfikuje poprzedniego ani obecnego właściciela domeny i nie podaje przyczyny zmiany.

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 zweryfikowaniu odbiorcy, domeny i kontekstu RRVS oraz po potwierdzonej, istotnej korekcie; wcześniej ponownie sprawdź status supresji.

Decyzja o supresji

Zalecenie operacyjne: nie dodawaj automatycznie adresu ani domeny do listy wykluczeń na podstawie samego 5.7.18. Sprawdź pełną odpowiedź, kontekst RRVS, zmianę właściciela domeny i inne zdarzenia doręczenia, a decyzję o supresji podejmij zgodnie z potwierdzoną przyczyną i właściwą polityką.

Najczęstsze przyczyny

  • Wiadomość zawierała pole Require-Recipient-Valid-Since lub rozszerzenie RRVS, a system odbiorczy ustalił, że właściciel domeny odbiorcy zmienił się od wskazanego czasu.

Kroki diagnostyczne

  1. Sprawdź surową odpowiedź SMTP lub raport niedostarczenia i potwierdź dokładny kod 5.7.18 oraz podstawową odpowiedź klasy 5xx; zachowaj pełne brzmienie odpowiedzi.
  2. Powiąż zdarzenie z właściwą wiadomością, czasem i etapem próby, domeną odbiorcy oraz czasem podanym w polu Require-Recipient-Valid-Since lub RRVS; nie wyprowadzaj tożsamości właścicieli z samego kodu.
  3. Poproś administratora systemu odbiorczego lub dostawcę o sprawdzenie dostępnych logów i potwierdzenie warunku zmiany właściciela domeny. Zatrzymaj niezmienione próby i sprawdź status supresji przed ewentualną nową, kontrolowaną wysyłką po potwierdzonej korekcie.

Działania z podziałem na role

Nadawca

  • Nie wysyłaj ponownie tej samej, niezmienionej wiadomości; potwierdź zamierzonego odbiorcę i jego domenę, a pełną odpowiedź przekaż administratorowi nadawcy.

Administrator nadawcy

  • Zachowaj pełną odpowiedź i kontekst próby, sprawdź domenę odbiorcy oraz użyty czas RRVS, zatrzymaj niezmienione ponowienia i skoordynuj potwierdzoną korektę z administratorem odbiorcy lub dostawcą.

Administrator odbiorcy

  • Jeżeli zarządzasz systemem, który zwrócił kod, sprawdź jego logi dla wskazanej domeny i czasu RRVS, potwierdź warunek zmiany właściciela domeny i przekaż nadawcy bezpieczny kontekst potrzebny do dalszej decyzji.

Dostawca

  • Jeżeli obsługujesz system uczestniczący w próbie, sprawdź logi zarządzanej usługi i kontekst RRVS, potwierdź podstawę wyniku oraz 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.

Ostatnia weryfikacja:

Znalazłeś błąd lub nieścisłość? Zgłoś poprawkę.

Wskaż element tej strony, który wymaga sprawdzenia. Każde zgłoszenie jest weryfikowane ręcznie.

Rodzaj problemu

Opisz problem i, jeśli chcesz, zaproponuj poprawione brzmienie.

Przy zgłoszeniu merytorycznym podaj publiczne źródło, jeśli je masz.

Możesz wysłać zgłoszenie anonimowo. Odpowiedź nie jest gwarantowana.

Nie wklejaj pełnych odpowiedzi bounce, nagłówków, adresów e-mail, Message-ID, tokenów ani innych danych osobowych. Przed wysłaniem zredaguj materiał dowodowy.

Wysłanie korekty przekazuje wpisane dane do Formspree, żebym mógł zweryfikować i poprawić tę stronę. Przeczytaj informację o prywatności.

Poradnik

  • Dostarczalność

    SPF/DKIM/DMARC i pokrewna polityka auth są wymagane do doręczenia do skrzynki.

Incydenty

Wojtek Blazalek

Ekspert ds. dostarczalności e-mail

Utknąłeś na tym kodzie błędu? Pomagam zespołom ustalać przyczyny odrzuceń oraz naprawiać uwierzytelnianie i reputację, żeby wiadomości trafiały do skrzynki.

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