Bounce-Nachricht - Bounce message

Eine Bounce-Nachricht oder einfach nur "Bounce" ist eine automatisierte Nachricht von einem E-Mail- System, die den Absender einer vorherigen Nachricht darüber informiert, dass die Nachricht nicht zugestellt wurde (oder ein anderes Zustellproblem aufgetreten ist). Die ursprüngliche Nachricht soll "abgesprungen" sein.

Diese Rückmeldung kann sofort erfolgen (einige der hier beschriebenen Ursachen) oder, wenn das sendende System einen erneuten Versuch durchführen kann, Tage später eintreffen, nachdem diese Versuche beendet sind.

Formellere Begriffe für Unzustellbarkeitsnachrichten sind "Unzustellbarkeitsbericht" oder "Nichtzustellungsbestätigung" (NDR), [Failed] "Delivery Status Notification" (DSN) oder eine "Non-Delivery Notification" (NDN).

Bounces-Klassifizierung

Obwohl SMTP eine ausgereifte Technologie ist, die mehr als dreißig Jahre alt ist, wird die Architektur zunehmend sowohl durch normale als auch durch unaufgeforderte Last belastet. Die E-Mail-Systeme wurden um Reputationssysteme erweitert, die an den tatsächlichen Absender der E-Mail gebunden sind, mit der Idee, dass die E-Mail-Server des Empfängers E-Mails ablehnen, wenn ein gefälschter Absender im Protokoll verwendet wird. Daher wurden zwei Arten von E-Mail-Bounces erstellt: Hard Bounces und Soft Bounces. Beides wirkt sich auf die IP-Reputation des Absenders aus, da die E-Mail-Dienstanbieter (ESPs) die Gesamtabsprungrate als Entscheidungsfaktor beim Weiterleiten der E-Mail in den Posteingang eines Benutzers berücksichtigen. Kurz gesagt, die Gesamtabsprungrate wird als Summe aus der harten Absprungrate und der weichen Absprungrate berechnet.

Harte Sprünge

Hard Bounces sind permanent und punkten im Hinblick auf den IP-Schaden des Absenders höher. Hard Bounces treten auf, wenn der Mailserver des Absenders feststellt, dass der Empfänger mit hoher Wahrscheinlichkeit nicht erreichbar ist und auch bleiben wird. Einige der Fälle, in denen Hard Bounces auftreten, sind, wenn sich der Empfänger der E-Mail in einer der folgenden Situationen befindet: falsche Kennung/falsche Domain (z. B. ein Tippfehler in der E-Mail-Adresse oder in der Domain) oder sein Server akzeptiert nicht E-Mails mehr. In diesem Fall ist die Entfernung der zurückgesendeten E-Mail-Adressen zwingend erforderlich.

Weiche Sprünge

Soft Bounces sind temporär. Eine zurückgesendete Nachricht, die einen Soft Bounce erfährt, kann zu einem anderen Zeitpunkt erneut zugestellt werden. Soft Bounces treten auf, wenn der Empfänger der E-Mail entweder über einen vollen Posteingang und daher keinen Platz zum Speichern einer weiteren E-Mail verfügt oder die Größe der E-Mails, die er empfangen darf, begrenzt ist. Weitere Situationen, in denen ein Soft Bounce auftritt, ist eine Blockierung der E-Mail des Empfängers, um einen bestimmten Absender als "Spam"-Absender zu markieren oder einen bestimmten Absender auf die schwarze Liste zu setzen. Darüber hinaus kann auch eine vorübergehende Sperrung der E-Mail des Empfängers oder ein vorübergehender Fehler auf seinen Servern einen Soft Bounce auslösen.

Lieferfehler

Bei der E-Mail-Zustellung können an mehreren Stellen Fehler auftreten. Ein Absender kann manchmal eine Bounce-Nachricht von seinem eigenen Mailserver erhalten, in der er meldet, dass er eine Nachricht nicht senden konnte, oder alternativ vom Mailserver eines Empfängers, der meldet, dass er die Nachricht zwar angenommen, aber nicht an die angegebene Adresse zustellen kann Benutzer. Wenn ein Server eine Nachricht zur Zustellung annimmt, übernimmt er auch die Verantwortung, eine Bounce-Nachricht zuzustellen, falls die Zustellung fehlschlägt.

Bounce wegen Platzmangels

Wenn eine E-Mail für eine Adresse (wie mymail.example, wenn das Senden an den Zielserver ankommt alice@mymail.example ), kann es sein , dass die Mail - Dämon nicht in der Lage ist , die Nachricht in den angegebenen Benutzer-Mailbox , wenn die abzulagern Die zugrunde liegende Festplatte des Servers hat nicht genügend Speicherplatz.

Absprung wegen unerreichbarem Ziel

Beim Senden einer E-Mail kann der Dienst, von dem die E-Mail gesendet wird, die Zieladresse möglicherweise nicht erreichen. In diesem Fall würde der Absender eine Bounce-Nachricht von seinem eigenen Mailserver erhalten. Häufige Ursachen dafür, dass Mailserver ein Ziel nicht erreichen können:

  • Kann nicht lösen die Zieladresse. Zum Beispiel, wenn der Domänenname nicht existiert.
  • Es kann keine Verbindung mit der Zieladresse hergestellt werden. Zum Beispiel, wenn die IP-Adresse keinem Server zugewiesen ist oder der Server offline ist .

Bounce von gefälschter Nachricht

Benutzer erhalten möglicherweise fehlerhafte Bounce-Nachrichten über Nachrichten, die sie nie tatsächlich gesendet haben. Dies kann insbesondere im Zusammenhang mit E-Mail-Spam oder E-Mail-Viren geschehen , bei denen ein Spammer (Absender) eine Nachricht an einen anderen Benutzer (beabsichtigter Spam-Empfänger) fälschen kann und die Nachricht von einem anderen Benutzer (einem Dritten) fälscht. . Wenn die Nachricht nicht an den vorgesehenen Empfänger zugestellt werden kann, wird die Bounce-Nachricht an den Dritten statt an den Spammer "zurückgesendet". Dies wird als Rückstreuung bezeichnet .

Andere Ursachen

Hätte der Mailserver library.example gewusst, dass die Nachricht nicht zustellbar ist (z. B. wenn Jill dort kein Benutzerkonto hätte), dann hätte er die Nachricht gar nicht erst akzeptiert und den Bounce daher nicht gesendet. Stattdessen hätte es die Nachricht mit einem SMTP-Fehlercode abgelehnt. Dies würde Jacks Mailserver (bei store.example ) die Verpflichtung überlassen , einen Bounce zu erstellen und zuzustellen .

Terminologie

Bounces sind eine Sonderform des Autoresponders . Automatische Antworten (automatische Antworten) sind E-Mails, die von einem Programm – im Gegensatz zu einem menschlichen Benutzer – als Antwort auf eine empfangene E-Mail an die Bounce-Adresse gesendet werden .

Beispiele für andere automatische Antworten sind Urlaubsmails , Herausforderungen durch Challenge-Response-Spam-Filterung , Antworten von Listenservern und Feedback-Berichte . Diese anderen automatischen Antworten werden in RFC 3834 behandelt: automatische Antworten sollten an die Return-Pathin der empfangenen Mail angegebene Adresse gesendet werden, die die automatische Antwort ausgelöst hat, und diese Antwort wird normalerweise mit einem leeren Return-Pfad gesendet; andernfalls könnten Autoresponder darin gefangen sein, automatische Antworten hin und her zu senden.

Das Return-Pathist in der zugestellten Mail als Header-Feld sichtbar, Return-Pathdas vom SMTP Mail Delivery Agent ( MDA ) eingefügt wird (der normalerweise mit einem Mail Transfer Agent oder MTA kombiniert wird ). Der MDA kopiert einfach den umgekehrten Pfad im SMTP- MAIL FROMBefehl in die Return-Path. Der MDA entfernt auch gefälschte Return-PathHeader-Felder, die von anderen MTAs eingefügt wurden; Dieses Header-Feld spiegelt im Allgemeinen garantiert den letzten im MAIL FROMBefehl gesehenen Rückwärtspfad wider .

Heute sind diese Pfade werden in der Regel zu gewöhnlichen reduziert E - Mail - Adressen , wie die alte SMTP ‚ Source Routing ‘ wurde 1989 als veraltet; einige historische Hintergrundinformationen finden Sie unter Sender Rewriting Scheme . Eine spezielle Form eines Pfades existiert noch: der leere Pfad MAIL FROM:<>, der für viele automatische Antworten und insbesondere alle Bounces verwendet wird.

Im strengen Sinne sind Bounces, die mit einem nicht leeren Wert gesendet Return-Pathwerden, falsch. RFC 3834 bietet einige Heuristiken , um falsche Bounces basierend auf dem lokalen Teil (linke Seite vor dem "@") der Adresse in einem nicht leeren Return-Path, und es definiert sogar ein Mail-Header-Feld, Auto-Submittedum automatische Antworten zu identifizieren. Aber der Mail-Header ist ein Teil der Mail-Daten (SMTP-Befehl DATA), und MTAs schauen normalerweise nicht in die Mail. Sie befassen sich mit dem Umschlag , der die MAIL FROMAdresse (auch bekannt als Return-Path, Envelope-FROM, oder "reverse path") enthält, aber nicht zB den RFC 2822- Fromim Mail-Header-Feld From. Diese Details sind für Programme wie BATV wichtig .

Die verbleibenden Bounces mit einem LeerzeichenReturn-Path sind Unzustellbarkeitsberichte ( NDRs ) oder Zustellstatusbenachrichtigungen (DSNs). DSNs können mit einer SMTP-Diensterweiterung explizit angefordert werden, werden jedoch nicht häufig verwendet. Explizite Anfragen nach Details zu Zustellungsfehlern werden viel häufiger mit variablem Umschlagrücklauf (VERP) implementiert, während explizite Anfragen dafür selten implementiert werden.

Unzustellbarkeitsberichte sind eine grundlegende SMTP-Funktion. Sobald ein MTA eine Mail zur Weiterleitung oder Zustellung angenommen hat, kann er diese nicht stillschweigend löschen ("drop"); es hat zu erstellen und eine Bounce - Nachricht an den senden Absender ob die Weiterleitung oder die Lieferung nicht.

Aufprallen vs. ablehnen

Mit Ausnahme von MDAs leiten alle MTAs E-Mails an einen anderen MTA weiter. Diesem nächsten MTA steht es frei, die Mail mit einer SMTP-Fehlermeldung wie "Benutzer unbekannt" , "über Quota" usw. abzulehnen . An diesem Punkt muss der sendende MTA die Nachricht zurückweisen , dh seinen Absender informieren. Ein Bounce kann auch ohne einen ablehnenden MTA auftreten, oder wie es RFC 5321 formuliert:

"Wenn ein SMTP-Server die Aufgabe der Weiterleitung der E-Mail übernommen hat und später feststellt, dass das Ziel falsch ist oder die E-Mail aus einem anderen Grund nicht zugestellt werden kann, MUSS er eine Benachrichtigungsnachricht "Unzustellbare E-Mail" erstellen und an den Absender senden der unzustellbaren Post (wie durch den umgekehrten Pfad angegeben)."

Diese Regel ist für SMTP unerlässlich: Wie der Name schon sagt, handelt es sich um ein „einfaches“ Protokoll, das nicht zuverlässig funktionieren kann, wenn E-Mails stumm in schwarzen Löchern verschwinden, daher sind Bounces erforderlich, um Probleme zu erkennen und zu beheben.

Nachrichten stumm verwerfen

Heutzutage kann es jedoch üblich sein, hauptsächlich Spam- E-Mails zu erhalten , die normalerweise gefälschte Return-Paths verwenden. Für den MTA ist es dann oft unmöglich, den Urheber zu informieren, und das Senden eines Bounces an den Gefälschten Return-Pathwürde einen unschuldigen Dritten treffen. Darüber hinaus gibt es spezielle Gründe , warum es vorzuziehen ist , zu leise fallen eine Nachricht nicht ablehnen es (geschweige denn abprallen es):

  • Heuristisch gefilterter Spam . Spamfilter sind nicht perfekt. Das Zurückweisen von Spam basierend auf der Inhaltsfilterung bedeutet, dass Spammern eine Testumgebung zur Verfügung gestellt wird, in der sie verschiedene Alternativen ausprobieren können, bis sie Inhalte finden, die den Filter passieren.
  • Viren und Würmer . Meistens werden diese automatisch von einem infizierten Computer gesendet. Da ein Bounce eine Kopie des Wurms selbst enthalten kann, kann er zu seiner Verbreitung beitragen.

Nochmals RFC 5321, Abschnitt 6.2 zitieren:

„Wie in den Abschnitten 7.8 und 7.9 unten erörtert, ist das Verwerfen von E-Mails ohne Benachrichtigung des Absenders in der Praxis zulässig. Es ist jedoch äußerst gefährlich und verstößt gegen eine lange Tradition und die Erwartungen der Community, dass E-Mails entweder zugestellt oder zurückgesendet werden missbraucht wird, könnte es leicht das Vertrauen in die Zuverlässigkeit der Mail-Systeme des Internets untergraben. Daher sollte das stille Verwerfen von Nachrichten nur in den Fällen in Betracht gezogen werden, in denen ein sehr hohes Vertrauen besteht, dass die Nachrichten ernsthaft betrügerisch oder anderweitig unangemessen sind."

Den Absender nicht zu validieren ist ein inhärenter Fehler des heutigen SMTP, das ohne die zuvor erwähnten veralteten Quellrouten auskommt. Dies wird durch verschiedene Vorschläge angesprochen, die meisten direkt von BATV und SPF .

Ursachen einer Bounce-Nachricht

Es gibt viele Gründe, warum eine E-Mail abprallen kann. Ein Grund dafür ist, dass die Empfängeradresse falsch geschrieben ist oder auf dem empfangenden System einfach nicht existiert. Dies ist eine vom Benutzer unbekannte Bedingung. Andere Gründe sind die Erschöpfung von Ressourcen – beispielsweise eine volle Festplatte – oder die Ablehnung der Nachricht aufgrund von Spamfiltern . Darüber hinaus gibt es MUAs , die es Benutzern ermöglichen, eine Nachricht bei Bedarf „ zuzusenden “. Diese benutzerinitiierten Bounces sind gefälschte Bounces; per Definition ist ein echter Bounce automatisiert und wird von einem MTA oder MDA ausgegeben.

Unzustellbare Nachrichten in SMTP werden mit der Absenderadresse des Umschlags gesendet <>, die als Null-Absenderadresse bekannt ist . Sie werden häufig mit einer From:Kopfzeilenadresse von MAILER-DAEMONam Empfängerstandort gesendet .

Normalerweise enthält eine Bounce-Nachricht mehrere Informationen, die dem ursprünglichen Absender helfen, den Grund für die Nichtzustellung seiner Nachricht zu verstehen:

  • Das Datum und die Uhrzeit, zu der die Nachricht zurückgesendet wurde,
  • Die Identität des Mailservers, der sie zurückgesendet hat,
  • Der Grund für die Unzustellbarkeit (z. B. Benutzer unbekannt oder Postfach voll ),
  • Die Kopfzeilen der zurückgesendeten Nachricht und
  • Ein Teil oder der gesamte Inhalt der zurückgesendeten Nachricht.

RFC 3463 beschreibt die Codes, die verwendet werden, um den Bounce-Grund anzugeben. Gängige Codes sind 5.1.1 (Unbekannter Benutzer), 5.2.2 (Mailbox voll) und 5.7.1 (Von Sicherheitsrichtlinie/Mailfilter abgelehnt).

Format

An einer Ablehnung beteiligte MTAs werden entsprechend der Sichtweise des meldenden MTA benannt . MTA-Namen sind oft vom Typ dns .

Das Format für das Melden von Verwaltungsnachrichten wird durch RFC  6522 definiert . Ein DSN kann eine mehrteilige MIME- /Berichtsnachricht sein , die aus drei Teilen besteht:

  1. eine menschenlesbare Erklärung;
  2. eine maschinenlesbare Nachricht/ Lieferstatus , eine Liste von "Name: Typ; Wert" -Zeilen , die mehrere mögliche Felder angeben ; und
  3. die ursprüngliche Nachricht oder ein Teil davon als Entität des Typs message/rfc822 .

Auch der zweite Teil eines DSN ist gut lesbar. Es ist wichtig zu verstehen, welcher MTA welche Rolle gespielt hat. Der Reporting-MTA ist für das Verfassen und Versenden des DSN verantwortlich.

Wenn ein Remote-MTA eine Nachricht während einer SMTP-Transaktion ablehnt, kann ein Feld Diagnostic-Code vom Typ smtp verwendet werden, um diesen Wert zu melden. Beachten Sie, dass die SMTP-Antwort neben dem numerischen 3-stelligen Wert selbst einen für Menschen lesbaren Teil enthält. Die Information 

Remote-MTA: dns; smtp.store.example [192.0.2.3]
Diagnostic-Code: smtp; 550 No such user here
wird manchmal berichtet als z.
while talking to smtp.store.example [192.0.2.3]
>>> RCPT TO:<nonexistinguser@store.example>
<<< 550 No such user here

Siehe auch

Zugehörige RFCs

  • RFC  5321 - Simple Mail Transfer Protocol
  • RFC  3461 - Simple Mail Transfer Protocol (SMTP)-Diensterweiterung für Zustellungsstatusbenachrichtigungen (DSNs)
  • RFC  6522 - Der Multipart/Report-Medientyp für das Reporting von administrativen Nachrichten des Mailsystems
  • RFC  3463 - Erweiterte Statuscodes für SMTP
  • RFC  3464 - Ein erweiterbares Nachrichtenformat für Benachrichtigungen über den Zustellstatus
  • RFC  3834 - Empfehlungen für automatische Antworten auf elektronische Post
  • RFC  5337 - Internationalisierte Lieferstatus- und Dispositionsbenachrichtigungen

Verweise

Externe Links