Backscatter (e-mail)
Backscatter (also known as outscatter, misdirected bounces, blowback or collateral spam) is a side-effect of e-mail spam, viruses and worms, where e-mail 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 often unprotected 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 e-mail 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.
Cause
The root cause of the problem is that the authors of spam and viruses are constantly seeking new ways to make their messages appear to originate from a legitimate source, so as to fool recipients into opening the message. These criminals have developed web-crawling software capable of scanning usenet postings, message boards, and web pages containing e-mail addresses in an easily machine-readable, text only format. For example, an easy target is an organizational directory containing names and clickable mailto e-mail addresses to contact the staff. These names and addresses are potentially used by other zombie computers in a spam-generation network, so as to deflect attention away from the crawler.
Due to the completely open and unsecured design of SMTP mail, the recipient mail servers receiving these forged messages have no way to determine the authenticity of the sender. They simply accept and process e-mail which, after further checking, they refuse - for example because they believe it to be spam. The recipient mail servers then 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 e-mail 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, and generate a bounce message back to the supposed sender indicating that message delivery failed.
The "bounce" approach is the cause of backscatter when the sender information on the incoming e-mail was forged - as is very common.
Reducing the problem
The primary method of reducing backscatter is to obscure contact information in a manner that is not easily machine-readable. Several methods are available, such as simply not using a standard text format (john (at) company.com) or using a bitmap image of the address rather than raw text, though such obscuration methods can be attacked by spammers in the same manner as CAPTCHAs.
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 e-mail client.
There are two other approaches to reducing backscatter. The first is to reject as much mail as possible at the initial SMTP connection stage; and the second to send bounce messages only to addresses where various checks have confirmed that the address has not been forged.
For mailbox (and domain) owners, implementation of anti-forgery technology (see below) is your solution. Remote systems sending DSNs to mailboxes left unprotected by any anti-forgery method should not be blacklisted as backscatterers as the real cause is the irresponsible mailbox owners that left their mailboxes open to spammer abuse in the first place.
Connection-stage rejection
A range of protocol-based techniques can be used by servers to reject during the initial SMTP connection:
- Recipient validation[1][2][3]
- 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[4].
- Temporary rejection via greylisting methods
- Mail transfer agents (MTAs) which forward mail can avoid generating backscatter by using a transparent SMTP proxy.
Due to controversial aspects of its design, the stock (unpatched) qmail mailserver cannot do "recipient validation" to reject messages during SMTP transactions[5]. When e-mail addressed to nonexistent recipients cannot be rejected at the SMTP connection, the only alternative is to auto-reply to the sender address, which causes e-mail backscatter if the sender address is valid and forged[6].
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 [7], e.g. where an SPF check has passed.
Checking bounce recipients
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.
References
- ↑ "The Hidden Power of Sender and Recipient Filtering"
- ↑ Configuring Recipient Filtering
- ↑ Recipient address verification
- ↑ 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.
- ↑ Qmail backscatter spam [LWN.net]
- ↑ Stopping Backscatter
- ↑ J. Klensin, "Simple Mail Transfer Protocol", IETF RFC 2821, page 25
See also
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.
If you like SEOmastering Site, you can support it by - BTC: bc1qppjcl3c2cyjazy6lepmrv3fh6ke9mxs7zpfky0 , TRC20 and more...