Talk:Backscatter (e-mail)
From Wikipedia, the free encyclopedia
[edit] 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)
-
- 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)
[edit] 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)
