> This stack was created out of frustration due to the fact that to this day there's no easy way to have a full email server without the overhead of installing and configuring all servers needed to handle incoming and outgoing messages.<p>Interesting approach, though I solved this frustration by the use of a Docker and kept "my data is mine" + "no vendor lock-in" + "I control all the gears" approach. (Though, it's not perfect since VPS is ran by "someone" else.. but that place where you run this stack can be easily changed at your convenience).
Simple docker-compose.yml with 3 images and voila.<p>This AWS S3 SES setup looks far more complex than what I did using only 3 docker images: the postfix (for smtp), dovecot (for imap), opendkim (for email sigining & verification).
It's really easy to fire-up a VPS with a single click nowadays.<p>If someone is interested in the images I am using:<p>- <a href="https://git.nixaid.com/arno/postfix" rel="nofollow">https://git.nixaid.com/arno/postfix</a><p>- <a href="https://git.nixaid.com/arno/dovecot" rel="nofollow">https://git.nixaid.com/arno/dovecot</a><p>- <a href="https://git.nixaid.com/arno/opendkim" rel="nofollow">https://git.nixaid.com/arno/opendkim</a><p>Then you just feed the images with the right configs (main.cf, master.cf, .., dovecot.conf, opendkim.conf).<p>It's also possible to template the configs and make the variable-based configs. Make things scale friendly.
I am also using Terraform to automate the server deployment/DNS record updates so it is easy to get from 0 to 100.<p>The only drawback is that you are the one to maintain the OS/SW upgrades, security, etc.. but that's something I really want to do by myself instead of relying on someone else :-)
Just a friendly reminder, since I've worked with SES in the past: Don't forget about bounces when using SES [0].<p>From [0]:<p>> If your bounce rate is 5% or greater, we'll place your account under review.<p>To sum it up, try to keep track of bounced e-mails by using the SES notifications [1].<p>[0] <a href="https://docs.aws.amazon.com/ses/latest/DeveloperGuide/e-faq.html#e-faq-bn" rel="nofollow">https://docs.aws.amazon.com/ses/latest/DeveloperGuide/e-faq....</a><p>[1] <a href="https://docs.aws.amazon.com/ses/latest/DeveloperGuide/monitor-sending-using-notifications.html" rel="nofollow">https://docs.aws.amazon.com/ses/latest/DeveloperGuide/monito...</a>
I don't know anything about serverless --- to this day I fail to understand what this word is even supposed to mean. And the deployment diagram[1] sure looks complicated to me. I think I prefer old-school servers.<p>[1]: <<a href="https://raw.githubusercontent.com/0x4447/0x4447-product-s3-email/assets/diagram.png>" rel="nofollow">https://raw.githubusercontent.com/0x4447/0x4447-product-s3-e...</a>
Thanks for putting this together and documenting it so well. I’ve had to build this solution twice now, and far less elegantly.<p>The S3 PUT charges caught me off guard the first time (receiving lots of marketing/spam email will cost $1/1000 emails). I ended up putting small emails up to 400 kB in dynamoDB and only using S3 for large emails and attachments, which could be a means of cost reduction in this solution as well.
I’ve been working on a small side project that involves processing incoming email. In particular, it’s an app that needs to do something for each email it receives from (hopefully paying!) users.<p>I am not interested in storing user mail, so SES is just too costly, at least according to a quick worst-case calculation.<p>That leaves me with two options:<p>1. Self-hosted Postfix<p>2. Mail service like Mailgun<p>With (1), there is no need to worry about overages, but scaling the mail server might be challenging.<p>The advantage of (2) over SES is that you are only charged a flat fee for each email, regardless of size. Emails are then automatically deleted after some period of time. Scaling up and down is easy.<p>For now, I am using Mailgun, but I am writing the mail processing daemon in a way that will make it easy to transition to Postfix, if needed.<p>Also, I decided to write the mail processing backend in Rust, so I’ve been learning the language as I go!
Seems like a crazy amount of architecture. Does AWS keep all this stuff organized in some way, or will my personal experiments in Lamba accidentally break this because it's all merged together?<p>Say I've installed this.<p>I now want to write my own lamba service to handle contact form POSTs or something. Then I decide to delete it, but I accidentally delete one of these crazy email things. What happens?
>his day there's no easy way to have a full email server without the overhead of installing and configuring all servers needed to handle incoming and outgoing messages.<p><a href="https://mailinabox.email/" rel="nofollow">https://mailinabox.email/</a>
Now someone just needs to create a serverless (aka client side or browser only) Gmail like interface you can host on S3.<p>And the shackles will be broken...
Please don't use '+' for special purposes in email addresses without making it changeable (I recommend '_' instead).<p>Yes, it is "nominally" accepted--in reality there are too many website that "validate" email addresses and barf on '+'.
If you only need to read the emails from S3, take a look at this project <a href="https://github.com/mewa/s3abird" rel="nofollow">https://github.com/mewa/s3abird</a>
You can get receive at any address on a domain forwarded to whatever email you want if you're registered with Monicker.<p>I imagine most other registrars offer the same thing.