Other than trapping bots into submitting forms meant for them just so you can flag content and or IPs... no not really.
I do have a trap for email crawlers that sees quite a bit of action from bots though :-) http://acoderslife.com/botfun/emls.cfm ps... its Bobby not Bobbie ;-) ..:.:.:.:.:.:.:.:.:.:.:. Bobby Hartsfield http://acoderslife.com -----Original Message----- From: Ray Champagne [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 14, 2006 3:36 PM To: CF-Talk Subject: RE: Capture Alternatives Here's a question that hasn't been answered, maybe 'cause there isn't one: we talk all day about protecting ourselves from these gnarly bastages, is there any way to fight back? I'd love to see a way for me to block them, then fire back with my own script - it might not solve anything, but man, it would feel good... > -----Original Message----- > From: Munson, Jacob [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 14, 2006 3:25 PM > To: CF-Talk > Subject: RE: Capture Alternatives > > > * Check the form was actually submitted from within the site? > > Perhaps via CGI. although I'm sure that may have issues as well. > > This is a good idea, but I don't think it will stop all spammers. > You're correct that some spammers directly access the submission form. > When I first put my math question on my blog's contact form, the spam > didn't stop at all. The reason was because the spam bots weren't using > the form at all, just sending data to my form processor. > > > * A field that checks when loaded vs submit time? Are the > > spam bots the submit bots, or is there a delay between the two. > > I've heard of this technique, and I'd think it would work in most cases. > The only problem I can see is if you have server side form validation, > the user gets an error, goes back and quickly modifies a field and then > resubmits. > > > * The scriptProtect function in Application.cfc? Is this applciable > > I've never used that, but I don't think it will help. Here's a > paragraph from livedocs: > "The ScriptProtect attribute lets you protect one or more variable > scopes from cross-site scripting attacks, where a client attempts to get > your application to send malicious code back to a user's browser. In > these attacks, user input (for example, from form fields or from URL > variables) sets a CF variable which is destined for user output. The > submitted data includes malicious code, such as JavaScript or an applet > or object reference, which then executes on the user's system." > > > > ---------------------------------------------------------------------------- -- > This transmission may contain information that is privileged, confidential and/or > exempt from disclosure under applicable law. If you are not the intended > recipient, you are hereby notified that any disclosure, copying, distribution, or > use of the information contained herein (including any reliance thereon) is > STRICTLY PROHIBITED. If you received this transmission in error, please > immediately contact the sender and destroy the material in its entirety, whether > in electronic or hard copy format. Thank you. > > ====================================================================== > ======== > "EMF <idahopower.com>" made the previous annotations. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Introducing the Fusion Authority Quarterly Update. 80 pages of hard-hitting, up-to-date ColdFusion information by your peers, delivered to your door four times a year. http://www.fusionauthority.com/quarterly Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:260444 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4