
Show HN: Heimdall – Self-managed email alias/forwarding service - fterh
https://github.com/fterh/heimdall
======
jedberg
> _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?

~~~
fterh
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.

~~~
thedance
This statement is pretty vague. Exactly what is not supported? Virtually all
email is in multipart mime format.

------
thatha7777
Self-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.

~~~
fterh
I was born in the 90s so I'm not familiar with the "dream of the 90s" haha -
care to explain?

~~~
mhluongo
We don't run our own infrastructure anymore :(

~~~
Keverw
Yeah and seems like the big providers don't like self hosted emails. I know
someone who runs a hosting company using cPanel and his clients email go to
spam a bunch even though not spammy emails, his answer is to just pay extra
for Google Apps and that running a email server is too complicated. Not sure
how true that is... For my own future projects I plan to run everything in
containers, Node, etc so not PHP/MySQL so still need to host the email
somewhere, kinda hate the idea of paying a third party and wonder how they
would handle shared inboxes(like piping email to a script like you can with a
cPanel server). Probably other email solutions though to look into though but
haven't looked into it too much yet but kinda hate how we have to rely on
large providers it seems for email.

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.

~~~
technion
Hosting company cPanel servers are a bit of a special case though. I've run
these before and once customers start installing WordPress it can be a matter
of hours before a bad plugin gets turned into a spam bot. It's at a point
where blocking port 25 outbound is a responsibility imo.

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.

~~~
Keverw
Yep, contact forms in WordPress but even non WordPress sites too. Then of
course if you got a plugin to detect brute forces, seem like WordPress sites
get ton of them! Probably because you can detect if a site runs WordPress or
not, so bots use that.

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.

------
mmcclure
This 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](https://www.fastmail.com/help/receive/alias-catchall.html)

~~~
btmiller
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 me@mydomain.com
unless I go manually setup the airbnb alias.

[1] [https://btmiller.com/2019/12/12/regain-control-over-your-
inb...](https://btmiller.com/2019/12/12/regain-control-over-your-inbox-by-
rejecting-email-with-a-custom-domain-wildcard-and-aliases.html)

~~~
mmcclure
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](https://www.fastmail.com/help/receive/alias-catchall.html)

~~~
btmiller
Oh neat! Now this needs to be in the native iOS Mail client.

------
christefano
FYI, the developer has a writeup about the design behind this project:
[https://medium.com/@fabianterh/how-i-built-heimdall-an-
open-...](https://medium.com/@fabianterh/how-i-built-heimdall-an-open-source-
personal-email-guardian-68e306d172d1)

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.

~~~
airstrike
> 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.

~~~
daseiner1
thank you

------
kazinator
I wrote and use a web service called Tamarind for managing throw-away mail
aliases:

[http://www.kylheku.com/cgit/tamarind/tree/README](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.

~~~
wrboyce
Not sure how this is relevant to OP’s post aside as an attempted hijack. You
don’t even address the differences between the product you’re pushing and
OP’s.

If you want to Show HN something, make your own post; this is just rude.

------
andrewkdinh
You might consider using a different name, as there’s already a pretty popular
dashboard called Heimdall [1]

[1]
[https://github.com/linuxserver/Heimdall](https://github.com/linuxserver/Heimdall)

~~~
Lammy
My mind went to the Kerberos implementation, despite the slight spelling
difference:
[https://github.com/heimdal/heimdal](https://github.com/heimdal/heimdal)

------
VvR-Ox
I like the idea but I do not understand why someone would want something self-
managed/hosted and then use AMZN SES to send/receive mail and S3 to save
mail/attachments.

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.

------
rodneyg_
I love you. Thanks for this

------
whatsmyusername
This service is offered by most domain registrars out of the box.

------
albertgoeswoof
And if you don’t want to host this yourself there’s
[https://IdBloc.co](https://IdBloc.co)

------
johnebgd
I’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.

~~~
sm4rk0
Providers usually don't give you (unlimited number of) aliases.

~~~
whatsmyusername
If all you want to do is forward all mail for a domain somewhere you can
easily do that at most domain registrars. I use this with Monicker.

------
zAy0LfpBZLC8mAC
> 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?

~~~
justusthane
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.

~~~
zAy0LfpBZLC8mAC
> 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?

~~~
fterh
No, you're not misunderstanding. I guess I made that statement with the
implicit trust of AWS so I didn't think to qualify it.

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.

~~~
zAy0LfpBZLC8mAC
> No, you're not misunderstanding. I guess I made that statement with the
> implicit trust of AWS so I didn't think to qualify it.

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.

