Blazalek.com

2.6.4SMTP 2.6.4: Wykonano konwersję z utratą danych

Wiadomość została dostarczona, ale dostarczenie wymagało konwersji, podczas której utracono część danych. To ostrzeżenie o wyniku powodzenia, a nie odrzucenie.

Kategoria
Treść i format wiadomości
Klasa
Powodzenie
Ponowienie
Nie ponawiaj bez zmian
Supresja
Sprawdź pełny kontekst

W skrócie

Doręczenie zakończone powodzeniem po konwersji z utratą części danych: ostrzeżenie, nie odrzucenie. Ważne dla integralności treści po stronie odbiorcy. Nie ponawiaj wysyłki. Dostarczalność utrzymana; reputacja bez wpływu, lecz sprawdź, czy utrata danych ma znaczenie dla odbiorców.

Co oznacza ten kod

Udane dostarczenie nie wyklucza ostrzeżenia o zmianie treści: wzorzec rejestru X.6.4 w klasie 2 jako kod 2.6.4 oznacza, że ścieżka odbiorcza wykonała wymaganą konwersję, lecz nie zachowała wszystkich pierwotnych danych. To ostrzeżenie w klasie powodzenia. Wiadomość dotarła do systemu odbiorcy, choć treść może różnić się od wysłanej. Sam kod nie rozstrzyga, które pola utracono ani czy nadawca zabronił konwersji z utratą; to wynika z tekstu odpowiedzi i wymagań wysyłki.

Znaczenie techniczne

Konwersja z utratą danych to wzorzec X.6.4. Przy konkretnym kodzie 2.6.4 klasa 2 potwierdza udane dostarczenie i ostrzega nadawcę, że wymagana konwersja nie zachowała wszystkich danych. Ten sam stan może mieć znaczenie trwałego błędu, gdy nadawca zabronił konwersji z utratą, lecz sam kod 2.6.4 pozostaje statusem powodzenia.

Status dostarczenia

Klasa 2 opisuje pomyślny wynik tego zdarzenia. Nie jest to odrzucenie i sam kod nie potwierdza końcowego umieszczenia w skrzynce ani nie wyklucza późniejszych zdarzeń.

Klasa
Powodzenie
Ponowienie
Nie ponawiaj bez zmian
Supresja
Sprawdź pełny kontekst

Decyzja o ponowieniu

Nie ponawiaj automatycznie wysyłki na podstawie samego kodu 2.6.4, ponieważ wiadomość została dostarczona. Jeśli utracone dane są istotne, ustal zakres konwersji i dopiero wtedy rozważ świadome wysłanie poprawionej wersji w odpowiednim formacie; ponowienie tej samej wiadomości może dać ten sam rezultat lub utworzyć duplikat.

Decyzja o supresji

Nie dodawaj adresu ani domeny do listy wykluczeń na podstawie samego kodu 2.6.4. Kod nie wskazuje nieprawidłowego lub niedostępnego odbiorcy; decyzję o supresji podejmuj wyłącznie na podstawie innych, niezależnych zdarzeń i pełnego kontekstu.

Najczęstsze przyczyny

  • Dostarczenie wymagało konwersji wiadomości, a podczas tej konwersji nie udało się zachować wszystkich danych.

Kroki diagnostyczne

  1. Sprawdź surową odpowiedź SMTP lub raport dostarczenia i potwierdź, że kod rozszerzony to dokładnie 2.6.4 oraz że zdarzenie należy do klasy powodzenia.
  2. Powiąż ostrzeżenie z właściwą wiadomością i odbiorcą, a następnie zachowaj pełny tekst odpowiedzi, aby ustalić, czy raport zawiera dodatkowy kontekst dotyczący konwersji.
  3. Porównaj wysłaną wiadomość z rezultatem dostarczenia, jeśli jest dostępny, i sprawdź wymagania wysyłki, aby ustalić, czy konwersja z utratą była zabroniona lub czy potrzebna jest poprawiona wersja.

Działania z podziałem na role

Nadawca

  • Traktuj 2.6.4 jako informację o udanym dostarczeniu z ostrzeżeniem i nie wysyłaj tej samej wiadomości ponownie wyłącznie z powodu kodu.
  • Jeśli zachowanie całej treści jest istotne, sprawdź rezultat i przygotuj poprawioną wersję dopiero po ustaleniu, co utracono podczas konwersji.

Administrator nadawcy

  • Klasyfikuj 2.6.4 jako powodzenie, zachowując osobno ostrzeżenie o utracie danych; nie kieruj go automatycznie do obsługi odrzuceń.
  • Zachowaj surowy raport i wymagania dotyczące konwersji, a w razie nieakceptowalnej utraty pomóż dobrać format lub ścieżkę dostarczenia, która nie wymaga tej samej konwersji.

Dostawca

  • Zachowuj kod 2.6.4 i pełny tekst ostrzeżenia w zdarzeniu powodzenia, aby informacja o konwersji nie została utracona podczas normalizacji.
  • Nie przedstawiaj 2.6.4 jako odbicie ani podstawy do automatycznego ponowienia lub supresji.

Ź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

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ę.