A thread is essentially a simple program. A thread can only do one thing at a time in the same way you follow a basic flowchart. Occasionally though, you come across a need to kick off another process flow and run 2 processes side-by-side that are each doing their own thing at the same time.
Thus your need to have the emailing process either somewhat or totally disconnected from your web application's ability to update/return your page. You want the process of emailing to run in the background, while at the same time keeping updated as to the status of that process via the main web application process.
Does that make sense?
Anywho, a Service is another method of accomplishing that same task of passing off a process to another thread because a Service is already a separate application running on its own thread. A Service is always waiting to receive the instruction to start working on the task it was designed for.
It sounds like Gorkem has a solution for internally starting your email processing on a new thread. The service would work as well and both have some benefits and some drawbacks. The service would be more flexible in allowing you to call it from other applications in the future, but it would require that you create a new service application with an installer. The threading keeps all of the code in the same application, but it could only be started/used by your web application.
Either way you go, you will be starting a thread that is sort of invisible as it runs silently in the background... so you will want to log errors to the event viewer or a file of some sort. If you go to the Event Viewer (recommended) make sure that if you create a new event log that you set it up to Overwrite as needed.
Senior Software Developer