Talk:Backscatter (email)/Archives/2013

Definition of Backscatter

Most people agree that backscatter is the receipt of unwanted non-delivery reports (NDR) received as a result of undeliverable spam where the sender's address was forged. However, there is a minority view that true backscatter can only happen when the forged sender's domain is protected by an anti-forgery method and said method is ignored. This view comes about on account of the historical standard of the mail system to send an NDR for every non-deliverable message and that without use of an anti-forgery method, there is no declaration of what is or isn't an unwanted NDR - i.e. no anti-forgery method used means all NDRs are in fact wanted. An NDR that is wanted cannot be backscatter (by the minority view's defintion). Furthermore, this also means that a domain that has employed no anti-forgery methods cannot receive true backscatter, and therefore first puts the burden on every domain registrant to first defend their domain(s).

"Only a foolish man intentionally leaves the doors to his house unlocked when not at home." 71.106.211.188 (talk) 23:43, 10 May 2009 (UTC)

I disagree that the DSNs are going to "innocent" parties. I agree that due to the act of forgery committed by the spammer, the true mailbox owner is not the sender. However, he is not innocent. Since 2004, there have been several anti-forgery technologies created (the most common being SPF and DomainKeys). Failure by the mailbox owner to use at least one of these leaves his mailbox (or even an entire domain) open to the forgery abuse by spammers.

Therefore, every mailbox owner and domain registrant has the responsibility to the Internet community at large to protect his asset(s) from being abused by spammers. FAILURE of the mailbox owner to protect his asset in no way translates to any responsibility by a remote system to suppress a DSN for e-mail non-deliverability which would otherwise be suppressed if an anti-forgery method were used (by the mailbox owner). These negligent users cause bogus listings of systems as backscatterers when the fault is their own and not that of the remote relay. By failing to protect their mailboxes, these people are spammer-collaborators, and are as responsible and guilty for the spam sent in their name as the sending spammers themselves. The true cause of the abuse is the originating spam, not the DSN; a factor that the mailbox owner has control over - by choosing to implement one or more of the anti-forgery methods.

True backscatter only occurs when an anti-forgery protected mailbox is used by a spammer as a forged source and the remote system fails to check the forgery status (or checks but ignores the result) and sends the DSN anyway. Remember that the forgery status of a message has nothing to do with its content: Spam need not be forged, and forgeries need not be spam. As spam content is also grounds for suppressing a DSN, it is assumed that any such forged message receiving a DSN will not be spam. RFC 5321, Section 6 indicates that to suppress an otherwise required DSN, there must exist a reason. Assuming no other reason exists for suppressing generation, a DSN issued to an alleged forged message where the mailbox owner supplied no criteria upon which to determine its forgery status is not the fault of the DSN-generating relay but that of the mailbox owner. Such is not grounds for the DSN to be considered backscatter.

One interesting side-effect of this: Perhaps mail from mailboxes and domains that lack implementation of anti-forgery technology should not be accepted by anyone. Such would be a major change to e-mail processing policy, but it could be the future as long as 95% of the Intenet community fails to implement some forgery detection method while spammers continue to abuse such unprotected resources.

- D. Stussy, Los Angeles, CA, USA 71.106.209.107 (talk) 23:21, 20 July 2009 (UTC)

Reducing backscatter spam

Now that you folks have decided to split this subject off into its own article, here's are some more things to think about.
It should be mentioned that -- by definition -- the most effective way of dealing with backscatter spam is to reject messages as opposed to bouncing them. The article seems only to hint at this concept, mentioning unpatched qmail systems (last I heard, qmail bounces by default), but not explaining what the patch is for.
Rejecting messages is when the receiving MTA keeps the connection open with the sending MTA until it has decided whether or not the incoming message is spam. If it is spam, and this decision may come early (during the SMTP phase) or late (at the end of the data phase), then a reject response (500) is returned to the sending MTA, which means that message delivery is never completed (no bounce necessary). If it's not spam, the receiving MTA replies with an accept (200) and only then is the message delivery completed. By contrast, bouncing messages always involves the receiving MTA completing the entire message transfer and responding with an accept (200) *before* it analyzes the message and recognize it as spam. This is when it ends up getting sent "back" (bounced) to the forged source address instead.
Regarding the "Possible ways to reduce the scope of this problem", including the use of SPF, DNSBLs and not accepting mail from hosts with invalid reverse lookups, I believe it's wrong to say this. Sure, these are all good filtering methods, but none of them can change what a mail server does with the message afterwards, which is either to bounce or reject. --Jwinius (talk) 02:41, 9 April 2008 (UTC)

Maybe. Got cites?- (User) WolfKeeper (Talk) 02:59, 9 April 2008 (UTC)

This is the best I can do at the moment: Bouncing is evil. These two sections on a Spamcop page are reasonable: one, two. If you think something better is required, let me know. --Jwinius (talk) 12:56, 9 April 2008 (UTC)

1st Paragraph Unclear?

I am pretty IT-literate, but I can't make head nor tail of the first paragraph. It says that backscatter is a side effect, but doesn't say what the side effect is. It then gives an alternate definition and seems to explain why the alternate definiton is better. Or is that the definition. Anyone want to try re-write of those first few sentences? Rob Burbidge (talk) 08:39, 9 April 2008 (UTC)

I've added a citation of RFC 2821 later, almost exactly the same words are used in 2821bis (not yet published): non-delivery has to reported to the originator, in other words the envelope sender, what you see in the Return-Path header of mails sent to you. That's very good for legit mails, because mail is not always as reliable as it should, e.g. if you mistype an address you want a report that it didn't work. And it's very bad for spam, if the spammer happens to forge your address, and you get misdirected bounces. It's a dilemma for receivers after they decided to accept the mail: If it was legit and they discard it you're unhappy when your mail silently vanished. If it was spam you're unhappy when you get a bounce for mail never sent by you. Whatever the receiver does, somebody is unhappy (you or you in this example). The issue is better explained in other articles, all relevant links I'm aware of are already given, BATV, SPF, SMTP, and bounce message. --217.184.142.6 (talk) 00:55, 26 April 2008 (UTC)

Greylisting

How about including Greylisting under "Reducing the problem"? It doesn't directly help against Backscatter, but it does reduce spam and in turn helps bounce less. Prog Nathous (talk) 13:14, 13 August 2008 (UTC)

Miscellaneous

SPF isn't the only forgery detection system out there, but appears to be the only one that the main article mentions. DomainKeys (also called DKIM) is also commonly implemented. There may be other methods (e.g. PGP signed mail) that never really caught on. 71.106.211.188 (talk) 23:43, 10 May 2009 (UTC)

Problems with the main article

Far too much is discussed regarding how e-mail addresses are harvested by spammers, and methods to reduce such harvesting. The truth is that spammers and list-masters have probably never really implimented significant search-bots the scan the www for publically-visible email addresses, relying instead on trojans and botnet software designed to scan infected PC's for address and contact lists as well as cached web-pages containing the transactions of web-mail sessions.

It could be made more clear that the receiving server can determine during the SMTP transfer that the destination address does not exist and throw an error back to the sending server, removing the need to send a bounce notification later on. —Preceding unsigned comment added by 64.231.107.85 (talk) 14:27, 20 February 2010 (UTC)

Cleanup

Just did a cleanup on this. Most is pretty non-controversial (I hope!), except perhaps for the deletion of the qmail bit. It's a legitimate gripe, but I took it out because (a) It's too much detail, and (b) I don't think it's sensible to pick on one product. Snori (talk) 23:36, 26 March 2010 (UTC)

Challenge/Response and Backscatter

One anti-spam proposal has been the challenge/response type of system, which sends challenge messages to unknown senders of incoming mail and awaits a response before delivering a message. Such systems are generally declared as failures and backscatter is the reason. Concerning a legitimate message, the challenge would typically be sent to the sender. However, for spam, this is often a forged address, so such a challenge "raises the noise floor" for its innocent recipient. Although such a recipient will fail to reply, thus causing the originating spam to be discarded, one is effectively placing the decision into the hands of an unknown third party, who is annoyed by the unsolicited challenge message.

Furthermore, for a challenge to be useful, it must somehow refer to the original message sent, and even include a (partial) copy of such. When a C/R system does so, effectively it becomes a spam relay. A spammer, knowing that a certain C/R system includes a copy, will design his message so that the spam payload is among the copied portion, and forge his desired recipient's address as if he were the sender, thus allowing the C/R system to be the actual delivering server of the spam (as a challenge message payload) to his desired target.

The definition of backscatter as used by some individuals very well includes such challenges from C/R systems, especially those which can be tricked by spammers to deliver their message payloads. Such challenges are not technically "bounce messages" as they are not NDRs but otherwise satisfy all the other common requirements to be considered backscatter (if not spam in its own right).

- 71.106.213.194 (talk) 00:23, 20 March 2011 (UTC)