Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?

Using Statistics to Cause Spammers Pain 337

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."
This discussion has been archived. No new comments can be posted.

Using Statistics to Cause Spammers Pain

Comments Filter:
  • Nice idea (Score:2, Interesting)

    But what if the spammer sends a message to a (good) SMTP server which haven't got the system, and the SMTP server in turn tries to deliver the "spammail" to the right SMTP server, won't that hurt the good SMTP server, who just tries to do it's job?
    • Re:Nice idea (Score:5, Insightful)

      by LowneWulf ( 210110 ) on Friday February 28, 2003 @08:09PM (#5410559)
      Most mail servers will only forward mail from users of their own domain. If the mailserver is sending spam for one of their legitimate users, I feel no pity for them if their server slows down.

      If they forward mail from anyone who sends them mail, then they are an open relay, and again, they deserve what they get for leaving an open relay up.

      • But then the only way the actual spammer would be sending from your server is if you have an open relay? So the idea would be to set up false open relays? But wouldn't the spammer just black/whitelist the servers? The place where I work once got hit by a spammer, (because we used some matt formmail script), it all happened automatic in steps: - Some webspider found out about the formmail.cgi - The spider sends a mail to some hotmail account - 15 minutes later (I guess after confirming the mail got through) it started sending mails non-stop. - 30 minutes later, we could see some other type of traffic (The bot apparently sent out mails about the open relay to other spammers (possible persons who bought access to the open relays?)). All the while we were on the phone with the police computer-crime department, which didn't know what to do. Then we denied those users access to the network and patched up the security breach (We were waiting to do that, while talking to the police, in the hope that they could actually do something, since the spammer were spamming "right now"... But apparently they were quite clueless).
        • Re:Nice idea (Score:2, Insightful)

          by Anonymous Coward
          I suppose a fake open relay that forwards nothing is definitely an idea that has merit. However, it still doesnt really hit back. Now, a fake open relay that is a tarpit, as per the article, would be pretty good.

          However, I guess the 'blank relay' is good as a time waster, because they THINK its succeeding. Whereas a tarpit open relay will eventually be ignored.

          As anything, they will evolve to counter these kind of subterfuges, mapping out known good relays could just be done programmatical by either make sure it actually forwards or doesnt hog bandwidth.

          So the only really good solution would be to close all open relays, and tarpit all valid SMTP recievers. Hardly likely to happed, tho =( I guess we will just have to hope there is someday a common denominator alternative to SMTP, and that it actaully gets used!

        • Re:Nice idea (Score:3, Insightful)

          by freeweed ( 309734 )
          An open relay is different than the formmail.cgi vulnerability. Ok, so they can result in the same thing, but when people talk about open relays they usually mean production SMTP servers which accept mail from anywhere, instead of verifying the source domain first.

          Matt's formmail script isn't really intended for use as a mail server, but on a webserver (ok, so I'm arguing semantics here :) to just fire off the odd email easily for the admin.

          As for your questions, the idea is *not* to set up false open relays per se, but to set up servers that tie up the 'upstream' mail server. Tarpitting is a pretty cool idea if you ask me - it hurts no one but the spammer, if implemented properly. As for blacklisting/whitelisting servers, sure, let the spammers. Note that if enough people tarpitted, eventually spam wouldn't get *anywhere* - spammers could spam each other all they want, but none of it would ever get delivered.

          Unfortunately the critical mass for this to really work is very, very large.

          • Re:Nice idea (Score:2, Interesting)

            by stand ( 126023 )
            Unfortunately the critical mass for this to really work is very, very large.

            I don't think this is necessarily true. As the article points out, setting it up on a few servers would be sufficient to get things started provided those few servers were the right ones. I'll leave it as an exercise to the reader to determine which servers they should be.

            I don't think they should be doing this in Java though. Java is not a text parsing language and this thing really requires some text parsing muscle. Cross platform ability isn't as important.

            • I don't think this is necessarily true. As the article points out, setting it up on a few servers would be sufficient to get things started provided those few servers were the right ones. I'll leave it as an exercise to the reader to determine which servers they should be.

              Hmmm, the BIG isp's with thousands of users, who would be hard-pressed to provide the horse-power for such a system in the first place?
              • But what would be a more pressing need for this to take place: hardware muscle or bandwidth?

                Sometime ago, someone (can't remember who) came up with a tar pit for the nimda virus and one of the warnings I remember was that this was very bw expensive.
            • Re:Nice idea (Score:3, Interesting)

              by jonadab ( 583620 )
              > > Unfortunately the critical mass for this to really work is
              > > very, very large.

              Yes, it is large.

              > I don't think this is necessarily true. As the article points
              > out, setting it up on a few servers would be sufficient to get
              > things started provided those few servers were the right ones.

              Let me guess: Yahoo's several dozen, AOL's however many, and
              the ones at Earthlink,, and MSN -- and I close?

              That's a very large critical mass, not in terms of the number of
              servers, but in terms of the amount of mail handled (and, therefore,
              the amount of server beef needed to implement any such measures).

              > I don't think they should be doing this in Java though. Java is
              > not a text parsing language and this thing really requires some
              > text parsing muscle. Cross platform ability isn't as important.

              No need to sacrifice the cross-platformness. Perl is a GREAT
              text processing language, performs faster than Java, and as an
              added bonus is much more cross-platform (provided you don't need
              a GUI (which for this you don't)). It does use quite a bit of
              RAM sometimes, but so does Java. And doing SMTP stuff in Perl
              is really easy. (Net::SMTP rocks in a significant way.) And
              any operating system that's remotely appropriate for use as a
              mail server probably comes with Perl out of the box these days.
          • Re:Nice idea (Score:3, Insightful)

            by Zeinfeld ( 263942 )
            Tarpitting is a pretty cool idea if you ask me - it hurts no one but the spammer, if implemented properly.

            As with all vigilante actions, it works pretty well if only the bad guys get a lynching.

            The problem with these teergrubbing type schemes is that they typically only hurt the innocent victims caught by accident. It is very unlikely that a bulk email sender program does not have code in it to detect slow connections and abort. Otherwise the bulk sender is going to fail at the least network problem.

            Bulk senders are in any case coded with multiple threads, either by using a threads package like pthreads or in some cases the threading is simulated by maintaining a state machine for each connection. The teergrubbing scheme described only causes pain if the bulk sender is single threaded and blocks when connecting to a single slow server.

            Vigilante hacking frequently goes wrong. Coupling a vigilantge hacking scheme up to a heuristic detection scheme is pure stupidity.

            • Re:Nice idea (Score:3, Informative)

              by rplacd ( 123904 )

              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.

      • Re:Nice idea (Score:5, Interesting)

        by minas-beede ( 561803 ) on Friday February 28, 2003 @10:19PM (#5411046)
        There's a few spammers who send direct from their own IPs. If you want to tarpit them just tarpit the traffic from their Ips - you don't need to analyze anything.

        For other spam, through open proxies or open relays, you are not hurting the spammer to tarpit. If the spammer is working through open proxies and if you got enough tarpits going then you could hurt them, but until there's enough tarpits there is still zero (0.000) percent pain to the spammer. Some open proxes are slow with one or two tarpits, the others are fast enough to keep the spammer's server fully busy. He only cares if he's running his server flat out. Delays at one or more open proxies mean little.

        Right now I'm trapping spam on a relay spam honeypot. It comes to the honeypot from open proxies - theer's nothig I can learn about the spammer by learning about the proxies. It comes (usually) as 99-recipient spam messages. This particular spammer uses imbedded comments in his spam to evade Bayesian filters. Makes no difference to me - I see it is spam. I have no valid email to filter out - everything is spam. That's one of the beauties o a honeypot - the spammer does yor filtering for you.

        Somewhere over 20,000 recipients so far, since Wednesday. Here's a tiny sample, showing the URL's he advertises and the random comments he uses to defeat filters:

        [a href=" 0]"A ni[!--HVtu--]ce la[!--HVtu--]dy

        [a href=""]L[!--WPVizB-- ]im[!--WPVizB--]ited

        (I replaced agle brackets with square brackets - tou'll have to imagine them restored.)

        I have no filter, no smarts of any kind. The honeypot is a mail server with the output queue stopped. I got the spammer to start sendng spam by delivering to him three of his relay test messages - he'd sent so many I decided to see who he was, what spam I'd get if I did deliver.

        I'm trying various ways to hurt the spammer but I've not yet delivered enough hurt - he's still operating. Other spammers have succumed more readily - this guy is better at hiding himself.

        Note, by the way, that he puts no comments in the URL - if you filter on those (or remove comments before filtering - that would be easy) the spam instantly is revealed. One guy simply rejects any email message with three repeated comments in a line (this spam is laced with the comments throughout, not just in the http lines.) The spammer's clever way of obscuring the spam is useful in identifying the spam - no points for Spammy.

        Windows users with a permanent connection can step into running a relay spam honeypot very easily: they can run Jackpot:

        There is at least one open proxy honeypot out there: Google in for it. These can be very wicked - create your own for even more fun. Or create your own open relay honeypot - see if you can make it even more wicked.

        (Oversize reply packets from an open proxy honeypot might have a very interesting efffect.)
      • Re:Nice idea (Score:5, Interesting)

        by Shoten ( 260439 ) on Friday February 28, 2003 @10:56PM (#5411198)
        First off, you are incredibly wrong. Almost all spam is bounced off of servers that relay...that is, they forward mail for users of any domain. That's why this concept exists; spammers search for "open relays" (that's why they're called that, btw) and use them. TarProxy would look like a normal open relay to the spammer, and therefore he would use it.

        Unfortunately, there is a problem. Before TarProxy there was another thing, called a "teergrube" or "tarpit." What it did was slow down the connection (with things like ICMP source-quench and psychotically small TCP window sizes) so that it acted like a spam speed bump. In the meanwhile, it didn't actually forward any of the spam anyhow. Why didn't this technology become more widespread? I'm glad you asked! Because it was trivial for the guys who develop spammer software to recognize these systems, have their software detect such behavior, and cease using them within less than a minute. And that's what will happen with a TarProxy, alas.
    • Re:Nice idea (Score:5, Insightful)

      by Snowgen ( 586732 ) on Friday February 28, 2003 @08:24PM (#5410641) Homepage

      what if the spammer sends a message to a (good) SMTP server which haven't got the system, and the SMTP server in turn tries to deliver the "spammail" to the right SMTP server, won't that hurt the good SMTP server, who just tries to do it's job?

      The situation you're describing is called relaying.

      If you start with the assumption that spammers are evil, then the logical conclusion is that there is no such thing as a "good" SMTP server that would relay mail on a spammer's behalf. Servers that do are either in collusion with the spammer, or are mis-configured to allow anonymous relaying. A server that willingly acts in collusion with evil is, by definition, evil. The level of stupidity necessary to allow your sever to act as an open relay also, by definition, precludes being considered a "good" server.

      So the short answer to your query is that it's a non-issue. A truly good server will, by definition, never relay spam!

    • But what if the spammer sends a message to a (good) SMTP server which haven't got the system

      Said SMTP server would have to be an open relay, which would hardly let it qualify as "good."
  • Anti-Spam software (Score:4, Insightful)

    by Visaris ( 553352 ) on Friday February 28, 2003 @08:03PM (#5410530) Journal
    This may be just a little off topic, but the thing is that I always have to go through all my mail by hand to make sure I didn't miss anything important anyways. No anti-spam software out there seems to save me this hassle... So to this day I haven't stuck with any. It doesn't look like this will be better.
    • by stinky wizzleteats ( 552063 ) on Friday February 28, 2003 @08:12PM (#5410579) Homepage Journal

      I've been using bogofilter for a while now as a pass-through tagging mechanism. I filter on the client side based on the tag information. This sounds a lot like what you are doing.

      The only thing close to a false positive I've gotten was having to dumpster dive into my spam folder to retrieve an amazon order confirmation.

      Bayesian filtering really works, but you have to train the filter correctly and with as large a corpus as possible.

      • Bayesian filtering is a great technology, but the OSS movement really needs to tread-lightly or get some legal beagles to help us analyze the implications of inherently using it, because MSFT has a patent on it []. We (the OSS community) need to make sure that we can easily and indisputably prove "prior-art" in the event that MSFT tries to overwhelm some of our best projects with _expensive_ legal tactics.

        I can't help but think that we need to _really_ be on our guard with regard to things like this, becuase I wouldn't put it past MSFT, et al. to soak up much of the good IP (Intellectual Property) and then try to "drop the hammer" on us down the road.

        Just my .02 cents...

    • by cyphem ( 609056 )
      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...

    • by Scooter ( 8281 )
      I didn't think there was a solution available to this either - but I have since implemented a SpamAsassin script that logs in to my IMAP mailbox at my ISP, deletes all the spam, and then fires up fetchmail to grab what's left. I did loads of testing and kept the spam in a seperate folder for a few weeks just in case, but it never deleted anything that wasn't spam - so now I don't bother moving it - it just zaps it stright off the IMAP server. Yeah one day it might delete some non spam - but what the hell. It accepts "whitelists" for known good recipients. Some spam still gets through - but nothing like the 150 odd I used to get each day. Of course this doesn't really stop the spam being delivered to my ISP - and wasting bandwidth etc etc, but at least I don't have to stare at 30 variants of the Nigerian scam, 10 invitations to a bigger penis, and (more worringly for me) bigger breasts, 15 or so attachments (.scr, .jpg.pif, and those real cunning ones with 100 spaces before the extension - lol), and for some reason beyond my capacity, a fair old amount of email about septic tanks. About 35% of this email was from Korea/China but most of it was from the USA.

      I can reccomend SpamAsassin - I'd never used Perl before and probably never will again (nothing against perl - I'd just rather use one script language for my own stuff, and I happened to see PHP first!) but like most script languages it was easy enough to cobble something together, using SA and the imap perl module.

    • by lboxman ( 587913 )
      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.
    • I'm using POPFile []. So far it's processed over 10,000 incoming emails and has given me exactly 3 false positives. There are always a handful of false negatives, but it's a whole lot better than sorting through >100 spam messages a day by hand. It was a bit of an effort to train up, but no more effort than you're going through right now.
  • Interesting idea (Score:5, Interesting)

    by Quasar1999 ( 520073 ) on Friday February 28, 2003 @08:03PM (#5410531) Journal
    Just one question... what if the spammer doesn't connect to your SMTP server to send billions of messages from it? What if the spammer (with half a brain, and some scripting ability), only sends a few emails through your SMTP server? Most SMTP servers are wide open still, and simply sending 10 emails on one server and moving on to another open server would be so low that statistical usage wouldn't show anything on the radar screen... or did I not understand what you are trying to do?
    • That would still hurt the spammer alot, since it would take waaay more time for him to send all the spam, instead of just doing it through one big bulb.
    • by Osty ( 16825 ) on Friday February 28, 2003 @08:14PM (#5410588)

      Two things here. First, this article wasn't about preventing spammers from using your SMTP server as a relay, but in slowing down the reception of mail at the end-point SMTP server. This will ripple up the chain to hurt the spammers by slowing down the relays they use. Second, it doesn't matter whether I get 10 spam emails or 10,000. One of the goals of TarProxy is to be ubiquitous. I may only receive 10 spammy emails, but my running instance of TarProxy will determine that those are of sufficient spamminess to throttle bandwidth to each of those connections. At the same time, you're doing the same on your SMTP server, and Joe over there is, and so is Susie, and so on. If everybody (defined as "a large number of smtp servers", and not necessarily "everybody") is running such a service, the spammers will be hurt. You're right that a single individual using this won't make much difference, but that didn't seem to be the goal of the article.

    • Also, forgot to mention before, its not the traffic that is being analyzed, but the spamminess of the message.

      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.

    • simply sending 10 emails on one server and moving on to another open server would be so low that statistical usage wouldn't show anything on the radar screen

      Assuming such a solution were to be widely used, it would work. To send a million emails using an open server/10 emails would require one to fine 100,000 of them. Yes, there are that many out there, but this would dramatically increase a spammer's "cost."

    • Re:Interesting idea (Score:4, Interesting)

      by minas-beede ( 561803 ) on Friday February 28, 2003 @10:34PM (#5411112)
      Spammers have done exactly that. A year ago almost all relay spam I trapped came as two 21-recipient spam messages followed by about an hour of silence.

      My current spammer is sending 99-recipient spam, and sometimes he sends as many as 10 in one session. All the spam stays on my system - he is totaly wasting his time.

      I've seen a lot of recent single-recipient spam, I've seen single spam messages with recipient counts in the thousands. Much relay spam reaches my relay spam honeypot from open proxies. I think thee was some in January that came direct from the spammer.

      This (running a relay spam honeypot) is easy for many Windows users - try it yourself:

      Linux users can make Jackpot work (it's in Java) or they could jimmy sendmail (or some other MTA) to be a honeypot - do it on a second Ip with no other email function. The MTA I use is so old it doesn't know EHLO. You don't need sophisticated tools to beat the spammers.
  • Quite sad.. (Score:3, Insightful)

    by Aliencow ( 653119 ) on Friday February 28, 2003 @08:06PM (#5410545) Homepage Journal
    That we need all these technicalities to try and fight spam... But this is just like people trying to fight piracy, there will always be a new way to get around security. Actually, what we needed was authenticated SMTP from the beginning...
    • Re:Quite sad.. (Score:2, Insightful)

      *wry grin*
      Authenticated? Authenticated by whom? Who gets to determine who has the authority to send messages and who doesn't. I run my own mail server, therefore I, and anyone else I permit, can send mail through it. Are you suggesting that I shouldn't be allowed to run something as simple and utilitarian as a mail server?

      Now granted, adding authentication to SMTP in the beginning would have been nice, and useful, but it wouldn't have prevented, and it won't now solve, the spam problem.
  • Exactly ... (Score:5, Funny)

    by SuperDuG ( 134989 ) <be AT eclec DOT tk> on Friday February 28, 2003 @08:06PM (#5410548) Homepage Journal
    Back to old punishments ... Tar and Feathering ...

    Exactly [] how it should be.

    Perhaps public floggings and other corperal punishment as well.

    However I have to wonder if all spammers are really sane ... I just got an email about chicks who crave small penis's and those who crave big penis's and then emails about penis enlargement and viagra online purchases, it just seems weird that there is so much concern for my penis. Perhaps we should just imprison them on an island as they might find tar and feathering a bit kinky and enjoy it.

  • Uh... (Score:4, Insightful)

    by jdreed1024 ( 443938 ) on Friday February 28, 2003 @08:08PM (#5410557)
    I just published an article that suggests a way to use classifier output against a spammer while they're connected to your SMTP server,

    But, but, but, why would they be connected and sending spam through your server? Unless you run an open relay. And you don't run an open relay, do you? Do you?!

    • Re:Uh... (Score:5, Insightful)

      by highcaffeine ( 83298 ) on Friday February 28, 2003 @08:19PM (#5410617)
      In his article he actually does address this very question. He even gives, what I feel at least, is an interesting answer.

      So, you don't run an open relay. You're not going to slow down the spammer directly, but you will slow down all the connections that come from that open relay to your mail server. For a particularly abused open relay, that could lead to such problems that the admin of that open relay will finally get a clue and look in to configuring their server properly.

      Hence, a cascading effect that will eventually harm the spammers. Admins of open relays that get a clue will tighten their servers, thus depriving the spammers of one more relay they can abuse.
    • Re:Uh... (Score:2, Funny)

      by feepness ( 543479 )
      But, but, but, why would they be connected and sending spam through your server? Unless you run an open relay. And you don't run an open relay, do you? Do you?!

      Now if there were only a way to use Bayseian filters to detect people who didn't RTFA and slow down their ability to post.
  • by dacarr ( 562277 ) on Friday February 28, 2003 @08:11PM (#5410572) Homepage Journal
    The simpler method is still SMTPAUTH. Now we just have to convince the world that this is a Good Thing.
    • SMTPAUTH helps you not being an open relay.
      But if you want to receive any mail at all, you'll have to accept anonymous SMTP connections from any odd server out there. You just don't relay those mails.

      • This is why we should have a central authorized mailer list. This list would specify all servers allowed to send e-mail of any type. Naturally this system would be maintained by the homeland security department and personally overseen by John Ashcroft. Also, naturally, all e-mails will have to pass through a gateway on the server that maintains this central database to allow for inspection. This way every terrorist who uses the word DeCSS or MP3 in an e-mail can be promptly arrested and thrown in a holding cell for an indefinate amount of time. Additionally, as I'm sure all of you guessed, any encryption used should have a backdoor for official government use. We all know this is a perfectly logical and reasonable requirement. In order to prevent spam and protect the country from terrorists (which includes people who play(ed) DooM, watched DVD's in Linux, burned the US flag, openly admited to being gay, and/or protested against the government in any shape, form or fashion) we must be able to monitor all communications.
  • by starling ( 26204 ) <> on Friday February 28, 2003 @08:11PM (#5410573)
    TarProxy is written in Java,

    Well, that's one way to do it.

  • by Incadenza ( 560402 ) on Friday February 28, 2003 @08:12PM (#5410576)

    The hurt-back part of the project is not new. Theo de Raadt is working on just that [], in connection with an IP number list (much faster, so suitable for busy servers):

    Very simply, this hangs the full list of ~12,000 spam-sending IP/mask entries listed at off a pf(4) rdr-anchor (which is only entered for port 25). When connections from these spammers arrive they are redirected to a daemon which minimally fakes the SMTP protocol with very low overhead -- for multiple connections at the same time -- and then the message is left on the sender's queue by providing a 550 return code.

    The theory here is that most spam still comes in via open relays, and the only way we are going to convince them to clean up their act is to waste _their_ disk space, their time, and their network bandwidth more than they waste ours. For those spammers who drop messages when they received a 550, well, we have not wasted any further time or network bandwidth, and even in that situation I think some of the might remove an address if they receive a 550.

    • I mentioned this earlier in the discussion - I'm repeating myself because it also applies here...

      Using a list of the spam-sending IP's and Bayesian methods, one could assign a high prior probability of a message being Spam. The affect would be to slow down the connection on less evidence if its from a suspect IP address, and to require more evidence if its from an IP address that you trust. Thus you preferentially slow-down suspect computers, and allow your friends to get away with more spam-like messages before tarring them.

    • by mindriot ( 96208 ) on Friday February 28, 2003 @08:38PM (#5410712)
      in connection with an IP number list (much faster, so suitable for busy servers)

      Another big advantage of going by IP numbers is simply this: I have an IMAP mail account at my university that I use, but I have some external Email addresses as well, which are configured to forward their mail to the university server. Now, if the university's server will add tar based on the message content, I suppose the external mail provider will not be too happy about being slowed down. I would suppose there are quite a number of users simply forwarding mails from one account to another. Maybe (depending on how many people actually use automatic forwarding capabilities) "innocent" servers could be slowed down due to forwarding mail to a "dynamic tarpit", and maybe there are some providers that would not be too happy about such stuff... on the other hand, tarpitting by IP lists seems a little more practical then. But I suppose only practice will show which works best.

    • by Anonymous Coward
      Theo changed his mind about 550..

      It's now 450.. Hurts more.. 04 027378218501&w=4
    • by laing ( 303349 ) on Friday February 28, 2003 @09:51PM (#5410938)
      A 550 error is a permanent reject. The spam source knows that the mail cannot be delivered so it quits. A 450 error tells the connecting smtp server that your server is temporarily unable to deliver the mail, but that it's not a fatal error and delivery should be retried. This is much more likely to keep the message in the spammer's mail queue.
  • OpenBSD's spamd (Score:5, Informative)

    by almeida ( 98786 ) on Friday February 28, 2003 @08:17PM (#5410600)
    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.
    • Actually, it isn't quite the same thing. What spamd does is to use up resources on open proxies by sending back a bunch of bounces. He identifies these by using SPEWS, or some other list of open proxies. The side effect of this is that you will be bouncing all messages from them. If you are unfortunate enough to have a business relationship with someone with an open proxy, then you have just stopped any ability to communicate via e-mail by running spamd.

      However, if the idea suggested in the article are implemented, you will still be using up resources on the open proxy, but only for those messages that are actually spam. You can still receive e-mail from idiots running open proxies if you have the misfortune of needing to.
  • by Anonymous Coward on Friday February 28, 2003 @08:19PM (#5410613)
    I was hoping to get first post, but my connection got throttled back to nothing....
  • Parallel (Score:5, Insightful)

    by Spazmania ( 174582 ) on Friday February 28, 2003 @08:19PM (#5410615) Homepage
    Nonsense. The spammer will just run the connections in parallel. The slower they get the more he'll run. He already does this to some extent. All this will accomplish is to tie up resources on YOUR mail server.
    • Perhaps so... in which case you could modify your program so that after a certain amount of such abuse, it blacklists the abusing IP address -- ie. it drops all connections from that IP address and refuses to accept any more from it.

      (Yeah, I know, then the spammer can just connect from other IP addresses... but you have to admit it would be a pain for him to have to do that)

    • Re:Parallel (Score:4, Insightful)

      by letxa2000 ( 215841 ) on Friday February 28, 2003 @10:50PM (#5411178)
      I more or less agree. I actually tried this approach about a year and a half ago. I modified my Sendmail server to analyze incoming mail during the DATA phase of the SMTP connection. While it was just a simple text filter rather than a cool Bayesian approach, the idea was the same: Cause pain to the spammer because even if I filter the spam before I see it, the spammer has already done his damage. The problem is you can't really do anything to slow him down once they're on the DATA phase and the data is coming in because there is no handshaking at that point. So all I did was have Sendmail close the connection as soon as it recognized something that was sure to be spam.

      I gave up on this approach. While there was a satisfaction in looking at my message log and seeing all the spam I had hung up on, spammers would often just keep trying to deliver. Some of the worst software would try a second or two after I hung up on them so they literally pounded my system. It didn't cause any problems except for a little bit of bandwidth, but it certainly didn't seem to phase the spammer.

      The fact is, there's not much you can technically do to hurt the spammer. Even if everyone implements this there's no reason why spam software can't open up hundreds of tasks running in parallel and simply be patient when necessary. It could even make spam worse because spam software might evolve to where it DOES send spam out in parallel hundreds at a time by default [forgive me if this is already the case, I have no idea what capabilities spam software has].

      The fact is, the only way to make spam go away is to make the response rate go down. This approach gives you, as the admin, a certain satisfaction but it really won't reduce spam--it'll just make spam software more advanced. The only way to make the response rate go down is make sure the spam doesn't get to the user, and that's filtering. Feel free to implement this system, but once the thrill of sticking it to some spammers gets old you'll be back to where you were--with the filters doing the real work.

    • Re:Parallel (Score:4, Insightful)

      by WolfWithoutAClause ( 162946 ) on Saturday March 01, 2003 @01:06AM (#5411665) Homepage
      All this will accomplish is to tie up resources on YOUR mail server.

      The spammer already IS tying up 30-50% of the resources on the mail server; if you throttle the bastards back they'll end up using less. What would you prefer a few hundred megs of spam on your hard disk or a few kilobytes of spam that trickled in over a few days till they eventually kill the run. This way you save both bandwidth AND disk space.

      Either they use their own server, in which case they're easy to spot. Or they use someone else's- in which case chances are, it isn't engineered for lots of parallel connections.

      This scheme may actually work.

  • Misunderstandings (Score:4, Interesting)

    by MajroMax ( 112652 ) on Friday February 28, 2003 @08:20PM (#5410619)
    There seem to be some currently-popular misunderstandings about this article. This TarProxy is not intended to be running on outgoing SMTP servers -- it makes no sense to throttle clients that you're supposed to be monitoring anyway.

    Instead, this is meant to be run on the incoming SMTP server, the one that receives the mail. It will only hurt the spammer if he's trying to send a bunch of spam to your domain, but every server running this can help.

  • by sillobalso ( 624454 ) on Friday February 28, 2003 @08:20PM (#5410620) Homepage
    Daniel Hartmeier [] uses OpenBSD [] and packet filter [] to waste spammers time [].
  • by TheGratefulNet ( 143330 ) on Friday February 28, 2003 @08:20PM (#5410621)
    so exactly WHO are you hurting?

    sure, the open relay deserves some pain. but you're naieve if you think that most spammers send from their OWN systems!

    I have qmail running on my mail hub and I reject mail at the time of connect simply based on the receiver they're trying to send to. when they handshake (part of the HELO exchange) I detect the user they're trying to send to, and since I only have a handful of valid users, its easy to know if they're dictionarying me or not. once I know that, I immediately cut them off, AND add an ipfw (I run freebsd) rule to block all traffic from that IP to my port 25. not only do they NOT get to send any DATA to me, but they're for now on (until it ages out, automatically) forbidden from even connecting to my box. I know that's harsh but I can be that selective since its mostly just me on my mailhub.

    but I don't think for a second that even tarpitting that source IP is punishing the spammer. they've most likely broken into (or found) an open relay and they're routing thru them. they don't even see the 'address not reachable' error due to my firewalling them.

    • but the open relay is enabling the spammer. The people operating the open relay should really fix their server.
      • entirely agreed.

        I think the OR's should be punished.

        but unfortunately, the punishment doesn't get .forward'd back to the spammer.
  • the tarpits (Score:5, Informative)

    by spoonist ( 32012 ) on Friday February 28, 2003 @08:21PM (#5410625) Journal
    Here are some more spam tarpits:

    TarProxy []
    ChuckMail []
    OpenBSD's spamd [] (tarball [])
    Google Search Results []
    • We are still working on the next generation of ChuckMail, code-named "ChuckieMail".

      This slowly replies to the spammer to hold open the connection, meanwhile it launches assorted scanning and attack tools against the originating IP...

      The current version is quite primitive -- when it sees a new connection, it runs 'atq' to check if a job is pending, and if not, uses "sudo nmap -og -O" to determine the remote OS, then "at" to launch the appropriate attacks based on OS and open services.

      qmail-spamthrottle [] is a patch to qmail which I have found quite helpful in fending off the high-volume spammers, particularly the "dictionary attack" type of spam run.

      In a "dictionary attack", the spam sending software tries every likely recipient, from aabraham to zzebra. Usually they are looking more to generate a list of valid email addresses (these sell for a premium) than to actually deliver spam.

      This causes a problem for qmail, as the default behavior is to accept any RCPT TO, then generate a bounce when the local delivery agent realizes the users does not actually exist.

  • Is it possible to write some kind of program that has a detrimental yet still legal effect on the web sites (if any) featured in your spam?

    If enough people run it, suddenly it may not be so effective to promote sites that way.

    Other spam invites you to call toll-free numbers - I do, and politely let them know I don't need anything.
  • by stevenbdjr ( 539653 ) <> on Friday February 28, 2003 @08:24PM (#5410645) Homepage

    This sounds a lot like Marc Merlin's SA-Exim patch [] for Exim v4. It runs SpamAssassin at SMTP time. If it scores over a certain threshold, then the connection is stalled.

  • by vinnythenose ( 214595 ) on Friday February 28, 2003 @08:27PM (#5410659)
    The easiest solution is to have no open relays. I know I know, it ain't gonna happen, but perhaps this could convince more of those relays to close their doors:

    What we do is have a small app that plugs into eudora, outlook, evolution, kmail etc. Whenever you get a spam, you click a button, it scans the header, finds the smtp server that sent the spam and then sends them 1 email informing them of the fact that they are sending spam (of course you need a way of getting the sysadmin's email address).
    If enough people did this then the bad relays would be swamped with emails informing them of the spam they've been relaying, and they might close their relay. And non-open relays that just allow spammers to spam might think about being less friendly to spammers.

    What do people think, is it lame?
    • I happen to use Spamcop [] to get said information. You enter the headers and the body of the spam, and it processes all the headers, compares them to known open relays, and will identify the email of the admin of both the origin point of the email, and the relays it passes through. Even sends an alert for you, if you so choose.
  • What the hey (Score:5, Insightful)

    by Fished ( 574624 ) <> on Friday February 28, 2003 @08:27PM (#5410664)
    Okay, I think you've got what to do down - this is a great idea. The problem is, when to use it?

    Here's what I propose: setup a large number of bogus email accounts. Broadcast them everywhere, and let them be honey-pots for spam. The point is, since you NEVER use this account for anything but dropping in spammable places, anything you receive on it *must* be spam. As soon as you get a connection from a mail server to one of these addresses, you *know* it's an open relay, and you put it in your database -- automatically, with no interaction required.

    Step 2: You also do a "fingerprint" on the spam you get in your honeypot (you know the routine - what's the length, average use of the word "dildo", etc) so that you can identify this particular spam "copy" by the message -- NOT the header. This allows you to automatically filter out spam messages. If the spammers want to adapt, they have to rewrite their copy. As long as your signature algorithm is fairly lose -- that is, not a true hash algorithm -- they should have to do a total rewrite if they don't want to be detected. You can then filter these at the relays. Thus, once again, you raise the cost for them to do their spam. Since you are filtering by actual known-spam content -- that is, you're doing this like they do virus signatures -- you should get virtually no false positives.

    And, anybody whose friends who are emailing them about penis enlargement doesn't really deserve email anyway.

    Anyway, there's step 1 and 2. To summarize:

    1. Lag spammers.
    2. Filter spammers.
    3. ????
    4. Profit - and make sure to send me some.
  • Step 1: sysadmins band together in a DDOSOR alliance. Step 2a: Spammer uses open relay for spam campaign. Step 2b: Alliance member starts to receive spam. Step 2c: DDOSOR alliance is notified immediately and starts one-hour DDOS attack on open relay. Step 2d: open relay can't finish sending spam. Step 3: Profit!
  • Writing it in Java is a good way to ensure that I'll never run it on my machine. I have no desire to continue the JVM hell... Write in Perl, or C, or something that doesn't require me to load up yet another JVM just to run it.

    That said, great idea.

  • by zatz ( 37585 ) on Friday February 28, 2003 @08:36PM (#5410706) Homepage
    If these tarpits were ubiquitous, they could completely change the economics of spam, creating a scarcity of bandwidth experienced only by spammers.

    Err, I don't think so. This just requires spammers to use more simultaneous connections to overcome the slowdown; it doesn't really increase their network requirements much, only their host CPU requirements. 20,000 simultaneous TCP connections from one process is quite possible with /dev/kqueue under FreeBSD, for example; and you can do the same, but with a bit more CPU wasted, using plain old select() on almost any Unix.

    I also don't understand the rationale behind processing the message incrementally. Why not just do your processing before sending back the final 2xx response to the DATA command? Most spam software does not hang up right after sending the final "\r\n.\r\n" from what I've heard from people who run tarpits.

    How about this instead: when you are confident you are receiving spam, you stop reading from the socket entirely, and send perhaps 10MB of data back on the other side of the connection. (If the other endpoint isn't reading, and consequently you can only send one window worth of data, then do something to get your TCP stack to generate a lot of useless ACKs, or send your trash back one octet at a time and push between them, or something.) The intent being that sending spam to a large number of MTAs configured in this manner rapidly just becomes a way to DDOS *yourself*. Probably this is too disruptive for most sites to want to bother implementing, though :(

    I don't know exactly what the profit margin for spammers is like, but I'm not convinced a small multiplier in network costs is going to matter. Anyway, a lot of these "countermeasures" are mostly going to hurt maintainers of open relays, but if that means they actually fix them, I suppose that is almost as good.
    • Err, I don't think so. This just requires spammers to use more simultaneous connections to overcome the slowdown; it doesn't really increase their network requirements much, only their host CPU requirements. 20,000 simultaneous TCP connections from one process is quite possible with /dev/kqueue under FreeBSD, for example; and you can do the same, but with a bit more CPU wasted, using plain old select() on almost any Unix.

      So, instead of throttling back per connection, you throttle back per connecting IP. Joe Spammer opens 20k connections to my SMTP box & starts sending spam, he gets throttled back to 5kB/s *total*.

      Or if what he's sending appears to be spam, limit him to 10 simultaneous connections.

  • Seems to me that some of the comments miss the point.
    Granted, it is unlikely to be *directly* throttling a spammers server.
    Granted, what it *is* likely to throttle is some unsuspecting (we hope) person's open relay, and only one connection at a time.

    The win comes when tarpits are widely distributed, thus raising the probability than *any* open relay is likely to get throttled as soon as it starts relaying spam. In the limiting case, most/all open relays are effectively useless to spammers. Now the probabilities work in favor of Good Folks (tm) and against spammers. The key to making this work is to have enough tarpits in place to capture all open relays quickly.

    Note also, this is very low administration, requires zero active user intervention, and the cost of a false positive is quite low with no end user impact.

  • by sanermind ( 512885 ) on Friday February 28, 2003 @09:01PM (#5410768)
    Easy to defeat, just use spamming software that dynamically increases it's connection pool whenever it encounters a 'slow' SMTP recipient. Even if a large part of the net population were running this, the spammer could just spawn thousands of simultanious (slowed down, yes) connections, and still maximize his bandwidth utilization. If it takes 2 minutes to send each message, it dosen't matter if he's sending 5000 messages at once!

    I believe linux, for example, allows up to 8192 open sockets, and I think this can be changes with a sysctl command, and most definitely could be with a few changes to kernel headers.

    Sure, it would take a machine with decent memory, but that's not too hard to find.
  • I'm thinking that using spamassassin [] along with qmail-qfilter [] and a small perl script to tie it together that envokes a sleep() loop for every spam-like message, that it could easily be used to do the same thing because spamassassin kicks back a score for the message's likehood of being spam...

  • Why use statistics to cause pain to spammers when electrical shocks to the testicles work so much better?
  • If hurting spammers is really what we're after, why not just set up a bunch of honey-pots around the net? Publish this software with the ability to tag a specific as a honey-pot (user configurable). Then sys-admins around the world can make fake web pages publishing the emails, bots can catalog them, and consequently get stuck in them.

    This method is better in the sense that it doesn't mess with anyone's real e-mail address and capitalizes off the stupidity of spambots.
  • Training (Score:3, Interesting)

    by gmuslera ( 3436 ) on Friday February 28, 2003 @09:33PM (#5410862) Homepage Journal
    The idea sounds good, but as far I understand, bayesian filtering is based in training, and what is learned could be different from user to user.

    If you do an static word frequency list, spammers will pass around it (check in POPfile site for the latest spammers tricks), if is dinamic, then the users of your system must train it for a while (someone must tell that some message is spam or not, reading it). You must have another way to access your server for the training thing, and then another possible point of vulnerability.

    And more than this, as it depend on the user, you should not use a common word frequency list, you should have one for each user, and check if the message is spam against destination word base.

    At best, it will work for the users that care to train this server, for the other users that don't want to waste their time spam will be coming at the same speed as before. At worst, you'll be using a common list for all, and maybe slow down receptions of mailing lists or things like that, and people in your server could be unsubscribed from some of them.

    Is a good idea, but there are some things that should be implemented with care, and should work only for the users that care about it, the others should not be slowed down because you can put obstacles in the reception of normal mail.

  • Anything that hurts spammers is a good thing(tm)

    I hope that I'll be able to use software like this in conjunction with spam assassin or messgewall, I use messagewall ( ) primarily in front of my MTA and it does a reasonable job of identifying obvious junk as well as doing basic virus scanning on incoming & outgoing email.

    Amazing how much spam a few posts to some newsgroups generate, I create a new alias just for news every now and then to control the amount of spam I get, just delete the old alias and the spam bounces off the MTA..

    I applaud the project, every cool idea!

    If only we couldnt throw the spammers in the tar pit.. that'd slow em down :)

  • by Nonesuch ( 90847 ) on Friday February 28, 2003 @09:39PM (#5410886) Homepage Journal
    We are working on a project called "Stations of the cross".

    I have several domain names that appear on many of the "million address" CDs and other popular spam lists, but which longer any legitimate recipients/users.

    We are also working on obtaining access to true "realtime" RBL lists of currently abused open relay servers. Assistance would be appreciated.

    The core of "stations of the cross" is a custom DNS server. This server is authoritative for these oft-spammed domains, and each time a request is made for an MX record, it returns (with a short TTL) a unique randomly generated list of MXes, each address on the list being a known open relay.

    So when a spammer or relay first goes to deliver a message, the system will select an open relay off the list of MXes, and hands off the message to that host. Being an open relay, the host accepts the message for my domain, then goes to do a DNS lookup for the MX record. The relay receives a (different) list of other open relays...

    Usually, you can get a message to traverse a dozen or more open relays (most sendmail systems default to a maximum "hop count" of 25), after which the message will bounce.

    Since the only traffic my server has to deal with is DNS queries and responses, this is very low-overhead for me, but depending on the size of the spammail, very high overhead for the open relay servers.

    • by Anonymous Coward on Friday February 28, 2003 @10:43PM (#5411145)
      Want to find open relays? Here's a nice simple way I implemented a couple of years ago, and ran for awhile. It's quite simple, and detects single stage relays rather quickly.

      Write something that listens on port 25. When it receives a connection, connect back to the calling host on port 25. If the connection attempt succeeds, copy characters back and forth. Anything they send to you, you send to their port 25, and vice-versa.

      If it's a true open relay, it will gladly accept the mail over and over again. I had a few mail servers looping THOUSANDS of times through me since they didn't check Received: headers. I also realize that it would be trivial to *ahem* "break" the Received: line such that it wouldn't increment the counter.

      Granted, that sucks down bandwidth, so back to the point - proving that this is an open relay. What you do is stick a magic header in the message as it heads back to them. If you receive that header back from a host, it's something you've already looped, and they're an open relay.

      Now you know they're an open relay, so you can add them to your MX lists. You can also then avoid letting them run through your looper, since it won't provide any more data.

      The beauty of this plan is that you're only giving them what they pushed upon you first. If they leave you alone, you leave them alone. It's a nice implementation of a concept I wish more people would honor.
  • Predictable failure? (Score:4, Interesting)

    by Euphonious Coward ( 189818 ) on Friday February 28, 2003 @09:46PM (#5410915)
    The first two design principles they suggest:
    • Free: It's no good unless it's everywhere... or at least in lots of places. TarProxy is Open Source Software released under a BSD-style license and available on SourceForge (see project page for details).
    • Platform Independent: TarProxy is written in Java, so it runs on Linux, Windows, Solaris, OS X, and any other operating system with a Java Virtual Machine available.
    contradict one another, and therefore directly suggest incipient failure. Any program you want widely deployed had better not depend on having some buggy JVM installed.

    (Arguably that is the reason that Freenet has been a practical failure. Every time I have tried to use it, it has got stuck in an infinite loop, or consumed all my swap space, or crashed. I blame buggy JVMs.)

    If you want software to be widely and successfully deployed, it should (must!) resemble the software that already has been. Almost all such code (99%+) has been in C or in C++. Are there any Free Software programs written in Java successfully deployed outside of Java development shops? (Rhetorical question; the answer is "not enough to matter".)

    If you want portability to Unixes, to w32, and to Macosix, you already get that with Gcc and autoconf.

    If it's in Java, I certainly won't run it as a daemon.

  • Argh! (Score:4, Interesting)

    by SecretAsianMan ( 45389 ) on Friday February 28, 2003 @09:56PM (#5410963) Homepage
    It seems like every proposal I hear for a solution to the spam problem concludes with "If enough people did this, then...". That highlights the main problem with tarpits and similar mechanisms that only work when used en masse. Guess what? There's not a icicle's chance in hell of there being enough people to make any of these schemes work. As long as Johnny Sixpack and Patricia Partygirl (who probably outnumber the geeks at this point) keep using their spam-magnet Hotmail accounts and engage in activities conducive to having their addies harvested, spam will survive.

    Personally, the spam solution I like the best is to have procmail+formail or some other tool sitting on your mail server and making unknown senders go through a confirmation step. It doesn't work for everyone (for instance, people expecting email replies to résumés! NAGI...), but if it works for you it tends to work very well. It inconveniences everyone else, but hey, everyone else is not me. I can whitelist all the people I truly care about.

    Either that or we should throw out SMTP, email RFCs, sendmail, etc. and build a spam-free system from the ground up. Yeah, right.

  • Bouncing? (Score:3, Interesting)

    by pz ( 113803 ) on Friday February 28, 2003 @10:10PM (#5411016) Journal
    How about a manual method where one creates a ficticious bounce message from spam that has made it to the mailbox?

    The idea is the following: spam gets through whatever filter you might have, but you still want to reject it, and given that some spammers MIGHT be trimming their lists based on bounces, you forge a bounce message from the spam.

    Does anyone know if this is possible with, eg, RMail or VM (or something else) running under Emacs?

    • Re:Bouncing? (Score:3, Informative)

      by lost_packet ( 67330 )
      send your thanks to Apple and OS X

      Mac OS X mail []

      Yes, Mac OS X Mail can help you deliver a staggering blow to spammers. Simply pull down the Mail menu, choose Junk Mail, and select Automatic. The next time you receive email, Mail will move suspect email into a Junk folder. With that done, you're ready to deliver a real knockout punch to spammers by taking advantage of yet another potent spam-fighting weapon: 1. Click on the Junk folder. 2. Type Command-a to select all of the email in the Junk folder. 3. Choose "Bounce to Sender" from the Message menu. Mail will return the selected messages to the senders marked "User unknown," making them think your email address invalid, encouraging them to drop you from their lists, and, thus, eliminating spam at its source

      that's from the Feb 6 2003 issue of Apple eNews

  • by drf5n ( 561106 ) on Friday February 28, 2003 @10:25PM (#5411079)
    Do the statistics on 'spamminness' really improve the system? Wouldn't it be easier to throttle all the email to a site-adjustable rate, and have the same effect on the spammers? The ease of implementation would increase the ubiquity, and it would increase the hardware/software requirements of those who mail massively.

    For example, if your machine only receives a small amount of email per day, why not throttle them to take 10-20 minutes of connect time overall? If you only get two emails per day (one real and one spam), getting them 10 minutes later probably won't bother you too much, but could cost the spammer or his relay-helpers a 5 minute duration on a connection.

    I receive about a hundred emails per day from a number of sources, and adding six to sixty seconds of delay per email wouldn't cause me any grief. But if everyone throttled their email, it might cause someone using their '250 million Valid! Tested! Opt-In!' email lists to have to upgrade their machine to half a million connections to process it in an hour.

    I don't see that differential throttling has any benefit over a contant throttling rate. For a big site, the differentiation between spam and not-spam would probably cost you any load advantage you earned in slowing the spam, and for a small system, the delay would not be noticable.

    Of course, big senders like AOL, prodigy, and yahoo, might have to upgrade...

  • by Charles Dodgeson ( 248492 ) <> on Friday February 28, 2003 @10:35PM (#5411113) Homepage Journal
    If more people would run relay honeypots [] such as jackpot [] that might make a dent in the economics of spam.

    I'm not saying that the recipient server tar-pitting is a bad idea, but I think that there are more effective ways of raising the cost for spammers. Blacklisting the entire /24 of anything supporting spam would pressure providers to nuke spammers (or at least pass on costs to spammers).

  • Question (Score:3, Interesting)

    by helix400 ( 558178 ) on Friday February 28, 2003 @10:49PM (#5411175) Journal
    If I were the spammer, and these S L O W tarpits really mess me first instinct would be configure my program to keep track of the transmission rates of every outgoing email. If one started off fast, but slowed down, I'd cut the connection immediately, log that address away in some "do not spam again...he's a tarpitter" list, and move on to the next victim.

    Would that work? Or would trying to keep track of 20,000 outgoing email's transmission rates simultaneousy cause more problems than its worth?

  • Not a new idea. (Score:4, Informative)

    by chrome ( 3506 ) <chrome @ s t u p e n d> on Friday February 28, 2003 @10:50PM (#5411176) Homepage Journal
    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.
  • by Fuzzums ( 250400 ) on Saturday March 01, 2003 @12:44AM (#5411608) Homepage
    Ever heared about a spam-relay?
    With this method you'll only get (most of the times) the relaying host and STILL the spammer doesn't get is.
    i'd say read the e-mail and use whois and CALL THE FUCKERS. mail the registrants, complain about yahoo addresses for administrative contacts. waste their personal time. I wouldn't give a shit if it would take ond day to spam a lot of people or just one hour, but if i had to answer the phone all day without making any money...
  • iffy at best (Score:3, Interesting)

    by tacocat ( 527354 ) <> on Saturday March 01, 2003 @09:59AM (#5412886)

    I understand this guys theory of operation, but I am not convinced of it's value for the following reasons:

    • Each slow link results in a port being consumed on my machine. If I have a limit of 64 simultaeneous threads on my box, this can be effectively deployed as a Denial of Service tool.
    • Bayesian filters are already suffering from a problem where spammers break up works with bogus http tags: Via<foo>gr for fr<bar>ee. This simply means that they have to front load their email messages with a lot of cleaner words in a white-on-white text or just keep using the bogus html tags.
    • You are going to have a tremendous negative impact on all the false positives, which are rampant in the beginning of any Bayesian implimentation

    With all that aside, there may be some points in this that are valid. But I'm not certain that the usage of mail servers by spammers is going to be entirely effected by this technique.

    Wouldn't it be easier to simply challenge each incoming IP address to test it for being an open relay and if so, REJECT?

    I think that the postfix group has a similar concept for testing any incoming email address in the MAIL FROM tag to see if that address can in turn accept mail.

  • No pain (Score:3, Insightful)

    by Brian Kendig ( 1959 ) on Sunday March 02, 2003 @01:50PM (#5419119) Homepage
    The short of it is that there is no legal way to cause spammers pain.

    I've been running a tarpit for the past six months. (Exim + SpamAssassin + SA-Exim) During that time, I've seen that roughly 5% of spammers will sit around for however long I feel like tarpitting them (my timeout is currently four days), while the rest of them are smart enough to disconnect from my tarpit when they see that I'm holding them open.

    But the spammers are using open relays, and there's an infinite supply of open relays. If one of them gets bogged down, they'll just move on to another.

    The especially interesting thing is that I've seen the amount of spam attempts on my server *triple* since I started tarpitting them, from 100/day last year to 300/day now! It's as if the spammers love to be tarpitted!

    And I've found out there's absolutely no way to convince a spammer to remove me from his mailing list. Tarpit him, he doesn't care! Give him a 5xx error code, he doesn't care! Firewall his connection attempts, he doesn't care! It's easier for spammers to sell lists of five million addresses (4.99 million of which don't accept email) than it is to try to pay attention to error messages and failure states and weed out bad addresses. I've even seen spam addressed to the messageID's on Usenet news postings.

I have hardly ever known a mathematician who was capable of reasoning. -- Plato