A Short Email Adventure – Working with Amazon SES in Sandbox Mode
on October 11, 2017
I needed a quick way to be able to send email notifications. This was for a cluster of servers that I use for R&D. I wanted those servers to be able to push notifications that they were done, or that specific progress has been achieved. Immediately, I thought of using Simple Email Service (SES) from Amazon Web Services (AWS).
I already had an AWS account, so I logged in and activated SES. I verified my personal domain (jvroig.com) so I can send email from that domain, and then I saw that since I’d be in sandbox mode, I can only send 200 emails per day. That’s pretty low. Depending on what my R&D servers are doing, they can realistically exceed 200 emails in a day, particularly if I want to hourly updates from each one (16 servers * 24 hrs = 384 notifications in a day.)
Being in sandbox mode also has another limitation: it can only send emails to verified email addresses. Other people in my research team who should be getting notifications will have to have their email addresses verified. I didn’t want to deal with that either.
I know this sending limit and sandbox scenario is just temporary, so I didn't want to bother - just wanted a solution that will work immediately, and with everything done on my end .
The best solution I could think of was to create email accounts on my domain that will correspond to the researchers in my team, and then have those email accounts forward the emails they receive to the actual personal email accounts of the researchers involved. As far as the researchers would see, the email notifications were sent straight to them, so that’s an acceptable solution.
Implementing that was easy and only took a few minutes:
- Went into my personal SiteGround account’s cPanel, created email accounts for JARVIS (that’s what I call the suite of automation tools I made to streamline control of R&D servers; this account will be the email sender) and researchers (the recipients). These aren’t email accounts the researchers will actually use – I just need accounts in my domain, and that I control, so I can verify them immediately in AWS SES. Later, I’ll setup email forwarding on these accounts, which is the magic sauce here.
- Back in AWS SES, registered and verified the researcher email accounts I created from my SiteGround account.
- Back at SiteGround, setup mail forwarding on the researcher email accounts I created, forwarding to their actual personal/work email accounts. This is what makes the solution work – since I can only send emails through SES to the email accounts I created and verified myself, I wouldn’t normally be able to send email notifications directly to the researchers’ personal email accounts. With forwarding enabled, however, they’ll receive the email notifications as if it were sent directly to them – even though it was actually sent to their counterpart email account in my domain.
- After that, I just created a python emailer for my R&D servers to run.
- TA DA! Even with SES limits still in place, researchers receive email alerts.
In a week or two, once AWS sees I’m not a spammer, this quick hack won’t be necessary and I can send email directly to the team without having people actually verify their email addresses. But for now, this solved my problem quite nicely, and it only took a few minutes.
There’s a lot here that deserves its own write-up – for example, working with SES (configuration / verifying domains and addresses), working with cPanel (how to verify domain for SES, creating email addresses, setting up forwarding), and the python email script that works for SES. I’ll get to these in future blog posts, so stay tuned!