1. Validate and sanitize all form input that will be used in the email.  If a field is supposed to be an email address or a phone number, then it should not be a link to a porn site.  If a form input is to be used a recipient for the email, make sure its format is consistent with that of an email address.  Visitors have been know to leave off their domain name (probably AOL users) or supply phone numbers or personal names instead of the expected email address.  Others have combined multiple email addresses where only one was expected.  Typos are common so “aol.com” is often “aol,com” and the “@” is the lower case version, 2.  

2. Send mail via localhost if you expect to need help from our support team.  While you are free to send via your office Exchange server or any other mail server which is open, we will not have visibility into those servers and will not be able to assist in trouble shooting the problem if anything goes wrong. 

3. If you choose to send mail other than local host (including the Digital West Mail cluster) be sure that your application will adequately handle temporary delays and “try later” responses.

4. Do not use site visitor input as the From address.  You can add a reply-to header if you wish the simplify the mail recipient’s response.  Send emails from a valid email address that you control and know is valid.

5. Do not use input from a visitor, even in the case of a perfectly completed ecommerce application or other situation where you are certain of the validity of the email address.  Many domains have set up a SPF record as part of their DNS which limit where mail from that domain is allowed to originate.  Your webserver’s address is probably not included in their allowed IPs or sending mail.

6. Consider requiring email addresses to be input twice and match similar to the way you would require password entry.  That will help eliminate some typos such as “mydomain.con” when “mydomain.com” was needed and get your emails to the intended recipient.

7. Do not expose your email address and other sensitive data to the spiders and bots.  You need server side code to send the email  Place your email information data there where it is not available for harvesting for spammers – on the server only.  

8. It is a very bad idea to put the recipient address as a hidden field on the form.  That is an invitation for the form to be exploited by replacing your recipient address with thousands of others that a spammer may have collected turning your feedback form into a “buy viagra” spam from your domain.

9. Do not depend on JavaScript as your only input validation.  Validate on the server as well.  The scripted exploit attempts as well as some paranoid visitors will have JavaScript disabled.   While it is possible to arrange a form such that submittal only happens when JavaScript validation is successful, that will not prevent anyone who can read your code from manually submitting the form without validation.

10. Do not depend on the referrer or user agent information to filter out exploit attempts.  Anyone who is able to get to a point where those matter is probably capable of forging those items as well.  Validate the input and sanitize the data on the server.

11. Use a database backend to back up your mail.  Record the relevant items in a database and you won’t be concerned if something ends up in a spam filter or accidentally deleted.

12. Use captcha to screen out scripts which try to exploit forms for spamming.  If Google and other spiders can reach your form pages, so can the bad spiders.

13. If you must include an “email a friend” option, strictly limit the text they can provide (no URLs) and provide their name and email as part of the subject rather than using their information as the sender.  Improperly handled “email a friend” forms are a spammer’s delight.

14. Test your scripts.  Try bad input, different browsers, different mail clients, and options as well as using different email addresses if you have more than one.  (There are still plenty of free email providers if you need another one for your testing.)

15. For those hosting on Linux servers, do not use “formmail” as part of the name of the form handler script.  The old Perl script by Matt Wright had many exploits over the years and the older versions kept popping up in sites (and being exploited).  Any script named formmail (formmail.cgi, formmail.pl, forrm-mail.cgi) will return a 404 not found.  If you insist on using a variation of that script, please get the most recent one and rename it to something less likely to be discovered by the automated scripts.

16. Those sending mail from Windows servers should use CDOsys if coding with classic ASP.  While CDONTS is currently available on the shared hosting server, it was not included in Windows 2003.  It is well past time to replace that with more current code.  Another component which was provided as an alternative to CDONTS was ASPMail.  That one is also well past the point of being supported.  It also has a tendency to stop working for no good reason, allowing mail to queue up on the server.