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.htmlBackscatterers - www.backscatterers.com/How to deal with backscatter - www.spamnation.info/notes/guides/BackscatterFAQ.htmlDealing with joe jobs - research.mince.ac.nz/NZNOG_2007_Dealing_With_Joe_Jobs.pptMy email address is being used in spam! - www.spamresource.com/2007/07/ask-al-my-email-address-is-being-used.htmlBounce 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