Re: [SAtalk] Clever spam (first of many, I'm afraid...)

[Brad Koehn]

Any spammer worth his salt runs his message through SA and other popular anti-spam tools as best he can. Most of SA is relatively static and slow to respond to changes in message content. The problem comes in a few areas like checks against Received headers (since the spammer may be using thousands of zombies to send the message to your MTA) and Bayes filters, which are tailored to each recipient and the spammer cannot access. If a smart spammer wanted to try to make it past the Bayes filters, he'd set up a spamtrap, gather spam, and run his message against the Bayes tokens it gathers. Of course, that only partially reduces the likelihood of making it in (since it doesn't know which good tokens to use for each recipient), but at least he can avoid the same tokens other spammers are using. Of course, running it through SA won't help against the dynamic collaborative filters like razor, pyzor, dcc, etc. without varying the message. I suppose the spammer could send the message to his own spam trap (after the dynamic collaborators have crunched it) and see how it came out. He could also tweak the message after it's been in flight for a while, hopefully breaking the signatures of the dynamic collaborators. A really smart spammer would examine the algorithms, and design algorithms of his own to morph the message enough to defeat them. Of course, the more algorithms there are, the harder it is for the spammer to morph his message enough to defeat them and yet have an intelligible message. Lastly, RBLs adapt quickly, so you need a fresh supply of machines/IPs to transmit the message. We've made it pretty tough on the spammers. I'm glad I'm in another line of work. Brad Martin Radford wrote: At Mon Dec 15 15:12:42 2003, Gary Smith wrote: Rubin, About a week ago a guy asked how to use SA to check the emails before he sent them for some mail list (or some private promo thing). I think that problem is that spammers themselves are starting to use product like SA to validate if an email is spam or not so they can fool the system. I don't think there is a clear and easy way to stop them if they are using the same tools. Just my $0.02. The spammer might be able to run his *content* through SA, but he still has to use some spamming tool (which SA might identify), and send mail out through servers which might be in one or more RBLs. In addition, the spammer has no idea what might be in your Bayes database, and can't deal with that other than by brute force which might still not work. On top of that, there's Razor, pyzor, DCC to cope with. Martin