Uses SES incoming SMTP to forward E-mails to the final recipient, based on https://github.com/arithmetric/aws-lambda-ses-forwarder. Useful for small domains, where you don't want users to manage another Inbox.
Address aliases are stored in a DynamoDB table.
Management of addresses can be done in DynamoDB directly, or you can use the web-ui: ses-email-forward-ui.
SES can only send from a validated domain. To be able to forward any "From domain", it needs to be rewritten.
John Doe <john.doe@corporation.com>
sends a message to bob@example.com
.
The message will be forwarded to bob@gmail.com
with the new sender John Doe <forwarder-daemon@example.com>
and a Reply-To: John Doe <john.doe@corporation.com>
.
- An AWS account
- A role with the relevant rights (Administrator if you are lazy)
- NodeJS 12, ideally with nvm
- Use a region in which "EMail Receiving" is available
- Manually created SNS queues for bounces and complaints. All domains need to use the same queues
You need to whitelist all domains that you want to use. Including domain aliases and the domain used for global bounces defined in the settings as sender.
git clone https://github.com/DanielMuller/ses-email-forward
cd ses-email-forward/
nvm use
npm ci
cp -a stages/production.sample.yml stages/production.yml
Edit stages/production.yml to suite your setup.
npx serverless deploy
You can use ses-email-forward-ui, or fill them manually in DynamoDB (console, CLI, ...)
{
"domain": "example.com",
"aliasfor": "another-example.com"
}
To redirect to a locally defined alias, omit the domain. Every change in the definition table will trigger a Lambda function that popoulates the alias table. Multiple destinations are entered as an array.
{
"active": true,
"alias": "info",
"destinations": [
"bob@example.com",
"john"
],
"domain": "mycorp.com",
"type": "group"
}
{
"active": true,
"alias": "john",
"destinations": [
"john@example.com"
],
"domain": "mycorp.com",
"type": "person"
}
Update your domain's MX to point to 10 inbound-smtp.<AWS Region>.amazonaws.com.
- Transient Bounces are stored for 1 day
- Permanent Bounces are stored for 30 days
- Complaints are stored for 2 years
Every change in the bounce log table (insertion, deletion) triggers an update on the bounce count. Destinations with a least one bounce count aren't used anymore. Messages to this destinations are silently dropped.
All domains are passed through the spam rules:
- Messages tagged as SPAM are silently dropped
- Messages not passing DMARC are bounced back to the sender
- Messages not intended for a valid recipient are bounced back to the sender.
- Triggers
BuildForwards
for every change in the definition table.
- Builds the aliases list from the definition table. Omitting previously bounced destinations and avoiding duplicate destinations.
- Populates the bounce and complaint table.
- Updates bounce counters in the alias table.
- Find a way to feedback false negative SPAM to SNS
- Use a spamassassin API (self made or https://spamcheck.postmarkapp.com/doc/)