![]() |
Quote:
|
Can you consider adding an option that when you add an IP address to the Blacklist, you are no longer notified about that IP as attempting to register.
I'm getting bombarded by a few persistant and consistant IP's and since they're now in my Blacklist, I don't care to know about their registration attempts via the PM notifications. One of them is 216.145.49.15 which resolves to 'snv-global1.corp.yahoo.com' - anyone know if that is a legit one - if so I can add it to my Whitelist. I'm suspicious that it's a bot or something tripping up on it, but I'm not sure. Thanks in both cases! |
Feature Request: The ability to do the checking for DNS BL upon registration, but in a non-blocking mode. That is, give the option for what to do to the admin. I would very much like to do a dry run to see how things lie for me, prior to enabling this in full blocking mode. I had the plugin installed, and it was rejecting some users at login. Yes, they were using proxies, and I can easily add them to the white list, however I'd like to get a baseline without blocking out a lot of users right off the bat.
Until then, I've had to uninstall the plugin. |
It shouldn't block people at login as it only fires at register_start.
I'll look at adding a report/block option. |
I couldn't reproduce my users' problem. It might be useful to include the URL that the user was getting blocked on, that way if there is a user who is having a problem, we can better help them.
Also, in the default list of "Known Proxies" is "10.237.44.144", which is an RFC1918 Non-routable ip address (as are 192.168.x.x addresses). It'll never trip, but it's also probably not a good idea to include ip addresses that often exist in corporate private networks. One more thing (sorry sorry, i know that you do this in your free time, but I want to help you make it the best it can be), The "RBL Match Mask" only allows to match against the first octet (I haven't tested this, but it's what it says). It would be useful if we could provide a list of things to match against. Different DNSBL's return different 127.0.0.x addresses, which indicate the type of host that is matching. From http://www.spamhaus.org/sbl/howtouse.html, Quote:
http://www.njabl.org/use.html Quote:
I think it's dangerous just to blindly use a DNSBL without making sure that you want to block everything it has to offer. In the context of a bulletin board system, you might not want to block the same hosts that you'd block in the context of an anti-spam system. |
I have removed the 10. IP from the list of "known proxies" .. I suspect that was a typo on my part. The RBL mask currently only matched the first octet because various RBLs have various return codes - all varieties of 127.0.0.x
If you want to be granular to the point of the last octet then the benefit of using more than one RBL - which was requested by several people - goes out the window as no 2 RBLs tend to use the same definitions. I - for one - am looking at a more "inclusive" matching pattern. That being I would rather block people that shouldn't be than allow trolls in... the function of a whitelist allows you to specify IPs that are erroneously getting blocked. |
Quote:
Quote:
Quote:
Quote:
Quote:
Thanks for all the positive feedback guys... what started as a quick and dirty hack for my own forum is actually getting to be a decent hack. |
Quote:
How about this idea: It could come, preconfigured, with a good number of common SBLs. For each of these, the admin has the ability to choose open proxies, spammy servers, dial-up networks, etc etc. Additionally, give the ability to add their own SBLs with their own options for matching against there. I think it might give many admins a false-sense of accomplishment once they install this and start blocking lord knows what, but believe that they're only bad things (The plugin name says block proxies, but in reality it is blocking far more than just proxies). It's widely known that large American broadband networks are responsible for a great deal of spam, and a good number of these block-lists include those subnets. I'm afraid of doing a disservice to the users if we choose to just blindly block everything. I think that for this plugin to truly be successful, the admin should be able to finely tune what is and isn't blocked. If you've got a forum with tens of thousands of users, with hundreds of signups a day, whitelisting things would be almost certainly unmaintainable. As for trolls and whitelisting, how are you going to know if someone is a troll or not before they've even posted anything? What indicators should be used to go ahead and whitelist one IP over another? I think that in order for our individual communities to grow, it's like dealing with spam in that it's important that we make sure that all the good guys can get in, even if that means some cruft gets in on occasion. I'd rather ban 2 or 3 trolls a month, than waste my time trying to figure out if 233.44.23.XX is going to be a troll or not, over and over and over again. |
Quote:
Thanks Daniel! https://vborg.vbsupport.ru/ |
Quote:
|
All times are GMT. The time now is 04:40 PM. |
Powered by vBulletin® Version 3.8.12 by vBS
Copyright ©2000 - 2025, vBulletin Solutions Inc.
X vBulletin 3.8.12 by vBS Debug Information | |
---|---|
|
|
![]() |
|
Template Usage:
Phrase Groups Available:
|
Included Files:
Hooks Called:
|