Moving an EC2 server Exim4 email to AWS Email systems
Tags: aws, ses, email
Published: 2022-11-01 03:44:17

## Background

I have an EC2 server running in production that connects to 
Exim4 to send out emails, transactional and otherwise.

AWS's recommendation for simplest email seems to essentially be "[Use AWS SES instead of pinpoint](https://docs.aws.amazon.com/pinpoint/latest/developerguide/send-messages-email.html#send-messages-email-choose-method)".

### Pieces

Generally there are some email templates that have to be programmatically fed into the email system.

An internal API has to be created to accept requests for sending out new transactional emails.  Implementation of this will be with an AWS lambda called first by local CLI, and later via an invocation event.

Initially, manual whitelisting of addresses in SES will be done via the console while the SES is still in sandbox mode.

Security checks need to be done to ensure email injection can not be done (there may be something that AWS SES will do to make email injection attackers less effective than Exim4, but that is always worth checking)

Create unsubscribe link system, requiring a url on the main domain that accepts url-based unsubscribes in one action, and  adds the user to a blacklist


Eventually, getting the AWS SES out of sandbox mode (here are some example rationales, though your milage may vary, these are just drafts).

### Getting out of SES sandbox mode

- How do you plan to build or acquire your mailing list?
- - Users must opt in to receiving transactional emails after they create an account and provide an email address.  We do not cold-call/cold email users, they sign up and willingly provide their information.
- How do you plan to handle bounces and complaints?
- - Complaints: Complaints can just be forwarded through to the main contact email, and dealt with accordingly on a case-by-case basis.  
- - Bounces: Bounces are more complicated, and need an automated system to take out email addresses that bounce in real time.  To handle bounces, an SNS notification topic will be created, which triggers an AWS lambda to add the email to a do-not-send list and refrain from sending further emails to the bouncing address.
- How can recipients opt out of receiving email from you?
- - We provide a simple on-step unsubscribe link in clear, blue text in the footer of every email.  We also follow the structure that allows standard free email providers to use the one-click [Unsubscribe] button method.
- How did you choose the sending rate or sending quota that you specified in this request?
- - Currently there are XXX number of users in the system.  Only X% of them opt in to receiving emails.  We send a transactional email at the end of the day to those people who have opted in.  As a result, we expect to send XXX * 0.0X emails a day, * 31 for monthly numbers.  We also send out a monthly update email to those users who have opted in, thus adding another XXX * 0.0X emails per month.  Give a buffer of 120%, results in YYY emails per month as an upper bound.

...More on this process later...


Useful references:
- https://medium.com/@serbanmihai/how-to-handle-aws-ses-bounces-and-complaints-53d6e7455443
- https://docs.aws.amazon.com/ses/latest/dg/send-email-exim.html
- https://medium.com/free-code-camp/sending-emails-with-amazon-ses-7617e83327b6
- https://docs.aws.amazon.com/pinpoint/latest/developerguide/send-messages-email.html#send-messages-email-choose-method