[HN Gopher] Show HN: Heimdall - Self-managed email alias/forward...
___________________________________________________________________
Show HN: Heimdall - Self-managed email alias/forwarding service
Author : fterh
Score : 77 points
Date : 2020-02-01 14:58 UTC (8 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| kazinator wrote:
| I 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.
| mmcclure wrote:
| 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
| NicoJuicy wrote:
| Set a dns record for catch-all
| mekster wrote:
| For groups of people, you can also do,
|
| [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.
| caymanjim wrote:
| 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 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.
| moonlighter wrote:
| 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).
| mmcclure wrote:
| 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.
| btmiller wrote:
| 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...
| mmcclure wrote:
| 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
| btmiller wrote:
| Oh neat! Now this needs to be in the native iOS Mail
| client.
| albertgoeswoof wrote:
| And if you don't want to host this yourself there's
| https://IdBloc.co
| thatha7777 wrote:
| 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.
| andrewkdinh wrote:
| You might consider using a different name, as there's already a
| pretty popular dashboard called Heimdall [1]
|
| [1] https://github.com/linuxserver/Heimdall
| honopu wrote:
| There's also a db proxy you can run yourself that sits in front
| of Postgres and maybe others also named Heimdall. It's like
| varnish for your db.
| Lammy wrote:
| My mind went to the Kerberos implementation, despite the slight
| spelling difference: https://github.com/heimdal/heimdal
| milankragujevic wrote:
| There is also the tool for flashing Samsung Android phone
| firmware on Linux...
|
| https://gitlab.com/BenjaminDobell/Heimdall
| zAy0LfpBZLC8mAC wrote:
| > 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 wrote:
| 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.
| OJFord wrote:
| 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.
| zAy0LfpBZLC8mAC wrote:
| > 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?
| jedberg wrote:
| > _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?
| christefano wrote:
| FYI, the developer has a writeup about the design behind this
| project: https://medium.com/@fabianterh/how-i-built-heimdall-an-
| open-...
|
| 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 wrote:
| > 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 wrote:
| thank you
| johnebgd wrote:
| 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 wrote:
| Providers usually don't give you (unlimited number of) aliases.
| JohnsonY wrote:
| nice job.
| rodneyg_ wrote:
| I love you. Thanks for this
___________________________________________________________________
(page generated 2020-02-01 23:00 UTC)