Modulul 6 · 6.1
Cum se citește un mesaj bounce
Modulul 6: Erori de livrare (bounces) și rezolvarea problemelor · Timp de citire: 11 minute
Obiectivul lecției: După această lecție veți putea descifra un mesaj de eroare privind o mail nelivrată (un bounce): ce server a dat eroarea, pentru ce adresă, ce înseamnă codul și dacă este temporar sau definitiv.
Noțiuni cheie: bounce, Mailer-Daemon, delivery status notification (DSN, RFC 3464), Reporting-MTA, Remote-MTA, Final-Recipient, Action (failed, delayed), Status, Diagnostic-Code, Will-Retry-Until, cod de răspuns (RFC 5321), cod de stare extins X.Y.Z (RFC 3463), mesaj de amânare, backscatter
Ce este un bounce?
Dacă un server de e-mail nu poate livra un mesaj, el trimite un mesaj înapoi către expeditor. Acesta se numește bounce (sau: non-delivery report, NDR). Provine de la un expeditor precum Mailer-Daemon@..., MAILER-DAEMON sau Mail Delivery System, cu un subiect de genul:
Mail delivery failed: returning message to senderUndelivered Mail Returned to SenderDelivery Status Notification (Failure)Warning: message ... delayed 24 hours(acesta nu este un bounce, ci un mesaj de amânare, vedeți mai jos)
Mulți oameni aruncă imediat un astfel de mesaj sau se sperie de textul în engleză. Păcat, pentru că un bounce spune aproape întotdeauna exact ce e în neregulă. Trebuie doar să știți unde să vă uitați.
Un bounce are întotdeauna un expeditor de plic (envelope) gol (Return-Path: <>). Acest lucru este intenționat: un bounce la un bounce ar putea altfel duce la o buclă infinită (RFC 5321).
Cine a refuzat mesajul?
Un mesaj trece prin cel puțin două servere: cel al furnizorului dumneavoastră și cel al destinatarului. Un bounce poate apărea în două situații:
- Serverul destinatarului refuză mesajul în timpul conversației SMTP (lecția 1.2), de exemplu după
RCPT TO(adresă necunoscută) sau după conținut (spam sau DMARC). Serverul dumneavoastră propriu primește acest refuz și face din el un bounce pentru dumneavoastră. Eroarea provine atunci de la destinatar, iar bounce-ul de la serverul dumneavoastră propriu. - Serverul dumneavoastră propriu renunță, de exemplu pentru că destinatarul nu a fost accesibil zile în șir, sau pentru că ați atins dumneavoastră înșivă o limită.
Distincția este importantă: în primul caz trebuie să aflați ce nu i-a plăcut destinatarului, în al doilea caz problema este mai aproape de casă.
Partea lizibilă
În partea de sus se află un text destinat oamenilor. Acesta diferă în funcție de software-ul de e-mail, dar conține aproape întotdeauna aceleași elemente:
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 unknownCitiți-l astfel:
| Fragment | Ce înseamnă |
|---|---|
permanent error | Definitiv: serverul nu mai încearcă din nou |
pieter.devries@example.net | Adresa pentru care s-a produs eroarea (la mai mulți destinatari: doar aceasta) |
host mx1.example.net [198.51.100.20] | Serverul destinatarului cu care s-a comunicat |
SMTP error from remote mail server | Eroarea a venit de la destinatar, nu de la serverul dumneavoastră propriu |
after RCPT TO | În ce moment al conversației: aici la indicarea destinatarului |
550 5.1.1 ... User unknown | Codul și textul destinatarului: această adresă nu există |
Partea pentru mașini: DSN-ul
Sub text se găsește de obicei o parte destinată programelor, delivery status notification (RFC 3464). Aceasta are întotdeauna aceeași structură, ceea ce o face ușor de citit:
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| Câmp | Semnificație |
|---|---|
Reporting-MTA | Serverul care a scris acest bounce (de obicei propriul dumneavoastră server de trimitere) |
Final-Recipient | Adresa despre care este vorba |
Action | failed (eșuat, definitiv), delayed (amânat, se mai încearcă), uneori delivered sau relayed |
Status | Codul de stare extins, vedeți mai jos |
Remote-MTA | Serverul de cealaltă parte care a dat răspunsul |
Diagnostic-Code | Răspunsul literal al acelui server: aici se află motivul real |
Will-Retry-Until | La delayed: până când serverul va continua să încerce |
Cu totul la final se află mesajul original sau doar capetele sale (headerele). Acolo vedeți despre ce mesaj era vorba, precum și ce adresă de expeditor și ce Return-Path au fost folosite. Acesta este uneori cheia soluției (vedeți studiul de caz DMARC din exercițiu).
Citirea codurilor
Există două tipuri de coduri, și de obicei ambele apar într-un bounce.
Codul de răspuns (RFC 5321): trei cifre, precum 550 sau 451. Prima cifră este cea mai importantă:
| Începe cu | Semnificație | Ce face serverul de trimitere |
|---|---|---|
2 | Reușit | Nimic mai mult, mesajul a fost acceptat |
4 | Eroare temporară | Păstrează mesajul și încearcă din nou mai târziu |
5 | Eroare definitivă | Renunță și trimite un bounce |
Codul de stare extins (RFC 3463): trei numere separate prin puncte, precum 5.1.1 sau 4.7.500. Primul număr este din nou 2, 4 sau 5. Al doilea număr indică unde se află problema:
| Al doilea număr | Subiect | Exemple |
|---|---|---|
X.1 | Adresă | 5.1.1 adresa nu există, 5.1.2 domeniul nu există |
X.2 | Mailbox | 5.2.2 / 4.2.2 mailbox plină, 5.2.1 mailbox dezactivată |
X.3 | Sistem de e-mail | 5.3.4 mesaj prea mare |
X.4 | Rețea și rutare | 4.4.1 niciun răspuns, 4.4.7 prea mult timp în coadă, 5.4.4 nicio rută |
X.5 | Protocol | 5.5.1 comandă nevalidă |
X.6 | Conținut | 5.6.0 problemă cu conținutul sau codarea |
X.7 | Security (securitate) și politică | 5.7.1 refuzat, 5.7.26 neautentificat (Gmail), 5.7.509 DMARC (Microsoft) |
Al treilea număr este motivul precis. Furnizorii mari folosesc pentru acesta propriile lor numere, precum Gmail cu 5.7.25 până la 5.7.30 și Microsoft cu 4.7.500 și 5.7.509. Acestea se găsesc în documentația lor proprie (lecția 6.2).
Regulă practică: codul care începe cu 5 și are un 7 la mijloc (5.7.x) este aproape întotdeauna o chestiune de politică: autentificare, reputație sau spam. Retrimiterea nu ajută în acest caz; trebuie schimbat ceva.
Amânat nu înseamnă încă eșuat
La o eroare temporară (4xx), serverul dumneavoastră păstrează mesajul și încearcă din nou. RFC 5321 recomandă să se persiste timp de cel puțin patru până la cinci zile, cu cel puțin o jumătate de oră între încercări. Multe servere trimit după câteva ore sau după o zi un mesaj de amânare:
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 +0100Acest lucru înseamnă: nu retrimiteți, serverul mai încearcă el însuși. Dacă retrimiteți totuși, este posibil ca destinatarul să îl primească ulterior de două ori. Dacă până la urmă nu reușește înainte de Will-Retry-Until, va apărea totuși un bounce real, adesea cu 4.4.7 (mesaj expirat în coadă).
Bounce-uri false: backscatter
Primiți dintr-odată zeci de bounce-uri pentru mesaje pe care nu le-ați trimis niciodată? Uitați-vă atunci la mesajul original din partea de jos. Dacă acolo apare un expeditor de la domeniul dumneavoastră, dar un server și un text pe care nu le recunoașteți, înseamnă că un spammer a folosit adresa dumneavoastră ca expeditor. Destinatarii își trimit bounce-urile către dumneavoastră. Acest fenomen se numește backscatter.
Căsuța dumneavoastră poștală nu este de obicei spartă (hackuită) în acest caz (vedeți lecția 3.4 pentru diferență). Ce ajută: o politică DMARC care devine treptat mai strictă (lecția 4.4), astfel încât destinatarii să refuze mesajele falsificate înainte ca un bounce să apară. Verificați totuși în mesajele trimise și la furnizorul dumneavoastră dacă într-adevăr nu s-a trimis nimic din căsuța dumneavoastră poștală.
În practică: așa arată
La WebOké, pe lângă bounce, puteți vedea și în E-mail Tracking din DirectAdmin ce a făcut serverul cu un mesaj: Delivered (livrat), Deferred (amânat) sau Fail (eșuat), împreună cu răspunsul serverului destinatarului. Alte panouri au adesea un jurnal de e-mail (maillog) sau o „urmărire a mesajelor” similară; la Microsoft 365, de exemplu, se numește urmărirea mesajelor (message trace). Este util să vă uitați mai întâi acolo dacă nu aveți un bounce sau dacă cineva vă spune că mesajul dumneavoastră nu a ajuns.
Rezumat
- Un bounce provine de la Mailer-Daemon și are un Return-Path gol. Citiți-l, de obicei spune exact ce e în neregulă.
- Verificați mai întâi cine a dat eroarea (
SMTP error from remote mail server= destinatarul) și pentru ce adresă. - În partea pentru mașini:
Action,Status,Remote-MTAși mai alesDiagnostic-Code. - Prima cifră: 4 = temporar, 5 = definitiv. Al doilea număr: 1 adresă, 2 mailbox, 3 sistem, 4 rutare, 5 protocol, 6 conținut, 7 politică.
- Mesaj de amânare (
delayed): nu retrimiteți. Bounce-uri pentru mesaje pe care nu le-ați trimis: backscatter.
Quiz
Exercițiu
Exercițiu Z6.1: Analizarea a trei mesaje bounce. Primiți trei exemple de bounce (bounce-1.txt, bounce-2.txt și bounce-3.txt). Completați pentru fiecare bounce: adresa pentru care s-a produs eroarea, serverul care a dat eroarea (Remote-MTA), codul de stare, dacă este temporar sau definitiv, și ce trebuie să facă expeditorul (alegeți dintr-o listă). Programul verifică folosind o cheie fixă și oferă explicații pentru fiecare câmp.
Lecturi suplimentare
Pașii din aceste articole se aplică panourilor WebOké; la alți furnizori funcționează similar.
- Livrarea mesajului a eșuat (Mail delivery failed): cum interpretați mesajul de eroare și ce înseamnă codurile
- Mesaj de eroare: 550 5.5.0 Requested action not taken: mailbox unavailable
- Verificați dacă un e-mail a ajuns, cu Email Tracking în DirectAdmin
- Manual DirectAdmin 9.3: E-mail Tracking: unde a dispărut mesajul meu?
- RFC 3464 (structura unui DSN), RFC 3463 (coduri de stare extinse), RFC 5321 paragraful 4.2 (coduri de răspuns) și 4.5.4.1 (reîncercare)