Some other "imperfect" solutions: * Take the CRC (or some other hash function) of the message content and reject messages with duplicate CRC (still vulnerable to morphing of the message).
* limit submissions by sender to one every X minutes. Avoids the AOL issue, but vulnerable to DDOS and spoofing. * Have the form run some client side code (javascript or VBS) to create the email and send it from the client, so you have more information about the sender (Use something similar to browser or mail client behavior on a "mailto:"; URI.). Plus, using a client-side script will allow you to turn some of the spammers techniques back on them. If it's a bot, it's likely to either blow up or reject your request. If you send a bunch of extra requests back to suspected bots, you're more likely to crash the bot. For example: * for each request, open a new client window to acknowledge receipt. Clients can deal with it, bots have to be designed to filter it or handle it. * For suspected bot requests, send huge text strings back to the requester to see if the bot has a buffer overflow vulnerability. * CC: the mailto: message back to the sender from the client side to flood their inbox when its a bot. Even if the bot honors the send mail request, you're returning the favor back to the spammers and flooding their system with Emails, too. Even if the bots can continue to hit the "submit" button, it will reduce the server side processing time for each request, and greatly reduce the number of emails actually sent. Downside is that if they scan the outgoing emails from their machine, they can spam the email address. -----Original Message----- From: Bill Moseley [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 18, 2002 1:13 PM To: [EMAIL PROTECTED] Subject: [OT] Ideas for limiting form submissions I've got a mod_perl feed-back form that sends mail to a specific address.. Spammers have their bots hitting the form now. The tricks I know of are: - generate a random image of numbers and make the user type in the numbers on the form. Painful for the user and spammers probably have OCR! - require an email and send a confirmation email (like a list subscription) and whitelist some email addresses. But we want to allow anonymous submissions. - limit submissions by IP number to one every X minutes. AOL users may get blocked. - md5 the submission and block duplicates (should do this anyway). BTW -- what would you recommend for caching the md5 strings. Cache::Cache or DBM? I suppose a Cache::Cache file cache would be the easiest. Any other ideas on the "easy to implement" side? -- Bill Moseley [EMAIL PROTECTED]
