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 sender
• Undelivered Mail Returned to Sender
• Delivery 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:

1. A fogadó szerver visszautasítja a levelet az SMTP-párbeszéd közben (1.2. lecke), például a RCPT TO utá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.
2. 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:

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

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:

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:

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 +0100

Ez 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 a Diagnostic-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: így olvassa ki a hibaüzenetet, és mit jelentenek a kódok
• 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)