Bounce-Nachricht – Wikipedia

Automatisierte Nachricht von einem E-Mail-System

EIN Bounce-Nachricht oder einfach “Bounce” ist eine automatisierte Nachricht von einem E-Mail-System, die den Absender über eine vorherige Nachricht informiert, dass die Nachricht nicht zugestellt wurde (oder ein anderes Zustellungsproblem aufgetreten ist). Die ursprüngliche Nachricht soll “abgeprallt” sein.

Diese Rückmeldung kann sofort erfolgen (einige der hier beschriebenen Ursachen) oder, falls das sendende System es erneut versuchen kann, Tage später nach Ende dieser Wiederholungsversuche eintreffen.

Formellere Begriffe für Bounce-Nachrichten sind “Non-Delivery Report” oder “Non-Delivery Receipt” (NDR). [Failed] DSN-Nachricht (Delivery Status Notification) oder NDN-Meldung (Non-Delivery Notification).^[1]

Bounces Klassifizierung[edit]

Obwohl das SMTP eine ausgereifte Technologie ist, die mehr als 30 Jahre zählt, wird die Architektur zunehmend sowohl von normaler als auch von unerwünschter Last belastet.^[2] Die E-Mail-Systeme wurden um Reputationssysteme erweitert, die an den tatsächlichen Absender der E-Mail gebunden sind. Die Idee, dass die E-Mail-Server des Empfängers E-Mails ablehnen, wenn ein gefälschter Absender im Protokoll verwendet wird.^[3] Daher wurden zwei Arten von E-Mail-Bounces erstellt: Hard-Bounces und Soft-Bounces.^[4] Beide wirken sich auf die IP-Reputation des Absenders aus, da die E-Mail-Dienstanbieter (ESPs) die gesamte Absprungrate als Entscheidungsfaktor betrachten, wenn sie die E-Mail in den Posteingang eines Benutzers leiten. Kurz gesagt wird die gesamte Absprungrate als die Summe der harten Absprungrate und der weichen Absprungrate berechnet.

Harte Sprünge[edit]

Harte Bounces sind permanent und erzielen einen höheren IP-Schaden des Absenders. Harte Bounces treten auf, wenn der Mailserver des Absenders feststellt, dass eine hohe Wahrscheinlichkeit besteht, dass der Empfänger nicht verfügbar ist, und dies wahrscheinlich auch bleibt. In einigen Fällen befindet sich der Empfänger der E-Mail in einer der folgenden Situationen: falsche Kennung / falsche Domain (z. B. Tippfehler in der E-Mail-Adresse oder in der Domain) oder sein Server akzeptiert dies nicht E-Mails mehr. In diesem Fall müssen die zurückgesendeten E-Mail-Adressen entfernt werden.

Weiche Sprünge[edit]

Weiche Sprünge sind vorübergehend. Es kann versucht werden, eine zurückgesendete Nachricht, die einen weichen Sprung erfährt, zu einem anderen Zeitpunkt erneut zuzustellen.^[5] Soft Bounces treten auf, wenn der Empfänger der E-Mail entweder über einen vollständigen Posteingang verfügt und daher keinen Platz zum Speichern einer weiteren E-Mail hat oder die Größe der E-Mails, die er empfangen darf, begrenzt ist. Zusätzliche Situationen, in denen ein weicher Absprung auftritt, sind Blockierungen in der E-Mail des Empfängers, mit denen ein bestimmter Absender als Spam-Absender markiert oder ein bestimmter Absender auf die schwarze Liste gesetzt wird. Darüber hinaus führt eine vorübergehende Unterbrechung der E-Mail des Empfängers oder ein vorübergehender Fehler auf seinen Servern dazu, dass ein weicher Sprung ausgelöst wird.

Lieferfehler[edit]

Bei der Postzustellung können an mehreren Stellen Fehler auftreten. Ein Absender kann manchmal eine Absprungnachricht von seinem Absender erhalten besitzen Mailserver, der meldet, dass keine Nachricht gesendet werden konnte, oder alternativ von a Empfänger Der Mailserver meldet, dass er die Nachricht zwar akzeptiert, aber nicht an den angegebenen Benutzer übermitteln kann. Wenn ein Server eine Nachricht zur Zustellung akzeptiert, übernimmt er auch die Verantwortung für die Zustellung einer Bounce-Nachricht, falls die Zustellung fehlschlägt.

Bounce aufgrund fehlenden Speicherplatzes[edit]

Wenn eine E-Mail für eine Adresse auf dem Zielserver eintrifft (z. B. mymail.example beim Senden an [email protected]) kann es sein, dass der Mail-Daemon die Nachricht nicht im Postfach des angegebenen Benutzers ablegen kann, wenn auf der zugrunde liegenden Festplatte des Servers nicht genügend Speicherplatz vorhanden ist.

Sprung wegen nicht erreichbarem Ziel[edit]

Beim Senden einer E-Mail kann der Dienst, von dem die E-Mail gesendet wird, möglicherweise die Zieladresse 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:

• Die Zieladresse kann nicht aufgelöst werden. Zum Beispiel, wenn der Domainname nicht existiert.
• Es kann keine Verbindung mit der Zieladresse hergestellt werden. Zum Beispiel, wenn die IP-Adresse keinem Server zugewiesen ist oder wenn der Server offline ist.

Von gefälschter Nachricht abprallen[edit]

Benutzer erhalten möglicherweise fehlerhafte Bounce-Nachrichten zu Nachrichten, die sie nie 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 und die Nachricht so fälschen kann, dass sie von einem anderen Benutzer (einem Dritten) angezeigt wird. . Wenn die Nachricht nicht an den vorgesehenen Empfänger übermittelt werden kann, wird die Absprungnachricht anstelle des Spammers an den Dritten “zurückgegeben”. Dies wird als Rückstreuung bezeichnet.

Andere Ursachen[edit]

Hatte die library.example Der Mailserver wusste, dass die Nachricht nicht zugestellt werden kann (wenn Jill dort beispielsweise kein Benutzerkonto hat) nicht Ich habe die Nachricht an erster Stelle akzeptiert und hätte daher den Absprung nicht gesendet. Stattdessen hätte es die Nachricht mit einem SMTP-Fehlercode abgelehnt. Das würde gehen Jacks Mailserver (at store.example) die Verpflichtung, einen Sprung zu erstellen und zu liefern.

Terminologie[edit]

Bounces sind eine spezielle Form des Autoresponders. Autoresponses (automatische Antworten) sind E-Mails, die von einem Programm – im Gegensatz zu einem menschlichen Benutzer – als Antwort auf eine empfangene E-Mail gesendet und an die Absprungadresse gesendet werden.

Beispiele für andere automatische Antworten sind Ferien Mails, Herausforderungen von Challenge-Response-Spam-Filterung, Antworten von Listenservern und Feedback-Berichten. Diese anderen automatischen Antworten werden in erläutert RFC 3834: Automatische Antworten sollten an die gesendet werden Return-Path angegeben in der empfangenen Mail, die die automatische Antwort ausgelöst hat, und diese Antwort wird normalerweise mit einem leeren Rückweg gesendet; Andernfalls könnten Auto-Responder beim Senden von Auto-Antworten hin und her gefangen sein.^{[citation needed]}

Das Return-Path ist in der zugestellten Mail als Headerfeld sichtbar Return-Path vom SMTP Mail Delivery Agent eingefügt (MDA) (was normalerweise mit a kombiniert wird Mail Transfer Agent, oder MTA). Der MDA kopiert einfach den umgekehrten Pfad in das SMTP MAIL FROM Befehl in die Return-Path. Der MDA entfernt auch Schwindel Return-Path Header-Felder, die von anderen MTAs eingefügt wurden; Es wird im Allgemeinen garantiert, dass dieses Header-Feld den letzten umgekehrten Pfad widerspiegelt, der in der MAIL FROM Befehl.

Heutzutage werden diese Pfade normalerweise auf normale E-Mail-Adressen reduziert, da das alte SMTP-Quellrouting 1989 veraltet war. Einige historische Hintergrundinformationen finden Sie unter Sender Rewriting Scheme. Eine spezielle Form eines Pfades existiert noch: der leere Pfad MAIL FROM:<>, wird für viele automatische Antworten und insbesondere für alle Bounces verwendet.

Im engeren Sinne werden Bounces mit einem nicht leeren gesendet Return-Path sind falsch. RFC 3834 bietet einige Heuristiken, um falsche Bounces basierend auf dem lokalen Teil (linke Seite vor dem “@”) der Adresse in einer nicht leeren Adresse zu identifizieren Return-Pathund es definiert sogar ein Mail-Header-Feld, Auto-Submitted, um automatische Antworten zu identifizieren. Der Mail-Header ist jedoch Teil der Mail-Daten (SMTP-Befehl) DATA), und MTAs sehen normalerweise nicht aus in die Post. Sie beschäftigen sich mit dem Briefumschlag, das schließt die ein MAIL FROM Adresse (aka Return-Path, Envelope-FROModer “umgekehrter Weg”), aber nicht z RFC 2822– –From im Feld Mailkopf From. Diese Details sind wichtig für Systeme wie BATV.

Der Rest springt mit einem leeren Return-Path sind Nichtzustellungsberichte ((NDRs) oder Lieferstatusbenachrichtigungen (DSNs). DSNs können explizit mit einer SMTP Service Extension (ESMTP) angefordert werden, sie werden jedoch nicht häufig verwendet. Explizite Anforderungen für Details zu Zustellungsfehlern werden viel häufiger mit VERP (Variable Envelope Return Path) implementiert, während explizite Anforderungen für diese selten implementiert werden.^[6]

NDRs sind eine grundlegende SMTP-Funktion. Sobald ein MTA eine E-Mail zur Weiterleitung oder Zustellung angenommen hat, kann er sie nicht stillschweigend löschen (“löschen”). Es muss eine Bounce-Nachricht erstellen und an die senden Urheber wenn die Weiterleitung oder Lieferung fehlgeschlagen ist.

Bouncing vs. Rejecting[edit]

Mit Ausnahme von MDAs leiten alle MTAs E-Mails an einen anderen MTA weiter. Dieser nächste MTA ist kostenlos ablehnen die Mail mit einer SMTP-Fehlermeldung wie “Benutzer unbekannt”, “Über Quote”usw. An dieser Stelle muss der sendende MTA Bounce die Nachrichtdh informieren ihren Urheber. Ein Sprung kann auch ohne einen ablehnenden MTA oder als auftreten RFC 5321 drückt es aus:

“Wenn ein SMTP-Server die Aufgabe der Weiterleitung der E-Mail angenommen 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 von wesentlicher Bedeutung: Wie der Name schon sagt, handelt es sich um ein “einfaches” Protokoll. Es kann nicht zuverlässig funktionieren, wenn E-Mails lautlos in schwarzen Löchern verschwinden. Daher sind Bounces erforderlich, um Probleme zu erkennen und zu beheben.

Nachrichten stillschweigend löschen[edit]

Heutzutage kann es jedoch üblich sein, hauptsächlich Spam-E-Mails zu erhalten, bei denen normalerweise gefälschte E-Mails verwendet werden Return-Paths. Es ist dann oft unmöglich für den MTA, den Urheber zu informieren und einen Abpraller an den Fälscher zu senden Return-Path würde einen unschuldigen Dritten treffen. Darüber hinaus gibt es bestimmte Gründe, warum es vorzuziehen ist, still zu sein fallen eher eine Nachricht als ablehnen es (geschweige denn prallen es):

• Heuristisch gefilterter Spam. Spamfilter sind nicht perfekt. Das Ablehnen 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 bestehen.
• Viren und Würmer. Meistens werden diese automatisch von einem infizierten Computer gesendet. Da ein Sprung eine Kopie des Wurms selbst enthalten kann, kann er zu seiner Verbreitung beitragen.

Nochmals zitieren RFC 5321, Abschnitt 6.2:

“Wie in Abschnitt 7.8 und Abschnitt 7.9 unten erläutert, ist das Löschen 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ückgesandt werden Wird es missbraucht, kann dies leicht das Vertrauen in die Zuverlässigkeit der Mail-Systeme des Internets untergraben. Daher sollte das stille Löschen 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 auf andere Weise unangemessen sind. “

Die Nichtvalidierung des Absenders ist ein inhärenter Fehler des heutigen SMTP, der ohne die zuvor erwähnten veralteten Quellrouten auskommt. Dies wird durch verschiedene Vorschläge angesprochen, am direktesten von BATV und SPF.

Ursachen einer Bounce-Nachricht[edit]

Es gibt viele Gründe, warum eine E-Mail abprallen kann. Ein Grund ist, wenn die Empfängeradresse falsch geschrieben ist oder auf dem empfangenden System einfach nicht vorhanden ist. Das ist ein Benutzer unbekannt Bedingung. Andere Gründe sind die Erschöpfung der Ressourcen – z. B. eine vollständige Festplatte – oder die Ablehnung der Nachricht aufgrund von Spamfiltern. Darüber hinaus gibt es MUAs, mit denen Benutzer eine Nachricht bei Bedarf “abprallen” können.^[7] Diese vom Benutzer initiierten Bounces sind gefälschte Bounces. Per Definition wird ein echter Sprung automatisiert und von einem MTA oder MDA ausgegeben.

Bounce-Nachrichten in SMTP werden mit der Absenderadresse des Umschlags gesendet <>, bekannt als Null Absenderadresse. Sie werden häufig mit einem gesendet From: Header-Adresse von MAILER-DAEMON am Empfängerort.

In der Regel enthält eine Bounce-Nachricht mehrere Informationen, damit der ursprüngliche Absender besser verstehen kann, warum seine Nachricht nicht zugestellt wurde:

• Das Datum und die Uhrzeit, zu der die Nachricht zurückgeschickt wurde,
• Die Identität des Mailservers, der ihn zurückgesendet hat,
• Der Grund, warum es zurückgeworfen wurde (z Benutzer unbekannt oder Postfach voll),
• Die Header der zurückgesendeten Nachricht und
• Ein Teil oder der gesamte Inhalt der zurückgesendeten Nachricht.

RFC 3463 beschreibt die Codes, die zur Angabe des Absprunggrunds verwendet werden. Allgemeine Codes sind 5.1.1 (Unbekannter Benutzer), 5.2.2 (Postfach voll) und 5.7.1 (Von Sicherheitsrichtlinie / E-Mail-Filter abgelehnt).

MTAs, die an a ablehnen sind nach dem Gesichtspunkt der benannt MTA melden. MTA-Namen sind oft vom Typ DNS.

Das Format für die Meldung von Verwaltungsnachrichten wird durch definiert RFC 6522. Ein DSN kann ein MIME sein mehrteilig / Bericht Nachricht bestehend aus drei Teilen:

1. eine vom Menschen lesbare Erklärung;
2. eine Maschine analysierbar Nachricht / Zustellstatus, 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 vom Typ message / rfc822.

Der zweite Teil eines DSN ist ebenfalls gut lesbar. Es ist wichtig zu verstehen, welcher MTA welche Rolle spielte. Das Reporting-MTA ist verantwortlich für das Erstellen und Senden des DSN.

Wenn ein Remote-MTA lehnt eine Nachricht während einer SMTP-Transaktion ab, ein Feld Diagnosecode vom Typ smtp kann verwendet werden, um diesen Wert zu melden. Beachten Sie, dass die SMTP-Antwort neben dem numerischen dreistelligen Wert selbst einen von 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 gemeldet als z.

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

Siehe auch[edit]

Verwandte RFCs[edit]

• RFC 5321 - Simple Mail Transfer Protocol
• RFC 3461 - SMTP-Service-Erweiterung (Simple Mail Transfer Protocol) für Zustellungsstatusbenachrichtigungen (DSNs)
• RFC 6522 - Der Multipart- / Berichtsmedientyp für die Berichterstellung von Verwaltungsnachrichten des Mailsystems
• RFC 3463 - Erweiterte Statuscodes für SMTP
• RFC 3464 - Ein erweiterbares Nachrichtenformat für Zustellstatusbenachrichtigungen
• RFC 3834 - Empfehlungen für automatische Antworten auf E-Mail
• RFC 5337 - Internationalisierte Lieferstatus- und Dispositionsbenachrichtigungen

Verweise[edit]

Externe Links[edit]