We use the TFS Alerts system to signal to our teams what state project build are at. So when a developer changes a build quality to ‘ready for test’ an email is sent to everyone in the team and we make sure the build retention policy is set to keep. Now this is not the standard behaviour of the TFS build alerts system, so we do all this by calling a SOAP based web service which in turn uses the TFS API.
This had all been working well until we did some tidying up and patching on our Exchange server. The new behaviour was:
- Email sent directly via SMTP by the TFS Alert system worked
- Email sent via our web service called by the TFS Alert system disappeared, but no errors were shown
As far as we could see emails were leaving our web service (which was running as the same domain service account as TFS, but its own AppPool) and dying inside our email system, we presumed due to some spam filter rule?
After a bit of digging we spotted the real problem.
If you look at the advanced settings of the TFS Alerts email configuration it points out that if you don’t supply credentials for the SMTP server it passes those for the TFS Service process
Historically our internal SMTP server had allowed anonymous posting so this was not an issue, but in our tidy it now required authentication, so this setting became important.
We thought this should not be an issue as the TFS service account was correctly registered in Exchange, and it was working for the TFS generated alert emails, but on checking the code of the web service noticed a vital missing line, we were not setting the credentials on the message, we were leaving it as anonymous, so the email was being blocked
using (var msg = new MailMessage())
msg.From = new MailAddress(this.fromAddress);
msg.Subject = subject;
msg.IsBodyHtml = true;
msg.Body = body;
using (var client = new SmtpClient(this.smptServer))
client.Credentials = CredentialCache.DefaultNetworkCredentials;
Once this line was added and the web service redeployed it worked as expect again