Bouncen lukeminen

Moduuli 6: Virhepalautteet ja ongelmien ratkaisu · Lukuaika: 11 minuuttia

Oppimistavoite: Tämän oppitunnin jälkeen osaat erittää virheilmoituksen toimittamattomasta sähköpostista (bouncen): minkä palvelimen virhe oli, mille osoitteelle, mitä koodi tarkoittaa, ja onko kyseessä tilapäinen vai pysyvä virhe.

Keskeiset käsitteet: bounce, Mailer-Daemon, delivery status notification (DSN, RFC 3464), Reporting-MTA, Remote-MTA, Final-Recipient, Action (failed, delayed), Status, Diagnostic-Code, Will-Retry-Until, vastauskoodi (RFC 5321), laajennettu tilakoodi X.Y.Z (RFC 3463), viiveilmoitus, backscatter

Mikä on bounce?

Jos sähköpostipalvelin ei pysty toimittamaan viestiä, se lähettää viestin takaisin lähettäjälle. Tätä kutsutaan bounceksi (tai: non-delivery report, NDR). Se tulee lähettäjältä kuten Mailer-Daemon@..., MAILER-DAEMON tai Mail Delivery System, ja aiheena on esimerkiksi:

• Mail delivery failed: returning message to sender
• Undelivered Mail Returned to Sender
• Delivery Status Notification (Failure)
• Warning: message ... delayed 24 hours (tämä ei ole bounce vaan viiveilmoitus, katso jäljempänä)

Moni heittää tällaisen viestin heti pois tai säikähtää englanninkielistä tekstiä. Harmi, sillä bounce kertoo lähes aina täsmälleen, mikä meni pieleen. Pitää vain tietää, mistä katsoa.

Bouncella on aina tyhjä envelope sender (Return-Path: <>). Tämä on tarkoituksellista: bounce bouncesta voisi muuten aiheuttaa loputtoman silmukan (RFC 5321).

Kuka kieltäytyi vastaanottamasta viestiä?

Viesti kulkee vähintään kahden palvelimen kautta: oman palveluntarjoajasi ja vastaanottajan palvelimen. Bounce voi syntyä kahdessa tilanteessa:

1. Vastaanottava palvelin hylkää viestin SMTP-keskustelun aikana (oppitunti 1.2), esimerkiksi komennon RCPT TO jälkeen (osoite tuntematon) tai sisällön tarkistuksen jälkeen (roskaposti tai DMARC). Oma palvelimesi saa tämän hylkäyksen ja tekee siitä bouncen sinulle. Virhe tulee siis vastaanottajalta, mutta bounce omalta palvelimeltasi.
2. Oma palvelimesi luovuttaa, esimerkiksi koska vastaanottaja ei ole ollut tavoitettavissa useisiin päiviin, tai koska olet itse saavuttanut jonkin rajan.

Tämä ero on tärkeä: ensimmäisessä tapauksessa pitää selvittää, mikä ei kelvannut vastaanottajalle, toisessa tapauksessa ongelma on lähempänä kotia.

Ihmiselle luettava osa

Yläosassa on teksti ihmisille. Se vaihtelee sähköpostiohjelmiston mukaan, mutta sisältää lähes aina samat asiat:

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

Lue se näin:

Koneille luettava osa: DSN

Tekstin alla on yleensä ohjelmille tarkoitettu osa, delivery status notification (RFC 3464). Se on aina rakenteeltaan sama, mikä tekee siitä helposti luettavan:

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

Aivan alimpana on alkuperäinen viesti tai pelkät sen otsikkorivit. Siitä näkee, mikä viesti oli kyseessä, ja mitä lähettäjän osoitetta ja Return-Pathia käytettiin. Tämä on joskus avain ratkaisuun (katso DMARC-tapaus tehtävässä).

Koodien lukeminen

Koodeja on kahdenlaisia, ja yleensä molemmat esiintyvät bouncessa.

Vastauskoodi (RFC 5321): kolme numeroa, kuten 550 tai 451. Ensimmäinen numero on tärkein:

Laajennettu tilakoodi (RFC 3463): kolme pisteillä erotettua numeroa, kuten 5.1.1 tai 4.7.500. Ensimmäinen numero on jälleen 2, 4 tai 5. Toinen numero kertoo, missä ongelma on:

Kolmas numero on tarkka syy. Suuret vastaanottajat käyttävät siihen omia numeroitaan, kuten Gmail koodeilla 5.7.25, 5.7.30 ja Microsoft koodeilla 4.7.500 ja 5.7.509. Ne löytyvät niiden omasta dokumentaatiosta (oppitunti 6.2).

Nyrkkisääntö: koodi, joka alkaa 5:llä ja jonka keskellä on 7 (5.7.x), on lähes aina käytäntöön liittyvä kysymys: todennus, maine tai roskaposti. Uudelleenlähetys ei silloin auta, jotain pitää muuttaa.

Viivästynyt ei vielä tarkoita epäonnistunutta

Tilapäisen virheen (4xx) yhteydessä palvelimesi säilyttää viestin ja yrittää uudelleen. RFC 5321 suosittelee jatkamista vähintään neljä viiteen päivään, vähintään puolen tunnin välein yritysten välillä. Monet palvelimet lähettävät muutaman tunnin tai päivän kuluttua viiveilmoituksen:

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

Tämä tarkoittaa: älä lähetä uudelleen, palvelin yrittää itse vielä. Jos lähetät silti uudelleen, vastaanottaja saattaa saada viestin kahdesti. Jos se ei lopulta onnistu ennen Will-Retry-Until ajankohtaa, tulee silti oikea bounce, usein koodilla 4.4.7 (viesti vanhentui jonossa).

Väärät bouncet: backscatter

Saatko yhtäkkiä kymmeniä bounceja viesteistä, joita et koskaan lähettänyt? Katso silloin alkuperäisestä viestistä alimmasta osasta. Jos siellä on lähettäjänä oma verkkotunnuksesi, mutta palvelin ja teksti, joita et tunnista, roskapostittaja on käyttänyt osoitettasi lähettäjänä. Vastaanottajat lähettävät bouncensa sinulle. Tätä kutsutaan backscatteriksi.

Postilaatikkosi ei useinkaan ole silloin hakkeroitu (katso ero oppitunnista 3.4). Mikä auttaa: DMARC-käytäntö, joka tiukentuu vaihe vaiheelta (oppitunti 4.4), jotta vastaanottajat hylkäävät väärennetyn viestin ennen kuin siitä syntyy bounce. Tarkista kuitenkin lähetetyt-kansiostasi ja palveluntarjoajaltasi, ettei postilaatikostasi todella ole lähetetty mitään.

Käytännössä: miltä se näyttää

WebOkéssa näet bouncen lisäksi myös E-mail Trackingissa DirectAdminissa, mitä palvelin teki viestille: Delivered, Deferred tai Fail, sekä vastaanottavan palvelimen vastauksen. Muissa paneeleissa on usein vastaava sähköpostiloki tai "viestijälki"; Microsoft 365:ssä se on esimerkiksi viestien jäljitys. Kannattaa katsoa ensin sieltä, jos et saanut bouncea, tai jos joku kertoo, ettei viestisi tullut perille.

Yhteenveto

• Bounce tulee Mailer-Daemonilta ja sillä on tyhjä Return-Path. Lue se, se kertoo yleensä tarkalleen, mikä meni pieleen.
• Katso ensin, kuka antoi virheen (SMTP error from remote mail server = vastaanottaja) ja mille osoitteelle.
• Koneille luettavassa osassa: Action, Status, Remote-MTA ja etenkin Diagnostic-Code.
• Ensimmäinen numero: 4 = tilapäinen, 5 = pysyvä. Toinen numero: 1 osoite, 2 mailbox, 3 järjestelmä, 4 reititys, 5 protokolla, 6 sisältö, 7 käytäntö.
• Viiveilmoitus (delayed): älä lähetä uudelleen. Bouncet viesteistä, joita et lähettänyt: backscatter.

Tietovisa

Tehtävä

Tehtävä Z6.1: Kolmen bouncen erittely. Saat kolme esimerkkibouncea (bounce-1.txt, bounce-2.txt ja bounce-3.txt). Täytä jokaiselle bouncelle: osoite, jolle viesti ei mennyt perille, palvelin joka antoi virheen (Remote-MTA), tilakoodi, onko se tilapäinen vai pysyvä, ja mitä lähettäjän tulee tehdä (valitse listalta). Ohjelma tarkistaa vastaukset kiinteällä avaimella ja antaa selityksen jokaisesta kentästä.

Lue lisää

Näiden artikkelien vaiheet koskevat WebOkén paneeleja; muilla palveluntarjoajilla toiminta on vastaavaa.

• Mail delivery failed: näin luet virheilmoituksen ja mitä koodit tarkoittavat
• Virheilmoitus: 550 5.5.0 Requested action not taken: mailbox unavailable
• Sähköpostin perillemenon tarkistaminen DirectAdminin Email Tracking -toiminnolla
• DirectAdmin-ohje 9.3: E-mail Tracking: mihin sähköpostini katosi?
• RFC 3464 (DSN:n rakenne), RFC 3463 (laajennetut tilakoodit) ja RFC 5321 kappale 4.2 (vastauskoodit) ja 4.5.4.1 (uudelleenyritys)