NDR, DSN, Bounce: Slik skiller du korrekt mellom meldinger om mislykket levering

En e-post kommer ikke frem, og i saken står det enten «Bounce», «NDR», «Mailer-Daemon» eller «feilmelding fra serveren». I administrasjonshverdagen brukes disse begrepene om hverandre, selv om de betegner ulike ting: En reject i SMTP-økten er ikke en retur-e-post, en forsinkelsesmelding er ikke en leveringsfeil, og en lesebekreftelse har ingenting med manglende levering å gjøre. Den som skiller begrepene klart, finner årsaken raskere, fordi hver meldingstype sier noe forskjellig om hvor i transportveien problemet ligger, og hvem som kan løse det.

DSN: overbegrepet fra RFC-ene

Det formelle overbegrepet heter Delivery Status Notification (DSN), definert i RFC 3461 til 3464. En DSN er en maskinelt generert e-post som informerer avsenderen om leveringsstatusen til meldingen. Viktig: En DSN rapporterer ikke bare feil. Feltet Action i den maskinlesbare delen har fem verdier:

Meldingen om mislykket levering er altså bare et spesialtilfelle: en DSN med Action: failed. Microsoft kaller nettopp dette spesialtilfellet en Non-Delivery Report (NDR). Begrepet NDR stammer fra Exchange-verdenen, men brukes nå på tvers av leverandører. Presist formulert: Alle NDR-er er DSN-er, men ikke alle DSN-er er NDR-er.

Forsinkelsesmeldingen (Action: delayed) fortjener særlig oppmerksomhet, fordi den regelmessig misforstås som en leveringsfeil i supportarbeid. Et typisk emne er «Delivery delayed» eller «Levering forsinket». E-posten ligger da fortsatt i køen på den sendende serveren, som fortsetter å forsøke, vanligvis i én til to dager. Først når køens levetid utløper, følger den endelige NDR-en. En bruker som sender e-posten på nytt etter en forsinkelsesmelding, oppretter duplikater så snart målsystemet er tilgjengelig igjen.

Reject eller bounce: det viktigste skillet

Før de øvrige begrepene følger, må det sentrale tekniske veiskillet forklares, siden det avgjør hvilken server som genererer en melding.

Reject (avvisning i økten): Den mottakende serveren avviser e-posten allerede under SMTP-økten, med en 5xx-svarkode på RCPT TO eller etter DATA. Den tar aldri imot e-posten og genererer heller ingen egen returmelding. Plikten til å informere avsenderen ligger hos den innleverende serveren: Den sendende MTA-en ser 5xx-svaret og genererer deretter NDR-en for sin lokale bruker. NDR-en brukeren leser, kommer i dette tilfellet fra egen server, men siterer feilmeldingen fra motparten.

Bounce (aksept med senere returmelding): Den mottakende serveren aksepterer e-posten med 250 OK og fastslår først etterpå at den ikke kan levere den, for eksempel fordi postboksen ikke finnes, kvoten er full eller en underordnet server avviser den. Nå har den ansvaret for meldingen og må selv sende en DSN til avsenderen. Denne påfølgende retur-e-posten er en bounce i snever forstand.

For feilsøking kan forskjellen brukes direkte: Hvis egen server står oppført som genererende system i NDR-en, ble e-posten avvist i økten eller kom aldri ut. Hvis en ekstern server står som avsender av meldingen, har motparten først akseptert e-posten, og problemet ligger bak dens akseptpunkt, usynlig for avsenderen.

To ytterligere bounce-begreper kommer fra markedsføringsmiljøet og står ikke i noen RFC: Hard Bounce for endelige feil (5xx, Action: failed) og Soft Bounce for midlertidige feil (4xx, Action: delayed). For e-postplattformene er skillet sentralt, fordi Hard Bounces bør føre til umiddelbar opprydding i lister. Teknisk sett er dette de samme mekanismene som ovenfor.

Begrepene i oversikt

Slik er en DSN bygget opp

Standardkonforme DSN-er bruker MIME-typen multipart/report; report-type=delivery-status med tre deler: en menneskelesbar forklaring, en maskinlesbar del av typen message/delivery-status og eventuelt originalmeldingen eller headerne dens. Den maskinlesbare delen er den mest verdifulle for diagnostikk, fordi feltene er standardiserte:

Reporting-MTA: dns; mail01.example.net
Received-From-MTA: dns; client.example.org

Final-Recipient: rfc822; max.muster@example.com
Action: failed
Status: 5.1.1
Remote-MTA: dns; mx.example.com
Diagnostic-Code: smtp; 550 5.1.1 <max.muster@example.com>:
    Recipient address rejected: User unknown

En DSN sendes alltid med tom envelope-avsender (MAIL FROM:<>). Dette er ikke en forsømmelse, men et krav i RFC 5321: Den tomme avsenderen hindrer at en DSN for en ikke-leverbar DSN følger, og at to servere sender feilmeldinger til hverandre uten ende. Dette gir en konfigurasjonsregel: Et e-postsystem må ikke avvise e-post med tom envelope-avsender generelt, ellers kommer legitime meldinger om mislykket levering aldri frem til egne brukere.

Exchange og Exchange Online følger standarden for formatet, men pakker innholdet i sin egen presentasjon: Brukeren ser en klargjort side med forklaring i klartekst, etterfulgt av «Generating server» (tilsvarer Reporting-MTA) og rådataene. For diagnostikk er det alltid verdt å se på denne nedre, tekniske delen.

Slik leser du Enhanced Status Codes

I feltet Status og vanligvis også i Diagnostic-Code står det en tredelt kode etter RFC 3463: klasse.emne.detalj. Klassen angir bindende status, mens emne og detalj angir årsaken:

Den klassiske tresifrede SMTP-svarkoden (for eksempel 550) og Enhanced Status Code står ofte sammen på én linje: 550 5.7.1 .... Den tresifrede koden styrer protokollatferden til den sendende serveren, mens den utvidede koden gir den diagnostiske informasjonen. Ved motsetninger mellom kode og fritekst er motpartens fritekst ofte den mer presise kilden, fordi mange systemer setter generiske koder og skriver den faktiske årsaken i kommentaren, inkludert referanse-ID-er for support hos motparten.

Merk: Avvisninger med 5.7.x fra omdømme- og innholdsfiltre sier ofte bevisst lite. Den som bare ser på koden her, leter på feil sted; blokkeringslisten eller filterprodusenten i friteksten leder raskere til målet.

Backscatter: den skadelige typen bounce

Backscatter oppstår når en server først aksepterer spam med forfalsket avsender og deretter sender en NDR til den forfalskede adressen. NDR-en treffer dermed en uvedkommende hvis adresse spammeren har misbrukt. Ved store spamkampanjer mottar de berørte tusenvis av NDR-er for e-poster de aldri har sendt, og servere som genererer slike NDR-er i stort omfang, havner selv på blokkeringslister (for eksempel Backscatterer-listen fra UCEPROTECT).

Løsningen følger direkte av skillet mellom reject og bounce: Alt som kan avvises, skal avvises i SMTP-økten, ikke sendes tilbake etter aksept. Konkret betyr det mottakervalidering ved det ytterste akseptpunktet (edge-gatewayen kjenner de gyldige adressene, via katalogoppslag eller Recipient Callout, i stedet for å akseptere alt og la det feile internt), avvisning av spam og skadelig programvare under økten i stedet for karantene-NDR-er, og å avstå fra NDR-er for meldinger klassifisert som spam. En reject skaper ikke backscatter, for med forfalsket avsender mottar spammerens server 5xx-svaret og lager ingen NDR til offeret av det.

Hva som ikke er en melding om mislykket levering

Tre meldingstyper havner regelmessig i samme kategori i saker, men hører ikke hjemme der:

MDN (Message Disposition Notification, RFC 8098): Lesebekreftelsen. Den genereres ikke av transportsystemet, men av mottakerens e-postklient, og rapporterer visning eller sletting av meldingen, ikke levering. MIME-typen heter derfor multipart/report; report-type=disposition-notification. En uteblitt lesebekreftelse sier ingenting om leveringen; de fleste klienter spør brukeren eller undertrykker MDN-er helt.

Fraværsmeldinger og autosvar (RFC 3834): En fraværsmelding beviser det motsatte av en leveringsfeil, fordi den forutsetter at e-posten har nådd postboksen. I saksbeskrivelser («jeg får et automatisk svar, kommer e-posten min frem?») er det verdt å spørre hvilken melding som faktisk foreligger.

Karantenevarsler: Meldinger som karantenesammendraget fra Microsoft 365 eller en gateway informerer mottakeren om tilbakeholdte e-poster. De går til mottakeren, ikke avsenderen, og følger ingen DSN-standard. Avsenderen mottar ofte ingenting i dette scenariet, noe som forklarer tilfellene der en e-post «forsvinner uten feilmelding».

Sjekkliste for diagnostikk

Hvis en melding foreligger, avklar dette i følgende rekkefølge:

1. Hvilken type er det: NDR (Action: failed), forsinkelse (Action: delayed), MDN, autosvar eller karantenevarsel? Ved en forsinkelsesmelding: vent, ikke send på nytt.
2. Hvem genererte meldingen (Reporting-MTA eller «Generating server»)? Egen server betyr reject eller intern feil, en ekstern server betyr aksept med senere feil hos motparten.
3. Hva sier status- og Diagnostic-koden? Klasse 4 kontra klasse 5 skiller midlertidig fra endelig, emnet (x.1 adresse, x.2 postboks, x.4 nettverk, x.7 retningslinjer) avgrenser årsaken, og motpartens fritekst gir detaljene.
4. Mangler enhver melding selv om e-posten ikke kommer frem: Kontroller Message Tracking på eget system og tenk på karantene eller stille filtrering hos motparten.

Hvordan individuelle leveringsveier deretter kan gjenskapes målrettet, viser artiklene om Message Tracking og SMTP-diagnostikk i kommandogeneratoren samt Mail Header Analyzer for analyse av transportveien til en mottatt e-post.