Linux.com

Fight the abuse to fight spam

Posted by: Anonymous Coward on August 27, 2004 02:45 AM
I continue to be amazed, to be stunned. Spam is a huge problem, it affects almost everyone, it's a problem throughout the internet - and yet the solutions proposed are always limited to solutions at or after the destination email server. Plus, now, sender-ID, which must be implemented at the destination server but does involve the sending servers (for valid email.). What really burns me up is that there is no analysis of the spam problem that comes along with sender-ID - sender-ID is the solution for a problem that is left undescribed.

Were it described we would see that the main reason for sender-ID is that spammers abuse other systems to send their spam and use false sender information when they do. The reason they abuse those other systems is to hide their identity. So there's two parts to the problem, just from this simple analysis: the false names and the abuse of the other systems. When do you ever see any analysis on what can be done if the problem is approached from the abuse standpoint rather than from the false sender standpoint? Never - and yet combating the spam as abuse is far simpler than sender-ID, blocklists, or filters. The abuse is widespread, meaning that the abuse can be fought at many locations. The abuse is still mostly very simple, meaning that simple counter-methods can be effective. Such an approach already works, and is devastating to the spammers. That's why they have available a tool called "Honeypot Hunter" - to detect and avoid fakes. If they look for honeypots how they look can be found and then the honeypots can be made to again deceive the lookers.

In 2000 I stopped spam to millions with a simple tool on an even-then obsolescent computer. I did it on a mail server, meaning I had to distinguish spam form valid email. That, of course, is decidedly easy: simply treat as spam all the email you'd never accept in the first place if you rejected illicit attempts to relay through the server. Accept them but don't deliver them. That's simple. If you set up a non-server for the same technique then there's no thought at all needed: everything you receive is illicit, none need be delivered. There is one exception: the spammers precede the spam with test messages to determine if the system will relay. Those you deliver. It's amazingly simple.

Nowadays open relay abuse is finally fading, although it still happens from China, Korea and Taiwan (with the addresses also in those countries: they relay through open vulnerable systems in the US and probably elsewhere.) Open proxy abuse is still fairly common, and that can also be easily combated, by fake open proxy systems. Here there's never any discrimination needed: if it's email coming through your (fake) open proxy it's spam. Again, too, there's a need to allow the spammers to have success with their tests.

For zombie abuse there have been fake zombies, but those could get harder. If the ISPs are finally going to develop and follow some best practices I suggest they start with a dual-goal first step: detect abuse in their own space and report it back to the ISP that is in charge of the IP address of the apparent source. These ISPs, also following the best practices, should detect the source of the incoming traffic (if any) to the IP address identified as the source of abuse and report that to the ISP for that IP address. If the abuse originates at the local IP Address then they know the source and should take appropriate action. The two goals are (1) detect abuse that can be seen in their own space and (2) become responsive and proficient in tracing abuse to its apparent source.

There have been successful attacks made on the spammers by these methods. Michael Tokarev in Moscow caused spammer Alan Ralsky great inconvenience using a simple open relay honeypot. Ron Guilmette, in California, had great success using a small network of open proxy honeypots. He got over 100 spammer accounts closed in under 3 months, acting as an individual. The method has great power - but if groups such as the IETF continue to insist on complex long-term solutions the easier solutions already at hand will be ignored. that's a tragic mistake.

Pay more attention to Hadmut Danisch. Not only is spam a cash cow for the anti-spam software companies there's also the basic fact of human nature that seems to be intensified in computer people: they want to devise complex solutions. Let one think of an approach to spam and his attention shifts from dealing with the spam problem to establishing his method as the one used. I stopped relay spam with nothing more than command files on an ancient Vaxstation. That's partly because stopping spam wasn't my original goal. What I started out to do was to secure the mail server so it wouldn't relay. the traditional approach of rejecting illicit messages when they were coming in wasn't easily available so I chose an equivalent approach: stop them on the way out. From that I learned the obvious, that spammers test to find open relays, and then expanded what I was doing to make it intentionally deceive spammers as to the nature of the system so that it would trap spam.

There are objections you can raise to that but they aren't definitive objections. What I did worked and that is the point. While I read of others struggling to keep their filters good enough to keep up with the spammer creativity in avoiding filters I could simply look at the spam I was trapping and see the new spammer anti-filter efforts. Against me they were worthless, because I wasn't trying to filter spam at the destination. By acting mid-path my task was made extremely simple: if it came, it was spam. (Of course I had to first properly handle the valid email - but none of that was relay mail from unauthorized sources so dealing with it was easy. If I had created a system with no other purpose then there'd have been no valid email, and that's what Michael Tokarev (and others) did.

Sender-ID isn't needed to end spam. What is needed is an effort that is designed to end spam now, using what can be done now. That is simplest at intermediate steps in the spam delivery path. Look at it this way: is it really necessary for the spammers to always be correct when they conclude a system is abusable? That's what makes their lives easy. If the internet were lightly salted (under 1% of systems) with fake abusable systems the spammers would face a far more difficult task. That approach can be started today, and each system added has a very high probability of having some useful effect in ending spam.

"Minas Beede," posting "anonymously."

#

Return to Email Sender ID: The hype and the reality