Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Funny you should mention that.

    As darobin, at least, knows, I admin the Paris Perl Monger mailing list. I had a run-in with SPEWS today, and was about to write up my adventures in my journal and perchance happened to check what other friends had added new entries, and so came here.

    What has happened with is that its address [] belongs to the same C class as, apparently a known spammer [], and SPEWS had the entire class marked down as belonging to I suspect this is merely because both (apparently) and (certainly) are hosted by

    I started receiving piles of bounce messages from MTAs that decided to start refusing's traffic. I extracted all the destinees (if that's the word) and Bcc'ed them a message saying that their MTA was refusing traffic from and that until they rectified their anti-spam rules or the SPEWS situation is cleared up they will not be receiving anything from the list.

    One person was already familiar with the problem and whitelisted to let it go through. The other person was a lowly grunt in a university who pointed out that the chance he had of influencing e-mail policy was close to zero, and I haven't heard back from anybody else.

    What with all the recent fuss over Bayesian approaches to Dealing With Spam (c.f. Perl Monks, Need To Know, Paul Graham) it underlined for me once again that the idea of trusting your spam management to an outside/disinterested party is a dangerous thing to do.

    I can understand the rationale: "I hate spam, and I don't want to burn a single cycle on or transmit a single byte of the stuff", but I think that's just wishful thinking.

    Whilst spam arriving at my corporate MTA is still a blip on the radar in relative terms of bandwidth, in absolute terms it is becoming a major problem. At the moment we don't have antispam filters in place, because Domino on Win32 doesn't really lend itself to the process. But this year we are planning on migrating to Linux, so there's a good chance I'll wind up implementing something.

    And what I'm toying with is something a little more radical. Sure I'll probably sign up with an RBL or two, but what I'm going to do is I'm still going to accept everything. But. When I come acrosss mail that comes from a suspected spammer, I'm going to put sleep(120) or so between each step in the transfer dialog.

    If enough people start doing this (and maybe people do; I haven't looked into the matter) then spammers are going to be hit where it hurts: raw throughput. Instead of pumping out 100 000 messages per hour, they're gonna start choking on sites which take minutes to complete.

    If you are an innocent site, well, tough, from time to time you'll have a socket tied up on your mailer to a remote site, but as sending email isn't the be-all and end-all of your business, that's not going to be a big problem. But if you're a spammer, you're going to find that you can't bomb as many people in the same time frame as you used to. Spamming therefore becomes more uneconomical.

    And that, in my books, is a Good Thing.