Do you not have a server-side component running now?
I would avoid having the SQL Server send the Email itself.
If you just need code somewhere to wake up occasionally and check for specific conditions and take action, you could write a simple console app and use the Windows task scheduler on the server to run it every so often. If the conditions are right, send your Email messages, otherwise, just exit clean. Check again the next time the task scheduler fires up your console app.
Or you could write a Windows service to essentially do the same thing, except that you would use the task API or Windows timers to occasionally wake up and check for appropriate conditions. The service will be a bit trickier than scheduling a simple console app. There are service installation issues. You can't have your worker code blocking the primary thread where you're listening for important things like service control messages. Your worker code needs to be responsive to these events, as well. So if you get a shutdown message, you need to respond to it in a reasonable amount of time (a second or two, not a minute or two). You probably want to consider some kind of a queue-based design that can send half the messages, get shut down, wake back up and send the other half without losing it's place, and so on.
If you're not savvy about issues like service installation and the thread synchronization and service control events, I'd just do the simple console app and use the Windows Task Scheduler. "Low tech" can actually be kind of a beautiful thing.
But to reiterate, I definitely would not do this directly from SQL Server. Just because you can (.NET extended stored procedures) doesn't mean you should. :-)