> <i>Known Limitations</i><p>> Currently, attachments are not supported.<p>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?<p>From reading the code it seems like it just doesn't include the attachment and then deletes it from S3?
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?<p>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.<p>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: <a href="https://www.fastmail.com/help/receive/alias-catchall.html" rel="nofollow">https://www.fastmail.com/help/receive/alias-catchall.html</a>
FYI, the developer has a writeup about the design behind this project: <a href="https://medium.com/@fabianterh/how-i-built-heimdall-an-open-source-personal-email-guardian-68e306d172d1" rel="nofollow">https://medium.com/@fabianterh/how-i-built-heimdall-an-open-...</a><p>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:<p><pre><code> 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.</code></pre>
I wrote and use a web service called Tamarind for managing throw-away mail aliases:<p><a href="http://www.kylheku.com/cgit/tamarind/tree/README" rel="nofollow">http://www.kylheku.com/cgit/tamarind/tree/README</a><p>It integrates into Apache as a CGI program serving up a web UI for managing your aliases.<p>It works by managing the content of an alias file read by your mail server.<p>Authentication of the webUI is via IMAP or SASL.<p>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.
You might consider using a different name, as there’s already a pretty popular dashboard called Heimdall [1]<p>[1] <a href="https://github.com/linuxserver/Heimdall" rel="nofollow">https://github.com/linuxserver/Heimdall</a>
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.<p>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?<p>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.
> 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.<p>> 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).<p>Erm ... wut?