Show HN: Heimdall – Self-managed email alias/forwarding service
1–10 of 54 posts
Re: Show HN: Heimdall – Self-managed email alias/forwarding service
#2nice job.
Re: Show HN: Heimdall – Self-managed email alias/forwarding service
#3You might consider using a different name, as there’s already a pretty popular dashboard called Heimdall [1]
Re: Show HN: Heimdall – Self-managed email alias/forwarding service
#4> 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?
Re: Show HN: Heimdall – Self-managed email alias/forwarding service
#5You might consider using a different name, as there’s already a pretty popular dashboard called Heimdall [1] [1] https://github.com/linuxserver/Heimdall
My mind went to the Kerberos implementation, despite the slight spelling difference: https://github.com/heimdal/heimdal
Re: Show HN: Heimdall – Self-managed email alias/forwarding service
#6> 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 data stored on AWS could be encrypted by the app, in which case you're really not trusting AWS.
Re: Show HN: Heimdall – Self-managed email alias/forwarding service
#7I’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.
Re: Show HN: Heimdall – Self-managed email alias/forwarding service
#8I wrote and use a web service called Tamarind for managing throw-away mail aliases:
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.
Re: Show HN: Heimdall – Self-managed email alias/forwarding service
#9> 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…
My charitable reading of GP's comment is as a reaction to the fact that the project's been designed in such a way (Serverless :tm:) that AWS is required; a pre-requisite, not an example.
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.
Re: Show HN: Heimdall – Self-managed email alias/forwarding service
#10This 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 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