> Currently, attachments are not supported.
That's kind of a biggie. What happens when someone sends an attachment? Does it bounce? Are they warned? Do I get a notification? Is it silently dropped?
From reading the code it seems like it just doesn't include the attachment and then deletes it from S3?
Yeah, this is an issue I'm planning to work on. The reason I chose to release it before supporting attachments is that for my use case for receiving marketing emails (this project is primarily for my personal use, rather than as public software), there are almost never attachments.
I have all emails for my domain route to me, so when I use a service I just do [service-name]@my-domain.com. If a bad actor gets a hold of it I set up an inbox filter or black hole the email address at the service level. The big advantage of this project seems to be that you can reply, but I've found that a huge proportion of these email aliases are inbound only for me.
I'm using GSuite for my personal email but I've been considering Fastmail. Just checked and it looks like they also support sending from those catchall aliases: https://www.fastmail.com/help/receive/alias-catchall.html
The one killer feature that is missing in Fastmail right now is the ability to reply to email as the same alias it was received as. I.e. if Airbnb support emails me at airbnb@mydomain.com, it'll default replay as me@mydomain.com unless I go manually setup the airbnb alias.
[1] https://btmiller.com/2019/12/12/regain-control-over-your-inb...
> Creating an [wildcard] alias also creates a matching sending identity. This means you can also send mail using this wildcard alias. When sending from a wildcard alias, you'll be able to manually type the From address (to sales@mydomain.com or accounts@mydomain.com, etc) when writing a message.
So, yes, it appears you still have to manually set the from address, but at least you don't have to actually go do anything outside of the composition interface anymore!
[1] https://www.fastmail.com/help/receive/alias-catchall.html
I use Postfix and ViMbAdmin to manage my whitelist via a simple web UI, and I don't find it to be onerous. I don't sign up for new services every day, and it takes about ten seconds to add or delete a service-specific alias.
A catch-all email address is actually less complex to build and test, but there are a couple of reasons I chose to use this approach:
1. It seems that in the workflow you described, there is some work to be done in setting up an inbox filter/black-holing the email address too. In a way, my workflow simply shifts this work to the start?
2. I don't think it's laborious because I don't really need new email addresses that often. It's also really easy to generate a new email address imo - no logins or portals required, just email generate@mydomain.com and you get a reply with an email address within seconds.
3. You're welcome to fork it and tweak it for personal use too if you want! :) I'd love that.
1. I don't really think your workflow shifts any work over the catch-all workflow, it simply adds another step. In my workflow I essentially already have that alias you create in your first step. Then, if that alias gets abused, both systems require shutting off that alias.
2. Yeah, that's definitely just a different usage pattern. I'm one of those folks that enjoys testing out different onboarding workflows, etc, so I'm constantly signing up for services, etc.
3. I'm quite happy with the alias approach, but best of luck with the project :)
[service-name]@[user-name].my-domain.com
to provide everyone the same capability.
Email aliases ([user-name]+[service-name]@my-domain.com) isn't the best solution when spammers can remove the alias part (+[service-name]) and you can't know who leaked it.
At first I was confused and trying to figure out what AWS services Heimdall uses to work, and this was the section that explained it:
Infrastructure
I’m using AWS’s Simple Email Service (SES) to send and receive emails, S3 for storage, and Lambda functions for serverless computing. Here’s how it works:
All received emails trigger SES to store the email as a file in a S3 bucket, which triggers a Lambda function. Depending on the email, one of several things could happen:
1. The email gets forwarded to your personal email address
2. The email gets forwarded to the original sender (when you reply)
3. A command is invoked by you (e.g. to generate a new alias)
4. Nothing happens (when someone emails an invalid/disabled alias)
I chose to use AWS for practical reasons: I’m totally new to cloud computing, and AWS being the most popular cloud computing service means it is easier to find guides and resources online.> I’m using AWS’s Simple Email Service (SES) to send and receive emails, S3 for storage, and Lambda functions for serverless computing. Here’s how it works:
> All received emails trigger SES to store the email as a file in a S3 bucket, which triggers a Lambda function. Depending on the email, one of several things could happen:
> 1. The email gets forwarded to your personal email address > 2. The email gets forwarded to the original sender (when you reply) > 3. A command is invoked by you (e.g. to generate a new alias) > 4. Nothing happens (when someone emails an invalid/disabled alias)
> I chose to use AWS for practical reasons: I’m totally new to cloud computing, and AWS being the most popular cloud computing service means it is easier to find guides and resources online.
http://www.kylheku.com/cgit/tamarind/tree/README
It integrates into Apache as a CGI program serving up a web UI for managing your aliases.
It works by managing the content of an alias file read by your mail server.
Authentication of the webUI is via IMAP or SASL.
Each throw-away alias is associated with a memo in which you can have text and URL's (that get rendered into links), and a creation time. You can regex search through the aliases, edit the memo fields, rearrange their order and delete them.
If you want to Show HN something, make your own post; this is just rude.
1. AMZN has access to your mail (inc. your contacts) so you could just use any other service you do not trust. 2. Why would I process mail just so save it on another machine and not do both on the same server?
Probably it has to do with "serverless" (you have to use at least 2 "servers" now, don't you?) but maybe I am just missing the point.
Email isn’t a trusted method of communication anyway.
My primary motivation in doing this was to learn to use AWS and Serverless framework and also because I really enjoy working on pet projects :)
Could you explain why email isn't trusted? It's encrypted (vs SMS) so I'd imagine it's a far more secure way of communicating sensitive information (e.g. bank statements or one time passwords).
> Pre-requisites: You need to own a domain and have an AWS account. For reasonable use cases, you should not exceed AWS's free tier (which is very generous).
Erm ... wut?
Sure it would be nice to have other options in addition to AWS, but I don't think those two statements are contradictory.
Also, I don't know if it is, but the data stored on AWS could be encrypted by the app, in which case you're really not trusting AWS.
From the first quote you might think that it was the deployer's choice where to put it, including on one's own hardware.
I don't know, however, what you'd do instead of SES.
The claim was not "you are more in control than with a closed third-party product". The claim was "No [...] having to trust a third-party company with your data.". When you have to use AWS, then you evidently have to trust a third-party company with your data, unless you happen to be AWS. And not only do you have to trust a third party, you even have to trust one particular third party with no alternative if they misbehave somehow. That's pretty close to using a closed third-party product, if you ask me. I mean, really, you are using a closed third-party product--it just happens to be the infrastructure that you build on.
> Sure it would be nice to have other options in addition to AWS, but I don't think those two statements are contradictory.
So, AWS is either not a third party or could not access your data, no matter how much they wanted to? Or what other alternative do you see to make those statements not contradictory?
> Also, I don't know if it is, but the data stored on AWS could be encrypted by the app, in which case you're really not trusting AWS.
Wut? Am I just completely misunderstanding what this does? This uses SES, a service by AWS that handles your emails, right? As in: That speaks SMTP for you, and thus sees the plain text of the emails, right? And then, somewhere there is code that handles those emails that runs on machines that AWS has physical access to, right? As in: Code that AWS can trace and modify however they like, right? As in: Code where AWS trivially could extract any possible encryption keys from, right?
Unless I am completely misunderstanding this ... what would possibly stop AWS from reading all your emails if they wanted to?
Most of the time I do see an influx of spam it's because of one of the aliases clearly having made its way on a list, so I'd say the system is working as intended.
You're absolutely right that if AWS is a bad actor it has access to all the information, but I'm working on the assumption that it's more profitable to AWS to be a good actor than bad.
But that doesn't change that you are trusting a third party?! I mean, if that were to count as "you don't have to trust a third party", then anything does. Use gmail, so you don't have to trust a third party (except for the implicitly trusted Google)! Use Facebook, so you don't have to trust a third party (except for the implicitly trusted Facebook)!
There is nothing necessarily wrong with trusting any one of those. But then you don't get to claim "no trust in third parties required!"
> You're absolutely right that if AWS is a bad actor it has access to all the information, but I'm working on the assumption that it's more profitable to AWS to be a good actor than bad.
Well, for one, see above. But also: is it? Is it really more profitable to keep your data safe than to give the NSA access and in return get some of the good government contracts, say? Plus, trust isn't just about them not screwing you over intentionally, it's also about incompetence.
Then sounds like people running WordPress or support help desk scripts with contact forms forwarding to their Gmail, etc is a problem too... Those services think your server is the source of spam.
But maybe it's worth paying for a third party email server for your staff and also a service with APIs for programmable sending/receiving since you don't want emails to customers like password resets, receipts, etc going to spam. I noticed even when I mark someones emails as not spam they keep going to spam, I don't check my spam daily but sometimes they have to send me a IM to let me know they emailed them...
I feel like might be forced paying though instead of self handling email. Kinda feels like giving the mafia some extortion money for protection though in away. Plus email is a bit broken in the first place, open and all is great but opens itself up to abuse to spammers and scammers.
WordPress contact forms are routinely abused - I regularly see forms where enter a victim as "my address" and then it helpfully copies the message to the spam recipient. There's always a web designer who wants it this way for UX reasons, even when I shown how it's abused.
Sounds like the only solution to contact form spam might be rate limiting and/or captchas but even bots can bypass captchas too unless you use one like Google reCaptcha maybe but sucks your system has to rely on third party services then.
I'm far from shipping from what I'm working on though, but before going live want to get email setup for the main company website and product website for me and future staff, then want to be able to send email's for notifications, password resets, etc and then also have scripts receive and parse emails for replies to put into a database for the support portal part of the product domain but getting ahead of myself. Not sure if the product site would have users to people or just be all scripted sending/receiving while the main site is mostly emails hosted for humans.
I think one strategy would just run a mail server and have a script download the emails to the database and delete them, since doubt many solutions support a more of a webhoook type setup.