I am going to pull out SFS reporting based on this. I will be releasing a new version, perhaps this weekend.
If I report the raw ip then a good percentage of users will be reporting localhost, a local network, a hosting company, cloudflare, or a proxy server. It is better not to do it at all.
For the same reason, spammers will always be able to spoof an IP making
If this is a real problem to SFS, it might be better to pull all lookups by IP because IP address is not reliable.
Keith
Thank you for your attention in this matter. Unfortunately, there is no good answer. Furthermore, casual users do not realize how unreliable any of the data is that we have to work with. We do what we can with preponderance of evidence. When IPv6 becomes pervasive, perhaps the situation will change.
FWIW, the only way localhost or private network IPs will show up in REMOTE_ADDR, since it cannot be spoofed, is if the spammer were truly operating off the same server or LAN. You are of course correct about the rest regarding proxies and gateways. At least we know for sure where the spam is coming through from. While X_FORWARDED_FOR etc. should usually yield more useful information, the fact someone can define it as anything they like, IMHO, makes it about as useful as usernames for identifying spammers.
You are of course free to do what you think best if it is not impacting the SFS database. One thing you could do is use X_FORWARDED_FOR etc. as you see fit but use the REMOTE_ADDR field when actually reporting data to SFS. Or not report at all works too.
Cheers
The version that I am testing uses only remote_address for checking and reporting. I am treating forwarded headers, including the coudflare header as spoof attempts and the plugin denies access.
I give them a second chance with a captcha if they are denied so it takes the sting out.
I have been running this version for about 12 hours and I have not had anyone use the captcha to gain entrance, so it may be that relying on remote_address will be sufficient. Time will tell.
Keith
Now that’s interesting! While the potential is always there, I was always reluctant to deny access simply on mere existence. I personally hate it when presented with captchas, so I’m always reluctant to force them on other potentially human users. But if the numbers are really that small it’s a great strategy!
Of course there’s possibly others like me, when presented with a captcha, think “Ah, forget about it, dropping a comment is not that important to me” and abandon the process. Each site owner will need to decide for themselves if it’s worth possibly turning off a few random real users in exchange for less hassle from spam. It’s great to have such a choice 🙂
I hate captchas also, and that is why I never use them on my sites.
The “second chance” captcha is mainly to keep a sysop from locking themselves out and secondarily to allow comments from users who look like spammers and are not.
I have been running the code on two dozen sites for 30 hours with many thousands of spam rejections and a dozen or so comments, and not one person has filled in the captcha. Either it is unnecessary or there are legitimate commenters who gave up. I think it is unnecessary.
The captcha is just a fall back, and it can be turned off easily.
Keith
I noticed in your changelog you have released the new IP source version. FYI, I let the folks at StopForumSpam know that all is well again with Stop Spammers. Thanks for taking care of this in a timely manner!
