How bounces work

With the fundamental shift from content to reputation based filtering, it becomes even MORE important today to make sure that all customers understand their failures or behaviors when it comes to email. Their failures could be classified as things such as unknown users, complaints, blocking, technical failures, and temporary problems. The way we know these things is by bounce processing. When there is a problem delivering your message to its destination you receive an error message included in the mail returned from a receivers system. A bounce message, or Delivery Status Notification (DSN) message, aka Non-Delivery Report/Receipt (NDR), Non-Delivery Notification (NDN), or simply a bounce is an automated electronic mail message from a mail system informing the sender of another message about a delivery problem. The original message is said to have bounced.

Example coursity of Wikipedia, the free encyclopedia

Imagine that Jack (jack@example.com) sends a message to Jill (jill@example.org) at a different site. (Note that these are two different domains: Jack uses a COM domain while Jill is using an ORG one). Once Jack’s mail server has accepted the message, it must either pass it along to Jill’s mail server, or else deposit a bounce message in Jack’s mailbox.

Let us say that Jack’s mail server passes it on to Jill’s mail server (at example.org), which accepts the message for delivery. However, unfortunately, a moment later the disk on the example.org server fills up, and so the mail daemon cannot deposit the message in Jill’s mailbox.

The example.org mail server then must send a bounce message to jack@example.com, informing Jack that his message to Jill’s mailbox could not be delivered.

Had the example.org mail server known that the message would be undeliverable (for instance, if Jill had no user account there) then it would not have accepted the message in the first place, and therefore would not have sent the bounce. Instead, it would have rejected the message with an SMTP error code (bounce still). This would leave Jack’s mail server (at example.com) the obligation to create and deliver a bounce

There are many reasons why an email may bounce. One reason as stated above is if the recipient address is misspelled, or simply does not exist on the receiving system. This is a user unknown condition. Other reasons include resource exhaustion — such as a full disk — or the rejection of the message due to spam filters.

Typically, a bounce message will contain several pieces of information to help the original sender in understanding the reason his message was not delivered:

• The date and time the message was bounced,
• The identity of the mail server that bounced it,
• The reason that it was bounced (e.g. user unknown or mailbox full),
• The headers of the bounced message, and
• Some or all of the content of the bounced message.

RFC 3463 describes the codes used to indicate the bounce reason. Common codes are 5.1.1 (Unknown user), 5.2.2 (Mailbox full) and 5.7.1 (Rejected by security policy/mail filter).

When a receiver bounces a message, they will always send it to the “Return-Path:” header. This header is hidden behind all that pretty HTML and IMAGES you stuff into your emails these days and normally contains an email address for the author of the message so they are notified of the problem. In the case of BULK sending that email address is usually an email address pointing back to an automated system and not a person due to the amounts of bounces that might occur in such large mailings (let’s just hope it’s WAY much less than 10% of your entire database).

In cases of bulk sending, ISP’s and other receivers REQUIRE that you

1. Accept ALL bounces sent to you in a timely manner
2. That you take action or adhere to the bounce message request or suggestions.
   • This include removing users when they say they don’t exist there.
     • 550 "username" Is Not Accepting Mail From This Sender
     • 550 Mailbox not found
3. They you do not second guess what they are trying to tell you

If you do not, then the IP sending the email that generated the bounces will be blocked. In some cases, the domain being used in the emails or other aspects of the sending system will be blocked.

-Dennis
Eloqua

Last 5 posts by Dennis Dayman

• European Data Protection "Upgrades" - January 30th, 2012
• Return Path acquires OtherInbox - January 10th, 2012
• How NOT to react to spam complaints - January 9th, 2012
• Care2 breach is something to care about - January 3rd, 2012
• The passing of a great mind and great friend - November 17th, 2011