Undelivered Mail – coś na temat wracającej poczty

Chyba każdy z Was ujrzał kiedyś poważnie brzmiący tytuł:

„Undelivered Mail return to Sender”, „Delivery Notification – Failed” czy „Delivery Report Error”.

Wiadomość taka wynika ze specyfikacji protokołu SMTP (Simple Mail Transfer Protocol). Żeby zrozumieć, skąd się bierze wiadomość zwrotna w przypadku błędu w doręczeniu wiadomości, trzeba najpierw poznać działanie protokołu SMTP przy połączeniu z serwerem pocztowym.

Najprościej przedstawia tą komunikację krótki opis z polskiej Wikipedii (SMTP):

• klient rozpoczyna połączenie z serwerem (polecenie helo),
• podaje adres nadawcy (polecenie mail from),
• podaje adres odbiorcy (polecenie rcpt to),
• wpisuje wiadomość (polecenie data),
• kończy sesję (polecenie quit).

Do zrozumienia Bounce Message (bo tak fachowo nazywa się wiadomość zwrotna) konieczne jest bliższe spojrzenie na pierwsze trzy etapy wysyłki wiadomości.

helo – nawiązanie łączności (upewnienie się, że serwer jest online).

mail from – przedstawiamy się jako nadawca wiadomości – na tym etapie powstaje również część nagłówka wiadomości w serwerze odbiorcy – zbierane są wpisy From, podpis cyfrowy (jeśli jest wymagany), dane certyfikatu SSL (jeśli wysyłamy z użyciem SSL).

rcpt to – adres odbiorcy – tu również powstaje część nagłówków wiadomości, m.in. informacje o serwerach pocztowych (jaką drogą wiadomość szła do nas).

Możemy już przejść do sedna.

Bounce Message

W dosłownym tłumaczeniu jest to „odbita wiadomość”. BM towarzyszy niemal każdemu problemowi z doręczeniem wiadomości do końcowego odbiorcy. Jej istotą jest zawarta w niej informacja, dlaczego nie mogliśmy doręczyć wiadomości pomyślnie – a tym samym wskazówka, kto jest winien problemom z korespondencją. Zwrot wiadomości może wystąpić na dowolnym z podanych wyżej trzech istotnych etapów komunikacji SMTP. Ten element (spośród helo, mail from i rcpt to), który pierwszy zawiedzie, jest podstawą generowania błędu i odesłania BM.

Skoro więc wiadomości nie udało się doręczyć, to kto odpowiada za poinformowanie nas o tym? Odpowiedź podsyła nam MTA (Message Transport Agent – Agent transportu wiadomości). Czemu to robi? Bo takie są założenia protokołu SMTP. Jest on protokołem prostym, ale nie może dopuszczać do sytuacji, w której wiadomości znikają bez śladu niedoręczone, dlatego MUSI odsyłać Bounce Message z informacją, dlaczego nie udało się doręczyć naszego maila. Poza szczególnymi przypadkami opisanymi w specyfikacji protokołu, BM musi powstać zawsze.  Dla żądnych szczegółowej wiedzy: specyfikacja protokołu SMTP w oryginale, po angielsku, niemal 100 stron – znajduje się tutaj.

Zrozumieć wiadomości zwrotne.

Skoro wiemy, skąd się biorą, to spróbujmy choć w podstawowy sposób zrozumieć to, co chcą nam przekazać.

Przykład:

Delivery to the following recipient failed permanently:

     uzytkownik@domena.pl

Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the recipient domain.
We recommend contacting the other email provider for further information about the cause of this error.
The error that the other server returned was: 550 550 5.1.8
User not found (state 13).

W przykładzie widać akurat początek BM przesyłanej przez MTA serwerów Google – GMail. Pokazuję tylko to, co istotne – poniżej wklejonego tu fragmentu znajdowały się już tylko nagłówki wiadomości oraz jej treść.

Co nas interesuje – poziom błędu.

Możliwe są 4 typy:

FAILED – całkowite niepowodzenie z podaniem powodu.

DELIVERED – Doręczono pomyślnie i nadawca wiadomości zażądał odesłania przez MTA Bounce Message z informacją, że wiadomość została doręczona do odbiorcy. Otrzymanie BM ze statusem DELIVERED oznacza tylko i wyłącznie, że serwery pocztowe pomyślnie zrealizowały swoją robotę – nigdy, że odbiorca wiadomość odczytał!

RELAYED – wiadomość została przekazana dalej, do innego MTA, zdolnego odesłać wiadomość zwrotną z właściwą informacją o stanie wiadomości (niekoniecznie DELIVERED).

DELAYED – Wiadomość nie została jeszcze doręczona i z jakiegoś powodu oczekuje w kolejce na doręcznie (powód jest podawany w treści zwrotu, a stan DELAYED z reguły zakończy się stanem FAILED).

Druga ważna informacja w zwrocie to kod błędu. W powyższym przykładzie jest to:

5.1.8

Co on oznacza?

Pierwsza kolumna:

Doręczono pomyślnie

Oznaczenie kodowe stanu DELAYED, niżej zawsze podany będzie czas za jaki zostanie ponowiona próba doręczenia.

Inaczej FAILED – całkowite niepowodzenie.

Druga kolumna cyfr zawiera szersze informacje o stanie wiadomości.

Status inny, nieznany lub brak dodatkowych informacji do przekazania drogą powrotną.

Status adresu. Jeśli jest podany to raportowany jest adres docelowy, który wymaga poprawy przez nadawcę.

Z reguły zgłasza błąd skrzynki pocztowej i niemal zawsze oznacza błąd po stronie skrzynki pocztowej odbiorcy – najczęstszy problem to pełna skrzynka Inbox.

Błąd systemu wiadomości lub tylko wypisanie jego statusu. Jeśli zwracany jest błąd to jest on poza zasięgiem nadawcy/odbiorcy i wymaga interwencji administratora systemu pocztowego u odbiorcy wiadomości.

Błąd dotyczy problemów z siecią lub z routingiem sieciowym. Wskazywał będzie również na błędy serwerów DNS – „domena.com” będzie przez DNS przetłumaczona na poprawny docelowy adres IP, ale jeśli popełnimy literówkę, np. „dmoena.com”, to DNS nie będzie jej znał, a w treści BM umieści wpis „Domain not found”.

Błąd protokołu pocztowego. Dotyczy całego wachlarza problemów z serwerem – błędna konfiguracja, nie działa, nie jest aktualnie uruchomiony, system operacyjny nie pozwala wykonać zleconego doręczenia. Błędy bardzo obszerne i do analizy zawsze przez Administratora systemu.

x.6.x
Message Content or Media Status

Błąd treści wiadomości lub jej zawartości. Dotyczy dwóch, głównych przypadków:

– wiadomość zapisana z użyciem strony kodowej, która nie jest dopuszczalna na serwerze pocztowym, lub z użyciem języków (jak np. html czy java script), które mogły być permanentnie zablokowane.

– błąd zawartości – załącznik jest plikiem, którego rozszerzenie nie jest dopuszczalne na danym serwerze pocztowym (często dotyczy wszystkich plików wykonywalnych).

Ostatni status środkowej kolumny dotyczy błędów zabezpieczeń – najczęściej niezgodności kluczy szyfrujących lub specyficznej polityki bezpieczeństwa ustawionej przez Administratora np. tylko ręcznie wpisani na listę nadawcy mogą wysyłać pomyślnie wiadomości – taki przypadek zwróci powyższy kod błędu z powołaniem na Policy Status.

Ostatniej kolumny nie będę rozwijał. Jest to uzupełnienie środkowej części kodu błędu o szczegółowy status. Opis ostatniej cyfry wraz z komentarzem – niestety po angielsku – znajduje się na stronie: //www.apps.ietf.org/rfc/rfc1893.html.

Na koniec teoretycznego przynudzania mam dla Was poradę praktyczną:

Jak sobie poradzić z Message Bounce?

Jeśli otrzymałeś zwrot i nie wiesz co z tym zrobić, polecam prostą metodę, która dla wielu osób jest wystarczająca. Początkową treść opisu zwrotu skopiuj i przetłumacz na translate.google.pl

Wystarcza to w zupełności do zrozumienia ogólnego sensu błędu, a wówczas, jeśli mamy możliwość sami go poprawić, to będziemy w stanie to zrobić.

Prosty przykład – jeśli zwrot mówi, że „User not found” (nie znaleziono takiego użytkownika), to sprawdź, czy nie popełniłeś literówki w treści adresu odbiorcy przed symbolem @. W sieci, „kowalski” i „kofalski” to dwie różne osoby, a więc serwer domena.com odeśle BM).

To samo dotyczy problemów typu „Domain not found”. Sprawdź czy się nie pomyliłeś – ale tym razem za symbolem @.

Tyle w kwestii Undelivered Mail. Do poczty elektronicznej wrócimy jeszcze nieraz. To temat rzeka – jak zresztą cały internet.

Miłego popołudnia.