Odczytanie zwrotki (bounce)

Moduł 6: Zwroty (bounce) i rozwiązywanie problemów · Czas czytania: 11 minut

Cel lekcji: Po tej lekcji będą Państwo potrafili przeanalizować komunikat o błędzie dotyczący niedostarczonej wiadomości (bounce): który serwer zgłosił błąd, dla jakiego adresu, co oznacza kod oraz czy problem jest tymczasowy, czy trwały.

Kluczowe pojęcia: bounce, Mailer-Daemon, delivery status notification (DSN, RFC 3464), Reporting-MTA, Remote-MTA, Final-Recipient, Action (failed, delayed), Status, Diagnostic-Code, Will-Retry-Until, kod odpowiedzi (RFC 5321), rozszerzony kod statusu X.Y.Z (RFC 3463), komunikat o opóźnieniu, backscatter

Czym jest bounce?

Jeśli serwer pocztowy nie może dostarczyć wiadomości, odsyła komunikat z powrotem do nadawcy. Nazywa się to bounce (lub: non-delivery report, NDR). Przychodzi od nadawcy w postaci Mailer-Daemon@..., MAILER-DAEMON lub Mail Delivery System, z tematem takim jak:

• Mail delivery failed: returning message to sender
• Undelivered Mail Returned to Sender
• Delivery Status Notification (Failure)
• Warning: message ... delayed 24 hours (to nie jest bounce, lecz komunikat o opóźnieniu, patrz dalej)

Wiele osób od razu wyrzuca taki komunikat albo zniechęca się angielskim tekstem. Szkoda, ponieważ bounce niemal zawsze dokładnie mówi, co poszło nie tak. Trzeba tylko wiedzieć, gdzie szukać.

Bounce zawsze ma pusty adres nadawcy koperty (Return-Path: <>). Jest to celowe: bounce na bounce mógłby inaczej spowodować niekończącą się pętlę (RFC 5321).

Kto odrzucił wiadomość?

Wiadomość przechodzi przez co najmniej dwa serwery: Państwa dostawcy oraz odbiorcy. Bounce może powstać w dwóch sytuacjach:

1. Serwer odbiorcy odrzuca wiadomość podczas sesji SMTP (lekcja 1.2), na przykład po RCPT TO (adres nieznany) lub po treści (spam lub DMARC). Państwa własny serwer otrzymuje to odrzucenie i tworzy z niego bounce dla Państwa. Błąd pochodzi wtedy od odbiorcy, a bounce od Państwa własnego serwera.
2. Państwa własny serwer poddaje się, na przykład ponieważ odbiorca był niedostępny przez kilka dni, albo ponieważ sami osiągnęli Państwo pewien limit.

To rozróżnienie jest ważne: w pierwszym przypadku trzeba wiedzieć, co nie odpowiadało odbiorcy, w drugim przypadku problem leży bliżej.

Część czytelna dla człowieka

Na górze znajduje się tekst przeznaczony dla ludzi. Różni się w zależności od oprogramowania pocztowego, ale niemal zawsze zawiera te same elementy:

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  pieter.devries@example.net
    host mx1.example.net [198.51.100.20]
    SMTP error from remote mail server after RCPT TO:<pieter.devries@example.net>:
    550 5.1.1 <pieter.devries@example.net>: Recipient address rejected: User unknown

Proszę czytać to w ten sposób:

Część dla maszyn: DSN

Pod tekstem zwykle znajduje się część przeznaczona dla programów, czyli delivery status notification (RFC 3464). Ma zawsze taką samą budowę, co ułatwia odczyt:

Reporting-MTA: dns; mail.hosting.example

Action: failed
Final-Recipient: rfc822;pieter.devries@example.net
Status: 5.1.1
Remote-MTA: dns; mx1.example.net
Diagnostic-Code: smtp; 550 5.1.1 <pieter.devries@example.net>: Recipient address rejected: User unknown

Na samym dole znajduje się oryginalna wiadomość albo tylko jej nagłówki. Można tam zobaczyć, jakiej wiadomości to dotyczyło oraz jaki adres nadawcy i jaki Return-Path zostały użyte. Czasem jest to klucz do rozwiązania problemu (patrz przykład DMARC w zadaniu).

Odczytywanie kodów

Istnieją dwa rodzaje kodów i zazwyczaj oba znajdują się w bounce.

Kod odpowiedzi (RFC 5321): trzy cyfry, takie jak 550 lub 451. Pierwsza cyfra jest najważniejsza:

Rozszerzony kod statusu (RFC 3463): trzy liczby oddzielone kropkami, takie jak 5.1.1 lub 4.7.500. Pierwsza liczba to znów 2, 4 lub 5. Druga liczba mówi, gdzie leży problem:

Trzecia liczba to dokładny powód. Więksi odbiorcy używają do tego własnych numerów, na przykład Gmail z zakresem 5.7.25 do 5.7.30 oraz Microsoft z 4.7.500 i 5.7.509. Znajdują się one w ich własnej dokumentacji (lekcja 6.2).

Zasada praktyczna: kod zaczynający się od 5, z 7 na środku (5.7.x), niemal zawsze dotyczy kwestii polityki: uwierzytelniania, reputacji lub spamu. Ponowne wysłanie nic tu nie pomoże; trzeba coś zmienić.

Odroczone to jeszcze nie niepowodzenie

Przy błędzie tymczasowym (4xx) Państwa serwer zachowuje wiadomość i ponawia próbę. RFC 5321 zaleca podtrzymywanie prób przez co najmniej cztery do pięciu dni, z odstępem co najmniej pół godziny między próbami. Wiele serwerów wysyła po kilku godzinach lub po dniu komunikat o opóźnieniu:

Action: delayed
Status: 4.7.500
Diagnostic-Code: smtp; 451 4.7.500 Server busy. Please try again later from [203.0.113.25].
Will-Retry-Until: Thu, 12 Nov 2026 08:58:40 +0100

Oznacza to: nie wysyłać ponownie, serwer sam jeszcze próbuje. Jeśli mimo to wyślą Państwo wiadomość ponownie, odbiorca może ją w rezultacie otrzymać dwukrotnie. Jeśli ostatecznie nie uda się przed Will-Retry-Until, nadejdzie prawdziwy bounce, często z kodem 4.4.7 (wiadomość wygasła w kolejce).

Fałszywe zwroty: backscatter

Otrzymują Państwo nagle dziesiątki zwrotów dla wiadomości, których nigdy nie wysyłali? Proszę wtedy spojrzeć na oryginalną wiadomość na dole. Jeśli widnieje tam nadawca z Państwa domeny, ale serwer i tekst, których Państwo nie znają, oznacza to, że spamer użył Państwa adresu jako nadawcy. Odbiorcy wysyłają swoje zwroty do Państwa. Nazywa się to backscatter.

Państwa skrzynka pocztowa zazwyczaj nie jest wtedy zhakowana (różnicę wyjaśnia lekcja 3.4). Co pomaga: polityka DMARC zaostrzana krok po kroku (lekcja 4.4), dzięki czemu odbiorcy odrzucają sfałszowaną pocztę, zanim powstanie bounce. Warto jednak sprawdzić folder wysłanych wiadomości oraz skontaktować się z dostawcą, aby upewnić się, że naprawdę nic nie zostało wysłane z Państwa skrzynki.

W praktyce: tak to wygląda

W WebOké oprócz samego bounce'a mogą Państwo sprawdzić w Śledzenie e-mail w DirectAdmin, co serwer zrobił z wiadomością: Dostarczono, Odroczone lub Niepowodzenie, wraz z odpowiedzią serwera odbiorcy. Inne panele mają zwykle podobny dziennik poczty lub "śledzenie wiadomości"; w Microsoft 365 nazywa się to na przykład śledzeniem wiadomości. Warto najpierw tam zajrzeć, jeśli nie otrzymali Państwo bounce'a lub jeśli ktoś twierdzi, że Państwa wiadomość nie dotarła.

Podsumowanie

• Bounce przychodzi od Mailer-Daemon i ma pusty Return-Path. Warto go przeczytać, ponieważ zwykle dokładnie mówi, co poszło nie tak.
• Proszę najpierw sprawdzić, kto zgłosił błąd (SMTP error from remote mail server = odbiorca) i dla jakiego adresu.
• W części dla maszyn: Action, Status, Remote-MTA i przede wszystkim Diagnostic-Code.
• Pierwsza cyfra: 4 = tymczasowy, 5 = trwały. Druga liczba: 1 adres, 2 skrzynka, 3 system, 4 trasa, 5 protokół, 6 treść, 7 polityka.
• Komunikat o opóźnieniu (delayed): nie wysyłać ponownie. Zwroty dla wiadomości, których Państwo nie wysyłali: backscatter.

Quiz

Zadanie

Zadanie Z6.1: Analiza trzech zwrotów (bounce). Otrzymują Państwo trzy przykładowe zwroty (bounce-1.txt, bounce-2.txt i bounce-3.txt). Dla każdego zwrotu należy podać: adres, dla którego wystąpił błąd, serwer, który zgłosił błąd (Remote-MTA), kod statusu, informację, czy jest tymczasowy czy trwały, oraz co powinien zrobić nadawca (do wyboru z listy). Program sprawdza odpowiedzi według stałego klucza i podaje wyjaśnienie dla każdego pola.

Dalsza lektura

Kroki opisane w tych artykułach dotyczą paneli WebOké; u innych dostawców działa to w podobny sposób.

• Mail delivery failed: jak odczytać komunikat o błędzie i co oznaczają poszczególne kody
• Komunikat o błędzie: 550 5.5.0 Requested action not taken: mailbox unavailable
• Sprawdzanie, czy e-mail dotarł, za pomocą śledzenia e-maili w DirectAdmin
• Instrukcja DirectAdmin 9.3: Śledzenie e-mail: gdzie podziała się moja wiadomość?
• RFC 3464 (budowa DSN), RFC 3463 (rozszerzone kody statusu) oraz RFC 5321 paragraf 4.2 (kody odpowiedzi) i 4.5.4.1 (ponawianie prób)