Bounce

The term Bounce as related to SpamCop can be thought of in a broader form than the general technical defination might allow for. As such, this article will start by using the broader definition of a bounce being any automatic reply to an email message. Using this defination, Vacation Responders, Out of Office Notices and the like would also be considered bounces. Bounces are one of the most common causes for IP addresses to added to the SpamCop Blocking List (SCBL)

Used by some as a description of the notification of undelivered e-mail also know as:

• NDR - Non-Delivery Report
• DSN - Delivery Status Notification

There are two scenarios (or methods) in which a 'bounce' can be generated.
1. Sending a coded message (SMTP reject code).
This is a message that a receiving Mail Transfer Agent (MTA) returns to the sending MTA that the email was not accepted. The sending MTA may create a separate email to send to the originator, informing her of the failed attempt to transfer the message but it will be attached as part of the coded message. These messages are returned by following the IP address path as recorded in the email header in the reverse order that they were originally listed in.
2. Sending a new separate email message.
After an email is received by an MTA (the SMTP transaction was completed) but for some reason cannot be delivered. This 'bounce' email must go to the From/Reply-To (or Return-Path). Note that these addresses may contain any value specificed by the sender and are not authenticated by the SMTPprotocol. Spammers and viruses regularly forge these fields (addresses) with random or arbitrary email addresses.

The RFCs for email permits a receiving MTA to generate an email bounce. However, that is no longer a good practice, because the return address cannot be trusted in the case of spam or virus-laden messages. These messages account for at least 50 to 70 percent of all incoming e-mail, and almost always have a forged return-path. Thus, if they are accepted and a bounce message is sent afterwards, that bounce message will most likey go to an address of an innocent third party, provided the forged return-path is a valid address. These 'bounces' are just as annoying as receiving the spam or viruses directly, and can be considered spam as they are unsolicited.

The preferred practice is for the receiving MTA to issue an SMTP reject code if it can not deliver the e-mail. The sending MTA, upon handling the reject error, may generate a bounce if it is a relaying MTA. If the sending MTA is paired with a Mail User Agent (MUA), such as Mozilla Thunderbird, it may notify the user directly (via the user interface) that her email could not be sent because of the reject message.

Since spammers often use random or arbitrary addresses in the forged return-path, there is a chance that those addresses are SpamCop SpamTraps. If bounces are sent to these addresses, the sending MTA may be put on the SpamCopBlockingList.

SpamCop users who receive a MisdirectedBounce can report it to SpamCop.

See VacationResponders, which is another specialized type of bounce.

See SMTP for explanations about MTA, MUA, etc.



Other related topics:
Why Am I Blocked? - additional information is also available the SpamCop Forum topic Why am I Blocked?∞
Automatic Responses - Out of Office (Vacation) Messages
Blowback, Backscatter, Misdirected Bounces
VacationResponders

---

CategorySpamCopGlossaryWikiB
CategoryWhyAmIBlocked

---