Backscatter (email)

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.

Recipients of such messages see them as a form of unsolicited bulk email or spam since they were not solicited by the recipients, are substantially similar to each other and are delivered in bulk quantities. Systems that generate email backscatter can end up being listed on various DNSBLs and be in violation of internet service providers' Terms of Service.

Backscatter occurs because worms and spam messages often forge their sender address, and mailservers configured by naive administrators send a bounce message to this address.

Measures to reduce the problem include avoiding the need for bounce message by doing most rejections at the initial SMTP connection stage; and sending bounce messages only to addresses which can be reliably judged to have not been forged.

Cause

Authors of spam and viruses wish to make their messages appear to originate from a legitimate source to fool recipients into opening the message so they often use web-crawling software to scan usenet postings, message boards, and web pages for legitimate email addresses.

Due to the design of SMTP mail, recipient mail servers receiving these forged messages have no simple standard way to determine the authenticity of the sender. If they accept the email during the connection phases then, after further checking refuse it - for example because they believe it to be spam they will use the (potentially forged) sender's address to attempt a good-faith effort to report the problem to the apparent sender.

Mail servers can handle undeliverable messages in three fundamentally different ways:

• Reject. A receiving server can reject the incoming email during the connection stage while the sending server is still connected. If a message is rejected at connect time with a 5xx error code then the sending server can report the problem to the real sender cleanly.

• Drop. A receiving server can initially accept the full message, but then determine that it is spam, and quarantine it - delivering to "Junk" or "Spam" folders from where it will eventually be deleted automatically. This is common behaviour, even though RFC 5321 says: "...silent dropping of messages should be considered only in those cases where there is very high confidence that the messages are seriously fraudulent or otherwise inappropriate..."

• Bounce. A receiving server can initially accept the full message, but then determine that it is spam or to a non-existent recipient, and generate a bounce message back to the supposed sender indicating that message delivery failed.

Backscatter occurs when the "bounce" method is used, and the sender information on the incoming email was that of an unrelated third party.

Reducing the problem

Every step to control worms and spam messages helps reduce backscatter, but there are also several other common approaches:

Preventing email address collection

It is common to attempt to obscure email addresses in a manner that is not easily machine-readable. Several methods are available, such as simply not using a standard text format (john (at) example.com) or using a bitmap image of the address rather than raw text. More complex address obscuration methods are available, such as encoding the addresses using a substitution cipher, embedded as program code within a tiny javascript or Adobe Flash program for each address, which when clicked, opens a temporary window and sends the decoded mailto: address to the local email client, but all such obscuration methods can potentially be attacked by spammers in the same manner as CAPTCHAs.

Connection-stage rejection

During the initial SMTP connection mailservers can do a range of checks, and often reject email with a 5xx error code while the sending server is still connected. Rejecting a message at the connection-stage in this way will usually cause the sending MTA to generate a local bounce message or Non-Delivery Notification (NDN) to a local, authenticated user.^[1]

Reasons for rejection include:

• Recipient validation^[2][3][4]
• Anti-forgery checks such as SPF, DKIM or Sender ID
• Servers that do not have a forward-confirmed reverse DNS entry
• Senders on block lists^[5].
• Temporary rejection via greylisting methods

Mail transfer agents (MTAs) which forward mail can avoid generating backscatter by using a transparent SMTP proxy.

Checking bounce recipients

Mail servers sending email bounce messages can use a range of measures to judge whether a return address has been forged.

Filtering backscatter

While preventing backscatter is desirable, it is also possible to reduce its impact by filtering for it, and many spam filtering systems now include the option to attempt to detect and reject^[6] backscatter emails as spam.

In addition, systems using schemes such as Bounce Address Tag Validation "tag" their outgoing email in a way that allows them to reliably detect incoming bogus bounce messages.

See also

• Joe job

References

1. ^ Alternatively, if the MTA is relaying the message, it should only send such an NDN to a plausible originator Klensin, J, IETF RFC 2821, p. 25, "as indicated in the reverse-path"  e.g. where an SPF check has passed.
2. ^ The Hidden Power of Sender and Recipient Filtering, MS Exchange.org, http://www.msexchange.org/tutorials/Sender-Recipient-Filtering.html .
3. ^ "Configuring Recipient Filtering", Technet, Microsoft, http://technet.microsoft.com/en-us/library/aa998898.aspx 
4. ^ "Recipient address verification", Address verification readme, Postfix.org, http://www.postfix.org/ADDRESS_VERIFICATION_README.html#recipient .
5. ^ Marsono, MN (2007.), "Rejecting Spam during SMTP Sessions", Proc. Communications, Computers and Signal Processing, Pacific Rim: IEEE, pp. 236–39 .
6. ^ "The "Virus Bounce Ruleset" is a SpamAssassin ruleset to catch backscatter"

External links

• (PDF) Mail DDoS Attacks through Non Delivery Messages (paper), Techzoom, 2004, http://www.techzoom.net/papers/mail_non_delivery_notice_attacks_2004.pdf .
• "Backscatter", Postfix (readme), http://www.postfix.org/BACKSCATTER_README.html .
• "Backscatter", SpamLinks, http://spamlinks.net/prevent-secure-backscatter.htm .
• RFC 3834: Recommendations for Automatic Responses to Electronic Mail .
• "Moronic Mail Autoresponders", A FAQ From Hell, FI: Iki, http://www.iki.fi/era/mail/autoresponder-faq.html .
• "Why are auto responders bad?", FAQ, SpamCop, http://www.spamcop.net/fom-serve/cache/329.html .
• Don’t bounce spam, http://www.dontbouncespam.org/ : why you shouldn't bounce spam.
• 100 E-mail Bouncebacks? You've Been Backscattered, PC World, http://www.pcworld.com/businesscenter/article/145449/100_e-mail_bouncebacks_youve_been_backscattered.html .