Modul 6 · 6.1
Egy bounce elolvasása
Modul 6: Bounce-ok és hibaelhárítás · Olvasási idő: 11 perc
Tanulási cél: Ennek a leckének a végén képes lesz elemezni egy kézbesítetlen levélről kapott hibaüzenetet (bounce): megállapítani, melyik szerver adta a hibát, melyik címre vonatkozik, mit jelent a kód, és hogy ideiglenes vagy végleges hibáról van-e szó.
Kulcsfogalmak: bounce, Mailer-Daemon, delivery status notification (DSN, RFC 3464), Reporting-MTA, Remote-MTA, Final-Recipient, Action (failed, delayed), Status, Diagnostic-Code, Will-Retry-Until, válaszkód (RFC 5321), kibővített állapotkód X.Y.Z (RFC 3463), késleltetési értesítés, backscatter
Mi az a bounce?
Ha egy levelezőszerver nem tudja kézbesíteni a levelet, visszaküld egy üzenetet a feladónak. Ezt nevezzük bounce-nak (vagy: non-delivery report, NDR). A feladó jellemzően Mailer-Daemon@..., MAILER-DAEMON vagy Mail Delivery System, a tárgy pedig valami ilyesmi:
Mail delivery failed: returning message to senderUndelivered Mail Returned to SenderDelivery Status Notification (Failure)Warning: message ... delayed 24 hours(ez nem bounce, hanem késleltetési értesítés, lásd lejjebb)
Sokan rögtön kidobják az ilyen üzenetet, vagy megijednek az angol szövegtől. Pedig kár, mert egy bounce szinte mindig pontosan megmondja, mi a baj. Csak tudni kell, hová kell nézni.
Egy bounce-nak mindig üres a boríték szerinti feladója (Return-Path: <>). Ez szándékos: egy bounce-ra adott bounce végtelen körforgást okozhatna (RFC 5321).
Ki utasította vissza a levelet?
Egy levél legalább két szerveren megy keresztül: a szolgáltatóján és a címzettén. Bounce két esetben keletkezhet:
- A fogadó szerver visszautasítja a levelet az SMTP-párbeszéd közben (1.2. lecke), például a
RCPT TOután (ismeretlen cím) vagy a tartalom után (spam vagy DMARC). Ekkor a saját szervere kapja meg ezt az elutasítást, és abból készít bounce-t az Ön számára. A hiba tehát a címzettől jön, a bounce-t viszont a saját szervere küldi. - A saját szervere adja fel a próbálkozást, például mert a címzett napokig nem volt elérhető, vagy mert Ön elérte a saját korlátját.
A megkülönböztetés fontos: az első esetben azt kell tudnia, mi nem tetszett a címzettnek, a második esetben a probléma közelebb van Önhöz.
Az emberek számára olvasható rész
Legfelül egy emberek számára szóló szöveg található. Ez levelezőszoftverenként eltérő, de szinte mindig ugyanazokat az elemeket tartalmazza:
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Így olvassa:
| Rész | Mit jelent |
|---|---|
permanent error | Végleges: a szerver nem próbálkozik újra |
pieter.devries@example.net | A cím, amelynél a hiba történt (több címzett esetén: csak ez) |
host mx1.example.net [198.51.100.20] | A címzett szervere, amellyel a kapcsolat létrejött |
SMTP error from remote mail server | A hiba a címzett oldaláról jött, nem a saját szerveréről |
after RCPT TO | A párbeszéd melyik pontján: itt a címzett megadásakor |
550 5.1.1 ... User unknown | A kód és a címzett szövege: ez a cím nem létezik |
A gépi rész: a DSN
A szöveg alatt rendszerint található egy programok számára szóló rész, a delivery status notification (RFC 3464). Ennek felépítése mindig ugyanaz, ami könnyen olvashatóvá teszi:
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| Mező | Jelentés |
|---|---|
Reporting-MTA | A szerver, amely ezt a bounce-t írta (általában a saját küldőszervere) |
Final-Recipient | A cím, amelyre a hiba vonatkozik |
Action | failed (sikertelen, végleges), delayed (késleltetett, még próbálkozik), néha delivered vagy relayed |
Status | A kibővített állapotkód, lásd lejjebb |
Remote-MTA | A másik oldali szerver, amely a választ adta |
Diagnostic-Code | Az adott szerver szó szerinti válasza: itt áll a valódi ok |
Will-Retry-Until | delayed esetén: meddig próbálkozik még a szerver |
Egészen alul található az eredeti levél vagy legalábbis annak fejlécei. Ott láthatja, melyik levélről van szó, és milyen feladó cím és Return-Path lett használva. Ez néha a megoldás kulcsa (lásd a DMARC-esettanulmányt a feladatban).
A kódok olvasása
Kétféle kód létezik, és egy bounce-ban általában mindkettő megtalálható.
A válaszkód (RFC 5321): három számjegy, például 550 vagy 451. Az első számjegy a legfontosabb:
| Ezzel kezdődik | Jelentés | Mit tesz a küldő szerver |
|---|---|---|
2 | Sikeres | Semmi további teendő, a levelet elfogadták |
4 | Ideiglenes hiba | Megőrzi a levelet, és később újra megpróbálja |
5 | Végleges hiba | Feladja, és bounce-t küld |
A kibővített állapotkód (RFC 3463): három, pontokkal elválasztott szám, például 5.1.1 vagy 4.7.500. Az első szám ismét 2, 4 vagy 5. A második szám megmondja, hol van a probléma:
| Második szám | Terület | Példák |
|---|---|---|
X.1 | Cím | 5.1.1 a cím nem létezik, 5.1.2 a domain nem létezik |
X.2 | Postafiók | 5.2.2 / 4.2.2 a postafiók tele van, 5.2.1 a postafiók le van tiltva |
X.3 | Levelezőrendszer | 5.3.4 az üzenet túl nagy |
X.4 | Hálózat és útvonal | 4.4.1 nincs válasz, 4.4.7 túl sokáig volt a sorban, 5.4.4 nincs útvonal |
X.5 | Protokoll | 5.5.1 érvénytelen parancs |
X.6 | Tartalom | 5.6.0 probléma a tartalommal vagy a kódolással |
X.7 | Biztonság és szabályzat | 5.7.1 elutasítva, 5.7.26 nem hitelesített (Gmail), 5.7.509 DMARC (Microsoft) |
A harmadik szám a pontos okot adja meg. A nagy szolgáltatók itt saját számaikat használják, például a Gmail a 5.7.25 és 5.7.30 közöttieket, a Microsoft pedig a 4.7.500 és 5.7.509 kódokat. Ezek a saját dokumentációjukban találhatók (6.2. lecke).
Ökölszabály: az a kód, amely 5-tel kezdődik és középen 7-es áll (5.7.x), szinte mindig szabályzati kérdés: hitelesítés, reputáció vagy spam. Ilyenkor az újraküldés nem segít, valamin változtatni kell.
A késleltetett még nem jelent sikertelent
Ideiglenes hiba (4xx) esetén a szervere megőrzi a levelet, és újra megpróbálja kézbesíteni. Az RFC 5321 azt javasolja, hogy ezt legalább négy-öt napig tartsa fenn, a próbálkozások között legalább fél óra teljen el. Sok szerver néhány óra vagy egy nap után küld egy késleltetési értesítést:
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 +0100Ez azt jelenti: ne küldje el újra, a szerver még maga is próbálkozik. Ha mégis újraküldi, előfordulhat, hogy a címzett két példányban kapja meg a levelet. Ha végül nem sikerül a Will-Retry-Until idő előtt, akkor mégis érkezik egy valódi bounce, gyakran 4.4.7 kóddal (az üzenet lejárt a sorban állás közben).
Hamis bounce-ok: backscatter
Egyszer csak tucatnyi bounce-t kap olyan levelekről, amelyeket soha nem küldött el? Ilyenkor nézze meg az eredeti levelet legalul. Ha ott az Ön domainjéhez tartozó feladó szerepel, de olyan szerver és szöveg, amelyet nem ismer, akkor egy spammer az Ön címét használta feladóként. A címzettek az Önnek küldik vissza a bounce-okat. Ezt nevezzük backscatter-nek.
Ilyenkor a postafiókja általában nincs feltörve (a különbségről lásd a 3.4. leckét). Ami segít: egy fokozatosan szigorodó DMARC-szabályzat (4.4. lecke), hogy a címzettek már azelőtt elutasítsák a hamisított levelet, mielőtt bounce keletkezne. Ugyanakkor érdemes megnézni az elküldött leveleit és a szolgáltatójánál is, hogy valóban nem küldtek-e ki semmit a postafiókjából.
A gyakorlatban: így néz ki
A WebOkénál a bounce mellett a DirectAdmin E-mail követés funkciójában is láthatja, mit tett a szerver az üzenettel: Kézbesítve, Késleltetett vagy Sikertelen, a fogadó szerver válaszával együtt. Más vezérlőpultokon gyakran hasonló levelezési napló vagy "üzenetkövetés" található; a Microsoft 365 esetében ezt például üzenetkövetésnek nevezik. Érdemes először ott megnézni a helyzetet, ha nem kapott bounce-t, vagy ha valaki azt jelzi, hogy a levele nem érkezett meg.
Összefoglalás
- A bounce a Mailer-Daemontól érkezik, és üres a Return-Path mezője. Olvassa el, szinte mindig pontosan megmondja, mi a baj.
- Először nézze meg, ki adta a hibát (
SMTP error from remote mail server= a címzett) és melyik címre vonatkozik. - A gépi részben:
Action,Status,Remote-MTA, és leginkább aDiagnostic-Code. - Első számjegy: 4 = ideiglenes, 5 = végleges. Második szám: 1 cím, 2 postafiók, 3 rendszer, 4 útvonal, 5 protokoll, 6 tartalom, 7 szabályzat.
- Késleltetési értesítés (
delayed): ne küldje el újra. Olyan levelekről érkező bounce-ok, amelyeket nem küldött: backscatter.
Kvíz
Feladat
Feladat Z6.1: Három bounce elemzése. Kap három példa bounce-t (bounce-1.txt, bounce-2.txt és bounce-3.txt). Bounce-onként töltse ki: melyik cím esetében történt a hiba, melyik szerver adta a hibát (Remote-MTA), az állapotkódot, azt, hogy ideiglenes vagy végleges hibáról van-e szó, és mit kell tennie a feladónak (válasszon egy listából). A program egy rögzített kulcs alapján ellenőrzi a válaszokat, és mezőnként ad magyarázatot.
Továbbolvasás
Az ezekben a cikkekben leírt lépések a WebOké vezérlőpultjaira vonatkoznak; más szolgáltatóknál hasonlóan működik.
- Mail delivery failed: a hibaüzenet értelmezése és a kódok jelentése
- Hibaüzenet: 550 5.5.0 Requested action not taken: mailbox unavailable
- Levél kézbesítésének ellenőrzése az E-mail-követés funkcióval a DirectAdminban
- DirectAdmin útmutató 9.3: E-mail követés: hová lett az e-mailem?
- RFC 3464 (egy DSN felépítése), RFC 3463 (kibővített állapotkódok) és RFC 5321 4.2. szakasza (válaszkódok) és 4.5.4.1. szakasza (újrapróbálkozás)