Pushing Past Amazon SES Sandbox Limitations
I am working on a new project, Security Awareness for Busy People, and I accidentally found a trick to bypass one of the restrictions when working in the AWS SES sandbox. But first, can I just say that I love finding undocumented functionality in AWS? I feel like a techie version of Indiana Jones!
AWS SES, or Simple Email Service, is a service provided by Amazon Web Services that allows customers to send emails. This is similar to services like SendGrid. Emails can be sent either via SMTP or through their API. It's really cool, fairly cheap, and very easy to setup and get started. The best part is that you can hook your incoming or outgoing emails into the entire AWS ecosystem and process them automatically. But I digress.
When you first setup the service, SES puts you in what is known as a
- Daily sending limit (every 24 hours): 200 emails
- Max send rate: 1 email per second
- Can only send emails to verified addresses or domains
Promoting your account out of the sandbox is as simple as sending in a support case asking to be removed from the sandbox. You may also want to increase your sending limit and send rate at the same time, as they are intentionally low.
But the annoying part of being in the sandbox is that you are restricted to using verified email addresses or domains. This is tough when testing an application's ability to deliver email because, as is happened in my case, I setup multiple customers each with a different email address. I really don't want to go and verify each email address, so I did the old trick of using the + symbol in the email username field. Some email providers, like GMail, see the + character as the beginning of an email alias, and routes the email to the user named before the + symbol. Thus, test@example.com and test+foo@example.com get routed to the same inbox. Personally, I use this to filter out email from various companies, as it lets me filter emails to various folders automatically and it helps me know when a company sells my email address to another company (e.g. Nobody but Google should be using my test+google@example.com alias).
To my surprise, even though only test@example.com was verified in the SES service, it still allowed test+foo@example.com to be sent. Thus, you can use GMail-style email aliases in AWS SES without needing to verify each individual email address. If only test@example.com is verified, you can send emails to the following addresses:
test@example.comtest+foo@example.comtest+1@example.com
This is helpful when testing because you don't want to move out of the sandbox until you are sure your service works, but you also don't want to have to constantly verify a bunch of different email addresses either.
I hope this helps when testing your application's email capabilities!