I've seen some blog postings out there recently on what to do if your contact form fails for some reason. Some have suggested including your email address using JavaScript, which I do not recommend. Some people even suggest substituting "@" with "at"; if I was writing a screenscraper, this is the first thing I'd check for, after "dotcom"! If you're going to try and include your email address, then why bother with a contact form in the first place?
I've been using my own standard contact form for some time now. It displays either a success or error message upon submission. If there is an error, then it generates an email back to me. In fact, I like to have an email generated whenever there is an application error in a client's website, and I include this as part of routine error handling in my projects. This works for small projects where it is unlikely to over-burden the mail server. The strategy pattern helps me to factor out this kind of repetitive functionality; see an earlier post about this. At the end of this post, you can find a link to download a simple contact form.
A lot of people have problems testing email with ASP.NET. The simple answer is to use a drop folder on your local machine when developing. Just create a folder called "maildrop" on your c:/ drive and use the following in your Web.config file:
<mailSettings>
<smtp deliveryMethod='SpecifiedPickupDirectory'>
<specifiedPickupDirectory pickupDirectoryLocation="c:\maildrop" />
</smtp>
</mailSettings>
When you are ready to deploy your application, simply comment out the above entry in the config file and use the usual syntax below. Keep the drop directory section commented out in your config file as you might need it later for testing or further development:
<mailSettings>
<smtp from="info@customersite.com">
<network host="smtp.somehost.net"/>
</smtp>
</mailSettings>
For the CSS purists out there, this is created using tables because we are more interested in the functionality here. If you want a CSS contact form layout, just holler in the comments :-)
Depending on the importance of the project you are working on, you may want to log the errors to a database. This is simple to do so I'm not going to delve into it here. Note, that there is nothing to prevent you from grabbing some fine-grain error details and storing them in your errors table also. Anything that helps you identify problems at a later date is a good candidate for a table field.
That just leaves network errors. I haven't had a chance to play with this yet, but it would be nice to know in advance if the mail server was down and I'm wondering if we could somehow tap into the SMTP return status codes before sending the mail? If anyone has any suggestions along these lines, please share them here?
ContactForm.zip (22.61 kb)
