We have an ASP Web Forms application hosted in IIS. In the very same hosting environment there is 1 app pool that servers two entities of this application, 1 for the live environment and 1 for staging / testing. Recently, we have added a mail service to the application, that connects to an Exchange Server with a dedicated email account's credentials. The credentials are configured in the web.config file as:
<system.net>
<mailSettings>
<smtp from="foo@bar.com">
<network host="foo.bar.local" port="25" userName="FOO" password="My_Foo_Password" enableSsl="false" defaultCredentials="false" />
</smtp>
</mailSettings>
</system.net>
It worked properly on both the staging and the live environment too. After the feature was tested, we wanted to disable the emailing from the staging environment.
As an easy workaround, we thought that would be enough to change the staging application's web.config file and set the password for something else, that is not the real password. The problem is, after setting the password to an invalid one, the staging enviroment is still able to send emails out.
Our first thought was that perhaps the IIS caches some settings, so we called iisreset /restart via command prompt. But even after the full IIS restarted all the services, the staging application was still able to send out emails.
We have ended up setting another configuration variable to be able to disable email sending from business logic, but I'm still curious how could this happen to the staging environment as it was able to connect to the Exchange server with an invalid password.
Perhaps, the Exchange server caches the connections? Or can there be some token they use between the server and the client that will work until it expires? Only after that expiration will the staging app try to get a new token and at that time it will fail as the used password is not correct anymore? One more thing I can imagine is that it can be due to the shared app pool both application entities use. As the live environment uses the correct password, can it cause this whole behaviour?
Any ideas or thoughts would be appreciated.
For starters, I would break out those into two separate app pools. You can technically induce a bug that takes down the entire app pool so you wouldn't want to be doing some testing and crash the app pool and subsequently take your prod site offline.
Also doing this might solve your original problem. The shared app pool shares memory space of the process and the way you're setting that particular mailsetting might be in a global memory space of the shared memory. If that's the case it could be using a first or last time that setting is changed 'wins' scenario and if so you're lucky you didn't break production sending email.