This is the first part in a series of posts about how a pretty simple problem with outbound email led me down some interesting paths of automation.
How it all started
I help to maintain the infrastructure for the website of GP Systems, the company my Dad runs. This infrastructure is all hosted in Azure, and is now mostly expressed in Terraform code - but it wasn't always so, and this problem was the catalyst for getting a lot of that automation in place.
One of the pages on the GP Systems site has a form that visitors can fill out if they require more information. Submitting the form invokes a very simple
.cshtml page that uses the (now deprecated)
System.Net.Mail.SmtpClient class to create and send the form contents in an email back to my Dad so that he can respond with the relevant information. Originally, this used the SMTP service provided by Outlook.com (since that's where his email is hosted), authenticating as him, but on occasion his email account would get locked out - typically when he was on holiday abroad and Outlook deemed access from this location to be suspicious, for example - and email from his site would fail to send. To prevent this from happening, I recommended moving outbound mail services to MailGun since that was the service I used on my own site, and the free tier would be more than sufficient for his needs.
This all worked fine until recently he noticed that emails were not arriving again and, upon testing the web form, found that the test didn't seem to be sending an email either. I delved into it and found that the MailGun SMTP servers had been blacklisted against Outlook.com. Great! And since my own email account is also hosted at Outlook.com, it turned out that this issue had affected the outbound email from my own site too, and there didn't seem to be a way around this - short of moving to MailGun's paid tier.
How long had this been happening? We couldn't be sure, and that's not good. So now we had two problems.
- Find a free outbound email service that wasn't blacklisted against Outlook.com's mail servers
- Find a way of making sure we know if things stop working again in the future.
For the second requirement, I had already started looking at MailGun's webhooks to push notifications about events such as bounced or undelivered mail, and this seemed like a good solution to pursue further. It turns out most of the common providers have some kind of webhook functionality in their free tier. In the end I opted for MailJet, but there are others that would have worked just as well.
Until next time...
At this point, we now had working outbound mail services again. Hooray! But there was still more to be done, including figuring out a way of getting any webhook messages to somewhere that we could read them. And ideally, all wrapped up in automation, of course.