== Another comment spam precaution that no longer works out I use a number of [[comment spam precautions CommentSpamPrecautions]] here (although [[most of the work is done by only one ../spam/CommentSpammerBehaviorIII]]). However [[every so often CommentSpamMistake]] one of these clever tricks turns out to be not just useless but a bad idea. One of my most elaborate comment spam precautions here is signing the comment form with [[various information SigningRequestIP]] about the IP address that fetched it. When I came up with this precaution back four years ago, it was clear from my logs that spammers were fetching my 'add a comment' page from one IP address, sitting on it, and then submitting comments from another IP; adding the precaution caught a certain amount of spammers with no false positives that I could see. Well. That situation has now changed. It's been some time since this precaution has prevented any spam; if spammers are still doing this at all, they're tripping over other precautions first (almost always my honeypot form field). Unfortunately I've now seen two instances where this precaution seems to have misfired, preventing real people from posting actual comments. So out it goes; I can live with inactive and useless comment spam precautions, but not ones that give false positives. (Unfortunately I fumbled some code when I did this the first time. For semi-obvious reasons testing this case is kind of tricky, but I really should have tried harder.) I'm not sure why people are hopping between significantly different IP addresses. My current theory is some sort of proxies, possibly for mobile devices and smartphones; if the proxy choice is basically random per request and the proxies are on multiple subnets, it would match what I saw in the logs. The alternate theory is that ISP DHCP servers are giving out significantly divergent IP addresses when people have flaky lines and keep disconnecting and reconnecting.