There are many times when doing DotNetNuke development that your module needs to send emails. You often have emails that need to go out to several different addresses i.e. an email to the user, one to the system administrator and maybe one to a fulfillment partner. You frequently have different emails that get sent based on specific configuration settings or that change based on the role of the user.
When developing for DotNetNuke I often create a custom installation devoted to the module under development. In the past I have not always had an easy method for configuring the SMTP server so that I could trap all the emails being sent out from the system. I would try to set all the emails to one of my many email addresses and set my SMTP settings to use one of my production email servers. The problem with my previous approach is that I often missed emails. Unless all the emails are directed to my personal email accounts, I had no way to trap the emails on my dev box to make sure they were correct. My previous method also did not make it easy to follow the entire email workflow.
All of these problems were solved recently when I discovered a simple little application called Papercut after reading a blog from Scott Watermasysk. Papercut provides a nice GUI that allows me to actually view the raw email content, the text content and an HTML view where appropriate. Neptune is not as nice in this The added bonus with Papercut, is that I can also forward emails to whatever email address I wish.
Now whenever I configure a new DotNetNuke test instance, I just set the SMTP server to localhost and startup Papercut. Every email is trapped and ready for me to inspect. When I think everything is working correctly, I can forward the appropriate emails off to my Marketing director for final approval. At no time did I clutter my inbox or worry about customers inadvertently receiving test emails.
While doing some research for this post, I also found another solution called Neptune which also traps emails during development. It works a bit differently and is designed for integration into the development environment with interfaces exposed for automated unit testing. You can trigger an email to be sent and then programmatically inspect the actual email that was sent.
Being able to easily inspect and test emails will greatly improve your email handling code. Tools which simplify this task make it more likely that you will run through more scenarios without worrying about filling your inbox or being worried about sending inadvertent emails to customers. This is a good thing. I will definitely be using both of these tools on all my future DotNetNuke development work.