Bill Atkins wrote:
Oh, give it a rest, you. He's got nothing to gain from lying.
Then you wouldn't mind giving out the server logs for us to confirm you
are telling the truth.
I'm not the one that is telling lies, and yes he does. He thinks he has some type of authority over security. He doesn't prolly even know what an ankon does. He has no experience and yet he makes remarks about implementations not working. I've experience to identify when people are lying, plenty of it. The truth is that RBLs are more than just mail servers, they are lists of abusive hosts for different reasons. If chad wants to be blnd because I came up with the idea and he didn't, fine. There are other smarter people out there with wikis that have an open mind.
There was the beginning email about Rubygarden spam which had the IP listed on RBL servers since last year. There was also another person who replied to the [SOLUTION] thread which even said some of the IPs were in the blacklists as well.
even from 221.15.71.32 which spammed Captcha
I never said RBLs were the ultimate solution, of course they are supposed to be used in other means as mail servers use them. Mail servers take use of RBLs, AV, grep engines, sender identification by mail/rcpt tag, and many other ways.
I've been searching through.. there are also IPs like 61.149.119.74, 61.50.242.197, 68.40.176.215,200.56.233.5, and many many others which have had a god contribution to spam.
I was checking most of the pages like.. Captcha for the ips.
Hosts like.. www.bhmassociates.com are open proxies (this one is a squid proxy on port 3128) that is on the page above.
I think there should also be prox scanner checks done on the common ports at start, have a database of hosts.
The RBLs will block about 80%
The Scanners will block another 10% of the spam that gets past the RBL
Implementing the RBL access is simple, and what would be nice is to have access in a wiki to submit abusive hosts with the IP and revision page to the blacklists for people to check, like dsbl, which has open relays, open proxies, or some other vulnerability.
There are other ways to bundle a better security method. My way is the easiest for blocking people who love spamming the wikis instead of applying ill-minded restrictions to the wiki pages.
If he wants to be so foolish as to not listen to my advice, fine. Its his loss, and everyone elses in the Ruby community since there will probably still be spam. Logins can be automated, captachas can be read by smart bots as autoaim bots for video games are created. The real solution is not obfuscation, its security.
David Ross
···
On Fri, 29 Oct 2004 22:13:51 +0900, David Ross <dross@code-exec.net> wrote: