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

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: <postmaster@mail.example.org>
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: <postmaster@example.org>
To: postmaster@mail.example.com
Cc: *deleted*
Subject: Re: testing
Message-ID: <20050620145950.GZ61818@mail.example.org>
References: <DIIE.000004250005303D@mail.x.y> <20050614161552.GU3604@mail.example.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050614161552.GU3604@mail.example.org>

• Die unzustellbare Nachricht oder deren Anfang

test - please reply.

Ursachen

Häufige Ursachen für Bounce Messages sind fehlerhafte Adressierung, Filter oder Hardware-Probleme, zum Beispiel:

Fehlerhafte Adressierung

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

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

554 Error writing message to safe storage; message could not be stored to disk

Temporäre Probleme

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

Blacklisting

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

→ Hauptartikel: E-Mail-Loop

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

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

• K. Moore: RFC 3461 – Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs). Januar 2003 (löst RFC 1891 ab, englisch).
• G. Vaudreuil: RFC 3463 – Enhanced Mail System Status Codes. Januar 2003 (löst RFC 1893 ab, englisch).
• K. Moore, G. Vaudreuil: RFC 3464 – An Extensible Message Format for Delivery Status Notifications. Januar 2003 (löst RFC 1894 ab, englisch).

Siehe auch

• Echo-Mailer