Bounce message
A bounce message ( English bounce , bounce ',' throw back '), and Non Delivery Notification (NDN) , Non-Delivery Report / Receipt (NDR) or short Bounce called, is an error message from a mail server is created automatically when an e-mail cannot be delivered. It is one of several possible types of delivery status notification (DSN).
This error message is sent by e-mail to the sender ( envelope sender ) of the undeliverable e-mail and has an empty envelope sender ( <>
) itself to prevent e-mail loops . The From:
address or is often used as the address .
MAILER-DAEMON@mailserver
POSTMASTER@mailserver
A distinction is made between hard bounces , which are caused by permanent errors, for example if the recipient's e-mail address does not exist, and soft bounces , which are generated in the event of temporary problems, for example when the disk quota of the recipient's mailbox is exhausted or the hard disk is full is.
content
A bounce message contains i. d. Usually various pointers that help the sender of the undeliverable e-mail to find out why his message was undeliverable. This includes
- Date and time, e.g. B.
Date: Mon, 20 Jun 2005 16:59:51 +0200
- The mail server that generated the error message, e.g. B.
host mail.example.com [192.0.43.10]
- The reason the message was undeliverable, e.g. B.
550 Diese E-Mail Adresse existiert nicht. sorry, no mailbox here by that name (#5.1.1)
- The headers of the undeliverable email, e.g. 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>
- The undeliverable message or its beginning
test - please reply.
causes
Common causes of bounce messages are incorrect addressing, filters or hardware problems, for example:
Incorrect addressing
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 problems
554 Error writing message to safe storage; message could not be stored to disk
Temporary problems
An MTA should not react directly to temporary errors with a bounce, since it can be assumed that the mail can be delivered at a later point in time. In this case, the mail server keeps mails in the queue and tries to deliver them periodically. Only if the mail has been in the queue for too long does he have to write a bounce and delete the mail from the queue.
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
Bounce issues
Blacklisting
Any mail server that sends bounce messages runs the risk of ending up on black lists (RBL) . This problem is exacerbated with so-called Joe jobs . A server that accepts the mails of such a Joe job and replies to them with NDNs to existing addresses generates a large amount of collateral spam . This collateral spam leads in many cases to entries on different RBLs.
The only effective countermeasure is to only send non-delivery messages to known senders. This is usually only possible on the mail server on which the e-mail is delivered from the sender's mail client . This is also the reason why no server should accept mail that it cannot or does not want to forward. In other words: Undeliverable e-mails should be rejected with a 500 error while they are being received (at SMTP time). In this case, the sending server must generate the bounce. If the sending server is a good server, this is not a problem, as it only receives mails from known senders and can therefore correctly deliver the undeliverable message to them - but if it is a bad server (e.g. spam bot) , he will not send bounce messages as it will not do him any good and if it does, he will (rightly) be blacklisted.
Email loops
Some improperly implemented mail servers generate undeliverable messages with an existing / deliverable sender. If this undeliverable message is also undeliverable, it will not be discarded as usual, but sent to the specified sender. If the sender's server sends another bounce message (e.g. in the case of automatic replies due to absence), the circle is complete.
Security breaches
In conjunction with the entered reply address for e-mails, bounces can also become a serious security problem. Administrators like to enter a nonexistent address for e-mails that should not be answered and often use the donotreply.com domain, especially for English e-mails . However, this domain is registered and has a catch-all on its e-mail addresses. Ultimately, this can lead to z. B. When sending e-mails internally within a company, if a @ donotreply.com reply address is used, the e-mail is forwarded to the outside through a bounce .
Associated RFCs
- RFC 3461 - Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)
- RFC 3463 - Enhanced Mail System Status Codes
- RFC 3464 - An Extensible Message Format for Delivery Status Notifications