Bouncebericht

De opmaak van dit artikel is nog niet in overeenstemming met de conventies van Wikipedia. Mogelijk is ook de spelling of het taalgebruik niet in orde. Men wordt uitgenodigd deze pagina aan te passen.
Opgegeven reden: Computervertaling vanuit het Engels

Een bouncebericht, of simpelweg "bounce", is een automatisch bericht van een e-mailsysteem dat de afzender van een eerder bericht informeert dat het bericht niet is afgeleverd (of dat er een ander afleveringsprobleem is opgetreden). Het originele bericht wordt gezegd te zijn "gebouncet".

Deze feedback kan direct zijn (zoals sommige van de hier beschreven oorzaken), of, als het verzendsysteem opnieuw kan proberen, kan het dagen later arriveren nadat deze pogingen zijn beëindigd.

Formelere termen voor een bounce-bericht zijn onder andere "Non-Delivery Report" of "Non-Delivery Receipt" (NDR), [mislukte] "Delivery Status Notification" (DSN) bericht, of een "Non-Delivery Notification" (NDN).

Classificatie

Hoewel SMTP een volwassen technologie is, met een geschiedenis van meer dan dertig jaar, wordt de architectuur steeds meer belast door zowel normaal als ongevraagd verkeer. E-mailsystemen zijn verbeterd met reputatiesystemen die gekoppeld zijn aan de werkelijke afzender van de e-mail, met als doel dat de e-mailservers van de ontvanger de e-mail weigeren wanneer een vervalste afzender in het protocol wordt gebruikt.

Daarom zijn er twee soorten e-mailbounces ontstaan: hard bounces en soft bounces. Beide beïnvloeden de IP-reputatie van de afzender, omdat de Email Service Providers (ESP's) de totale bouncepercentage beschouwen als een beslissingsfactor bij het richting geven van de e-mail naar postvak IN van een gebruiker. Kortom, het totale bouncepercentage wordt berekend als de som van het hardbouncepercentage en het softbouncepercentage.

Hard bounces

Hard bounces zijn permanent en veroorzaken aanzienlijke schade aan het IP van de afzender. Hard bounces doen zich voor wanneer de mailserver van de afzender vaststelt dat de kans groot is dat de ontvanger niet beschikbaar is en waarschijnlijk ook niet beschikbaar zal blijven. Enkele situaties waarin hard bounces optreden, zijn wanneer de ontvangers van de e-mail zich in een van de volgende situaties bevinden: onjuiste identificatie/onjuist domein (zoals een typfout in het e-mailadres of in het domein) of wanneer hun server geen e-mails meer accepteert. In dit geval is het verplicht om de e-mailadressen die terugkomen als bounces te verwijderen.

Soft bounces

Soft bounces zijn tijdelijk. Een gebouncet bericht dat een soft bounce ervaart, kan op een later tijdstip opnieuw worden bezorgd. Soft bounces komen voor wanneer de ontvanger van de e-mail een vol postvak IN heeft en er dus geen ruimte beschikbaar is om een andere e-mail op te slaan, of wanneer een limiet op de grootte van de e-mails die hij mag ontvangen is bereikt. Aanvullende situaties waarin een soft bounce voordoet, zijn een blokkade die is ingesteld op de e-mail van de ontvanger om een bepaalde afzender als 'spam' afzender te markeren, of om een bepaalde afzender op een zwarte lijst te zetten. Bovendien kunnen een tijdelijke opschorting van de e-mail van de ontvanger of een tijdelijke fout op de server ook oorzaken zijn van een zachte bounce.

Bezorgingsfouten

Fouten kunnen op verschillende plaatsen in de e-mailbezorging optreden. Een afzender kan soms een bounce-bericht van zijn eigen mailserver ontvangen, waarin wordt gerapporteerd dat het een bericht niet heeft kunnen verzenden, of van de mailserver van de ontvanger die meldt dat, hoewel het het bericht heeft geaccepteerd, het niet in staat is het aan de opgegeven gebruiker te bezorgen. Wanneer een server een bericht accepteert voor bezorging, aanvaardt deze ook de verantwoordelijkheid om een bounce-bericht te bezorgen in het geval de bezorging mislukt.

Bounce vanwege gebrek aan schijfruimte

Wanneer een e-mail aankomt bij de bestemmingsserver voor een adres (zoals mymail.example, bij het verzenden naar alice@mymail.example), kan het voorkomen dat de maildaemon de boodschap niet in de mailbox van de opgegeven gebruiker kan afleveren als de harde schijf van de server onvoldoende ruimte heeft.

Bounce vanwege onbereikbare bestemming

Bij het verzenden van een e-mail kan het voorkomen dat de dienst waarvan de e-mail wordt verstuurd het bestemmingsadres niet kan bereiken. In dat geval zou de afzender een bounce-bericht van zijn eigen mailserver ontvangen. Veelvoorkomende oorzaken waarom mailservers het bestemmingsadres niet kunnen bereiken:

Niet in staat om het bestemmingsadres op te lossen. Bijvoorbeeld, als de domeinnaam niet bestaat.

Niet in staat om een verbinding te maken met het bestemmingsadres. Bijvoorbeeld, als het IP-adres niet aan een server is toegewezen, of als de server offline is.

Terugsturen van vervalst bericht

Gebruikers kunnen foutieve bounce-berichten ontvangen over berichten die ze nooit daadwerkelijk hebben verzonden. Dit kan met name gebeuren in de context van e-mailspam of e-mailvirussen, waarbij een spammer (de afzender) een bericht kan vervalsen naar een andere gebruiker (de beoogde ontvanger van de spam) en het bericht laat lijken alsof het afkomstig is van weer een andere gebruiker (een derde partij). Als het bericht niet kan worden afgeleverd bij de beoogde ontvanger, wordt het bounce-bericht "teruggestuurd" naar de derde partij in plaats van naar de spammer. Dit wordt backscatter genoemd.

Andere oorzaken

Had de mailserver van library.example geweten dat het bericht onbezorgbaar zou zijn (bijvoorbeeld als Jill daar geen gebruikersaccount had), dan zou het bericht in de eerste plaats niet zijn geaccepteerd en zou er dus geen bounce zijn verzonden. In plaats daarvan zou het bericht zijn afgewezen met een SMTP-foutcode. Dit zou de mailserver van Jack (bij store.example) de verplichting opleggen om een bounce te genereren en te bezorgen.

Terminologie

Bounces zijn een speciale vorm van autoresponder. Automatische antwoorden (automatische reacties) zijn e-mails die door een programma worden verzonden—in tegenstelling tot een menselijke gebruiker—in antwoord op een ontvangen e-mail en worden verzonden naar het bounce-adres.

Voorbeelden van andere automatische antwoorden zijn vakantie-e-mails, uitdagingen van challenge-response spamfiltering, antwoorden van lijstservers en feedbackrapporten. Deze andere automatische antwoorden worden besproken in RFC 3834: automatische antwoorden moeten worden verzonden naar het Return-Path dat in de ontvangen e-mail staat, die de automatische reactie heeft getriggerd, en dit antwoord wordt doorgaans verzonden met een leeg Return-Path; anders kunnen autoresponders vast komen te zitten in het verzenden van automatische antwoorden heen en weer.

Het Return-Path is zichtbaar in afgeleverde e-mail als het headerveld Return-Path, dat is toegevoegd door de SMTP-mailbezorgagent (MDA) (dat meestal is gecombineerd met een mail transfer agent, of MTA). De MDA kopieert simpelweg het omgekeerde pad in de SMTP MAIL FROM-opdracht naar het Return-Path. De MDA verwijdert ook valse Return-Path headervelden die door andere MTA's zijn ingevoegd; dit headerveld garandeert over het algemeen dat het het laatste omgekeerde pad weerspiegelt dat in de MAIL FROM-opdracht is gezien.

Tegenwoordig worden deze paden normaal gesproken gereduceerd tot gewone e-mailadressen, aangezien de oude SMTP 'source routing' in 1989 is afgeschaft; voor wat historische achtergrondinformatie zie Sender Rewriting Scheme. Eén speciale vorm van een pad bestaat nog: het lege pad MAIL FROM:<>, dat wordt gebruikt voor veel automatische antwoorden en vooral voor alle bounces.

In strikte zin zijn bounces die zijn verzonden met een niet-leeg Return-Path onjuist. RFC 3834 biedt enkele heuristieken om onjuiste bounces te identificeren op basis van het lokale deel (linkerkant vóór de "@") van het adres in een niet-leeg Return-Path, en het definieert zelfs een mail header veld, Auto-Submitted, om automatische antwoorden te identificeren. Maar de mailheader is een onderdeel van de mailgegevens (SMTP-opdracht DATA), en MTA's kijken doorgaans niet naar de inhoud van de mail. Ze behandelen de envelop, die het MAIL FROM-adres omvat (ook wel Return-Path, Envelope-FROM of "omgekeerd pad" genoemd), maar niet bijvoorbeeld de RFC 2822-From in het mailheader veld From. Deze details zijn belangrijk voor schema's zoals BATV.

De overblijvende bounces met een leeg Return-Path zijn niet-bezorgingsrapporten (NDR's) of delivery status meldingen (DSN's). DSN's kunnen expliciet worden aangevraagd met een SMTP Service Extension, maar dit wordt niet veel gebruikt. Expliciete verzoeken om details over afleverfouten worden veel vaker geïmplementeerd met variable envelope return path (VERP), terwijl expliciete verzoeken daarvoor zeldzaam worden geïmplementeerd.

NDR's zijn een basisfunctie van SMTP. Zodra een MTA een e-mail heeft geaccepteerd voor doorsturen of aflevering, kan deze het niet stilletjes verwijderen ("drop"); het moet een bounce-bericht creëren en verzenden naar de afzender als de doorsturing of aflevering is mislukt.

Bouncen vs. afwijzen

Met uitzondering van MDA's sturen alle MTA's e-mails door naar een andere MTA. Deze volgende MTA is vrij om de e-mail te weigeren met een SMTP-foutmelding zoals "gebruiker onbekend", "quota overschreden", enz. Op dit punt moet de verzendende MTA het bericht bouncen, dat wil zeggen de afzender informeren. Een bounce kan ook ontstaan zonder een afwijzende MTA, of zoals RFC 5321 het verwoordt:

""Als een SMTP-server de taak heeft geaccepteerd om de e-mail door te sturen en later ontdekt dat de bestemming onjuist is of dat de e-mail om een andere reden niet kan worden bezorgd, dan MOET deze een 'onbezorgbare e-mail'-meldingsbericht opstellen en dit verzenden naar de afzender van de onbezorgbare e-mail (zoals aangegeven door het omgekeerde pad).""

Deze regel is essentieel voor SMTP: zoals de naam al zegt, is het een 'simpel' protocol, en het kan niet betrouwbaar functioneren als e-mail stilletjes verdwijnt in zwarte gaten. Daarom zijn bounces vereist om problemen te detecteren en op te lossen.

Stilletjes berichten verwijderen

Vandaag de dag kan het echter vaak voorkomen dat men voornamelijk spam-e-mails ontvangt, die meestal vervalste Return-Paths gebruiken. Het is dan vaak onmogelijk voor de MTA om de afzender te informeren, en het verzenden van een bounce naar het vervalste Return-Path zou een onschuldige derde partij treffen. Bovendien zijn er specifieke redenen waarom het beter is om een bericht stilletjes te verwijderen in plaats van het te weigeren (laat staan te bouncen):

Heuristisch gefilterde spam. Spamfilters zijn niet perfect. Het weigeren van spam op basis van inhoudsfiltering houdt in dat spammers een testomgeving krijgen waarin ze verschillende alternatieven kunnen proberen totdat ze inhoud vinden die de filter doorstaat.
Virussen en wormen. Meestal worden deze automatisch verzonden vanaf een geïnfecteerde machine. Aangezien een bounce een kopie van de worm zelf kan bevatten, kan dit bijdragen aan de verspreiding ervan.

Nogmaals citerend uit RFC 5321, sectie 6.2:

"Zoals besproken in Sectie 7.8 en Sectie 7.9 hieronder, is het in de praktijk toegestaan om e-mail te verwijderen zonder de afzender te notificeren. Het is echter extreem gevaarlijk en schendt een lange traditie en de verwachtingen van de gemeenschap dat e-mail ofwel wordt afgeleverd of wordt teruggestuurd. Als stilletjes berichten worden verwijderd op een misbruikelijke manier, kan dit gemakkelijk het vertrouwen in de betrouwbaarheid van de mailsystemen van het internet ondermijnen. Daarom moet stilletjes verwijderen van berichten alleen in overweging worden genomen in die gevallen waarin er zeer veel vertrouwen is dat de berichten ernstig frauduleus of op andere wijze ongepast zijn."

Het niet valideren van de afzender is een inherente tekortkoming in het huidige SMTP, dat geen gebruik meer maakt van de eerder genoemde afgeschafte source routes. Dit wordt aangepakt door verschillende voorstellen, het meest direct door BATV en SPF.

Oorzaken van een bouncebericht

Er zijn veel redenen waarom een e-mail kan bouncen. Een reden is als het ontvangeradres verkeerd gespeld is of simpelweg niet bestaat op het ontvangende systeem. Dit is een "gebruiker onbekend" conditie. Andere redenen zijn bijvoorbeeld uitputting van bronnen — zoals een volle schijf — of de afwijzing van het bericht door spamfilters. Daarnaast zijn er MUA's die gebruikers in staat stellen om een bericht op verzoek te "bouncen". Deze door de gebruiker geïnitieerde bounces zijn valse bounces; per definitie is een echte bounce geautomatiseerd en wordt deze uitgezonden door een MTA of MDA.

Bounce-berichten in SMTP worden verzonden met het enveloppe-afzenderadres <>, bekend als het null sender address. Ze worden vaak verzonden met een From:-headeradres van MAILER-DAEMON op de ontvangersite.

Typisch bevat een bounce-bericht verschillende stukken informatie om de oorspronkelijke afzender te helpen begrijpen waarom hun bericht niet werd bezorgd:

De datum en tijd waarop het bericht werd gebounced,
De identiteit van de mailserver die het heeft gebounced,
De reden waarom het is gebounced (bijv. gebruiker onbekend of mailbox vol),
De headers van het gebounceerde bericht, en
Een deel of de gehele inhoud van het gebounceerde bericht.

RFC 3463 beschrijft de codes die worden gebruikt om de reden voor het bouncen aan te geven. Veelvoorkomende codes zijn 5.1.1 (Onbekende gebruiker), 5.2.2 (Mailbox vol) en 5.7.1 (Afgewezen door beveiligingsbeleid/mailfilter).

Formaat

MTA's die betrokken zijn bij een *afwijzing* worden genoemd vanuit het perspectief van de *rapporterende MTA*. De namen van MTA's zijn vaak van het type *DNS*.

Het formaat voor het rapporteren van administratieve berichten is gedefinieerd door RFC 6522. Een DSN kan een MIME multipart/report-bericht zijn dat uit drie delen bestaat:

Een menselijk leesbare uitleg;
Een machine-parseerbaar bericht/bezorgstatus, een lijst van "naam: type; waarde"-regels die verschillende mogelijke velden aangeven; en
Het oorspronkelijke bericht, of een gedeelte daarvan, als een entiteit van het type message/rfc822.

Het tweede deel van een DSN is ook vrij leesbaar. Het is essentieel om te begrijpen welke MTA welke rol heeft gespeeld. De Reporting-MTA is verantwoordelijk voor het samenstellen en verzenden van de DSN.

Wanneer een Remote-MTA een bericht afwijst tijdens een SMTP-transactie, kan een veld Diagnostic-Code van het type smtp worden gebruikt om die waarde te rapporteren. Let op dat, naast de numerieke 3-cijferige waarde, de SMTP-respons zelf ook een menselijk leesbaar deel bevat. De informatie

Remote-MTA: dns; smtp.store.example [192.0.2.3]
Diagnostic-Code: smtp; 550 No such user here

wordt soms gerapporteerd als bijvoorbeeld

while talking to smtp.store.example [192.0.2.3]
>>> RCPT TO:<nonexistinguser@store.example>
<<< 550 No such user here

Zie ook

Sender Policy Framework (SPF)
DomainKeys Identified Mail (DKIM)
Eenvoudig e-mailoverdrachtprotocol (SMTP)

Verwante RFC's

RFC 5321 - Simple Mail Transfer Protocol
RFC 3461 - Simple Mail Transfer Protocol (SMTP) Service Extension voor bezorgingsstatus (DSNs)
RFC 6522 - Mediatype voor rapportage van systeemmeldingen
RFC 3463 - Uitgebreide statuscodes voor SMTP
RFC 3464 - Berichtformaat voor statusinformatie
RFC 3834 - Aanbevelingen voor automatische antwoorden voor e-mail
RFC 5337 - Internationale bezorgingsstatus en kennisgeving over beschikkingen

Externe links

Microsoft DSN's en NDR's in Exchange Server