Slashdot Mirror
Using Statistics to Cause Spammers Pain
mlamb writes "Statistical mail classifiers like PopFile save time on the part of their users, but don't do anything to actively combat spam. I just published an article that suggests a way to use classifier output against a spammer while they're connected to your SMTP server, and I'm launching a project called TarProxy to implement it."
The simpler method is still SMTPAUTH. Now we just have to convince the world that this is a Good Thing.
This sig no verb.
Bayesian methods would work well for this (mind you, I'm a pretty staunch frequentist on most issues). You could set up a prior probability of a message being spam based on where it is being sent from (one could even create a centralized list somewhere, such as exist for which IP's send a lot of spam) - if the message is from a suspect server, start off suspecting its spam - if its from your friend's mail server, be more skeptical. Then taking any of the piece-by-piece approaches, update your probability of spam, and act accordingly. This should help minimize the delerious affects on innocent servers, who just happen to send the odd piece of mail that looks like spam.
Quack!Quack!.....QUACK!!
This is the same thing as OpenBSD's spamd, which Theo de Raadt wrote specifically to cause spam relays pain. spamd uses some new features of pf and blacklists from Spews to create a tarpit for incoming messages from known spam relays. It was even discussed on Slashdot in this article. Also, Daniel Hartmeier, pf developer extraordinaire and all around good guy, wrote a little piece about annoying spammers using pf, spamd, and bmf.
Try to use SpamNet from cloudmark!
This one bases on a kind of P2P system which allows users to block Spam while this is reported to the main servers.
So if someone has blocked the message before, every SpamNet user doesn't have to do it again, because Spam is moved to a different folder automatically (they using checksums and stuff i think)
A problem still might be then, that this software is for Outlook only.
But nevertheless a good (though not perfect) system. I'm pretty satisfied with it.
Hope that helped...
cyphem
Reading this signature is senseless so don't do it.
Daniel Hartmeier uses OpenBSD and packet filter to waste spammers time.
Here are some more spam tarpits:
TarProxy
ChuckMail
OpenBSD's spamd (tarball)
Google Search Results
This isn't exactly consumer anti-spam software anyway, unless you are a consumer running an SMTP server. The idea is that it slows down the spammer, and the few odd false positives that get slowed down as well should be relatively insignificant. So, even if it misses some spam and classifies a very small amount of non-spam as spam, it could still do the job because it will still make it harder for the spammer to spam.
Regexes are like cocaine. The first hit is pretty good, but afterwards you try to use them to solve all your problems.
but the open relay is enabling the spammer. The people operating the open relay should really fix their server.
cpeterso
Theo changed his mind about 550..
1 04 027378218501&w=4
It's now 450.. Hurts more..
http://marc.theaimsgroup.com/?l=openbsd-misc&m=
You just described BrightMail's approach, though they anticipated you by about 3.5 years and went and got a patent for your Step 3.
Read about a method to get SpamAssassin to execute at SMTP time in exim (I'm about to impliment this on my own mailserver) and read about teergrubing which is basically the same idea as a tarpit.
Unlike the original post, Marc seems to have a stable working version of this right now.
That said, this is probably the most realistic method of causing spammers pain that we have right now, short of changing the way mail works in a fundamental manner.
I'll definately be implimenting teergrubing/tarpitting. I might even impliment it on the multi-user hosting system that I helped to build. It probably wouldn't scale too well on a busy site though
I'm going back to splinter cell.
Mac OS X mail
that's from the Feb 6 2003 issue of Apple eNews
BLOCK STRUCTURE breathing apparatus required for special maneuvers!!
This won't work the way the author wants. Once the receiving SMTP server sends the 354 after the client issues a DATA command, there is no opportunity for the server to slow things down until it produces the 250 response at the end of the message. That is, at the application level, all the server can do is slow down the WHOLE message. During the transfer, the only way to slow things down would be to mess around with the TCP layer. The transport layer lives in the kernel. That means kernel module. That means not very portable. That means no Java. That means an SMTP server (by its nature a security risk) futzing with the security of the operating system itself.
You can slow things down by waiting before you produce the 250, but that is not at all a new concept. Several people have referenced Sendmail milters for that purpose already.
An open relay allows a SPAMer to lie about his/her domain and ofload a batch of emails lighting fast. The SMTP server does the storing and the forwarding with faked headers.
Copyright Violation:"theft, piracy"::Anti-Trust Violation:"thermonuclear price terrorism"<-Overly dramatic language.
Shutting down for a week won't do it. I had a secondary EMail account I set up for a job search a couple of years ago. Once I got a job, I deactivated the account. That was back in late 2001. Two weeks ago I reactivated it because I needed to let some site I was registered on EMail me my password. I left the account active overnight, and the next morning it had half-a-dozen Spams. This was after being inactive and bouncing messages for more then a year.
I am NOT a man!
I am a free number!
I don't see why adding heuristics to a spam throttling device will make it work worse. It should make it work a lot better.
The package I use at the isp I do random consulting for is spamthrottle. It handles the case of multiple connections from a single address (or range of addresses), along with tarpitting. It works really well --
there have been no incidents since I applied the patch, and no (legit) users have called in to complain about the mail server.
I started using it because some customers would mailbomb remote users. Unfortunately the way the ISP's dialup auth stuff works, we really don't know who the users are, so we can't kick them off permanently. It's a combination of no caller-id (we have E1s, not PRIs), and a bad scratch card account scheme by the previous management.
They aren't, they publish rather extensive proof why they list an IP address or range.
I could show you unanswered emails, but they would be too easily faked to be relevant.
From the SPEWS FAQ:
Q41: How does one contact SPEWS?
A41: One does not. SPEWS does not receive email
I am surprised your mailserver didn't inform you that spews.org does not answer at port 25.
The fact that you suggest booting a client AT ALL due to a technical error goes to show how ignorant you are. If a client is intentionally spamming we give them the boot right away. If they are an open relay, even if due to incompetence, they fix it or we fix it. Suspending their account would be stupid. We would lose the client.
Not suspending the client means you are spamming lots of people. My clients don't like spam, hence I use SPEWS to stop the spam from your IP range(s).
No, we kindly inform them of the problem, like people over the age of 15 interested in making money and retaining good business relationships.
That decision is rather bad for your relationship with other providers. The Internet is a collection of networks, if you only care about your income and knowingly and willingly allow open servers to send spam, don't expect others to spend bandwidth and CPU time to filter the few legitimate messages from the flood of spam.
Once again, I remind you that I am not listed by SPEWS, just like 99.8% of the Internet.