An email solution for queuing, reviewing, and intercepting emails?

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开发者_JAVA技巧 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.

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.

If you want to prevent sending emails when running the debug version, you can write:

void SendEmail()
{
#if DEBUG
    // do nothing
#else
    // do normal send
#endif
}

If you want something that will work in the face of possible SMTP outages, you'll need to queue them to a file and have a separate process read that file and send the emails, retrying as required.

If you want to review some emails before sending them, have the batch file start the program with a command line switch. When the SendEmail method stores the emails in the file, have it write that value. The process that sends/retries will not send any message that has that flag attached. Rather, it puts those into another queue for review.