Question

We have a few issues with email that we’re looking to solve.

• If the SMTP server is down, we’d like our batch jobs to queue the emails they create somewhere so we don’t have to rerun the jobs. What would be a good queuing system and how would you feed the emails from the queue to the SMTP server?
• By default, when debugging, we don’t want emails to be sent. We’ve had a few cases when a developer unknowingly sent emails out to users while stepping through code. How can we prevent this from ever happening again?
• Occasionally, a developer may need to run a batch job manually by attaching a debugger and stepping through code which points at production data. In this case, any email that gets sent by the batch job we’d like to be able to review before it actually gets sent. Is there an easy method of identifying these emails among all the emails being sent out and then pause the sending of the email long enough to review it?

All our code that sends email goes through a SendEmail() function. This could be refactored to have the emails queue up somewhere. We’d be willing to look at different SMTP servers, building a custom solution, or something else.

What advise can you give? Is there one solution that can handle these issues or a set of solutions? Thanks.

Answer 1

We solved the unavailablity of the SMTP Server issue by using a try/catch – if the standard SMTP server isn’t available, we use the SMTP services provided by IIS by writing to the SMTP Pickup Directory as shown here:

http://systemnetmail.com/faq/4.7.aspx

It does what you’re looking for – writes the emails to a queue that will send when possible.

Writing email to the IIS Server’s SMTP
service pickup directory is another
new feature of System.Net.Mail. The
SMTP pickup directory is a special
directory used by Microsoft’s SMTP
service to send email. Any email files
found in that directory are processed
and delivered over SMTP. If the
delivery process fails, the files are
stored in a queue directory for
delivery at another time. If a fatal
error occurs (such as a DNS resolution
error), the files are moved to the
Badmail directory.

This means, of course, ensuring that SMTP services are installed on the web server in question.

This was much simpler than the route we intended to go down, which would have meant writing serialized emails somewhere (file system, database, etc) and then setting up a service to try to send them on a scheduled basis. We haven’t had any issues at all since we implemented this. That’s not a guarantee, but I’m just saying, it worked very nicely for us.