Simon graciously replied: >Require the user to be logged in, using cookies or whatever your >favourite authentication method is. For many scripts (such as a form >feedback script) it doesn't make sense to require user logins. In that >case, just make sure the scripts can't do anything harmful (like send >emails to any email address). That's exactly why I asked, to find out the recommended way of implementing a contact form. I had read that earlier Perl scripts, like FormMail.pl from Matt's Script Archive , were not to be used due to security holes which allowed spamming. Given Simon's good hint about just make sure it can only send to certain addresses, I initially started writing my own script to include this limitation (without requiring a login). However, I soon realized that maybe I ought to check to see if some of these old scripts had been updated to be more secure. Sure enough, the newer versions (starting with 1.91) of FormMail.pl claim to have closed "the worst problems that have been made public in:  It does this by limiting destination addresses to either certain domains or an actual list of allowed addresses. Does anyone have any experience with FormMail.pl 1.91 or 1.92 (the latest) and can recommend it to me, or not? - John  http://www.scriptarchive.com/index.html <http://www.scriptarchive.com/index.html>  http://www.monkeys.com/anti-spam/formmail-advisory.pdf <http://www.monkeys.com/anti-spam/formmail-advisory.pdf> P.S. to Points South: I'm CC'ing you because this relates to the question I asked recently (to which I haven't gotten an answer) about if you recommend any particular contact form email script. In all probability, I will install and use FormMail.pl 1.92 for my commercial domain, barring any negative responses to this message. ------------------------------------ This message may contain information which is private, privileged or confidential and is intended solely for the use of the individual or entity named in the message. If you are not the intended recipient of this message, please notify the sender thereof and destroy / delete the message. Neither the sender nor Sappi Limited (including its subsidiaries and associated companies) shall incur any liability resulting directly or indirectly from accessing any of the attached files which may contain a virus or the like.