Backscatter (e-mail)
From Wikipedia, the free encyclopedia
Backscatter (also known as outscatter, misdirected bounces, blowback or collateral spam) is a side-effect of e-mail spam, viruses and worms, where email servers receiving spam and other mail send bounce messages to an innocent party. This occurs because the original message's envelope sender is forged to contain the e-mail address of the victim. A very large proportion of such e-mail is sent with a forged From: header, matching the envelope sender.
Since these messages were not solicited by the recipients, are substantially similar to each other, and are delivered in bulk quantities, they qualify as unsolicited bulk email or spam. As such, systems that generate e-mail backscatter can end up being listed on various DNSBLs and be in violation of internet service providers' Terms of Service.
Contents |
[edit] Two Ways to Reject Spam
To help understand the backscatter problem more clearly there are basically two ways to reject spam. You can reject the incoming email while the sending server is still connected (preferred) or you can accept the message, determine that it is spam, and generate a new bounce message indicating that the message failed. The problem with generating a new message is that the new message is sent to what the spam claims is the sender but is more often an innocent third party whose email address was spoofed.
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. If however your server has already accepted the message and then it is determined to be spam you should take care in determining if you are indeed notifying the real sender. When designing a spam filtering system it is best to do all spam filtering tests while the sending server is still connected.
[edit] Reducing the problem
The root cause of the problem is mail servers accepting email which, after further checking, they reject. A range of techniques can be used by servers to reject during the initial SMTP connection:
- Recipient validation
- SPF checks
- Reject email from servers that do not have a reverse DNS entry
- Reject senders on dynamic black lists[1].
Mail transfer agents (MTAs) which forward mail can avoid generating backscatter by using a transparent SMTP proxy.
Modern practice is to reject suspicious mails at the border of the receiving network, e.g., for an SPF FAIL, and not to bounce undelivered messages when they have been judged to be spam. This is because since around 2002 the vast majority of spam has come from forged addresses.
Rejecting a message will usually cause the sending MTA to generate a bounce message or Non-Delivery Notification (NDN) to a local, authenticated user. Alternatively, if the MTA is relaying the message, it should only send such an NDN to a plausible originator as indicated in the reverse-path [2], e.g. where an SPF check has passed.
Due to controversial aspects of its design, the stock (unpatched) qmail mailserver is more likely than most to produce such bounces. For instance, qmail's security design prevents it from doing "recipient validation" to reject messages during SMTP transactions[3]. When email addressed to nonexistent recipients cannot be rejected at the SMTP connection, the only alternative is to auto-reply to the sender address, which causes email backscatter if the sender address is valid and forged[4].
Problems with backscatter reaching the innocent third party can be reduced if they always send e-mail using schemes such as Bounce Address Tag Validation.
The judgment call for what to do with undelivered mail is not simple. Best practice is, wherever possible, to reject the spam at the boundary and be done with it. The alternative is to discard spam that has already been received, and try to report non-delivery only to plausible senders.
[edit] References
- ^ M.N. Marsono, et al., "Rejecting Spam during SMTP Sessions," Proc. Communications, Computers and Signal Processing, 2007. PacRim 2007. IEEE Pacific Rim Conference on, 2007, pp. 236-239.
- ^ J. Klensin, "Simple Mail Transfer Protocol", IETF RFC 2821, page 25
- ^ Qmail backscatter spam [LWN.net]
- ^ Stopping Backscatter
[edit] See also
[edit] External links
- Mail DDoS Attacks through Non Delivery Messages
- Postfix - backscatter page
- SpamLinks - Backscatter
- RFC 3834: Recommendations for Automatic Responses to Electronic Mail.
- Moronic Mail Autoresponders (A FAQ From Hell)
- Why are auto responders bad? (a SpamCop FAQ)
- A DNSBL of Backscatter sources.
- Dontbouncespam.org Why you shouldn't bounce spam
- 100 E-mail Bouncebacks? You've Been Backscattered.
