(image courtesy of www.gdata.de) The best thing that could happen to reduce email (spam) backscatter (a.k.a. collateral spammage) on the Internet today would be to have all mail servers configured so that they would reject emails from zombie PCs.
So, I have to wonder. Why don't mail server admins use these block lists and reject spam from zombies? All the information about configuring various mail servers to reject mail from IPs on block lists can be found on the SpamCop FAQ web site.
Let's break it down in to two parts: 1) Rejecting email and 2) Identifying Zombies
Rejecting email
Rejecting email is not a new thing. It has always been part of the original RFC821 that allowed for email transfers to "fail" during SMTP. The history of why it became fashionable to accept emails first, then validate and possibly bounce them afterward, is probably tied to Microsoft's domination of the Internet with its software. But I'm not enough of an expert to venture an explanation. I can only say that die-hard sendmail users (one of the original mail servers on the Internet) know what rejecting is, and how good it can be with respect to spam fighting.
But even Microsoft wised up and allows rejecting. Their latest mail server will allow emails to be rejected (see the bit about Spam Confidence Level) rather than bounced. The administrators only have to make sure they understand why rejecting is better and that they've enabled it.
Some companies do a disservice to their customers by not informing them of all of the risks of bouncing. For example, Barracuda Networks provide a whitepaper on Email Non Delivery Receipts (bounces). Yes, there is useful text explaining the difference between rejecting and bouncing, and the "best practices" for how to draft NDRs. However, Barracuda Networks fails to mention that most spams have forged "From:" addresses and that most of those well written NDRs will go to the users whose email addresses have been forged in the spams that get bounced! All in the spirit of making sure a "false positive" doesn't get mishandled!
Those backscatter victims (like me and possibly you if you found this blog) will not be happy to get a well written NDR that says a message we sent (that we didn't send!) was blocked by the Barracuda Spam Firewall. If anything, it implies that Barracuda are foolish enough to be tricked by the forged sender address. On the one hand, they are experts who deal with spam filtering. On the other hand, they "ignore" that spammers forge the "From:" address. Smells like marketing... Anyway, that's what a whitepaper is.
Identifying Zombies
Here's a fact: 100% of the backscatter I get today results from bounced spam sent originally from zombie PCs. How do I know this? The backscatter messages often contain the RFC822 "Received:" headers of the spam that had my email address forged in the "From:" field. From these headers, I can see that the injection point of the spam was a zombie.
How do I know it's a zombie? That's easy. The IP address of the "from" host on the last "Received:" line is on a DNSBL, such as bl.spamcop.net, cbl.abuseat.org or zen.spamhaus.org. The first two DNSBL are for "known" spam-sending IPs (they are dynamically updated), and the last one is for IP address that are located on ISPs that have a policy that no email should be sent by such IPs. That's right - a "home PC" should not be acting like a mail server (Mail Transfer Agent) outside of the local network.
You'll notice that I don't need any high-powered Bayesian filtering or keywords or TCP/IP probes to decide if it's a zombie is sending me spam. It's just basic common sense. Has the IP shown up as a known spam-sender (open relay) or does the IP have no business sending SMTP traffic? If the answer is yes (i.e., it's on one of those block lists), I conclude it's a zombie and reject the email (spam) it wants to send me.
Rejecting spam from zombies
Here's an example of a missed opportunity that makes backscatter victims suffer. Barracuda, who definitely can use block lists to reject spam from zombies, could have stressed in their whitepaper about NDRs that rejecting email is a good compromise with respect to false positives and backscatter. That is, when a message gets rejected (rather than bounced), there are two possibilities:
- It's a spam message: the rejection causes the spammer's mail server (usually a zombie) to have to deal with the bounce. This means that the zombie does nothing and moves onto the next spam to send. No collateral spamage (damage?).
- It's a legitimate message (false positive): the rejection causes the legitimate sender's mail server to generate an NDR with the reason for the rejection in the message. This NDR will likely be written in the language of the legitimate sender.
