Bounce Message

A bounce message (english bounce, bounce ',' throw back '), also Non Delivery Notification ( NDN ) or shortly called Bounce, is an error message that is generated automatically from a mail server when an email is undeliverable. It is one of several possible modes of expression Delivery Status Notification (DSN).

This error message is sent by e- mail to the sender ( envelope sender ) of undeliverable e-mail and even has an empty envelope sender (<>) to prevent email loops. As From: MAILER- DAEMON address is the address @ mailserver or POSTMASTER @ mail server is often used.

A distinction is made between hard bounces that result from permanent errors, such as when the recipient's e -mail address does not exist, and soft bounces that are generated when temporary problems, for example if the disc exhausted quota of the mailbox of the recipient or the hard drive is full is.

  • 3.1 Blacklisting
  • 3.2 email loops
  • 3.3 security breaches

Content

A bounce message usually contains several helpful hints will help identify the sender of the undeliverable e- mail, why his message was undeliverable. These include

  • Date and time, for example, Date: Mon, June 20 2005 16:59:51 0200
  • The mail server that generated the error message, such as host mail.example.com [ 192.0.43.10 ]
  • The reason that the message was undeliverable, eg 550 This e-mail address does not exist. sorry, no mailbox here by did name ( # 5.1.1)
  • The header of the returned e-mail, for example,

------ This is a copy of the message, including all the headers. ------ Return -path: Received: from postmaster by mail.absen.der with local ( Exim 4:41 )         id 1DkNkc - 000OXB - Ib; Mon, June 20 2005 16:59:50 0200 Date: Mon, June 20 2005 16:59:50 0200 From: To: [email protected] Cc: * deleted * Subject: Re: testing Message-ID: < 20050620145950.GZ61818 @ mail.example.org > References: < 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 whose initial

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 name did 550 unknown recipient / recipient e -mail adress unknown 550 5.1.1 User unknown ... 550 This e-mail address does not exist. sorry, no mailbox here by did name ( # 5.1.1) filter

550 relay not permitted 550 5.1.8 Only registered users june use this system 550 mail what 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

On temporary errors an MTA should not react directly with a bounce, as it can be assumed that at a later time, the mail can be delivered. The mail server keeps mails in this case in the queue and periodically try to redeliver this. Only when the mail is too long in the queue, it must write a bounce and delete the message from the queue.

451 Temporary local problem - please try later 451 VS14 - RT5 Mailbox bounce arrival rate Exceeds system limit ( # 4.2.2) 450 : Client host rejected: try again later Problems due to non delivery reports

Blacklisting

Sent any mail server that bounce messages, run the risk of landing on black lists (RBL ). This problem is heightened in so-called Joe - jobs. A server accepts the mails of such Joe jobs and they answered with NDNs to existing addresses, generates a large amount of collateral spam. This collateral spam leads in many cases to the info on various RBL.

The only effective countermeasure is to send bounce messages only known senders. This is normally only possible to the mail server to which the e-mail is delivered by the mail client of the sender. This is also the reason that no server should accept mail that he can not continue to move or wants. In other words: Undeliverable E- mails should be already during the reception rejected ( for SMTP time) with a 500 error. In this case, the sending server must generate the bounce. Is it when the sending server is a good server that is not a problem as this only accepts mail from known senders and therefore this also can determine correctly the bounce message - it is but a bad server (eg spam bot ) he will not send bounce messages because it brings him no benefit and if it does, he gets (rightly ) on the black list.

Email loops

Some unclean implemented mail servers generate bounce messages with an existing / undeliverable sender. Is this also bounce undeliverable, it will not be discarded as usual but sent to the specified sender. Now, the server sends the sender again a bounce (eg an out of office reply), the circuit is closed.

Security breaches

In conjunction with the registered address for replies to emails bounces can also be a serious security problem. So give administrators will want for e- mails that are not to be answered, a non-existent address and do not use too often, especially in English e- mails for the domain donotreply.com. This domain has been registered, however, and has a catch-all on their e- mail addresses. Ultimately, this can lead to, for example, the internal transmission of e -mails within a company when [email protected] is used, the email is routed through a bounce to the outside.

Related 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
140738
de