5 ms·

Show HN: Versatile email infrastructure on AWS serverless

29 points by harryzcy 3y ago

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

deleted 3y ago
[deleted]
donalhunt 3y ago
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.
- deleted 3y ago
  [deleted]
- Thev00d00 3y ago
  Followed by: > Manually create S3 buckets, and setup SES and SQS (optional) from AWS console. Wowzers
- harryzcy 3y ago
  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/guide/credentials https://www.serverless.com/framework/docs/providers/aws/guid...
Kwpolska 3y ago
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…
- harryzcy 3y ago
  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
  - Kwpolska 3y ago
    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.
johnea 3y ago
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/ https://www.purplehat.org/ And run your own authoritative DNS server as well...
- eximius 3y ago
  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.
  - johnea 3y ago
    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.
    - eximius 3y ago
      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".
sneak 3y ago
This is not self-hosting. It's faster, easier, and cheaper to sign up for an email provider.

29 points by harryzcy 3y ago

deleted 3y ago

[deleted]

donalhunt 3y ago

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.

deleted 3y ago
[deleted]
Thev00d00 3y ago
Followed by: > Manually create S3 buckets, and setup SES and SQS (optional) from AWS console. Wowzers
harryzcy 3y ago
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/guide/credentials https://www.serverless.com/framework/docs/providers/aws/guid...

Kwpolska 3y ago

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…

harryzcy 3y ago
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
- Kwpolska 3y ago
  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.

johnea 3y ago

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/ https://www.purplehat.org/ And run your own authoritative DNS server as well...

eximius 3y ago
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.
- johnea 3y ago
  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.
  - eximius 3y ago
    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".

sneak 3y ago

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