can I make a folder that my webpage can access, but not anyone from the outside?

[gamergomer]

I've been using futurequest's form generated form for my contact page, but a client is getting overwhelmed with spam. I've decided to install tfmail and then possibly customize it with a small capatcha. tfmail has a perl script and then a few customization files.

What I've done before is put the perl file in the cgi-bin, but I've put the customization files in a private folder. Can I create, or do I have a private folder here?

I just feel that if the customization files are hidden, it's that much more that the spammers can't see...

[Bob]

Any file you place above the /www directory is not accessible via a browser but can be called by scripts using the absolute path...

-Bob

[CreatingHarmony]

I've also implemented a justhumans.com solution for this spam issue for myself and a couple clients and we've been really happy with it. The location of the cgi (if needed) is hidden as well as any email information. So far I have completely stopped receiving spam.

[jmihawkins]

Just FYI, I run nms's tfmail for several contact forms, mostly b/c it allows me to bury the mail-to address outside of the form/webpage, so it can't be scraped from the webpage (plus, I can format the output). It slows down the spammers, but doesn't stop them - they simply create automated scripts that fill-out and submit the forms. Why they bother is beyond me.

What it does prevent is their ability to use my forms (ie, cgi scripts) and bandwidth to generate tons of spam with spoofed addresses originating from my site and headed elsewhere.

The in-bound spam-content is mostly long lists of idiotic website addresses, and spam-assassin is pretty good at detecting this crap. I've seen periodic increases and decreases in spam-volume coming thru, mostly from any form that requests an email address from the user (they scrape for 'email' in the html) - overall, it really seems to depend on the stupidity level of the script-kiddie, since the end-result is essentially pointless. Regardless, I think the inbound issues are a LOT less than they could be with a different script.

You might also consider using an 'obfuscated' address whenever you need to post an actual 'mail-to' in the html - use '&xxx;' codes in place of the actual characters for part or all of the address.