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@mailserverPOSTMASTER@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: <[e-mail]>
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: <[e-mail]>
To: [e-mail]
Cc: *deleted*
Subject: Re: testing
Message-ID: <[e-mail]>
References: <DIIE.000004250005303D@mail.x.y> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>

• 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

This article or the following section is not adequately provided with supporting documents ( e.g. individual evidence ). Information without sufficient evidence could be removed soon. Please help Wikipedia by researching the information and including good evidence.

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

→ Main article : Email loop

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

See also

• Echo mailer