And if you don’t want to host this yourself there’s https://IdBloc.co
Show HN: Heimdall – Self-managed email alias/forwarding service
21–30 of 54 posts
Re: Show HN: Heimdall – Self-managed email alias/forwarding service
#22Self-managed email means using SES? The dream of the 90s exclaims “ouch”. It’s a realistic choice and I am not judging it, but still, ouch.
Re: Show HN: Heimdall – Self-managed email alias/forwarding service
#23Earlier quoted context omitted.
You're going to get an astronomical amount of junk mail with a catchall email address. Google is great at filtering spam, but not perfect. If you're running your own mail server, you're going to have a hard time dealing with it, even if you use SpamAssassin and other tools. It's also going to get worse over time, because every address that accepts delivery is going to get added to a database for future spamming. I us…
I disagree with the "astronomical amount of junk mail" statement. I've been using FastMail with a catchall email address for years, and get very little spam; most of which is correctly classified as such (I did have to 'train' FastMail for a while with custom spam/no spam folders though).
Yeah, I've also been using this approach for years now and see significantly less spam on this personal, catch-all account than I do on my work email (both are Gsuite). I will say I was honestly surprised at just how little email I see coming into random email addresses via the catch-all; over years I'd say (anecdotally) that number basically rounds down to 0 versus my "legitimate" email.
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.
Re: Show HN: Heimdall – Self-managed email alias/forwarding service
#24This is a really cool project, so I don't mean to be overly negative, but personally this workflow feels quite a bit more laborious than just having a catch-all email address. Before signing up for a service, I need to email myself to get an address to use for the service? 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 se…
Totally agreed, I do not want to manage my own workflow in a manner like this. I actually just put a doc together[1] last month for anyone looking to do the same through providers that support this workflow. 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…
I remember thinking the same thing last time I looked into Fastmail, but earlier when I was checking before posting, it appears that's gotten much, much better. From the Fastmail docs[1]:
> 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
Re: Show HN: Heimdall – Self-managed email alias/forwarding service
#25I’m confused. Why do you want this? You don’t trust a provider to forward your email? Email isn’t a trusted method of communication anyway.
Providers usually don't give you (unlimited number of) aliases.
Re: Show HN: Heimdall – Self-managed email alias/forwarding service
#26Earlier quoted context omitted.
Totally agreed, I do not want to manage my own workflow in a manner like this. I actually just put a doc together[1] last month for anyone looking to do the same through providers that support this workflow. 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…
I remember thinking the same thing last time I looked into Fastmail, but earlier when I was checking before posting, it appears that's gotten much, much better. From the Fastmail docs[1]: > 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@myd…
Oh neat! Now this needs to be in the native iOS Mail client.
Re: Show HN: Heimdall – Self-managed email alias/forwarding service
#27This is a really cool project, so I don't mean to be overly negative, but personally this workflow feels quite a bit more laborious than just having a catch-all email address. Before signing up for a service, I need to email myself to get an address to use for the service? 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 se…
Set a dns record for catch-all
Re: Show HN: Heimdall – Self-managed email alias/forwarding service
#28> Known Limitations
> 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?
Re: Show HN: Heimdall – Self-managed email alias/forwarding service
#29> With Heimdall, you completely own and manage your data and the service. No feature limitations or having to trust a third-party company with your data. > 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?
Unless you physically own a server you have to put your data somewhere, whether that somewhere is Digital Ocean, some shared hosting provider, AWS, or whatever else. You're still more in control of your data than you would be using a closed third-party product. 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…
> Unless you physically own a server you have to put your data somewhere, whether that somewhere is Digital Ocean, some shared hosting provider, AWS, or whatever else. You're still more in control of your data than you would be using a closed third-party product.
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?
Re: Show HN: Heimdall – Self-managed email alias/forwarding service
#30> Known Limitations > 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?
Right now, silently dropped.
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.