Show HN: Versatile email infrastructure on AWS serverless | Hacker News Reader

Show HN: Versatile email infrastructure on AWS serverless

github.com

29 pointsharryzcy11 comments

It's a self-hosted mailbox for all emails coming to your own domains, with Web interface and CLI included.

Notes:

- all emails share the same inbox, as long as set your DNS correctly

- Web client via self-hosted Docker or Cloudflare Pages

- need additional access controls, may use Basic Auth or Forward Auth with Cloudflare deployment

Open articleView on HN

I don't understand how the idea came about that running something on AWS is "self-hosting".

I'd be interested in understanding the privacy implications of AWS. Are there TOS terms that give Amazon the right to look into your instance and analyse your data? At a minimal they certainly see DNS querys.

For true email self-hosting, consider this guide:

https://www.purplehat.org/

And run your own authoritative DNS server as well...

Eh, it's a spectrum. On one side, gmail, hotmail, etc, on the other side a box in your closet.

This is clearly in between where you are hosting the domain and services, albeit the compute is leased.

I would argue that in this architecture, you're _not_ hosting the services, Amazon is. Therefore it's not self-hosting.

The phrase "hosting the domain" is also subject to the same conclusion. Registering a domain for use by a 3rd party service provider is not the same as "hosting" the DNS. To actually host DNS requires running an authoritative DNS server. Self-hosting DNS would imply running this service yourself, not using a 3rd party DNS service provider.

I guess my company doesn't host their own website because we use Amazon, then?

I hear you, but, again, it's a spectrum and you don't need your own DC or colocation or homelab to "self host".

E-mail is hard. This is gluing seven AWS services together. I wouldn’t certainly run any serious e-mail servers with a stack like this, good luck debugging why only half the emails come through…

Email receiving is easier than email sending. Sending needs to consider IP reputations, etc so that emails don't go to the spam on the recipients side. For receiving, there are fewer moving parts. As long as the DNS is correct, an email will land in AWS, and it will be in DB

The SMTP parts of receiving e-mail is simple, sure. But then your solution puts 6 AWS services between the SMTP server and the user, with four of them (SES, S3, Lambda, DynamoDB) critical for the e-mail to be seen by the user. What if SES calls your lambda before the e-mail contents are fully saved to S3? You seem to be loading the email contents into memory, what if you get a large attachment and run out of RAM? The function that saves data to DynamoDB handles errors by printing them and returning, without any retries or alerts, so it’s really easy for emails to get lost if DynamoDB goes down for even a second. What if you get a ton of spam (and you do get a lot of spam with any public e-mail address), and you rack up bazillions of dollars in bills, since SES charges you for every email? How many more holes could I find if I spent more than 10 minutes skimming the code and thinking what could go wrong?

This might work as an experiment or for some automated service, but it’s far from something that should be used anywhere near production or personal e-mail accounts.

This is not self-hosting. It's faster, easier, and cheaper to sign up for an email provider.

I hope no-one takes this seriously with something as lazy as this:

> Create an IAM user with AdministratorAccess and export the access key as environment variables.

Followed by:

> Manually create S3 buckets, and setup SES and SQS (optional) from AWS console.

Wowzers

It's certainly not good and should be avoid. For a background on why it's here, it's still shown in Serverless's guide: https://www.serverless.com/framework/docs/providers/aws/guid...

Reply on news.ycombinator.com