En bounce læse

Modul 6: Bounces og fejlfinding · Læsetid: 11 minutter

Læringsmål: Efter denne lektion kan du analysere en fejlmelding om en mail der ikke blev leveret (en bounce): hvilken server gav fejlen, for hvilken adresse, hvad koden betyder, og om den er midlertidig eller permanent.

Nøglebegreber: bounce, Mailer-Daemon, delivery status notification (DSN, RFC 3464), Reporting-MTA, Remote-MTA, Final-Recipient, Action (failed, delayed), Status, Diagnostic-Code, Will-Retry-Until, svarkode (RFC 5321), udvidet statuskode X.Y.Z (RFC 3463), udsættelsesmeddelelse, backscatter

Hvad er en bounce?

Hvis en mailserver ikke kan levere en mail, sender den en besked tilbage til afsenderen. Det kaldes en bounce (eller: non-delivery report, NDR). Den kommer fra en afsender som Mailer-Daemon@..., MAILER-DAEMON eller Mail Delivery System, med et emne som:

• Mail delivery failed: returning message to sender
• Undelivered Mail Returned to Sender
• Delivery Status Notification (Failure)
• Warning: message ... delayed 24 hours (dette er ikke en bounce men en udsættelsesmeddelelse, se nedenfor)

Mange smider sådan en besked ud med det samme, eller bliver skræmt af den engelske tekst. Det er ærgerligt, for en bounce fortæller næsten altid præcis hvad der er galt. Du skal bare vide hvor du skal kigge.

En bounce har altid en tom envelope sender (envelope-afsender) (Return-Path: <>). Det er bevidst: en bounce på en bounce ville ellers kunne give en uendelig løkke (RFC 5321).

Hvem afviste mailen?

En mail passerer mindst to servere: din udbyders og modtagerens. En bounce kan opstå i to situationer:

1. Den modtagende server afviser mailen under SMTP-samtalen (lektion 1.2), for eksempel efter RCPT TO (ukendt adresse) eller efter indholdet (spam eller DMARC). Din egen server modtager den afvisning og laver en bounce til dig. Fejlen kommer altså fra modtageren, bouncen fra din egen server.
2. Din egen server giver op, for eksempel fordi modtageren ikke kunne nås i flere dage, eller fordi du selv har nået en grænse.

Forskellen er vigtig: i det første tilfælde skal du vide hvad modtageren ikke kunne lide, i det andet tilfælde ligger problemet tættere på dig selv.

Den læsbare del

Øverst står en tekst til mennesker. Den varierer efter mailsoftware, men indeholder næsten altid de samme ting:

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

Læs det sådan:

Maskindelen: DSN'en

Under teksten står der som regel en del til programmer, delivery status notification (RFC 3464). Den er altid bygget op på samme måde, hvilket gør den nem at læse:

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

Helt nederst står den oprindelige mail eller kun dens headere. Der kan du se hvilken mail det var, og hvilken afsenderadresse og hvilken Return-Path der blev brugt. Det er nogle gange nøglen til løsningen (se DMARC-eksemplet i opgaven).

Læs koderne

Der er to slags koder, og som regel står de begge i en bounce.

Svarkoden (RFC 5321): tre cifre, som 550 eller 451. Det første ciffer er det vigtigste:

Den udvidede statuskode (RFC 3463): tre tal med punktummer, som 5.1.1 eller 4.7.500. Det første tal er igen 2, 4 eller 5. Det andet tal fortæller hvor problemet ligger:

Det tredje tal er den præcise grund. Store modtagere bruger deres egne numre til dette, som Gmail med 5.7.25 til 5.7.30 og Microsoft med 4.7.500 og 5.7.509. De står i deres egen dokumentation (lektion 6.2).

Tommelfingerregel: koden der begynder med 5 og har et 7 i midten (5.7.x) er næsten altid et politisk spørgsmål: autentificering, omdømme eller spam. Der hjælper det ikke at sende igen; der skal ændres noget.

Udskudt er ikke det samme som mislykket

Ved en midlertidig fejl (4xx) gemmer din server mailen og forsøger igen. RFC 5321 anbefaler at holde ved i mindst fire til fem dage, med mindst en halv time mellem forsøgene. Mange servere sender efter et par timer eller efter en dag en udsættelsesmeddelelse:

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

Det betyder: send ikke igen, serveren forsøger selv stadig. Sender du den alligevel igen, risikerer modtageren at få den to gange. Lykkes det til sidst ikke før Will-Retry-Until, kommer der alligevel en rigtig bounce, ofte med 4.4.7 (besked udløbet i køen).

Falske bounces: backscatter

Får du pludselig snesevis af bounces for mails du aldrig har sendt? Kig så i den oprindelige mail nederst. Står der en afsender fra dit domæne, men en server og tekst du ikke kender, så har en spammer brugt din adresse som afsender. Modtagerne sender deres bounces til dig. Det kaldes backscatter.

Din postkasse er som regel ikke hacket i det tilfælde (se lektion 3.4 for forskellen). Det der hjælper: en DMARC-politik der trin for trin bliver strengere (lektion 4.4), så modtagere afviser forfalsket mail før der opstår en bounce. Tjek dog i din sendte mail og hos din udbyder om der virkelig ikke er sendt noget fra din postkasse.

I praksis: sådan ser det ud

Hos WebOké kan du ud over bouncen også se i E-mailsporing i DirectAdmin hvad serveren gjorde med en besked: Leveret, Udskudt eller Fejl, med svaret fra den modtagende server. Andre kontrolpaneler har ofte en lignende maillog eller "beskedsporing"; hos Microsoft 365 hedder det for eksempel meddelelsessporing. Det er praktisk at kigge der først hvis du ikke har en bounce, eller hvis nogen siger at din mail ikke er kommet frem.

Opsummering

• En bounce kommer fra Mailer-Daemon og har en tom Return-Path. Læs den, den fortæller som regel præcis hvad der er galt.
• Kig først på hvem der gav fejlen (SMTP error from remote mail server = modtageren) og for hvilken adresse.
• I maskindelen: Action, Status, Remote-MTA og især Diagnostic-Code.
• Første ciffer: 4 = midlertidig, 5 = permanent. Andet tal: 1 adresse, 2 postkasse, 3 system, 4 rute, 5 protokol, 6 indhold, 7 politik.
• Udsættelsesmeddelelse (delayed): send ikke igen. Bounces for mail du ikke sendte: backscatter.

Quiz

Opgave

Opgave Z6.1: Analyser tre bounces. Du får tre eksempelbounces (bounce-1.txt, bounce-2.txt og bounce-3.txt). Udfyld for hver bounce: adressen hvor det gik galt, serveren der gav fejlen (Remote-MTA), statuskoden, om det er midlertidigt eller permanent, og hvad afsenderen skal gøre (vælg fra en liste). Programmet kontrollerer med en fast facitliste og giver forklaring for hvert felt.

Læs mere

Trinene i disse artikler gælder for WebOkés kontrolpaneler; hos andre udbydere fungerer det på lignende måde.

• Mail delivery failed: sådan læser du fejlmeddelelsen, og hvad koderne betyder
• Fejlmeddelelse: 550 5.5.0 Requested action not taken: mailbox unavailable
• Kontroller, om en e-mail er kommet frem, med e-mailsporing i DirectAdmin
• DirectAdmin vejledning 9.3: E-mailsporing: hvor er min mail blevet af?
• RFC 3464 (opbygning af en DSN), RFC 3463 (udvidede statuskoder), RFC 5321 afsnit 4.2 (svarkoder) og 4.5.4.1 (forsøg igen)