OpenBSD Journal

spam blocking engine

Contributed by jose on from the no-more-spam dept.

Somebody writes: 




From: Theo de Raadt

Date: Wed, 18 Dec 2002 19:25:02 -0700
To: misc@cvs.openbsd.org
Subject: spam blocking engine

This is a start at a spam blocking engine I have been working on.

Very simply, this hangs the full list of ~12,000 spam-sending IP/mask
entries listed at www.spews.org 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.

This will be chrooted and locked down further... and I also plan on
adding stuttering to it, to waste the spammer's time further.

If you use this, you must have very current pf code.
Wow, looks like the Spews approach was good enough for Theo. Now it's even more accessible.

(Comments are closed)

Comments

  1. By captain^k () on

    you can't complain when someone writes something specifically for OpenBSD :]

    Comments

    1. By X-Nc () me@x-nc.net on mailto:me@x-nc.net

      > you can't complain when someone writes something > specifically for OpenBSD :]

      Well, maybe a little. It would be better if it were cross-platform and portable to other OSs.

      Comments

      1. By Anonymous Coward () on

        view the code. http://marc.theaimsgroup.com/?l=openbsd-misc&m=104026480213590&w=2

    2. By mirabile () on

      No, one cannot.

      *cool* *cool* *cool*

      /me going to update to latest -current ASAP

  2. By Anonymous Coward () on

    I luv it 8^) I guess nobody can say Theo doesn't have a sense of humour after this... I'm not sure it would qualify as professional though, so hopefully it isn't going to be a new default.

    Comments

    1. By captain^k () on

      http://marc.theaimsgroup.com/?l=openbsd-misc&m=104034580619289&w=4

      ..that gives the impression it is going to become a part of the OpenBSD distribution.

      As for "being enabled by default" ? Time will tell.

    2. By petr () on

      It's nasty and if u will read the thread about this issues u will realize that Theo wants that aproach to be nasty. Spammers need to suffer for what they do.
      I thing it will be in new releases, but it will definitely not be enabled by default.

      Comments

      1. By pravus () on

        it's not so much about the spammers as it is the open relays that allow spammers to get away with their misdeeds.

  3. Comments

    1. By captain^k () on

      take a look for yourself:

      http://marc.theaimsgroup.com/?t=104026481600003&r=1&w=4

    2. By Anonymous Coward () on

      snapshots

  4. By Anonymous Coward () on

  5. By Passo () on

    Thanks Theo! Hope someone will port it to Linux soon.

    Comments

    1. By Anonymous Coward () on

      Someone has to port pf to Linux then. And given that each version of Linux has a different firewall util, it shouldn't be too long before it is pf's turn. ;-)

      Comments

      1. By Anonymous Coward () on

        looking forward to pf being on a Linux distribution. ;)

      2. By pravus () on

        well, technically pf doesn't *have* to be ported to linux for spamd to work. all the spamd program does is provide a false SMTP handshake to any IP address listed on the SPEWS (or other) spammer list. pf ties in through a redirect with rules being generated from the spammer list.

        you should be able to set something similar working for iptables in linux. the main rewrite would be in converting the spammer list to iptables format. i have a friend that does something similar except he blocks the IP addresses of machines infected with codered that have hit his server. it's all automated.

    2. By Anonymous Coward () 20ys1bi02@sneakemail.com on mailto:20ys1bi02@sneakemail.com

      giving 5xx error means spam sender can stop (ab)using resources immediately, but look at TARPIT.

      in case spammer ignores 5xx, in addition to the mail staying in the queue,
      (s)he also ends up using resources for the outgoing SMTP connection (the sending process, network buffers, etc.).

      if using the SPEWS list to get the IPs to block,
      filter out duplicates with aggregate:
      http://freshmeat.net/projects/aggregate/

      from file
      cvs/netfilter/patch-o-matic/extra/ipt_TARPIT.patch.help

      Adds a TARPIT target to iptables, which captures and holds incoming TCP
      connections using no local per-connection resources. Connections are
      accepted, but immediately switched to the persist state (0 byte window), in
      which the remote side stops sending data and asks to continue every 60-240
      seconds. Attempts to close the connection are ignored, forcing the remote
      side to time out the connection in 12-24 minutes.

      This offers similar functionality to LaBrea
      but doesn't require dedicated hardware
      or IPs. Any TCP port that you would normally DROP or REJECT can instead
      become a tarpit.

      To tarpit connections to TCP port 80 destined for the current machine:

      iptables -A INPUT -p tcp -m tcp --dport 80 -j TARPIT

      To significantly slow down Code Red/Nimda-style scans of unused address
      space, forward unused ip addresses to a Linux box not acting as a router
      (e.g. "ip route 10.0.0.0 255.0.0.0 ip.of.linux.box" on a Cisco), enable IP
      forwarding on the Linux box, and add:

      iptables -A FORWARD -p tcp -j TARPIT
      iptables -A FORWARD -j DROP

      You probably don't want the conntrack module loaded while you are using
      TARPIT, or you will be using resources per connection.

  6. By Anonymous Coward () on

    This sounds great!
    What is 'current pf code'? Is standard 3.2 ok?

    Comments

    1. By Clay Dowling () clay@lazarusid.com on http://www.lazarusid.com

      3.2 release probably isn't going to cut it. When the core developer sayss very current code, you can assume 3.2-current is probably your best bet to find this code, or 3.3-release

    2. By Peter Hessler () spambox@theapt.org on http://www.sfobug.org

      No, 3.2 will not cut it. Only those who run -current (or wait for 3.3) can use this. Be patient, you will have a chance to fight back against spammers soon. =)

      Comments

      1. By Anonymous Coward () on

        Check out http://spamconference.org
        if you are anxious to fight spam....

  7. By Brett Glass () on

    Isn't it a 400-series response that leaves the message on the sender's queue? As I understand it, a 4xx response indicates a temporary failure or rejection, while a 5xx indicates a permanent rejection (i.e. the sender should not retry).

    Comments

    1. By Pete () on

      From RFC821:

      550 Requested action not taken: mailbox unavailable
      [E.g., mailbox not found, no access]

      Perhaps 421 would be better, as it indicates a distinctive transient failure.

      421 Service not available, closing transmission channel
      [This may be a reply to any command if the service knows it must shut down]

      Or, perhaps, the IETF could sanction a new reply code specifically for source-based spam filtering, i.e.

      555 Requested action not taken: open-relay suspected
      [Sender should reconfigure server to get removed from the open-relay list and retry]

      Comments

      1. By gas () on

        Obviously, the return code should be ...

        666 Don't mess with the Daemon!

    2. By Shane () on

      Theo posted a follow-up changing the 550 to 450 (http://marc.theaimsgroup.com/?l=openbsd-misc&m=104027378218501&w=4). I think you can specify the return code on the command line too, although I'm not positive about that.

    3. By Anonymous Coward () on

      Bret Glass... The annoyance that used to lurk the FreeBSD lists.

      Re-read your message. Do you really want these spammers hitting your servers twice for the same spam?

      Comments

      1. By Anonymous Coward () on

        If it works, yes. I am willing to sacrifice a little for the greater good. When one uses SPEWS, in particular, one is asking others to change their behaviour for the good of the Internet as a whole; it seems like one should demonstrate a willingness to "walk the walk".

        But I'd rather tar-baby the spam on a separate host, really. That way it's just bandwidth...

      2. By Shane () on

        Actually, that seems to be the idea Theo had. He's willing to sacrifice his bandwidth and CPU time in order to make life a little more annoying for open relays. Personally, I agree with him (I pay a flat fee for my bandwidth). If you are paying per meg or whatever, you should probably consider 550 instead of 450.

      3. By Anonymous Coward () on

        step 1: Read the article before you flame someone.
        step 2: ?????
        step 3: Profit!

        Comments

        1. By zil0g () on

          wait wait! I know this one, #2 is bomb iraq, right?

        2. By Anonymous Coward () on

          jesus fucking aged christ... go back to slashdot. that joke is so old, God doesn't even remember it anymore.

      4. By Anonymous Coward () on

        Obviously, you've got such a chip on your shoulder about Glass that you responded to him without reading Theo's original message. He happens to be right.

    4. By Anonymous Coward () on

      Not that it matters, but choose wisely:

      599 F*ck off, and stop sending me spam.

      or

      499 Hit me again. I like the punishment.

      If you choose the 499 code, you have more time and resources on your hands than most. Why be polite with a spammer? They're obviously not being polite to you. Spammer mail blasting software just doesn't care what error code you've sent.

      async_printf(fd, "helo msn.comnmail from: random@aol.comnrcpt to: list,of,addresses,to,your,usersndatanMESSAGEn.nQUITn");

      The only place where it's practical to mess with a spammer (use 4xx, add delays) is when they use a well-behaved open mail relay, and even then, it's not the spammer's resource you're wasting.

      -ez

    5. By kristina83yu@yahoo.com () kristina83yu@yahoo.com on mailto:kristina83yu@yahoo.com

      Regarding response 400, and 'further wasting of spammers time'.
      Well mister, 'blocking' mail with 400 isn't going to do any good for you, since it doesn't waste much of our time. Our software is capable of sending up to 7.000.000 emails (personalized - not multiple rcpt to) per hour, and at average rate of 2.000.000 per hour. Upon receiving of error 400, we just retry several times in next hours, and *do not* remove address from our database.
      Please use 550, since it will do good for you. We DO NOT retry delivering to domains which answer to HELO/EHLO with 550, (simply, just because we are not interested in delivering mail to those who doesn't accept it). Also all addresses from those domains are removed from our lists. 550 responses to RCPT TO: / MAIL FROM: / DATA / are also removed from lists, but it doesn't apply to other addreses i same domain.
      Also, please, do NOT drop connection in the middle of response, or before sending anything at all, since this will also generate temporary error, and we will retry later. Droping packets (i.e. not accepting connections) is generaly o.k. since it doesn't waste much of your bandwidth, but on the other hand, your domain doesn't get removed from our system.
      So, the thing to keep in mind is, that we are always going to have more resources (cpu time, network bandwidth, and so on) to send mail out, then you will ever have for receiving it, no matter what happens.
      It is just a simple matter of money. We are paid to send it out, but you are not paid to receive it, and also not paid to not receive it.

      So,
      Have a nice day. Bye.

      Comments

      1. By Anonymous Coward () on

        rule #1: spammer lie
        uule #2: see rule #1

        Comments

        1. By kristina83yu@yahoo.com () kristina83yu@yahoo.com on mailto:kristina83yu@yahoo.com

          Then it is only your problem. Not ours. Sorry.

          Comments

          1. By gdi () on

            If a large set of mailservers used this system and start doing this routine with you you claim to have more bandwidth. Please report on your findings in a year time. Then inform the recipients of a DDOS attack how much bandwidth they tought they had. Because compared to a large number of mailservers in co-locations your bandwidth and any bandwidth you can buy is actually tiny in comparison. PS If you can not deliver your mail due to this system how much money can you make from spamming, because that is what it all boils down to "follow the money". And in this case you are targeted so you can not make any more money from your business. As a suggestion to Theo could you not give the option to test if the system sending is alive by using a ping. Since ping's are legitimate this could be used to check something and I couldn't care less what, but in effect it takes out an extra bit of bandwidth from the Spammer.

      2. By Chris () on

        Sounds plausible, but how many spammers actually know/care about SMTP response codes?

        Judging by the spelling and sometimes even visible tokens ("Subj: @user Get Rich Now!"), I get the impression most spam I get is from newbies who barely know how to operate the software they're using to send out the spam in the first place.

    6. By Anonymous Coward () on

      Think about it for a minute.

      If you send a 5xx code, the sending machine will stop trying to connect to you. Now, as Theo said, the assumption here is that the client is an open relay. And we also know that a ton of this spam (probably MOST of it) has bogus/undeliverable sender addresses.

      So if you use a 5xx, what does it mean? It means that the client (the open relay moron who is connecting to you) will stop trying to hand you the message, and will instead try -- for a very long time, quite possibly -- sending the bounce/failure notification back to the original "sender address."

      Using 5xx makes it HIS problem, not YOURS. I'm fully in favor of using 5xx.

    7. By Anonymous Coward () on

      Doesn't seem to work for me. I reject with 550 all the time from my own little access database. These idiot spammers from China/Taiwan keep on trucking, even though they've been told it's a perm failure. Same morons day after day send me the same freaking email in some busted ass foreign language that I couldn't give a shit about.

      It's kinda like the Simpsons episode where Bart tries to continuously take the muffin even though it's electrified.

      Comments

      1. By C. Frank Bernard () cfrankbernard@linuxmail.org on mailto:cfrankbernard@linuxmail.org

        Consider adding rules to your firewall. You could block all SMTP traffic (to port 25) from the IP ranges assigned to the APNIC and/or RIPE areas. If someone tries to Subseven attack you, use http://www.arin.net/ to get the contact info of the abuse department (and Cc: abuse@ their domain). Include the entry from your firewall log along with your time zone ( GMT -#). If they continue, then you may want to block all their IP traffic to you.

        http://www.iana.org/assignments/ipv4-address-space

        When new spam gets by your firewall rules, add more rules to block their particular IP or even their whole range (from a WHOIS search at http://www.arin.net/ )




  8. By Anonymous Coward () on

    Sorry, I had to ask ;)

    Comments

    1. By Anonymous Coward () on

      Troll :P

      Comments

      1. By Anonymous Coward () on

        That's not a troll. That could be the one factor that makes me try Theo's spam blocker. :)

  9. By Anonymous Coward () on

    I sympathize with hate of spammers. Unfortunately I believe the assumption that most spam is still coming from open relays is nolonger true. Maybe it will annoy any spammers that are using open relays ... we'll see.

  10. By mulc () mulc@zapha.com on mailto:mulc@zapha.com

    For all of us in the qmail world,
    How is this different from rblsmtpd?
    ( http://cr.yp.to )
    You gain MTA independence at the
    price of platform dependence.

    Black-lists are a flawed solution.
    In practice, users do not tolerate
    false positives.

    I eagerly followed the link to this story thinking
    that Theo might have come up with something new and unique, but this is just old-news RBL stuff.

    This is 'in-the-box' thinking.

    Comments

    1. By Anonymous Coward () on

      Why hasn't anyone thought of using peer to peer to handle the spam problem. We could build a Spamster instead of relying on RBL which obviously don't work?

      Comments

      1. By Anonymous Coward () on

        There is take a look at http://razor.sourceforge.net/ .

    2. By Anonymous Coward () on

      thank you, you boring djb whore.

      i'll go elevate my conciousness now or something.

      christ.

      Comments

      1. By Anonymous Coward () on

        quality. someone who speaks sense. i hate the djb stuff. it makes a right fucking mess of my system.

        Comments

        1. By Anonymous Coward () on

          oh, because you don't have a clue?

          Comments

          1. By anonymous niekze () on

            no, because it makes a fucking mess.

            Comments

            1. By Anonymous Coward () on

              If you had a clue you'd change it so it didnt make a mess....

  11. By Anonymous Coward () on

    I wonder, couldn't you chew up a bunch of the spammers bandwidth by forcing them to constantly resend as many packets as you can widdle out of them (at the TCP/IP level, asking for resends)? Seems to me this would be much harder for the spammer to compensate for (since they don't write there own operating systems).

    Comments

    1. By Anonymous Coward () on

      Well, actually, we are considering to use custom-tuned linux kernel. And that is just first step to complete custom solution (leading to our own operating system - or variation).

      (There are also ideas to implement mail-processing in hardware, so basicaly, you will just have to plug in PCI card to your server, and to plug etherinet into it)

  13. By Dan Anderson () dant@drydog.com on http://dan.drydog.com/

    Great work and it sounds promising. However, I find it funny this message is posted on a website hosted by Hurricane Electric. Hurricane Electric is famous for hosting spammers such as bulkispcomp.net. Personally, I would not deal with those who take blood money.

  14. By Anonymous Coward () on

    We have a class c that has been blocked in spews. Our company has a perfect record as far as spam is concered. We've never run an open relay, residential customers can't connect to external smtp servers and we don't take sign up buisness customers that spam. I emailed them requesting that we be removed and they informed me that they would not until someone five subnets that wasn't even using verio (we are) was spamming and we would not be removed until they stopped. Apparently spews has this "collateral damage" (their words not mine) policy where if a listed address/subnet continues spamming they will block the neighboring subnets and the corporate mail servers of the hosting company. I emailed spews again to inform them that we had nothing to do with the spammers and weren't even using the same bandwidth provider. They replied that it wasn't their problem and that I should email the spammers about it. When I replied that I had absolutely no control or influence over the spamming company, they (once again their words) told me to "fuck off and stop emailing us". Cool eh?

    I have a feeling this antispam system will be modified to better accept a blacklist something other than spews when openbsd.org or some developers company gets fucked over by the "collateral damage" policy. Hopefully this will happen before 3.3 is released, I look forward to using the system..:)

    Comments

    1. By mb () matt.b@myrealbox.com on mailto:matt.b@myrealbox.com

      They "escalate" netblocks to a higher level because the ISP has taken no action and/or moves the customer to a new IP block so they have to increase the range to stop the spam. Yes, this causes grief to neighboring netblocks, however you should complain to your ISP to stop the spammer.

      It's a two pronged attack, one on the spammer such that they need to find a new isp, and also the ISP in which its legitmate customers are suffering due to their negligence.

      Comments

      1. By bleh () on

        Many ISPS are under legal contracts with clients. Terminating a client for something as reaching as "spam support services" or anything else not recognized under existing law can quickly lead to litigation that smaller isps simply cannot afford. True, most/many isps have a "we can terminate our relationship for any reason deemed necessary", but this is not something I would wanna have as my platform in court if it went there.

        Spews and all blacklisting methods are drastically ineffective because they always 1 or 2 steps behind the spammer. Having had to contend with many spam gangs myself in this regard, I see the way they operate.

        Typically, they have an office, with several means of inbound connectivity. For instance, maybe 2 or 3 dsl lines, a t1, and a cable modem to boot. They start spamming on 1 line, inevitably, that line gets terminated. They know this (obviously this is why they have 2 or 3 others waiting). They move the operation to one of the other lines, reorder service under different pretenses on the one that got shut down, and keep right on going.

        The whole rabid nanae/spews mentality is so off base it's amazing. Their product review of Brightmail (the most powerful use of checksums in existence for antispam) says it all:

        "Only filters spam in progress can't be used to block IP ranges. Somewhat pointless in the grand scheme of things as it does not put pressure on spammers to shut down."

        The effectiveness of the software is completely disregarded because it doesn't "skewer" spammers?
        Let's apply a little logic here: If spamvertising
        sales generation is decreased, this drastically reduces the attractiveness of spam as a marketing tool. Marketers would eventually seek other (possibly more conventional) avenues of promotion if spam stopped panning out.

        (no I don't work for brightmail, I'm just a big fan)

    3. By John Oliver () im.easy.to.find@xampl.com on http://www.john-oliver.net/

      You haven't read the SPWS FAQ!

      http://www.spews.org/faq.html

      After you've done so, you'll understand that *you* aren't listed... your ISP is. Because they've ignored reports about their spammers for so long, SPEWS escalates the listings. This has the intended effect of having you call your ISP and put pressure on them to boot their spammers. They don't listen to anyone else, maybe they'll listen to their paying customers. And if they don't, well, it ought to tell you somthing if the spammers business is more important to them than yours. In that case, there are a lot of ISPs who're eager to earn your business... you'll have a better ISP, and the spam-friendly ISP looses revenue. Eventually, they become totally rogue and/or go out of business, or they clean up thir act and boot the spammers.

      Is this "fair" to you? No, it isn't. But remember... it's your ISP who's put you in this position. No one else. All SPEWS does is publish an opinion. That opinion has weight because a lot of people trust it. If SPEWS "sucked", then nobody would use it, and who would care if they listed 0.0.0.0/0 for spam support?

      Comments

      1. By Anonymous Coward () on

        Did you even read the original post? He already stated that he has a different ISP than the spammers.

        Why would an ISP listen to someone who isn't their customer over a paying customer.



    4. By Noel Duffy () m_aurelius@inbox.net on mailto:m_aurelius@inbox.net

      And just how did you email spews?

      From the spews faq:

      Q41: How does one contact SPEWS?
      A41: One does not. SPEWS does not receive email -
      it's just an automated system and website,
      general blocklist related issues can be
      discussed in the public forums mentioned
      above.

      There are no mx records for the spews domain.

      Methinks someone is telling lies, or is very very mistaken.

    5. By Anonymous Coward () on

      according to their faq you need to post to their newsgroup and hope the read it to become unblocked.

      Comments

      1. By Noel Duffy () m_aurelius@penguins.org on mailto:m_aurelius@penguins.org

        > according to their faq you need to post to
        > their newsgroup and hope the read it to become
        > unblocked.

        Well, news.admin.net-abuse.email isn't their group. The FAQ tells you that, if you want to get out, you need to remove the spammer and then post to news.admin.net-abuse.email with the Spews case number.

        Then it is likely that someone from Spews will see it and delist you, after they verify the problem is resolved.

        The group exists for discussion of email abuse, Spews admins happen to read it, though they do not post. The group existed before Spews did.

        The original poster claimed that he emailed Spews, and that Spews told him to fuck off. He could not have emailed Spews, so this poster is either lying or else exchanged mail with someone that he thought was Spews, but who really wasn't.

    6. By coolvibe () on

      Don't bitch at SPEWS, bitch at your ISP. If your ISP doesn't deal with the spammers, pack up and leave to a less spamfriendly ISP.

      Your ISP is getting you blocked, not SPEWS. You are in a bad net-neighbourhood, just move out.

  15. By submicron () i.hate.spammers@127.0.0.1 on mailto:i.hate.spammers@127.0.0.1

    For those of you who are interested, SPEWS has a pretty shitty reputation for blackholing blocks of totally unrelated IP addresses as part of their "collateral damage" policy. Check out http://www.antispews.org/ for the full poop.

    That said, I think this is a great idea, I just wish Theo had chosen a more reliable blackhole list source.

    Comments

    1. By Anonymous Coward () on

      You choose any list of IP addresses you like and feed it to pf. pf redirects incoming SMTP connections to spamd, which then plays its game with the sender.

      It works exactly the same for any list of IP addresses, doesn't have to be spews.

      If you understand how this works, you'll see that it's trivial to add a whitelist. Or why it wouldn't make sense to send DNS queries to check the RBL.

  16. By Anonymous Coward () on

    Call me a cynic, but has it occurred to anyone else that this is something that got written because Theo has had a spam problem recently?

    Don't get me wrong, I think it's a great idea. Just OBSD developers tend to write something they're interested in or need done. Which is the way it should be (not least because vested interest gives good results most of the time).

    Comments

    1. By Gimlet () on

      Ever notice that this is how all things get created? In order to SOLVE a PROBLEM? There's not much else of a reason to do something....

  17. By Gandalf () on

    What can I say .. EAT THIS SPAMMERS! It's a pretty darn handy thing if you ask me.

  18. By James () james@firstaidmusic.com on http://james.firstaidmusic.com

    This is why I like OpenBSD. Theo doesn't care about anything but how well his computers operate and how his computers play with others. If he doesn't like the computer talking to him, he's just the guy to come up with a way to convince that user not to talk to him anymore.

    Theo, keep the great ideas flowing!

  19. By chris cappuccio () chris@nmedia.net on mailto:chris@nmedia.net

    SPEWS sucks the big one. It is the most unreliable piece of shit list, managed by assholes who hate spam the same way the US government hates middle easterners. That is, they are fucking blind and have no clue. IP based blocking lists are like, so 90's, oh my god!!!

    I gotta say, doing this at the network layer is cool, and is useful for downstream mail servers where you may not necessary want to make changes on the host. Or at least, it would be useful if there was ever an IP based blocking list out there that didn't give you a huge false positive rate.


    Heuristic filters like Spamassassin are really much better tools than {SPEWS, ORBL, etc..}, with a much lower false positive rate. And the new stuff like the bayesian filters, where the software develops heuristics for you based on the messages you say are spam, that is also a good way to do it. These filters are much more processor intensive, so I guess it really depends on your application.

  20. By John Sokol () sokol@dnull.com on www.dnull.com

    leaving as many servers that mimic open relays but don't actualy relay is something I was sugesting a few months ago to the FreeBSD group here in SV.

    Make any server that's not doing mail act as a virtual open relay.

    Also all mail servers that when blocking a relay should report a sucessful relay message.

    If the spammers can't seperate real open relays from bogus one's it will increase there cost of doing bussiness.

    They key here is to make it not as profitable for them or for them to have to get there own DLS/T1's to spam from. Then these are easier to block and hunt down.

    JLS

    Comments

    1. By Anonymous Coward () on

      You can't mimic an open relay without actually relaying - it's pretty easy for a spammer probing machines to check that the messages actually get delivered...

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]