Bounce Message
Eine Bounce Message (englisch bounce ‚abprallen‘, ‚zurückwerfen‘), auch Non Delivery Notification (NDN), Non-Delivery Report/Receipt (NDR) oder kurz Bounce genannt, ist eine Fehlermeldung, die von einem Mailserver automatisch erzeugt wird, wenn eine E-Mail nicht zustellbar ist. Sie ist eine von mehreren möglichen Ausprägungsarten der Delivery Status Notification (DSN).
Diese Fehlermeldung wird per E-Mail an den Absender (Envelope Sender) der unzustellbaren E-Mail gesendet und hat selbst einen leeren Envelope Sender (<>), um E-Mail-Loops zu verhindern. Als From: Adresse wird häufig die Adresse MAILER-DAEMON@mailserver oder POSTMASTER@mailserver verwendet.
Man unterscheidet zwischen Hardbounces, die durch permanente Fehler entstehen, zum Beispiel wenn die E-Mail-Adresse des Empfängers nicht existiert, und Softbounces, die bei temporären Problemen erzeugt werden, zum Beispiel wenn die Disk Quota des Postfachs des Empfängers ausgeschöpft oder die Festplatte voll ist.
Inhalt
[Bearbeiten | Quelltext bearbeiten]Eine Bounce Message enthält i. d. R. verschiedene Hinweise, die dem Absender der unzustellbaren E-Mail helfen herauszufinden, warum seine Nachricht nicht zustellbar war. Dazu gehören
- Datum und Uhrzeit, z. B.
Date: Mon, 20 Jun 2005 16:59:51 +0200 - Der Mailserver, der die Fehlermeldung erzeugt hat, z. B.
host mail.example.com [192.0.43.10] - Der Grund, aus dem die Nachricht unzustellbar war, z. B.
550 Diese E-Mail Adresse existiert nicht. sorry, no mailbox here by that name (#5.1.1) - Die Header der unzustellbaren E-Mail, z. B.
------ This is a copy of the message, including all the headers. ------ Return-path: <[email protected]> Received: from postmaster by mail.absen.der with local (Exim 4.41) id 1DkNkc-000OXB-Ib; Mon, 20 Jun 2005 16:59:50 +0200 Date: Mon, 20 Jun 2005 16:59:50 +0200 From: <[email protected]> To: [email protected] Cc: *deleted* Subject: Re: testing Message-ID: <[email protected]> References: <[email protected]> <[email protected]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <[email protected]>
- Die unzustellbare Nachricht oder deren Anfang
test - please reply.
Ursachen
[Bearbeiten | Quelltext bearbeiten]Häufige Ursachen für Bounce Messages sind fehlerhafte Adressierung, Filter oder Hardware-Probleme, zum Beispiel:
Fehlerhafte Adressierung
[Bearbeiten | Quelltext bearbeiten]550 sorry, no mailbox here by that name 550 Empfaenger unbekannt / recipient e-mail adress unknown 550 5.1.1 <SMTPchocolate_dai811013@****>... User unknown 550 Diese E-Mail Adresse existiert nicht. sorry, no mailbox here by that name (#5.1.1)
Filter
[Bearbeiten | Quelltext bearbeiten]550 relay not permitted 550 5.1.8 Only registered users may use this system 550 Mail was identified as spam 554 Relay access denied
Hardware-Probleme
[Bearbeiten | Quelltext bearbeiten]554 Error writing message to safe storage; message could not be stored to disk
Temporäre Probleme
[Bearbeiten | Quelltext bearbeiten]Auf temporäre Fehler sollte ein MTA nicht direkt mit einem Bounce reagieren, da davon auszugehen ist, dass zu einem späteren Zeitpunkt die Mail zugestellt werden kann. Der Mailserver behält Mails in diesem Fall in der Warteschlange und versucht periodisch diese zuzustellen. Erst wenn die Mail zu lange in der Warteschlange liegt, muss er einen Bounce schreiben und die Mail aus der Warteschlange löschen.
451 Temporary local problem - please try later 451 VS14-RT5 Mailbox bounce arrival rate exceeds system limit (#4.2.2) 450 <mail.X[X]>: Client host rejected: try again later
Probleme durch Unzustellbarkeitsnachrichten
[Bearbeiten | Quelltext bearbeiten]Blacklisting
[Bearbeiten | Quelltext bearbeiten]
Jeder Mailserver, der Unzustellbarkeitsnachrichten verschickt, läuft Gefahr, auf Schwarzen Listen (RBL) zu landen. Dieses Problem tritt verschärft bei sogenannten Joe-Jobs auf. Ein Server, der die Mails eines solchen Joe-Jobs annimmt und sie mit NDNs an existierende Adressen beantwortet, erzeugt eine große Menge kollateralen Spam. Dieser kollaterale Spam führt in vielen Fällen zum Eintrag auf verschiedenen RBL.
Die einzige wirksame Gegenmaßnahme ist es, Unzustellbarkeitsnachrichten nur an bekannte Absender zu versenden. Dies ist in der Regel nur dem Mailserver möglich, auf dem die E-Mail vom Mail-Client des Absenders eingeliefert wird. Dies ist auch der Grund dafür, dass kein Server Mails annehmen sollte, die er nicht weitertransportieren kann oder will. Anders gesagt: Unzustellbare E-Mails sollen bereits während des Empfangs (zur SMTP-Zeit) mit einem 500er Fehler abgewiesen werden. In diesem Fall muss der sendende Server den Bounce erzeugen. Handelt es sich bei dem sendenden Server um einen guten Server, ist das kein Problem, da dieser nur Mails von bekannten Absendern entgegennimmt und diesen die Unzustellbarkeitsnachricht demnach auch korrekt zustellen kann – ist es aber ein schlechter Server (z. B. Spam-Bot), wird er keine Unzustellbarkeitsnachrichten verschicken, da es ihm keinen Nutzen bringt und falls doch, gerät er (zu Recht) auf die schwarze Liste.
E-Mail-Loops
[Bearbeiten | Quelltext bearbeiten]Einige unsauber implementierte Mailserver erzeugen Unzustellbarkeitsnachrichten mit einem existierenden/zustellbaren Absender. Ist diese Unzustellbarkeitsnachricht ebenfalls unzustellbar, wird sie nicht wie üblich verworfen, sondern an den angegebenen Absender gesendet. Schickt nun der Server des Absenders erneut eine Unzustellbarkeitsnachricht (z. B. bei automatischen Antworten wegen Abwesenheit), ist der Kreis geschlossen.
Sicherheitsverletzungen
[Bearbeiten | Quelltext bearbeiten]Im Zusammenspiel mit der eingetragenen Antwortadresse für E-Mails können Bounces auch zu einem ernsthaften Sicherheitsproblem werden. So geben Administratoren gerne für E-Mails, welche nicht beantwortet werden sollen, eine nicht existente Adresse ein und nutzen nicht zu selten, speziell bei englischen E-Mails, dafür die Domain donotreply.com. Diese Domain ist allerdings registriert und hat einen Catch-All auf ihren E-Mail-Adressen. In letzter Konsequenz kann dies dazu führen, dass z. B. beim internen Versand von E-Mails innerhalb einer Firma, wenn eine @donotreply.com-Antwortadresse verwendet wird, die E-Mail durch einen Bounce nach außen weitergeleitet wird.
Zugehörige RFCs
[Bearbeiten | Quelltext bearbeiten]- K. Moore: RFC – Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs). Januar 2003 (löst ab, englisch).
- G. Vaudreuil: RFC – Enhanced Mail System Status Codes. Januar 2003 (löst ab, englisch).
- K. Moore, G. Vaudreuil: RFC – An Extensible Message Format for Delivery Status Notifications. Januar 2003 (löst ab, englisch).