Backscatter and bounce attacks prevention

Backscatter (also known as outscatter, misdirected bounces, blowback or collateral spam) is

incorrect automated bounce messages sent by mail servers, typically as a side effect of
incoming spam.

Backscatter occurs when a Mail Transport Agent (email server) sends a bounce (return
message) to a person who did not really send the email, essentially, someone is spoofing the
Reply-To field in an email. They then send it to a mail server and it bounces not back to the
sending server but to the Reply-To address. Backscatter is caused by people who don't reject
mail during delivery, but instead accept the mail and then later send back a bounce message.

Problems arise with bounces if they are sent by a mail server to a non-local recipient.
Technically bounces are called non-delivery reports (NDR) or delivery status notifications
(DSN). If a message did not originate locally, then a mail server cannot know for sure if the
address it is sending the bounce to is forged or not. This quickly leads to this unsolicited
“backscatter” (or more rarely “outscatter”), sent to sites that never originated the email.
If you run a mail server you have a responsibility not to send backscatter. Bounces should
ideally only be generated by a mail server to a local recipient. Mail servers should not generate
bounces to non-local recipients, but should instead reject the mail during the SMTP session,
and leave the remote sending server to handle the bounce: if a rejected mail is a legitimate
message, the bounce gets generated by the remote sending machine, as expected; if a
rejected mail is not a legitimate message, the remote end will probably not generate a bounce,
and all is still well.
The MX should be made aware of the status of user mailboxes on the local system that the
mail will eventually be delivered to. To reduce the chances of a bounce being necessary,
DNSBLs should be used to reject spam during the SMTP session based on the sending IP
address, and content based spam filters should be used to identify and reject spam during the
SMTP session, during the DATA phase.
In that way Bounce attacks can be used to leverage the initial recipient's "good" reputation
when sending spam, pollute the initial recipient's IP reputation, or create denial of service
attacks at the target's server.

Dealing with Backscatter

It is not easy to cope with the floods of backscatter email that occur when a spammer forges
your email addresses. Options include blacklisting the worst culprits, and enabling bounce,
session and message verification techniques such as BATV, SPF and DomainKeys - the bounce
verification lets you determine which bounces are in response to your own email, and session
and message verification can help reduce the number of backscatter emails sent back.

Postfix Backscatter Howto - www.postfix.org/BACKSCATTER_README.html

How can I control unsolicited bounces? - www.spamcop.net/fom-serve/cache/380.html
Backscatterers - www.backscatterers.com/
How to deal with backscatter - www.spamnation.info/notes/guides/BackscatterFAQ.html
Dealing with joe jobs - research.mince.ac.nz/NZNOG_2007_Dealing_With_Joe_Jobs.ppt
My email address is being used in spam! - www.spamresource.com/2007/07/ask-al-my-email-
address-is-being-used.html
Bounce pi: where did my bounce come from? - bouncepi.com/

Symantec and bounce attacks prevention

Symantec Brightmail Gateway uses bounce attacks prevention to eliminate NDRs that are a
result of such redirection while still delivering legitimate NDRs.
Once your system is configured for bounce attack prevention, Symantec Brightmail Gateway
calculates a unique tag that uses the provided seed value as well as the current date. Your
Scanner attaches this tag to outbound messages sent by users in your defined policy groups.
If the message is then returned as undeliverable, the envelope's return address will contain
this tag.
When the system receives a message that appears to be a message returned as undeliverable,
the system will compare the inbound message's recipient with the policy group configuration to
see if the user's policy group is configured for bounce attack prevention. If the policy group is
configured, the system calculates a new tag that includes the seed value and current date,
then uses that new tag to validate the tag in the email.

Sources:

http://spamlinks.net/prevent-secure-backscatter.htm

http://www.gzone.it

http://seer.entsupport.symantec.com/docs/322196.htm