Many software solutions allow for sending reports, warnings, alarms and many other communications via email. This is a great feature to keep track of what’s happening to your installations without having to log into all of them, but having an email server at our disposal these days is not so common anymore. that’s what happened to me last week, and since I was tired to use my personal Gmail account to send myself emails, I decided it was time to find a different solution and to test AWS SES.
Introduction
In short, AWS Simple Email Service (SES) is an email platform that AWS users can consume to send and receive email. As the text in their starting page says: “Amazon SES eliminates the complexity and expense of building an in-house email solution. There is no need to set up your own servers, maintain your network infrastructure, or warm up your sending IP addresses.”. Also, as in any other AWS service, SES can be accessed via API to build a complex application around it, but in my case, I just needed an SMTP Relay to send emails.
You can read more about the different advanced options that are available here, but the short version of the story is that SES is a powerful email service, and at a cheap price too. As in my other AWS services, it’s a Pay Per Use pricing, that is (in September 2017 when I wrote this article) $0.10 per 1,000 emails sent, plus $0.12 per GB of attachments sent. for a few log emails per day, this is for me a completely acceptable price.
Setting up the service
The first step is to verify email addresses and domains. In my case, virtualtothecore.com is already registered in AWS since I use their Route53 DNS service. If the domain is managed by an external DNS server, you can follow the domain verification process, which is essentially based on the DKIM (DomainKeys Identified Mail) standard, which provides proof that the email you send originates from your domain and is authentic. Once DKIM verification is completed, your domain should look like this into the SES console:
Once the domain is verified, we can select it and choose to immediately Send a Test Email:
The email is correctly received in my Gmail inbox, so the Identity Management part is completed.
SMTP settings
It’s the time to use the SMTP service in SES. If we go into Email Sending -> SMTP Settings, we can see that some parameters are already pre-configured for us:
As we can read, even if the SMTP service is already configured, we need one or more SMTP credentials, that are a username and a password to connect to SES SMTP servers and send the needed emails. Since I’m going in the future to use this service for multiple software I will install, it’s a good security practice in my opinion to have a different SMTP credential for each software I’ll connect to SES. I will just create my first credential now. the link redirects to the AWS IAM service, where I can create a dedicated credential for this new access:
The output is a new set of credentials (username and password) that I can then use into my software. The credentials are not listed in the SES console, so you will have to go into the IAM console to control and manage these credentials.
Use SES inside a software package
I’m using in this example Veeam Backup & Replication, but obviously this example applies to any software with email sending capabilities. In the email settings, I go and configure the SMTP parameters, like this:
The important part is to enable SSL connections since AWS SES (as many modern SMTP systems) doesn’t accept unencrypted connections. For the TCP port, we have three possibilities: 25. 465 or 587. In my case, I discovered during the tests that both 25 and 465 were blocked by my provider, but I was able to send the message using 587. The test message arrived correctly in my inbox:
