Jump to content


  • Posts

  • Joined

  • Last visited

Mabu's Achievements


Newbie (1/6)



  1. In addition to Spamcop's RBL, we've been working on a non-expiring relay blacklist of DUL IP space that is run by irresponsible ISPs. This includes areas like China, Brazil and Korea as well as broadband ISPs all over the world and in the states. If you're running a Sendmail server, this RBL is available as a download and can be easily incorporated into sendmail via the /etc/mail/access file. This file is free and provided AS IS, but we and many others have found it so useful and helpful that it needs to be shared with the community. STOP SPAMMERS COLD by not even letting them clog up bandwidth, resources and disk space. If Spamcop didn't expire entries, their RBL might look something like this: http://relayblacklist.blogspot.com/
  2. Well, those that use Spamcop for their main e-mail address.. my comments are not relevant to that situation.. People who like me, run mail servers that use SCBL, can chime in and let me know what they think. Notwithstanding the two-bit attitude from the moderator here... go ahead and warn me. If thinking you're a wanker is grounds for getting me banned, then go ahead and ban me. I'm only trying to help, and I've been working with spamcop and loyally reporting spam since the beginning, so pardon me if I feel I am entitled to drop in and express my undiplomatic opinion. We're battling an army of scumbags who steal peoples resources and I don't have patience for them, and I don't have patience for power-tripping moderators who want to "warn" me for my "outburst" even though I am on topic and trying to point out an issue. Sheesh. With that out of the way, the issue here is, shouldn't there be a version of the SCBL where IP ranges do not expire? This seems to make a lot of sense. Is there another RBL that works like this? The DUL space for most broadband ISPs like Comcast, Bellsouth, Verizon and others should be permanently RBL'd and then whitelisted on an IP-by-IP basis IMO. This may shut out people who want to run their own rogue SMTP server legitimately, but in the long run it's better off IMO. Anyway, I guess if you don't see another post from me, it's because I've offended Wazoo's ego. C'est la vie. Just remember, banning me doesn't reverse the fact that I think you're a dork for your heavy-handed control crap. You do this community and old-timers who helped make Spamcop successful in the first place, a profound disservice. It would be wise for you to loosen up.
  3. Thanks for the insight Captain Obvious. I would have never realized that. That notwithstanding, I know when I've been the target of retribution. Please don't insult my intelligence with speculation that everything is random in spammer-land. Anyone with any amount of experience here knows that's not the case.
  4. Wow... forum Nazis here.... You people need to relax a little bit. Your guess is as good as mine. It seems a discussion about my experience with SCBL would fit in somewhere. The operative issue here is: 1. Any Sendmail experts know if an access-based (i.e. connect:x.x.x.x 550 REJECT) takes precedence over the FEATURE() enabling of RBLs? Then we can put that issue to rest. 2. Is Spamcop still auto-expiring IP entries, even for confirmed IP space that shouldn't have SMTP traffic? If so, then the way the Spammers are now operating, Spamcop's RBL isn't that useful. I am willing to make my RBL data available to anyone that wants it.
  5. I'm simply suggesting that this would be a useful feature. I'm sure I'm not alone. What's the point of wasting my time or spamcop's resources to send a spam report to an ISP that knows full well their customers are spamming? Why not skip them and send to an uplink? I have been attacked by spammers for reporting them via spamcop. I know in some cases, using Spamcop increases the amount of spam you will receive if the spam reports get into the hands of the spammer. They have a tendency of forging "from" headers of the domains of people who report them to Spamcop.
  6. I've taken to not reporting spam issues with the most popular spam-haven-hosting companies, like those in China or Russia. Obviously these ISPs know full well their clients are spamming. I see no advantage in sending reports to these companies, and in fact, I see a serious disadvantage in doing so, as you tip them off that the relay they've been exploiting has been "outed", and they can use the report to possibly seek retalitory action against the person reporting them. As a result, it seems that it would be useful to set the default option of sending reports to known spammer hosting companies to OFF. Does anyone agree with me? Can we get this changed?
  7. First and foremost let me say I love Spamcop's RBL and I'm one of the service's biggest boosters to the Internet community. However, I'm beginning to believe it just isn't as effective as it used to be. A little background: I run a dedicated mail server for several hundred clients who include everything from individual/non-commercial users to large corporations, government agencies and several prominent media groups. I consider my customers to be a very good mix of a wide variety of demographics for typical online users. I am very anal about making sure legit mail is not blocked and would prefer to err on the side of caution. I employ no content-based filtering, only RBLs, and I stop about 95% of spam this way. I haven't done a lot of research but my impression is that the current criteria for SCBL is that after x amount of time, blacklisted entries expire from the database. This would explain the ineffectiveness of the RBL over time, as spammers now operate from ever-rotating, very large chunks of DUL IP space that they can move through without much problems from Spamcop. In an attempt to deal with this, I've set up my own Sendmail access-based RBL and here are the stats for the past week: Date, received mail, invalid users, Spamcop caught, Spamhaus caught, my own RBL caught Jan 26 00:00:00, 4648, 1084, 2201, 528, 16132 Jan 27 00:00:00, 4634, 1488, 2280, 608, 16011 Jan 28 00:00:00, 2634, 1086, 2622, 535, 14516 Jan 29 00:00:00, 2654, 1284, 2465, 624, 16172 Jan 30 00:00:00, 5173, 1401, 2577, 645, 15844 Jan 31 00:00:00, 5370, 1490, 3493, 628, 17387 Feb 1 00:00:00, 4997, 1197, 2290, 617, 15640 Feb 2 00:00:00, 5130, 1129, 2782, 778, 18250 Feb 3 00:00:00, 4478, 1119, 2967, 649, 17198 Feb 4 00:00:00, 2823, 788, 2596, 532, 13251 According to the figures above... * This server receives 24,756 daily e-mails on average, of which 19,281 (77.9%) are confirmed spam. * If you consider most invalid user e-mails to be spam or spam bounces, then the UCE rate jumps to around 82% * Spamcop's RBL catches 2627 spams a day or 13.63% of confirmed spam * Spamnaus's RBL catches 614 spams per day * My homebrew RBL catches 16040 spams a day or 83.18% of confirmed spam It looks like my RBL is much more effective than either Spamcop or Spamhaus's efforts. What am I doing differently? Well, I am not removing IPs from the database unless I'm specifically asked. If I'm asked, then I do so without any additional questions. In about five years, I've had maybe 1-2 dozen reports of legitimate mail being blocked, and in every case, I fixed this quickly. In the same period of time, I've probably had a similar amount of legit mail blocked complaints involving both SCBL and Spamhaus. I sometimes do wholesale IP range blocks when I run across a spam I can identify as coming from DUL space. I also have aggressively identified "rogue spam nations" like China, Korea and others and have most of their class Bs RBL'd. If I ever get any requests for removal, I whitelist IP blocks upon request. In fairness, it may be possible that my access-based RBL might be checked first, before Spamcop or Spamhaus (can someone verify this) and this might be a factor in my system statistically seeming far superior to Spamcop. I guess the best way to test this would be to remove my RBL and tabulate some figures alone based on the existing RBLs, but I'm still pretty certain that my system is at least, just as effective and most likely more than SCBL. My feeling is that, it is now no longer an option, but a NECESSITY to PERMANENTLY RBL DUL SPACE that should not have outbound SMTP traffic. AOL and a few responsible ISPs have finally decided to filter port 25 and this has made a tremendously positive impact on the reduction of spam, but others like Mindspring, Verizon, TDE, AT&T, Comcast and others have not taken action. As a result, I think responsible ISPs should just stop accepting mail from their DUL IP space. We need to force these systems into policing their own users' illegal activities. If Spamcop is expiring DUL IP RBL entries, then the service is nowhere near as useful as it needs to be. Comments?
  • Create New...